Re: [RPRWG] A problem about shperD in Draft 2.2
Jon/Chao:
I just noticed this discussion. I have implemented the shaperD in my simulator,
but I do not have the problem as you indicated. There are two things I have done
in my simulator:
(a) Make sure that the stageQ has higher transmission priority over STQ. The
priority reversion between STQ and stageQ only happens when STQ gets full. In
the scenario Chao gave, when flow 1 traffics arrive at node B, they are queued
in the STQ, and should not consume the shaperD credit. Hence node B should be
able to add packets. And since flow2 at B is greedy, STQ would reach low
threshold, and node B will start to throttle back the upstream flow.
(b) With the shaperD hiLimit of 1*MTU, it is very important to make sure when
the shaperD credit should be updated. If one updates the shaperD credit right
before transmitting a packet, the link utilization could be degraded. But if one
updates the shaperD credit after a packet is transmitted and the credit has been
decremented,
the link utilization would be as it should be.
These are some of the things I learnt from my implementation. Hope it helps.
Dongmei
Jon Schuringa wrote:
> I used a shaperD hiLimit of 2*MTU in my simulation, and therefore
> station B can add some packets, and that triggered the congestion.
> I agree with you that with the default hiLimit value of 1*MTU,
> flow2 never gets a chance to add traffic.
>
> Regards,
> Jon
>
> ----- Original Message -----
> From: "chwang" <chwang@xxxxxxxxxxxxxxxxxxx>
> To: "Jon Schuringa" <jon.schuringa@xxxxxxxxxxxx>
> Cc: <stds-802-17@xxxxxxxx>
> Sent: Thursday, June 19, 2003 4:05 AM
> Subject: 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
> > > > >
> > > >
> > > >
> > > >
> > > >
> > >
> > >
> > >
> >
> >
> >
> >