|
Hi Gary,
I agree we can't ignore "How does what we do
at L2 impact UPL". Yikes - there are many ULP's, not just DS.
I agree that "We leave the discard decisions
up to the UPL".
I can't tell you exactly how CM will impact DS
until I know what CM does? I am consulting with one of the original DS
authors, Steve Blake, he and I use to work together a few companies ago
when we were both at IBM, this was when DS was standardized. We discussed
this point this morning and the general feeling was that a FDX point-to-point
(PTP) L2 Ethernet link should not be making implicit or explicit selective
packet drop decisions, that this would in a negative way impact the operation of
DS.
If what CM does is to channelize traffic
across a PTP link (high or low BW, short or long distance, inside a chassis
across an Ethernet backplane or externally across a physical copper or optical
link) into 'N' number of Classes (CoS transmission buffers) then when one Class
is "some how" determined to be using too much BW and that Class is "Turned OFF"
for some period of time there is a high likelihood that packets in that Class
will be dropped. When this happens you've just impacted DS ability to do its
drop probability calculations properly........... more to come on this as we
better understand what CM does.
NOTE: 802.1p has already defined a L2 "marker" that
is used as a form of L2 rate control. 802.1p is used by intermediate
L2 switches (between router hops; DS Hops) to provide intermediate L2
class of service prioritization. Most switch/router products that are worth
purchasing use this feature along with DSCP (L3) to prioritize traffic across
their available ingress & egress ports.
Regards,
- Jeff
----- Original Message -----
Sent: Thursday, May 13, 2004 11:48
AM
Subject: Re: [8023-CMSG] Proposed Upper
Layer Compatibility Objective
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>>
|