Re: [RPRWG] A problem about shperD in Draft 2.2
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
> > > >
> > >
> > >
> > >
> > >
> >
> >
> >
>
>
>
>