The draft currently does not discuss congestion control in hosts and thus if there is no response to an RS, a host will follow RFC2461 and send MAX_RTR_SOLICITATIONS separated by RTR_SOLICITATION_INTERVAL (default 3 RSs @ 4 sec. intervals). Should we specify some kind of exponential backoff as an improvement to this behaviour?
Yes. I think exponential backoff can improve performance for cases of random
drop and still provide protection in a congestion situation.
jak
True. I think that we need something to tackle the unlucky situation where a host would have to wait for a considerably long period in order to receive an RA. I guess that somebody already mentioned it but, for example, in *BSD the default RA sending interval is 30 minutes. -- Tero
Brett Pentland wrote: > The draft currently does not discuss congestion control in hosts > and thus if there is no response to an RS, a host will follow > RFC2461 and send MAX_RTR_SOLICITATIONS separated by > RTR_SOLICITATION_INTERVAL (default 3 RSs @ 4 sec. intervals). > > Should we specify some kind of exponential backoff as an > improvement to this behaviour? We have two affirmatives and no negatives so it looks like we need to do something. I'm still not sure what exactly. Jim's answer sounds like it ties in with the random drops proposed as an alternative to the token bucket used by the routers for limiting unicast RAs (note that this issue is about congestion control in hosts). I still don't fully understand this proposal, so I can't really write any text for it yet. Brett.
Brett,
We can use exponential backoff independently of whether we decide to use
random drop on the router. But if we do decide to use random drop, I think
we should use exponential backoff, because the whole point of random drop it
to make the responses look as if they have been delayed due to congestion,
and exponential backoff is designed to respond properly to that.
jak
----- Original Message -----
From: "Brett Pentland" <brett.pentland@eng.monash.edu.au>
To: <dna-dt@eng.monash.edu.au>
Cc: "James Kempf" <kempf@docomolabs-usa.com>
Sent: Thursday, April 21, 2005 12:38 AM
Subject: Re: [DNA-DT] Solution1, Issue 6: Congestion control in hosts
>> Brett Pentland wrote:
>
>>> > The draft currently does not discuss congestion control in hosts
>>> > and thus if there is no response to an RS, a host will follow
>>> > RFC2461 and send MAX_RTR_SOLICITATIONS separated by
>>> > RTR_SOLICITATION_INTERVAL (default 3 RSs @ 4 sec. intervals).
>>> >
>>> > Should we specify some kind of exponential backoff as an
>>> > improvement to this behaviour?
>
>>
>> We have two affirmatives and no negatives so it looks like we
>> need to do something. I'm still not sure what exactly. Jim's answer
>> sounds like it ties in with the random drops proposed as an
>> alternative to the token bucket used by the routers for limiting
>> unicast RAs (note that this issue is about congestion control in
>> hosts). I still don't fully understand this proposal, so I can't
>> really write any text for it yet.
>>
>> Brett.
Brett Pentland wrote: > Brett Pentland wrote: > >> The draft currently does not discuss congestion control in hosts >> and thus if there is no response to an RS, a host will follow >> RFC2461 and send MAX_RTR_SOLICITATIONS separated by >> RTR_SOLICITATION_INTERVAL (default 3 RSs @ 4 sec. intervals). >> >> Should we specify some kind of exponential backoff as an >> improvement to this behaviour? > > > > We have two affirmatives and no negatives so it looks like we > need to do something. I'm still not sure what exactly. Jim's answer > sounds like it ties in with the random drops proposed as an > alternative to the token bucket used by the routers for limiting > unicast RAs (note that this issue is about congestion control in > hosts). I still don't fully understand this proposal, so I can't > really write any text for it yet. How about listing this as an open issue in the draft. I think there are two related issues: - no response to RS (but on a link with old routers the first response might be delayed 3.5 seconds) - hysteresis about link up notifications; if a notification resulted in a RS being sent 100 ms ago, presumably the host shouldn't immediately send another RS Erik
Erik,
The problem with leaving this open is that it is somewhat connected to
whether we use the token bucket algorithm or not. I think the token bucket
algorithm is used, then we can decide independently whether we want to use
exponential backoff, but if not, then I think we should use exponential
backoff.
So, if we leave this open, I think we should leave open the issue of the
token bucket algorithm as well.
jak
----- Original Message -----
From: "Erik Nordmark" <erik.nordmark@sun.com>
To: "Brett Pentland" <brett.pentland@eng.monash.edu.au>
Cc: <dna-dt@eng.monash.edu.au>; "James Kempf" <kempf@docomolabs-usa.com>
Sent: Thursday, April 21, 2005 9:02 AM
Subject: Re: [DNA-DT] Solution1, Issue 6: Congestion control in hosts
>> Brett Pentland wrote:
>
>>> > Brett Pentland wrote:
>>> >
>>
>>>> >> The draft currently does not discuss congestion control in hosts
>>>> >> and thus if there is no response to an RS, a host will follow
>>>> >> RFC2461 and send MAX_RTR_SOLICITATIONS separated by
>>>> >> RTR_SOLICITATION_INTERVAL (default 3 RSs @ 4 sec. intervals).
>>>> >>
>>>> >> Should we specify some kind of exponential backoff as an
>>>> >> improvement to this behaviour?
>>
>>> >
>>> >
>>> > We have two affirmatives and no negatives so it looks like we
>>> > need to do something. I'm still not sure what exactly. Jim's answer
>>> > sounds like it ties in with the random drops proposed as an
>>> > alternative to the token bucket used by the routers for limiting
>>> > unicast RAs (note that this issue is about congestion control in
>>> > hosts). I still don't fully understand this proposal, so I can't
>>> > really write any text for it yet.
>
>>
>> How about listing this as an open issue in the draft.
>>
>> I think there are two related issues:
>> - no response to RS (but on a link with old routers the first response
>> might be delayed 3.5 seconds)
>> - hysteresis about link up notifications; if a notification resulted
>> in a RS being sent 100 ms ago, presumably the host shouldn't immediately
>> send another RS
>>
>> Erik
>>
| Topic DNASoln1Issue006 . { Edit | Attach | Ref-By | Printable | Diffs | r1.4 | > | r1.3 | > | r1.2 | More } |
|
Revision r1.4 - 22 Apr 2005 - 02:26 GMT - Main.BrettPentland Parents: WebHome > DNASolution1 |
Copyright © 1999-2003 by the contributing authors.
All material on this collaboration platform is the property of the contributing authors. Ideas, requests, problems regarding TWiki? Send feedback. |