Re: [8023-CMSG] Purpose
Jonathan,
> Improving performance is good, but how would one know if this is achieved.
Very good point. This brings even more fundamental question: how do we know
that there is a congestion in the first place. After all, 802.3 scope ends
at MAC service interface. MAC is given one frame at a time, and while
transmitting a frame, at best, it will know that another frame is waiting.
> Except for, perhaps, "Shall provide predictable, consistent network-wide
> operation" :-)
Another related point: what is "network-wide" operation in the context of
802.3? Is it a station-to-station within a single access domain?
> Regarding 802.1 v 802.3, I am working on a presentation on this topic.
> So, in the end, what objectives would you recommend adding?
I would be happy to collaborate on objectives and possible solutions. But I
have difficulty understanding what can be done within 802.3. It would be
more prudent to wait for your presentation explaining why this job should be
done under 802.3 and not 802.1.
Glen
> > Congratulations! Without making any changes to 802.3 you may
> > claim that all
> > the CMSG objectives were already met.
>
> Except for, perhaps, "Shall provide predictable, consistent network-wide
> operation" :-)
>
> Yes, you are correct about my list being primarily about constraints.
>
> Your points are all worthy of study and discussion. Improving performance
> is
> good, but how would one know if this is achieved Implicit in your comment
> is
> that there are aspects of CM that are not defined. I would be surprised if
> any disagree there. One thing that is implicit to me is that unlike PAUSE,
> CM will manage traffic flow to finer granularity than the link.
>
> On your second point, I thought that MPCP avoided specifying the method of
> doing rate control. I would love to see a presentation about how said
> simplification might be useful.
>
> Regarding 802.1 v 802.3, I am working on a presentation on this topic.
>
> So, in the end, what objectives would you recommend adding?
>
> jonathan
>
>
>
> > -----Original Message-----
> > From: owner-stds-802-3-cm@LISTSERV.IEEE.ORG
> > [mailto:owner-stds-802-3-cm@LISTSERV.IEEE.ORG]On Behalf Of Glen Kramer
> > Sent: Thursday, April 29, 2004 3:35 PM
> > To: STDS-802-3-CM@LISTSERV.IEEE.ORG
> > Subject: Re: [8023-CMSG] Purpose
> >
> >
> > Jonathan,
> >
> > Congratulations! Without making any changes to 802.3 you may
> > claim that all
> > the CMSG objectives were already met.
> >
> > Indeed, current 802.3 (with upcoming additions) already
> > supports copper and
> > optical media, 100 Mb/s, 1 Gb/s, and 10 Gb/s rates,
> > consistent with 802
> > architecture, provides predictable operation, and supports
> > OAM. Anything
> > else we should do?
> >
> > Seriously, I think your list of objectives is really just a set of
> > constraints that should be observed. But what this study
> > group wants to
> > achieve? What is missing?
> >
> > I am not certain that QoS should not be an objective. The
> > very reasons to
> > use congestion management are to get better performance than
> > afforded by the
> > best-effort operation. I agree that the term QoS is
> > overloaded. So, let's
> > talk about specific parameters: delay, jitter, frame loss, and may be
> > bandwidth utilization as well. An attention should be given
> > to decoupling of
> > bandwidth and delay. Many time-division systems suffer from this.
> >
> > This group may do some interesting things that would improve
> > performance. I
> > will just list some general ideas and let the group decide if
> > these are the
> > worthy of studying further:
> >
> > 1. PAUSE frame provides ON/OFF control. It is known that such control
> > methods do not easily achieve steady state behavior,
> > especially is control
> > loop delay is high. On the opposite, they tend to amplify traffic
> > oscillation throughout the network, as a result increasing
> > jitter and packet
> > loss. One way to improve the performance is to change the
> > rate control from
> > ON/OFF paradigm to "adjust by delta" paradigm. (Add a new MAC Control
> > message?)
> >
> > 2. 802.3ah P2MP STF introduced Multi-Point Control Protocol
> > that performed
> > explicit rate control for multiple devices. It can be
> > extended (actually
> > simplified) to be used on P2P links.
> >
> >
> > One question that is not completely clear to me is why 802.3
> > and not 802.1?
> >
> > Cheers,
> > Glen
> >
> >
> >
> > > -----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: Thursday, April 29, 2004 3:35 PM
> > > To: STDS-802-3-CM@listserv.ieee.org
> > > Subject: Re: [8023-CMSG] Purpose
> > >
> > > Okay, I'll take a shot at the objectives:
> > >
> > > First, my list of anti-objectives:
> > > -- No support for half-duplex
> > > -- No changes to PCSs / PMAs / PMDs
> > > -- No simultaneous support for PAUSE and CM
> > > -- Not end-to-end flow control (no transaction layer)
> > > -- No traffic classification (e.g. looking at L3/L4/L5...)***
> > > -- No reordering within class (e.g. by priority within class)
> > > -- Not QoS****
> > >
> > > Objectives:
> > > -- Shall support up to 100 m of media (copper or optical)*****
> > > -- Shall support 100 Mb/s, 1 Gb/s, and 10 Gb/s
> > > -- Shall be consistent with IEEE 802.3 and IEEE 802.1 layer
> > architecture
> > > -- Shall provide predictable, consistent network-wide operation
> > > -- Shall be consistent with slow protocols (e.g. OAM)
> > >
> > > Questions:
> > > -- Maximum supported latency across link (MAC to MAC)?
> > > -- Support of FEC?
> > >
> > > *** this does not mean that there isn't some traffic class
> > identifier
> > > provided by L2 and used within L2. It means that L2 does
> > not classify the
> > > flow and associate it with the identifier.
> > > **** QoS is an ambiguous, overloaded term. In most cases,
> > it is associated
> > > with a contract with a user rather than a feature or
> > function provided to
> > > a
> > > higher layer. Frequently it includes policies, shaping,
> > rate limits, etc.
> > > Congestion management has little to nothing to do with this.
> > > ***** not necessarily all media!
> > >
> > > > -----Original Message-----
> > > > From: owner-stds-802-3-cm@listserv.ieee.org
> > > > [mailto:owner-stds-802-3-cm@listserv.ieee.org]On Behalf
> > Of Benjamin
> > > > Brown
> > > > Sent: Thursday, April 22, 2004 8:09 AM
> > > > To: STDS-802-3-CM@listserv.ieee.org
> > > > Subject: [8023-CMSG] Purpose
> > > >
> > > >
> > > > Hi,
> > > >
> > > > I thought I'd try to kick start some discussions around the
> > > > Congestion Management Study Group's purpose for existence.
> > > > We have 3 tasks to accomplish between now and the May
> > > > interim. We need to develop a PAR, 5 Criteria and a list of
> > > > objectives. Ideally we can accomplish this in May in order to
> > > > pre-circulate the PAR and 5 Criteria so that we can formally
> > > > request Standards Board approval in the July meeting. During
> > > > the July meeting, we'll refine the objectives and hopefully not
> > > > change the PAR and 5 Criteria so the Standards Board is
> > > > approving the same thing we pre-circulated. If we miss this
> > > > May deadline, things get ugly. I'd rather not go into those
> > > > details, mostly because I don't know them well enough to
> > > > talk to but also because it sidetracks the discussion.
> > > >
> > > > The bottom line is that we need to work on those 3 items.
> > > > The PAR and 5 Criteria are used to get support from the
> > > > Standards Board. The objectives are used by WG 802.3
> > > > in order to validate the 5 Criteria. I intend to begin working
> > > > on the 5 Criteria and posting them to this reflector, probably
> > > > using individual threads. I would really appreciate some
> > > > discussion around them now since we've only got about a
> > > > day and a half at the May meeting. If we wait until then to
> > > > even see them, we may not be able to make the progress
> > > > we'd like to make.
> > > >
> > > > The implication of the above is that now is not the time to
> > > > propose solutions. That is the work for the task force. If
> > > > we can't get the above 3 items completed in order to become
> > > > a task force, the best solution in the world doesn't help us.
> > > > There will be time for solution proposals.
> > > >
> > > > If anyone has ideas or suggestions for objectives or any of
> > > > the 5 Criteria, please don't hesitate to start a thread on them.
> > > > Remember, I'm just the moderator of this process. I need
> > > > all of you participants to show that you're sufficiently
> > interested
> > > > to actually participate. In fact, this is one of the
> > Criteria - Broad
> > > > Market Potential - Multiple vendors, multiple users!
> > > >
> > > > Regards,
> > > > Ben
> > > >
> > > > --
> > > > -----------------------------------------
> > > > Benjamin Brown
> > > > 178 Bear Hill Road
> > > > Chichester, NH 03258
> > > > 603-491-0296 - Cell
> > > > 603-798-4115 - Office
> > > > benjamin-dot-brown-at-ieee-dot-org
> > > > (Will this cut down on my spam???)
> > > > -----------------------------------------
> > > >
> >