Jeff,
Let me see if I understand what you're trying to say. Differentiated
Services (DiffServ - DS), as an example upper layer protocol (ULP),
applies DS code points (DSCPs) to its traffic. These DSCPs are a
tag that classify different types of traffic. Since ULPs see layer 2 as
a simple pipe, it neither expects nor desires any kind of support for
these various DSCPs. In other words, if congestion occurs and packets
must be dropped in the layer 2 "pipe" it would make no difference to
DS what kind of traffic was dropped. It could be done totally randomly.
However, should the layer 2 provide some level of support, it would
be advantageous to DS if there was some type of mapping between
DSCPs and layer 2 priority tags. These priority tags could then be
used to separate the traffic into priority queues. Now, when buffer
congestion occurs and packets must be dropped, the lower priority
packets can be dropped before the higher ones. As long as the
mapping is done right, the packets that DS thinks are the most
important are least likely to be dropped.
Assuming I'm close on the above, why then is it so hard to take this
one more step? If Ethernet can make advances so that the highest
priority traffic is even less likely to drop packets in the face of
congestion,
further aiding DS (and other ULPs) to maintain the traffic flow of the
traffic they think is the most important, why is that bad? Indeed, why
isn't that justification for this project?
The whole approach of creating priorities within 802.1 (P802.1Q)
and now assigning a mapping between DSCPs and 802.1 priorities
so that everybody does it the same (isn't this being done in P802.1ad?)
is considered very worthwhile to most people. It seems to me that
it may be equally worthwhile to extend this further into layer 2 so
that a mechanism exists to communicate, not only within a bridge
but between bridges, when buffer congestion is occurring for these
different priorities so that steps can be taken to preserve the highest
priority traffic.
Thanks,
Ben
Jeff Warren wrote:
Message
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
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>>
--
-----------------------------------------
Benjamin Brown
178 Bear Hill Road
Chichester, NH 03258
603-491-0296 - Cell
603-798-4115 - Office
benjamin-dot-brown-at-ieee-dot-org
(Will this cut down on my spam???)
-----------------------------------------
|