[8023-CMSG] P802.3ar rate control
Hi Kevin,
Thanks for the pointers to the information. When I first
heard about this I was under the impression it was going to
be ingress rate limiting, but it looks like more of an
egress shaping function.
Conceptually, one can think of 802.3x pause frames as
achieving a similar objective, although at a coarser
granularity, and therefore it's probably not very
useful for achieving smooth rate control. However, 802.3x
is seldom used because it insensitive to the traffic class
of frames waiting for transmission. This means that once
a sender is told to pause, its high priority frames are
also held up.
In order to make P802.3ar behave fundamentally differently
than 802.3x, one would have to make the MAC sensitive to
the traffic class of the frame, so that when the MAC is
ready to schedule the next frame for transmission, it
has the ability to choose the one with the highest traffic
class.
Is this something that the group has talked about?
By the way, since this is officially a task force, should
we start referring to this group as CMTF instead of CMSG?
Anoop
> -----Original Message-----
> From: owner-stds-802-3-cm@ieee.org
> [mailto:owner-stds-802-3-cm@ieee.org] On Behalf Of Kevin Daines
> Sent: Thursday, January 20, 2005 10:12 AM
> To: STDS-802-3-CM@listserv.ieee.org
> Subject: Re: [8023-CMSG] 802.3ar
>
>
> Anoop,
>
> Thanks for your interest. I've copied your message to the
> reflector to help generate discussion/action.
>
> Hugh Barrass proposed defining (3) separate rate limiters
> within 802.3ar. This is to satisfy one of our four
> objectives. These rate limiters are described in his presentation:
>
> http://www.ieee802.org/3/cm_study/public/0501/barrass_1_0501.pdf
>
> The TF took a number of straw polls regarding these rate
> limiters. See:
>
> http://www.ieee802.org/3/cm_study/public/0501/motions_1_0501.pdf
>
> ...beginning on slide 10. Each rate limiter was considered separately.
>
> The work item between now and the March Atlanta meeting is
> for individuals in the TF to prepare a "technical proposal"
> for each rate limiter so the TF can vote them in (or not). If
> voted in, the proposal would become a "baseline proposal" and
> is material that is well enough defined for a technical
> editor to compose text and diagrams and prepare a draft. I'd
> highly recommend TF members collaborate and prepare a
> consensus proposal rather than disparate competing proposals,
> if possible.
>
> - - -
>
> Manoj presented supporting material and techniques for
> communication congestion indication at L2. This was also in
> support of one of our four objectives. His presentation may
> be found here:
>
http://www.ieee802.org/3/cm_study/public/0501/wadekar_1_0501.pdf
He may slight tweaks and presented in a joint 802.1 meeting. That
presentation may be found here:
http://www.ieee802.org/3/cm_study/public/0501/wadekar_2_0501.pdf
In order for a project to get started within 802.1, the CMTF needs to
prepare a "complete proposal" for review by 802.1, ideally at the March
meeting. 802.1 seems open to a congestion notification project along the
lines of what Manoj is proposing.
kevind
-----Original Message-----
From: Ghanwani, Anoop [mailto:anoop.ghanwani@hp.com]
Sent: Wednesday, January 19, 2005 4:25 PM
To: Kevin Daines
Subject: 802.3ar
Hello Kevin,
Are there any specific projects that 802.3ar is focused on?
I know that the work on congestion notification isn't
yet concrete, but I remember something that the San Antonio
meeting about rate limiting, so I thought I'd check with
you. If there are any specific work items, I'd appreciate
pointers to them.
Anoop