Re: [RPRWG] A problem about shperD in Draft 2.2
Hi, Fredrik,
Let's look at this scenario:
When transit traffic arriving evenly with unreservedRate, and at a certain
arriving time the shaperD credit number is below lowLimitD, say, equal to
(2/3) * lowLimitD, then the credit is decreased and won't exceed
(2/3)*lowLimitD level anymore. The passD indication will be False for all
the time ahead. Client packets won't be sent anymore. This is the case I
have met.
The key reason is that a client packet must firstly pass shperD, only on the
base of this can it gain priority over STQ packet.
Best Regards,
Wang Chao
==================================
Photonic Bridges Co., Ltd.
E-mail: chwang@xxxxxxxxxxxxxxxxxxx
----- Original Message -----
From: "Fredrik Davik" <bjornfd@xxxxxxxxx>
To: "chwang" <chwang@xxxxxxxxxxxxxxxxxxx>
Cc: <stds-802-17@xxxxxxxx>
Sent: Wednesday, June 18, 2003 5:38 PM
Subject: Re: [RPRWG] A problem about shperD in Draft 2.2
> Chwang
>
> In draft 2.2, the dual queue transmit flow chart (fig 6.28, page 151)
> specifies that stage queue entries shall have transmit priority over
> stq entries when stq space >= MTU.
>
> As a consequence, the stq will cross exceed stqLowThreshold and the
> IsCongested() function will return true
>
> Best Regards,
> Fredrik
> ---------------------------------------------
> Fredrik Davik
> Phone: +47 67 82 83 88
> Mobile: +47 45 24 91 88
> Fax: +47 67 82 82 01
> Switchboard: +47 67 82 82 00
>
> mailto:bjornfd@xxxxxxxxx
>
> http://heim.ifi.uio.no/~bjornfd
> http://www.simula.no/people_one.php?people_id=22
>
> Simula Research Laboratory
> P.O.Box 134, Lysaker
> N-1325 Lysaker
> Norway
> "chwang" <chwang@xxxxxxxxxxxxxxxxxxx> writes:
>
> > Hi, all,
> >
> > RPR Draft 2.2 states that shaperD's credit is decreased by the sizes of
> > all add and transit frames that are not subclassA0. All traffic except
for
> > subclassA0 is monitored by shaperD, but only client traffic is
backpressured
> > (via the passD indication). (See Page 110, D2.2)
> >
> > D2.2 also states that, in DualQueueMac datapath, local congestion status
is
> > indicated by either of the following conditions being ture.
> > 1. stqDepth > stqLowThreshold
> > 2. lpNrXmitRate > rateLowThreshold (optional, checked when AccessDelay
> > option is set)
> > 3. classBAccessDelayTimerExpired or classCAccessDelayTimerExpired
(optional,
> > checked when checkRateThreshold option is set)
> >
> > In clause 9.3.8, D2.2 further defines the IsCongested() function as
> > following:
> > IsCongested()
> > {
> > if ((dualQueueMAC && ((lpNrXmitRate > unreservedRate) || (stqDepth() >
> > stqLowThreshold)))
> > return TRUE;
> > else if ((!dualQueueMAC && ((lpNrXmitRate > unreservedRate)
> > || (lpNrXmitRate > rateLowThreshold) || classBAccessDelayTimerExpired
> > || classCAccessDelayTimerExpired)))
> > return TRUE;
> > else
> > return FALSE;
> > }
> >
> >>From above we conclude that we can implement a dualQueue RPR MAC without
the
> > AccessDelay and checkRateThreshold option.
> > But I found a problem when I test it on my OPNet model.
> >
> > The congifurtion scenario is as fllowing:
> >
> > flow 1: -------------------> 800Mbps
> > flow 2: ---------> 800Mbps
> >
> > A ------> B ------> C ------> D
> > | |
> > -------------------------------
> >
> > LinkRate = 622Mbps, unreservedRate 500Mbps,
> > ShaperD incSize = 500Mbps, (equal to unreservedRate)
> > station A add in traffic(sepcified as flow1): A->C, 800Mbps, Service
Class C
> > station B add in traffic(sepcified as flow2): B->C, 800Mbps
> >
> > Ideal bandwidth received by C should be: flow1 --> 250Mbps, flow2 -->
> > 250Mbps
> >
> >
> > But the simulation result show that the bandwidth received by C is:
> > flow1: about 500Mbps
> > flow2: about 0Mbps
> >
> >
> > When flow1 traffic being transited by B, it consumes up the credits of
> > shaperD. B's add traffic can't be sent due to lack of credits. Total
traffic
> > of flow1 and flow2 sent by B (nrXmitRate) doesn't exceed unreservedRate
> > because they are both control by shaperD. At the same time, stqDepth is
> > little enough. So station B is not considered to be congested for all
the
> > time, and flow1's traffic isn't limited. In this case the fairness
control
> > protocol doesn't work.
> >
> >
> > I think there are two ways to solve this problem:
> > 1. Change the AccessDelay check from optional to mandatory in RPR
standard.
> > 2. Or let shaperD credit decreased only by add frames, not by transit
> > frames, just as D2.0 specified.
> >
> >
> > Can someone explain the right usage of shaperD for me?
> >
> >
> >
> > Regards,
> >
> > Wang Chao
> > ==================================
> > Photonic Bridges Co., Ltd.
> > E-mail: chwang@xxxxxxxxxxxxxxxxxxx
>