Thread Links Date Links
Thread Prev Thread Next Thread Index Date Prev Date Next Date Index

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
> >
>
>
>
>