| Thread Links | Date Links | ||||
|---|---|---|---|---|---|
| Thread Prev | Thread Next | Thread Index | Date Prev | Date Next | Date Index |
|
All,
A few
thoughts.
In the
local (backplane or computer room) environment, the latency is small
enough
that
congested traffic doesn't have to be dropped--feedback to the sources can
stiffle
the
traffic to supportable rates. As such, I'm not very interested in using
priorities
to
determine the drop rate: if one cares, this should be zero in the local
interconnect.
However, rate restrictions _do_ depend on what type of
traffic is being sent.
I tend
to like the simplistic p802.17 model for classes of service:
A (TDM like, telephony),
B (longer latencies, but BW still guaranteed)
C (best effort)
For
the classA, there should be no restrictions on bandwidth, as devices
should
only
use what was prenegotiated.
For
the classB and classC, things get more interesting.
From
the perspective of a PAUSE, the generalization to support a
level-based
PAUSE is more important than a
send-this-amount-of-bandwidth parameter.
Instead,
a pause-everything-less-than-this-priority feature would seem to be
more
valuable.
DVJ
David V. James
3180 South Ct Palo Alto, CA 94306 Home: +1.650.494.0926 +1.650.856.9801 Cell: +1.650.954.6906 Fax: +1.360.242.5508 Base: dvj@alum.mit.edu Brad, If you step back & think about it - what PAUSE does is reduced the net bandwidth used on a link. If the devices at both ends of the link were smart, they would somehow negotiate what that net rate should be (so that the output of one drains at a rate that doesn't mess up the input of the other). Making this work using an XOFF/XON mechanism operating across an (potentially very long) link is far from optimal. Perhaps there is scope to change the PAUSE definition to say "send me no more than X % of bandwidth on this link." From the perspective of a higher layer, setting the effective width of a pipe should be perfectly acceptable; other changes that increase the "intelligence" of the MAC layer would require much more scrutiny. Hugh. Booth, Bradley wrote: JT, I got the answer I needed, which is that there is a base assumption that an 802.1 layer needs to exist above the 802.3 MAC if there is going to be any use of priorities. It was the interaction between the MAC's queues and 802.1 queues that I didn't understand as I spend most of my time at the physical layer. I'm still mulling over the statement by Matt that PAUSE makes a bigger pipe into a smaller pipe. Over a long period of time and if it was implemented correctly, I could understand that analogy. The trouble I'm having with that statement is that it seems to me that PAUSE is performed because of back pressure from upper layers (memory has passed a watermark). If upper layers can handle QoS/CoS, then surely they'd be able to handle making a big pipe run like a small pipe. If they cannot, then it seems that PAUSE would want some finer granularity rather than XON/XOFF. Thanks, Brad -----Original Message----- From: owner-stds-802-3-cm@listserv.ieee.org [mailto:owner-stds-802-3-cm@listserv.ieee.org] On Behalf Of Jonathan Thatcher Sent: Monday, May 17, 2004 8:49 AM To: STDS-802-3-CM@listserv.ieee.org Subject: Re: [8023-CMSG] Questions Brad, The way you choose to ask the question sends the response in a particular direction that you may, or may not be intending. If I were to ask you if 10GBASE-T knows how to forward packets from the MAC-Client interface one could respond in two different ways where both, depending on perspective, are technically correct: 1. 10GBASE-T does not know anything about the MAC-Client interface as that is exposed only in layers above 10GBASE-T. 2. Of course it does. By definition, 10GBASE-T references the upper layers. These are, therefore, explicitly included in the 10GBASE-T specification. Now someone might argue with each of these. For instance, the argument to the second might be, "you don't understand, the MAC is common across multiple port types." This argument is true, but misses the point. The fact is, that is the beauty of the layered architecture. Ethernet is not just the PMD. Ethernet is the PMD and all layers above the PMD that provide a complete solution, whether those layers are shared or not. Just because 802.1 is shared with other 802 "dots" does not mean that when it is integrated with Ethernet that it isn't part of Ethernet. Some in 802.1 would argue that all of 802.1 is part of the MAC. 802.1 is part of Layer 2. 802.1 is part of an Ethernet solution. There are any number of ways that you could modify your question to get opposite responses. Example: Is it understood or implied that 802.3 knows how to direct to and from multiple queues? Answer: Absolutely. See EPON. But, even without EPON, MAC-Control knows how to deal with packets to/from control and data queues. Etc. My response to 1) would therefore be: 802.1 knows. Therefore, by definition Ethernet knows.** jonathan ** Exception: if there is no 802.1, then there are no queues and Ethernet doesn't know because there is nothing to know. In this case, the question is moot. :-)-----Original Message----- From: owner-stds-802-3-cm@LISTSERV.IEEE.ORG [mailto:owner-stds-802-3-cm@LISTSERV.IEEE.ORG]On Behalf Of Booth, Bradley Sent: Sunday, May 16, 2004 6:50 PM To: STDS-802-3-CM@LISTSERV.IEEE.ORG Subject: Re: [8023-CMSG] Questions Norm, Thanks for the response. Two follow-up questions: 1) Is it understood or implied that Ethernet knows how to direct frames to and from these 8 queues? 2) What if the device does not use a bridge as in an adapter? Thanks, Brad -----Original Message----- From: owner-stds-802-3-cm@LISTSERV.IEEE.ORG [mailto:owner-stds-802-3-cm@LISTSERV.IEEE.ORG] On Behalf Of Norman Finn Sent: Sunday, May 16, 2004 11:11 AM To: STDS-802-3-CM@LISTSERV.IEEE.ORG Subject: Re: [8023-CMSG] Questions Brad, I think you did miss the mark, particularly with: "Considering that Ethernet doesn't know in advance about the provisioning of the network and does not care about which packets it delays or drops, then it is likely that 802.1 and the upper layers can do all the priorities or differentiated services that they want but will see diminishing returns as the load on the network increases." I would agree with, "Ethernet doesn't know in advance about the provisioning of the network", but 802.1D bridges certainly do care about which frames are delayed or dropped. Bridges define the use of 8 queues per output port, and frames are marked with 8 levels of priority. Although strict priority scheduling is the only queue draining algorithm specified in the standard, others are explicitly allowed, and most vendors implement varieties that provide very good latency and bandwidth guarantees. Furthermore, a great many bridges are able to assign priorities to 802.3 frames based on criteria such as IP DSCP code points. In short, ethernet is *far* from "best effort". -- Norm Booth, Bradley wrote: |