Thread Links Date Links
Thread Prev Thread Next Thread Index Date Prev Date Next Date Index

Re: [8023-CMSG] Fw: [802.1] Slides for per-priority flow control



Hugo
From what you have written, it appears that we have an agreement on the
need for "per flow" mechanism in the definition of the CM standard.
The open issue is the definition of a flow.
Your interpretation of VLAN use, is very specific, however, in the field
there are other usages. Specifically with Cisco equipment, that in the
past have used VLAN, to define a CoS in a metro application.
However, I'm not intending to presume that I know all the application
that are out there. I think none of us should.
I believe we should be providing the out most tools for handling CM, for
all the switch / router engineers out there, in the reasoning of the
standards 5 criteria we need to go along with.
VLAN - I have come across several MDU / MTU implementation, where a VLAN
has represented a user, and in some cases a CoS.
That is why I thought that in a L2 application VLAN can define a flow.
As you mentioned, ideally we should have defined a flow to be the MAC
address, but that would fail the 5 criteria required for making CM a
task force.
Maybe one day when 65nano process will be as low cost as 0.18 will
reconvene to enhance the standard even more.

Thanks

Gadi


-----Original Message-----
From: Hugh Barrass [mailto:hbarrass@cisco.com]
Sent: Wednesday, July 21, 2004 18:04
To: Gadi Lahat
Cc: STDS-802-3-CM@listserv.ieee.org
Subject: Re: [8023-CMSG] Fw: [802.1] Slides for per-priority flow
control

Gadi,

I don't understand the logic of making PAUSE per VLAN. VLANs were
defined to restrict the broadcast domains so that devices that don't
usually communicate with each other appear to be on different networks
(hence Virtual LAN). There is no "flow" information implied in a VLAN
tag - it should be expected that a VLAN could be just as meshed as any
other LAN. A per-VLAN PAUSE would suffer from exactly the same problems
that the current PAUSE suffers within the confines of the virtual LAN.
If your goal is to push the PAUSE back to the source of the traffic then
(in layer 2 terms) per source MAC address would be more logical. To
fully support this mechanism a network switch would have to support 2^48
queues per port - although practical implementations seem to be at
16,000 or more MAC addresses therefore 800,000 queues would be
sufficient for a 50 port network switch.

Such requirements would surely raise the complexity and cost of network
switch devices significantly. More expensive switches would only benefit
a very small section of society :-)

In short, any change to backpressure that does not include a "per-flow"
mechanism is essentially the same as we have. Any attempt at "per-flow"
backpressure will suffer from scaleability problems (and will work very
poorly on highly meshed systems).

Hugh.

Gadi Lahat wrote:

>Muneyoshi,
>Is your suggestion looks at making the priority field valid for the
>pause frame ?
>+ Has anyone raised the option of making the pause per VLAN ? (VLAN
>queuing )
>
>
>
>
>
>
>