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

[RPRWG] REMOVE






-- Original Message --

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


Timoteo González López
940461
ISC
Plan ´99