Re: [8023-CMSG] Purpose
Glen,
I think that you are getting the point exactly. If one uses an Ethernet link
to connect a source to a destination directly, and the destination can
swallow all that the source feeds it (without dropping packets), then there
is no congestion.
If the destination can not swallow all that the source feeds it (without
dropping packets), then there is congestion.
Dealing with said congestion can be done by:
1. dropping packets (causing an upper layer protocol to rate limit, presumed
to be based on its prioritization)
2. PAUSE
3. something new
But, before attempting to identify what the best "something new" is, we must
first ask the question, does the above characterization correctly reflect
the problem? Well no, it does not. Were it this simple, the problem could be
resolved relatively easily. In fact, it might even be fair to claim that
TCP/IP has already solved it. One solution would be, therefore, to have no
L2 network and every nexus should be a L4 "router" with a TOE per port. Now
there's a cost effective solution!
The issue is that a L2 network is not a link (even if that is the way the
TCP/IP experts choose to think of it and the way the OSI stack has defined
it). The congestion (dropping of packets and related inefficiencies),
generally, has little to do with the final destination.
The means to deal with "the problem" go far beyond what we can do in a
discussion on this reflector.
But, some basis is probably of value. Some would argue that when the
"connection" is established, bandwidth should be allocated or reserved. If
insufficient bandwidth is available, then a busy signal should be returned.
This represents the extreme position of "I the service provider decide what
level of QoS you need and if I can't provide that level of service then you
can't connect (busy signal, wait for new equipment installation and
capability, wait for someone to cancel their service...)." The opposite
extreme is one of "Hey, I do the best I can, if you don't like it, don't
send any more packets. If you want to use the service, give me the packet
and I'll see if I can deliver it."
As an industry, there is ample evidence that operation at these extremes is
no longer acceptable.
As you indicate, and implied in all discussion to date, one important path
to pursue (at least in thought) is related to the classification
(prioritization) of classes of traffic.
I had hoped in my objectives trial balloon to ensure that at least this was
left open for discussion (an degree of freedom for the task force) without
allowing discussion of the above "L4 'router' with a TOE per port" as this
is truly a degenerate case for which no work would be required by IEEE 802.
Implicit here is a discussion of 802.1 v 802.3. I presume that this is
obvious and won't belabor this point.
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: Monday, May 03, 2004 11:23 PM
> To: STDS-802-3-CM@LISTSERV.IEEE.ORG
> Subject: Re: [8023-CMSG] Purpose
>
>
> Ben and Jonathan,
>
> You are getting a lot of opposition simply for using terms
> that are neither
> relevant nor correct (in some cases). Based on what I hear
> from you and
> Jonathan, I believe congestion management is not an
> appropriate term here.
> More often than not, congestion is detected in queues and "congestion
> management" refers to queue management and smart scheduling
> algorithms.
>
> For example, the following excerpt is taken from Cisco
> website: "Congestion
> management features allow you to control congestion by
> determining the order
> in which packets are sent out an interface based on
> priorities assigned to
> those packets. Congestion management entails the creation of queues,
> assignment of packets to those queues based on the
> classification of the
> packet, and scheduling of the packets in a queue for transmission. The
> congestion management QoS feature offers four types of
> queueing protocols,
> each of which allows you to specify creation of a different number of
> queues, affording greater or lesser degrees of
> differentiation of traffic,
> and to specify the order in which that traffic is sent."
>
> There is no congestion on a full-duplex link. Full duplex
> MAC can transmit
> anytime if it is not already transmitting. So, for 802.3 it is really
> difficult to talk about congestion. This is not to say that
> 802.3 cannot add
> a supporting mechanism for CM at higher layers.
>
> Perhaps required is a mechanism that would allow some flows
> to have better
> performance than other flows on the same link. If such
> physical link can be
> presented to higher layers as multiple parallel links (or multiple MAC
> service interfaces) with different performance, the higher
> layer can decide
> which interface to use, based on some conditions known to
> this higher layer
> (conditions like congestion or QoS, for example). Note, that in this
> example, higher layer decides what constitutes a flow and
> what performance
> is required for each flow.
>
> In effect, what we want is a mechanism opposite to link
> aggregation. Whereas
> the link aggregation presents several physical links as one
> logical link, we
> want a mechanism where one physical link will be presented as multiple
> logical links.
>
> An example of such link segregation mechanism used for
> congestion management
> can be found every day: a single freeway stretch is segregated into a
> carpool lane and best-effort lanes.
>
> So, if the idea of Link Segregation Study Group (LSSG) is not
> too resentful
> for you, here is a crack at objectives:
>
> 1. Specify a mechanism to bind multiple MAC service interfaces to one
> physical layer.
> 2. Specify a mechanism to guarantee performance such as
> medium access delay
> differentiated for each MAC service interface. (Here we would
> talk about
> allowing frames sent on one MAC port to preempt frames sent
> on another MAC
> port. This preemption mechanism should be transparent to all
> clients using
> MAC service interfaces.)
> 3. The proposed link segregation mechanism is to remain
> compatible with 802
> architecture, including 802.1D bridging and STP.
>
> I avoided talking about end-to-end control, yet one can see
> that with a
> proper client behavior, high-performance links can be
> concatenated to build
> end-to-end high performance tunnels through the entire L2 network.
>
>
> Glen
>
>
>
> -----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: Monday, May 03, 2004 8:33 AM
> To: STDS-802-3-CM@listserv.ieee.org
> Subject: Re: [8023-CMSG] Purpose
>
>
> Gadi,
>
> While it may be interesting to talk about what it means to make
> congestion management a layer 2 edge-to-edge service, this isn't
> really what we're set up to do. We may decide there are pieces
> of this effort that need to work edge-to-edge but it isn't the job
> of this 802.3 study group to figure that out. We're here to figure
> out if there is anything that 802.3 wants to do about this issue.
> This implies a clear understanding of what the problem is that
> 802.3 wants to do something about and then what that something
> is (in general terms at this point). A suggestion for an 802.1 project
> may very well come out of this study group but that's about as far
> as this particular study group can go.
>
> This does, however, bring up another interesting discussion. Both
> 802.3x MAC Control Frames (PAUSE) and 802.3ad Link
> Aggregation didn't have an accompanying 802.1 project. 802.3
> provided a service that MAC Client implementations could use
> to differentiate themselves for customers. This may be a similar
> project if 802.1 doesn't find a component of this they want to
> standardize.
>
> Regards,
> Ben
>
> Gadi Lahat wrote:
>
> Glen
> I wanted to thank you for pointing to the important issues
> first, before
> we dive into the details devil.
> I would like to make it bolder
>
> Is CM supposed to control the link only ? Just the local link (hop) ?
>
> Be aware of the end to end path ?
> OR
>
> CM is supposed to be more network oriented, that is more like
>
> standardizing a switch ( multiport bridge ...) core load management ?
>
> We can then consider if 802.1 is more appropriate than 802.3, and how
> speed matters.
>
>
> Thanks
>
> Gadi
>
>
> -----Original Message-----
> From: Glen Kramer [mailto:glen.kramer@TEKNOVUS.COM]
> Sent: Friday, 30 April, 2004 22:29
> To: STDS-802-3-CM@listserv.ieee.org
> Subject: 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???)
> -----------------------------------------
>
>
>
>
>
>
> --
> -----------------------------------------
> 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???)
> -----------------------------------------