RE: [RPRWG] How to process ClassB frames requested to be marked f airness eligible and with no shaperC credits if client does not support VDQ
The only way to really avoid HOL blocking completely is
to do per-destination queueing for both classB and
classC in the client. It's kind of a waste for classB since
there's only one policer in the MAC for the CIR credits.
But it's need because the congestion point can bounce around,
and the client has to be able to selectively schedule traffic
destined before or after the congestion point.
-Anoop
-----Original Message-----
From: Shao, Winnie [mailto:winnie.shao@xxxxxxxxx]
Sent: Monday, April 28, 2003 5:48 AM
To: Castellano, Robert; Anoop Ghanwani
Cc: RPR (E-mail)
Subject: RE: [RPRWG] How to process ClassB frames requested to be marked f
airness eligible and with no shaperC credits if client does not support VDQ
If sendC is only a Boolean value it is easy to handle. But in draft 2.2
sendC is an integer value and used to limit the fairness eligible traffic
not to pass the congestion point.
For example, there is no sendB and sendC =5. there are two classB frame: the
first ttl=6 and the second ttl=3. How about this scenario?
The second frame has to wait until sendC is changed. And if there a classC
frame whose ttl =3 at class queue this classC frame can go before the
second classB frame only because the first classB frame is HOL.
Thanks,
Winnie
-----Original Message-----
From: Castellano, Robert [mailto:RCastellano@xxxxxxxxx]
Sent: 2003Äê4ÔÂ26ÈÕ 6:44
To: Anoop Ghanwani; Shao, Winnie
Cc: RPR (E-mail)
Subject: RE: [RPRWG] How to process ClassB frames requested to be marked f
airness eligible and with no shaperC credits if client does not support VDQ
Hi,
The classB HOL blocking is a pretty common question that comes up.
The MAC stage queue is designed that there will be no HOL blocking.
It is important to understand how the stage queue processes classB
and classC frames in both the cases where the client does the MarkFE marking
or the MAC does the marking.
The first is to understand the purpose of the MarkFE for classB frames.
ClassB traffic class is provisioned for a CIR and EIR. The sendB signal
from the MAC indicates when the client can send classB traffic that is
within CIR.
Whenever there is no sendB signal, it means there is no more CIR credit
available.
Likewise the sendC signal indicates when the client can send classC
or classB EIR frames. If the MAC transmits a classB frame when there
is a sendC signal and noSendB, the classB EIR is deducted from the classC
credit pool. Meaning the client can transmit classB
whenever there is a sendB or sendC signal from the MAC. When
a classB frame is transmitted, the appropriate classB or classC
credits are deducted depending on whether the sendB or sendC
signals are active. If there is a sendB, the classB is sent with
MarkFE=false, and if there is sendC and no sendB, the classB
frame is transmitted MarkFE=true. (My assumption here is that the sendA,
sendB,
and sendC signals are all independent, and can be active simultaneously.
The client then chooses which service class to transmit based on
its own queue and scheduling states and the state of the sendX signals.)
The advantage of transmitting a classB frame with MarkFE=true is when there
are no classB credits, however there are class C credits and the client
decides to transmit a class B frame ahead of any pending class C frames.
In this case there is no HOL blocking for class B traffic. If there are no
classB or classC credits, classB is blocked any way.
If the client has classB credits it makes much more sense to transmit
with MarkFE=false (if client is marking). The scenario you bring up is a
case where there
are classB credits but no classC credits, and the client is blocked
from transmitting classB because of one classB at the front of the
classB queue marked MarkFE=true. The better approach is
to transmit the classB frames with MarkFE=false when there is a
sendB signal avoiding a classB HOL blocking issue.
If the MAC is doing the MarkFE marking, this is pretty transparent
to the client and there are no HOL blocking issues. The client
is allowed to send classB whenever the MAC provides a sendB or sendC
signal. In the case where a classB frame is sent with sendB,
the MAC sets MarkFE=false. If the client sends a classB when
there is no sendB but there is a sendC, the MAC will mark the
frame as MarkFE.
As Anoop points out the client has to be able to manage separate
classB and classC traffic queues and do the appropriate scheduling
based on the sendB/sendC signals from the MAC. The client needs
to be intelligent enough to determine when it sees a sendC that it can
transmit either
a classB or classC frame. The client must also be careful
not to starve classC frames if classB always has precedence
over classC. These are all client design issues.
thanks,
robert
> -----Original Message-----
> From: Anoop Ghanwani [mailto:anoop@xxxxxxxxxxxxxx]
> Sent: Friday, April 25, 2003 10:04 AM
> To: 'Shao, Winnie '; 'RPRWG (E-mail) '
> Subject: RE: [RPRWG] How to process ClassB frames requested
> to be marked f airness eligible and with no shaperC credits
> if client does not support VDQ
>
>
>
>
> If the client does not have some kind of intelligent queueing,
> then what you say about HOL blocking will be true. However, if
> the client doesn't do some form of intelligent queueing, one
> would have to question the need for it to set the markFE
> parameter.
>
> Further, the client can take advantage of the sendC signal
> being deasserted when there are no shaperC credits. If it
> does that, it should never request a classB frame for
> transmission with markFE set when there are no classC
> credits.
>
> -Anoop
>
> -----Original Message-----
> From: Shao, Winnie
> To: RPRWG (E-mail)
> Sent: 4/25/03 12:08 AM
> Subject: [RPRWG] How to process ClassB frames requested to be marked
> fairness eligible and with no shaperC credits if client does
> not support
> VDQ
>
>
> In draft2.2, ClassB frames requested to be marked fairness eligible
> and with no shaperC credits are not accepted for transmission.
> But this classB frame will be HOL of other classB frames including CIR
> traffic.
>
> Thanks,
> Winnie Shao
> Senior Software Engineer
> IXA Development Center, Shenzhen Branch, PRC
> I-net: 8-754-1008
>