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

[RPRWG] A problem about shperD in RPR Draft 2.2:




Hi, all,

The 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