Re: Comments on draft-ietf-multi6-v4-multihoming-02

[Iljitsch van Beijnum <iljitsch@muada.com>]

On 12-nov-04, at 16:17, Joe Touch wrote:

> > Hm, wouldn't just one or two RTTs be a bit short? You may still get a 
> > delayed ACK after 2 RTTs.

> The delayed ACK should itself refresh things; I'm thinking of an 
> otherwise completely idle interaction.

But how do you know a session is completely idle vs there is still a 
delayed ack coming? (Without looking too deep into TCP, that is.)

> The key here is that TCP expects things not to change for a few RTTs 
> (pick a number). Designing things so that is not the case is likely to 
> cause unintended impact on TCP, esp. in some very typical cases (web 
> surfing over persistent connections).

(Note that is makes little difference whether you use persistent 
connections: we work at the IP layer.)

The trick is detecting legitimate idleness because in that state no 
action is necessary. For TCP this shouldn't be too hard, for other 
protocols we have to find good timeout values. I think these need to be 
higher than just a few RTTs.

> I'm suggesting that the above be tempered after a few RTTs. I.e., if 
> the only traffic has been the reachability tests for more than X RTTs 
> (pick X), then it might be OK to stop testing.

Hm, my assumption was that after a successful test, there wouldn't be 
any more tests until something changes. Since we don't do anything when 
the session is active in both directions or completely idle, 
reachability tests only happen after a suspicious active->idle 
transition. After the test, the multihoming layer would be satisfied 
that this transition wasn't because of a failure, and wouldn't have to 
do anything until there is a new active->idle transition.

Iljitsch