Re: [8023-CMSG] P802.3ar rate control
Hi Anoop,
I am not sure if you are pointing to inconsistency in MAC
Service
Inteface definition (MAC Client not knowing when MAC is ready to
accept next frame, done with current etc.).. There was good deal
of discussion during Sacramento meeting. Hugh presented this..
Idea was to clarify the interface so that MAC Client knows that
Frame transfer is imminent. (Maintain only one packet in MAC).
This way if low priority packet is submitted to MAC and before
it
is transmitted, high priority packet arrives at MAC Client, then
it has flexibility to withdraw old low-priority packet and
submit
new high-priority packet..
Thanks,
- Manoj
-----Original Message-----
From: Ghanwani, Anoop [mailto:anoop.ghanwani@hp.com]
Sent: Monday, January 24, 2005 10:36 AM
To: Wadekar, Manoj K; STDS-802-3-CM@listserv.ieee.org
Subject: RE: [8023-CMSG] P802.3ar rate control
Hi Manoj,
I think there may be a hole my understanding and perhaps
you (or someone else) can clarify.
When the client has data that it wants to send, does it
know whether or not the MAC is ready to put the packet
on the wire? If it does not, how would it deal with
the following scenario. Let's say the egress rate
is to be limited to 10% and several low-priority
MTU-sized packets are generated by its apps, followed
by high-priority minimum-sized packet?
Anoop
> -----Original Message-----
> From: owner-stds-802-3-cm@ieee.org
> [mailto:owner-stds-802-3-cm@ieee.org] On Behalf Of Wadekar, Manoj K
> Sent: Friday, January 21, 2005 5:53 PM
> 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