Re: [8023-CMSG] Fw: [802.1] Slides for per-priority flow control
For what it's worth, the discussion at last week's meetings made it very clear that "per flow" mechanisms were the realm of 802.1 and not 802.3. For this work to go forward in 802.3, it must consider only the link (ie the realm of 802.3). This is not to say, however, that the "per flow" discussion should not be taking place in 802.1.
--jc
> -----Original Message-----
> From: owner-stds-802-3-cm@listserv.ieee.org
> [mailto:owner-stds-802-3-cm@listserv.ieee.org]On Behalf Of Matt Squire
> Sent: Wednesday, July 21, 2004 10:02 AM
> To: STDS-802-3-CM@listserv.ieee.org
> Subject: Re: [8023-CMSG] Fw: [802.1] Slides for per-priority flow
> control
>
>
> I can't speak for Hugo (nor do I know who Hugo is, though I
> do know a Hugh), but I wouldn't jump to the conclusion that
> there is agreement on the need for "per flow" mechanisms in
> any 802.3 standard. This argument isn't about Cisco
> equipment. VLANs are not CoS markings - period. Equipment
> does not work that way, Cisco or anyone else. Its just
> wrong, broken, and otherwise bad. Such an interpretation
> violates standards and breaks networks.
>
> PAUSE, whether it be "per link", "per VLAN", or "per
> anything", causes bad things to happen in networks.
>
> - Matt
>
>
>
> > -----Original Message-----
> > From: owner-stds-802-3-cm@listserv.ieee.org
> > [mailto:owner-stds-802-3-cm@listserv.ieee.org]On Behalf Of
> Gadi Lahat
> > Sent: Wednesday, July 21, 2004 11:23 AM
> > To: STDS-802-3-CM@listserv.ieee.org
> > Subject: 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 )
> > >
> > >
> > >
> > >
> > >
> > >
> > >
> >
>