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
>
>
>
>