Re: [RPRWG] ConservativeRate SM questions
- To: STDS-802-17@xxxxxxxxxxxxxxxxx
- Subject: Re: [RPRWG] ConservativeRate SM questions
- From: Necdet Uzun <necdetu@xxxxxxxxx>
- Date: Tue, 17 May 2005 18:00:35 -0700
- Comments: DomainKeys? See http://antispam.yahoo.com/domainkeys
- DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=s1024; d=yahoo.com; b=0bzjPjPLy9CC8FrNhgdZLA/k/oEpaF7VH8BKsGWzGXjJKz+S2Uo3QqxogKM814kVGDIiJmZ15YdrbbPSKPLCKyAn5MUimdke9xkZUghGbtPrH8JHKDX4DQr1ZLQCGN+jpkZokvaLpbOnQizLKXIpteg6J4cRWYxTGbZnm/778OU= ;
- In-Reply-To: 6667
- Reply-To: Necdet Uzun <necdetu@xxxxxxxxx>
- Sender: owner-stds-802-17@xxxxxxxxxxxxxxxxx
Guoliang,
Initially, the condition in row 5 was as you suggested
(i.e., localFairRate >= unreservedRate[myRi]).
However, when people from AT&T simulated a scenario
where localWeight of the head node was greater than 1,
the head of the congested domain was observed to go
out of the congested state prematurely and leaving
some unused ring bandwidth. That is why they suggested
using localFairRate/localWeight >=
unreservedRate[myRi]), which had resolved the problem.
I hope that this helps.
BTW: As Mike mentioned in his e-mail, what I wrote
was/is my opinion and it needs to be agreed by the
group.
Thanks,
Necdet
--- Guoliang Wu <guoliang.wu@FNC.FUJITSU.COM> 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
> >>
> >
> >
>
__________________________________________________
Do You Yahoo!?
Tired of spam? Yahoo! Mail has the best spam protection around
http://mail.yahoo.com