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

RE: [RPRWG] Some questions about the pseudo-code in Gandalf





And a couple more...

- allow_rate is used, but never been shown to be computed.
  Did you mean to use allow_rate_congestion?
- lp_allow is computed but never used.  Is something missing?

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?
> 
> - The pseudo-code does not appear to account for virtual
>   output queueing support within the 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.
> > 
> > - When a fairness packet is received, there's some
> > code that says:
> > if (fairness_pkt.SA == my_SA) &&
> >    ((node_state == wrapped)) {
> >     ..
> > } else {
> >     ..
> > }
> > 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?
> > 
> > - 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?
> > 
> > - 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.
> > 
> > - What is the significance of the parameter AGECOEFF 
> > and how does one determine what is a good value to
> > use for it?
> > 
> > -Anoop
> > 
> > 
> > 
> > 
>