| 
 Jeff, 
  
I am 
perfectly fine with NOT having such an objective if you think we can get 
away with it. I'm not sure we can ignore how, what we propose to do at L2, will 
affect the operation of the upper layers. 
  
On the 
subject of DiffServ, I would simply propose that, within the limited scope of 
the high speed, short range, L2 interconnects we are trying to enhance, we leave 
the discard decisions up to the upper layers while maintaining the desired 
latency and traffic differentiation qualities within layer 2. We have shown 
through simulations that layer 2 rate control mechanisms can eliminate (or 
significantly reduce frame) discards within layer 2 (effectively pushing the 
discard decision up to L3). We have also shown that rate control combined with 
prioritization in layer 2 can maintain excellent latency and traffic 
differentiation qualities.  
  
Maybe 
you can explain to us how this is likely to affect the operation of DiffServ. I 
haven't dug deep enough into DiffServ to know if it is counting on L2 devices to 
discard. My intuition is telling me it is likely to improve the operation of 
DiffServ, as well as other upper layer protocols of 
interest. 
  
Gary 
  
  
  
  
 -----Original Message----- From: 
owner-stds-802-3-cm@LISTSERV.IEEE.ORG 
[mailto:owner-stds-802-3-cm@LISTSERV.IEEE.ORG] On Behalf Of Jeff 
Warren Sent: Wednesday, May 12, 2004 7:58 PM To: 
STDS-802-3-CM@LISTSERV.IEEE.ORG Subject: Re: [8023-CMSG] Proposed 
Upper Layer Compatibility Objective
 
  
  Gary, 
    
  You mentioned improved operation of DiffServ as a 
  goal for CM. DS is a collection of a number of RFC's, here's the basic 
  set of DS RFCs.   
  
  
    - 
    
RFC2474 "Definition of the Differentiated Services Field (DS Field) 
    in the IPv4 and IPv6 Headers" 
     - 
    
RFC2475 "An Architecture for Differentiated 
    Services" 
     - 
    
RFC2597 "Assured Forwarding PHB" 
     - 
    
RFC2598 "An Expedited Forwarding 
  PHB"    
  What 
  did you have in mind for supporting ULP's such as DS? For example this L3 
  protocol's purpose in life is to decide drop probabilities for individual 
  packets on a hop-by-hop basis. For example assured forwarding has three levels 
  of drop precedence (red, yellow, green). Then there's expedited forwarding in 
  the highest priority queue, plus best effort, etc...... 
    
  I've 
  been wondering how an "Ethernet" standard is going to assist a L3 protocol 
  such as DS by classification MAC traffic? Would you propose 
  duplication of or cooperation with DS protocols? Maybe you let DS do its 
  thing and present a CM enabled Ethernet egress port with remarked packets 
  that are fortunate enough to have passed across the devices fabric w/o 
  being dropped. This CM enabled Ethernet port would then align the 
  offered MAC load to the queues it has available, it does this for example 
  by inspecting DSCP values and comparing these DSCP values to a predefined 
  buffer table. Bla bla bla......   
    
  The 
  lights haven't gone off for me yet, I don't see the value in CM supporting DS 
  because switch manufactures have already figured this one out and 
  implemented this concept of multiple egress queues working at line rate. 
  Plus these implementations require global knowledge of networking policies to 
  configure them properly, and more importantly to standardize them were 
  talking about linking behavior of ingress and egress ports, knowledge of 
  system wide (e.g. switch or router) buffer management capabilities, all very 
  much vendor specific capabilities that would be very difficult to get everyone 
  to agree to.   
    
  Regards, 
    
     - Jeff Warren      
    
    
     
  
    ----- Original Message -----  
    
    
    Sent: Wednesday, May 12, 2004 5:44 
    PM 
    Subject: [8023-CMSG] Proposed Upper 
    Layer Compatibility Objective 
    
  
    My A.R. from last meeting (thank you Ben). 
     
    Here's a first shot at a Upper Layer 
    Compatibility objective:  
    The objective is:  "To 
    define 802.3 congestion control support that, at a minimum, will do nothing 
    to degrade the operation of existing upper layer protocols and 
    flow/congestion control mechanisms, but has the explicit goal 
    of facilitating the improved operation of some existing and emerging 
    protocols, over 802.3 full-duplex link technology."
  If we can narrow the scope and still make it meaningful, 
    I'm all for it.  
    I have attached RFC3168 (on ECN) as a reference. 
    It contains a very good overview of congestion control at the TCP and IP 
    layers. I would also consider this and DiffServ as examples of existing ULPs 
    we would want to do our part to improve the operation of. IMO, what we can 
    do at the 802.3 level to better support these will also provide the support 
    we need for improved operation of some emerging protocols such as iSCSI and 
    RDMA. 
    Gary 
    <<rfc3168.txt>> 
   
  |