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

Re: [RPRWG] ConservativeRate SM questions



Guoliang,

please be advised that a maintenance request has to be
generated and the Maintenance Task Force has to review
the request to confirm that what Necdet has written
is agreed to by the working group.

mike

Guoliang Wu wrote:
> Necdet,
> 
> Thank you for quick response and help. Appreciated!
> 
> Regarding the 1st item below, the condition probably should just be
> localFairRate >= unreservedRate[myRi].
> That is, the left side need NOT be divided by localWeight.
> Generally, a reasonable localFairRate should be <= unrevervedRate.
> When localFairRate ramps up and reaches or exceeds unreservedRate,
> localCongestion condition can be cleared.
> 
> Regards,
> Guoliang
> 
> 
> Necdet Uzun wrote:
> 
>> Guoliang,
>>
>> Please see below.
>>
>> Thanks.
>>
>> Necdet
>>
>> Guoliang Wu wrote:
>>
>>> Hello RPR experts:
>>>
>>> I have some questions regarding the conservative rate adjust State 
>>> Machine
>>> from the released RPR standard (802.17-2004.pdf, Table 10.9, pages 
>>> 258 - 259).
>>>
>>> 1. Row 5: the condition is
>>>     localFairRate/localWeight >= unreservedRate[myRi] - rampUpCoef.
>>
>>
>>
>> This is a typo. - rampUpCoef should not be there. I.e., it should be 
>> just:
>> localFairRate/localWeight >= unreservedRate[myRi]
>>
>>>   It seems having some typo in the right side, because unreservedRate 
>>> is in bytes and
>>>    rampUpCoef is a pure number.
>>> 2.  Row 5 and Row 16: the allowedRate is calculated twice in the
>>>      two states, first in Row 5 as
>>>       allowedRate += (maxAllowedRate - allowedRate) / rampUpCoef;
>>>   then after transiting from CGST state to FINAL state,
>>>         allowedRate = Min(unreservedRate[myRi], localFairRate);
>>
>>
>> You are right, the calculation in row 5:
>>
>> allowedRate += (maxAllowedRate - allowedRate) / rampUpCoef;
>>
>> is not needed (and overwritten later) as allowedRate has to be set to 
>> normalized localFairRate in conservative mode of operation.
>>
>>>    The later calculation invalids the early one. One of the 
>>> calculations should be
>>>    removed or changed.
>>>    Hope someone can clarify. Your help will be greatly appreciated!
>>>
>>> Regards,
>>> Guoliang Wu
>>> Fujitsu Network Communications, Inc.
>>> Richardson, TX 75082
>>>    
>>
>>
>>


-- 
Michael Takefman              tak@cisco.com
Distinguished Engineer,       Cisco Systems
Chair IEEE 802.17 Stds WG
3000 Innovation Dr, Ottawa, Canada, K2K 3E8
voice: 613-254-3399       cell:613-220-6991