Re: [8023-CMSG] Proposed Upper Layer Compatibility Objective
Jonathan,
Excellent points! I would contend there are various feasible and
practical solutions between the extremes that need to be evaluated for
L2 subnets that fall within the limits of the space for which we are
attempting to support congestion management. At least some need to be
subjected to cost vs. value analysis wrt this context before concluding
there is no practical solution.
Gary
-----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: Friday, May 21, 2004 8:47 AM
To: STDS-802-3-CM@listserv.ieee.org
Subject: Re: [8023-CMSG] Proposed Upper Layer Compatibility Objective
I have to agree with Hugh that the only sure way to make a truly
efficient control mechanism is for all queues to be aware of the state
of all downstream queues in the network/fabric.
This never has and (if extended to include the queues at the source and
destination) never will be practical. The amount of state information
shared would exceed the traffic itself; the latencies would be absurd
for a network of any size.
On the other hand, I also agree that dropping packets is a equally
impractical means of sharing queue state information.
These two methods represent opposite extremes in the solution space. I
was taught in Physics 101 that we identify extrema for the purpose of
understanding the boundaries, not for the purpose of finding an optimal
solution.
So, on one side we have the Right-to-Share position, on the other, the
Pro-drop. Surly, within the infinite number of options between these
extremes, there is a more optimal and practical choice.
jonathan
-----Original Message-----
From: owner-stds-802-3-cm@LISTSERV.IEEE.ORG
[mailto:owner-stds-802-3-cm@LISTSERV.IEEE.ORG]On Behalf Of Hugh Barrass
Sent: Friday, May 21, 2004 7:08 AM
To: STDS-802-3-CM@LISTSERV.IEEE.ORG
Subject: Re: [8023-CMSG] Proposed Upper Layer Compatibility Objective
David,
My example was considering frames that have the same priority. Adding
priority to the mix simply multiplies the problem by the number of
priority levels.
Hugh.
David Martin wrote:
Hugh,
For sake of discussion, if you take as a given that all bridges have 8
output queues per port, where frames are classified based on CoS (MEF
terminology) aka user_priority (802.1 terminology), then if a downstream
bridge could send a Pause_CoS_n (where n=0..7) backwards / upstream,
wouldn't that alleviate the scalability issue you mentioned?
In arithmetic terms, Device 1 would need 8*P queues, where P is the
number of ports it has.
Doesn't the scalability issue you mentioned only arise when different
bridges use different output queue classification approaches? Then I
could imagine a squared-type of relationship.
Just trying to follow the line of reasoning here.
Thanks.
...Dave
David W. Martin
Nortel Networks
dwmartin@ieee.org
+1 613 765-2901 (esn 395)
~~~~~~~~~~~~~~~~~~~~
-----Original Message-----
From: Hugh Barrass [mailto:hbarrass@CISCO.COM]
Sent: Thursday, May 20, 2004 9:23 AM
To: STDS-802-3-CM@listserv.ieee.org
Subject: Re: [8023-CMSG] Proposed Upper Layer Compatibility Objective
Brad,
I've answered below:
Booth, Bradley wrote:
>Hugh,
>
>I want to lock in on one paragraph you mentioned. It is listed below:
>
>"The only use of PAUSE that would (might) work would be if device 2
>could
>signal to device 1 that only frames destined for port K should be
>paused. This would require that device 1 must understand how device 2
is
>going to classify and direct the traffic and device 1 must maintain
>separate queues on its output port corresponding to the output ports of
>device 2. This means that device 1 will wind up with a total number of
>queues equal to the sum of all the queues on all of the devices
>connected to it. Scaling for more than 2 devices is left as an exercise
>for the reader."
>
>You said that this would require device 1 to understand how device 2
>classify and directs traffic. When you say that are you referring to
>the 802.3 portion of device 1? If you are, then I would agree that we
>have an issue of adding "intelligence" to the 802.3 MAC. If not, would
>not 802.1 know how to classify this traffic? Maybe this has to do with
>the definition of port, priority and queue. It might help if you could
>explain your use of the terminology to a layman.
>
>
>
If device 2 wants to send a message that says, "pause the traffic that
will be directed to my output queue K" then device 1 must understand the
criteria that device 2 will use to forward traffic to its output K. That
may be MAC address, that may be IP address, or something else entirely.
Note that the "output queues" of device 2 may be physical ports, virtual
ports or even s/w queues for an edge device.
Hugh.