Subject: Layer 3 vs layer 2 for delay guarantees ?

From: [email-masked] (SanJeev Rampal)
Date: Wed, 3 Jan 1996 12:59:55 -0500 (EST)

Hello all!                                                                     
                                                                                
 An issue which that we would like some clarification on                        
 is that of the interaction between layer 3 and layer 2 in                      
 determining end-to-end delay bounds.                                           
                                                                                
 The Guaranteed Service specification seems to                                  
 suggest that a scheduling mechanism that guarantees rates on a per             
 connection basis (e.g. WFQ) will be implemented at layer 3.                    
 The main b/R component of the Guaranteed Service delay bound comes from        
 this rate allocation. The deviation from the fluid model is accounted          
 for by the C_tot term and the fixed/processing delay components by             
 the D_tot term.  So, C appears to be related to layer 3 delays (e.g.           
 effect of layer 3 MTU), and D must account for delays incurred at              
 layer 2.                                                                       
                                                                                
 In what scenario, then, will a session actually see the b/R delay at layer 3?  
 Assume a WFQ server at layer 3. The ``service rate'' of the                    
 ``link'' from layer 3 to layer 2 really depends on the packet processing       
 rate (e.g. memory accesses in the router, AAL5 SAR, IP header processing       
 etc) of the router which can be much greater than the link                     
 bandwidth.  If, for the sake of argument, we assume that the layer 3           
 packet processing rate is infinitely greater than the link rate                
 (for eg. if there is only one packet at layer 3 at some instant, and no        
 other resources in the router are being contended for (e.g. bus, memory etc),  
 then this packet can be delivered to layer 2 in an amount of time which        
 will be much smaller than its transmission time on the link),                  
 we will very small delays at layer 3 regardless of the rate `R' assigned       
 to the session, (in which case there is no need for any scheduling,            
 other than simple FIFO, at layer 3).                                           
                                                                                
 Are the specs suggesting that the rate scheduler at layer 3 is                 
 needed in order to optimize on the layer 3 processing delays?  If so, how      
 do we quantify the total processing rate at layer 3                            
 (since we will need to check that the sum of the rates assigned to             
 each session must be no more than the total processing rate)?                  
 If on the other hand, we want to differentiate the network queueing            
 delay (i.e. the delay in accessing the link) of the different sessions,        
 how does rate scheduling at layer 3 help?  The actual queuing will occur       
 at layer 2 where we must assume there                                          
 is no rate scheduling and hence no way of differentiating between sessions ... 
                                                                                
 One possible way that a session will actually see a b/R delay is to implement  
 a queueing spacer operating at rate `R' at layer 3 and have one such           
 spacer for each individual session.                                            
 A disadvantage of this is that even when no other session is active, a session 
 will be served only at rate `R'. However, this may not really be               
 a problem since call admission is anyway based on the worst case               
 delay bound which is unaltered even with this technique.                       
 Further, no complex scheduling (WFQ etc)                                       
 is needed at layer 3; simply serve each session individually at a              
 deterministic rate `R'.                                                        
                                                                                
 In summary,                                                                    
                                                                                
         (a) What is the layer 3 scheduling seeking to optimize? Layer 3        
         delays?  Or layer 2 delays?  If it is the latter, then it seems        
         like the rate scheduler is in the wrong place..                        
                                                                                
         (b) Can the same result not be achieved using a deterministic rate     
         enforcement such as a simple queueing spacer for each                  
         session at layer 3?                                                    
                                                                                
 Your comments and clarifications would be most appreciated.                    
                                                                                
 Sanjeev Rampal                                                                 
 Vijay Srinivasan                                                               
 Networking Architecture                                                        
 IBM, RTP

---

From: Craig Partridge <[email-masked]>
Date: Wed, 03 Jan 96 10:57:45 -0800

Not quite.  The documents talk in terms of "service elements" where the
layer 2 network is one service element and a layer 3 device is another
service element.

What this translate to, in a real router, is that the router is responsible
for both its own scheduling, and for computing the behavior of the links.
I think this answers your question about router rate vs. line rate.  If
the line rate is < R, the reservation will be refused.

It isn't layer 3 scheduling -- it is how layer 3 model itself and layer 2. 
So it managers both layer 2 and layer 3  (which both have to be managed).

Rate enforcement alone is pretty inefficient.  So it is desirable to have
a more flexible model, so people willing to implement more effective
queueing schemes are free to do so.

Craig