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

Re: [8023-CMSG] Purpose



Arthur,

If the Congestion Management Study Group were to decide to include
preemption as part of its mission, then it would make sense to pull the "no
change to PCS" "anti-objective." While there are ways to do preemption
without changes to the PCS, that decision should be made by the Task Force,
not the Study Group. In short, that degree of freedom should be left open.

The real question is whether preemption is within the scope of congestion
management, or not.

To answer this question, one must first define what they think congestion
is. If it extends to the point of "there is something in the way (e.g. on
the wire) of what I want to put on the wire," then, preemption might be
considered "in scope."

Having spent a substantial number of months thinking through preemption,
there is no question in my mind that it is relatively trivial to architect
in a way consistent with 802 architecture and backward compatible with
existing ports.

The question is not if it has advantage. The question is not if it can be
done consistently. The question is one of scope, alone.

jonathan



> -----Original Message-----
> From: owner-stds-802-3-cm@LISTSERV.IEEE.ORG
> [mailto:owner-stds-802-3-cm@LISTSERV.IEEE.ORG]On Behalf Of
> Arthur Marris
> Sent: Friday, April 30, 2004 1:33 AM
> To: STDS-802-3-CM@LISTSERV.IEEE.ORG
> Subject: Re: [8023-CMSG] Purpose
>
>
> Jonathan,
>    The presentation you gave in March at the Data Center Ethernet CFI
> suggested preemption as an area for exploration.
>
>    Preemption would require a minor change to the PCS to support extra
> control-codes.
>
>    Supporting preemption seems like a worthwhile objective as every
> microsecond is precious in cluster computing.
>
> Arthur.
>
> Arthur Marris
> Cadence Design Foundry UK Limited
> The Alba Campus
> Livingston, UK, EH54 7HH
> +44 (0)1506 595104
>
>
> -----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 11: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???)
> > -----------------------------------------
> >
>