RE: [RPRWG] Some questions about the pseudo-code in Gandalf
Hi Anoop,
My apologies for answering your questions late. Please see below for my
answers or comments.
Thanks,
Donghui
At 06:30 PM 12/26/2001 -0800, Anoop Ghanwani wrote:
>And a couple more...
>
>- allow_rate is used, but never been shown to be computed.
> Did you mean to use allow_rate_congestion?
Yes, the allow_rate means allow_rate_congestion here.
>- lp_allow is computed but never used. Is something missing?
Please see the pseudo code in the section of "THESE ARE UPDATED EVERY CLOCL
CYCLE" on page 46.
>Apologies for sending these piece by piece but
>that's how I found them while trying to understand the
>nitty gritty of the algorithm. I think I'm done for now :-)
>
>Thanks,
>-Anoop
>
> > -----Original Message-----
> > From: Anoop Ghanwani [mailto:anoop@xxxxxxxxxxxxxx]
> > Sent: Wednesday, December 26, 2001 5:00 PM
> > To: 'stds-802-17@xxxxxxxx '
> > Subject: RE: [RPRWG] Some questions about the pseudo-code in Gandalf
> >
> >
> >
> >
> > While I'm at it, I might as well request a couple of more
> > comments and points of clarification:
> >
> > - What's the rationale for:
> > if (recd_rate != NULL_RCVD_INFO) &&
> > (lp_forward_rate > (allow_rate_congestion/WEIGHT))
> > in order to determine whether to send a rev_rate?
This is a part of the fairness algorithm to ensure fair rate transmission
on the ring. If some downstream node is congested and upstream nodes are
sending more traffic than the fair rate of the current node (in a weighted
fashion), current node will pass its received fair rate further upstream.
This fairness logic applies when current node is not congested.
> >
> > - The pseudo-code does not appear to account for virtual
> > output queueing support within the MAC client.
The pseudo-code presents the basic fairness algorithm with single
choke-point information. A VoQ capable MAC client would run multiple copies
of the basic fairness algorithm, and keep track of all the choke-points
information with each running copy corresponding to one virtual destination
queue. For details, please see section 6.7 for descriptions on the
relationship of the basic fairness algorithm and VoQ capable MAC client.
> >
> > Thanks,
> > -Anoop
> >
> > > -----Original Message-----
> > > From: Anoop Ghanwani [mailto:anoop@xxxxxxxxxxxxxx]
> > > Sent: Friday, December 21, 2001 5:05 PM
> > > To: 'stds-802-17@xxxxxxxx '
> > > Subject: [RPRWG] Some questions about the pseudo-code in Gandalf
> > >
> > >
> > >
> > >
> > > I had some questions/clarifications and comments about
> > > the pseudo-code in the Gandalf proposal. The version
> > > that I've been working with is the November one. If
> > > they've been fixed in the more recent one, just let
> > > me know.
> > >
> > > - First off, it seems that the pseudo-code does not handle
> > > the multi-choke point feature discussed in the proposal.
> > > It would be nice to see this.
ditto.
> > >
> > > - When a fairness packet is received, there's some
> > > code that says:
> > > if (fairness_pkt.SA == my_SA) &&
> > > ((node_state == wrapped)) {
> > > ..
> > > } else {
> > > ..
> > > }
One check condition is missing here. We'll update it Gandalf in next
version. The complete check should be
if ( (fairness_pkt.SA == my_SA) &&
( (fairness_pkt.ring_id == my_ring_id) || ( node_state ==
wrapped) ) ) {
rcvd_rate = NULL_RCVD_INFO;
} else {
rcvd_rate = fairness_pkt.rate;
}
The first check states that if a node receives a fair rate originated from
itself in same ringlet, which means its rate is the smallest around the
ring, it will treat the received rate as a NULL info so that its allowed
fair rate will be able to ramp up.
In case of the node is in wrap, if it receives on its outer ring a fair
rate info transmitted from its inner ring, it understands that the ring is
wrapped, both inner ringlet and outer ringlet become one ring essentially,
so its rate is the smallest around the ring, it will treat this case the
same way as in previous case.
> > > Should we also be checking the RING ID in the fairness
> > > packet? Or is it proposing that we don't do any
> > > bandwidth management when the ring wraps?
Ditto. Gandalf checks RING ID, and its fairness algorithm guarantees
bandwidth fairness management in all situations.
> > >
> > > - There's some code that sets my_rate_ok = TRUE. How
> > > does my_rate_ok get set to FALSE? Maybe just the else
> > > clause missing in that statement?
Gandalf probably should make the else statement explicitly.
> > >
> > > - Can one of the authors comment on the tolerance
> > > of the scheme to message loss? The fairness message is
> > > being sent hop-by-hop, and it seems like if it happens
> > > to get lost, those that don't see it will continue
> > > to increase their rates. If that is indeed the case,
> > > I think something needs to be done about robustness.
Fair rate messages get transmitted in fixed interval periodically. The
interval is about 100us. In addition, Gandalf incorporates fair rate
ramp-down and ramp-up in a low-pass filtered fashion at the intervals.
Overall, these schemes integrate and establish a very robust Gandalf
fairness algorithm, which is immune to occasional fair rate message losses.
However, a persistent fair rate message loss over several consecutive
intervals will trigger Gandalf protection procedure.
> > >
> > > - What is the significance of the parameter AGECOEFF
> > > and how does one determine what is a good value to
> > > use for it?
This parameter is part of Gandalf fair rate calculation, which is used for
all transmission rates and not supposed to change at all.
> > >
> > > -Anoop
> > >
> > >
> > >
> > >
> >