Re: [RPRWG] A problem about shperD in Draft 2.2
Jon,
I don't agree. In station B, nrXmitRate is the sum of flow1's transit rate
and flow2's add rate. Because flow1's transit rate is the output of A's
shaperD, and <= unreservedRate. If flow2 never got chance for transmission,
then flow2's add rate will be zero.
So in station B nrXmitRate won't exceed unreservedRate and the (lpNrXmitRate
> unreservedRate) won't be True.
Regards,
Wang Chao
----- Original Message -----
From: "Jon Schuringa" <jon.schuringa@xxxxxxxxxxxx>
To: "chwang" <chwang@xxxxxxxxxxxxxxxxxxx>
Cc: <stds-802-17@xxxxxxxx>; "Fredrik Davik" <bjornfd@xxxxxxxxx>
Sent: Wednesday, June 18, 2003 10:03 PM
Subject: Re: [RPRWG] A problem about shperD in Draft 2.2
>
> Chao,
>
> You are right that the STQ will not reach the low_threshold, but station
> B will get congested because of (lpNrXmitRate > unreservedRate).
> After congestion detection, both stations get the same amount of
bandwidth.
>
> Regards,
> Jon
>
>
> > > > IsCongested()
> > > > {
> > > > if ((dualQueueMAC && ((lpNrXmitRate > unreservedRate) ||
(stqDepth()
> >
> > > > stqLowThreshold)))
> > > > return TRUE;
> > > > else if ((!dualQueueMAC && ((lpNrXmitRate > unreservedRate)
> > > > || (lpNrXmitRate > rateLowThreshold) ||
> classBAccessDelayTimerExpired
> > > > || classCAccessDelayTimerExpired)))
> > > > return TRUE;
> > > > else
> > > > return FALSE;
> > > > }
>
>
> ----- Original Message -----
> From: "chwang" <chwang@xxxxxxxxxxxxxxxxxxx>
> To: "Fredrik Davik" <bjornfd@xxxxxxxxx>
> Cc: <stds-802-17@xxxxxxxx>
> Sent: Wednesday, June 18, 2003 1:13 PM
> Subject: 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
> > >
> >
> >
> >
> >
>
>
>