Re: [8023-CMSG] Proposed Upper Layer Compatibility Objective

[Jonathan Thatcher <jonathan.thatcher@xxxxxxxx>]

Title:

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.