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

Re: [8023-CMSG] P802.3ar rate control



However
802.3x PAUSE frame can be improved to support fine granularity flow
control, such that instead of blocking the link, it may signal to
1 - stop traffic at specific (low) priority level
2 - stop a VLAN
3 - stop traffic to a DA.
4 - stop traffic to a specific DA, P, VLAN combination
5 - All of the above, but instead of full stop, request for half rate.



Thanks

Gadi


-----Original Message-----
From: Wadekar, Manoj K [mailto:manoj.k.wadekar@INTEL.COM]
Sent: Saturday, January 22, 2005 03:53
To: STDS-802-3-CM@LISTSERV.IEEE.ORG
Subject: Re: [8023-CMSG] P802.3ar rate control

 Hi Anoop,

        You are right in observing that 802.3x also can achieve
        rate control as end-result, but it creates jitter on high
        priority traffic.

        So, instead of using 802.3x to achieve lower rate (say, 8Gbps
        on 10Gbps link), if there is a mechanism to control the rate
        of "drain" at MAC, then average latency for higher priority
traffic
        does not get affected (as long as amount of high traffic is <
8Gbps).

Thanks,
- Manoj

-----Original Message-----
From: owner-stds-802-3-cm@ieee.org [mailto:owner-stds-802-3-cm@ieee.org]
On Behalf Of Ghanwani, Anoop
Sent: Friday, January 21, 2005 5:08 PM
To: STDS-802-3-CM@listserv.ieee.org
Subject: [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