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

Iljitsch van Beijnum wrote:
> 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.)

Delayed ACKs come within 200ms of the other end going idle, AFAIR.

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

Persistent connections are the kind of TCP connections that might go 
idle for extended periods; most other TCP connections tend to either be 
sending data or be closed quickly. I.e., they're the kind of transport 
layer that would care whether you did keep-alives at the net layer, IMO.

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

Such as? I was thinking 300ms-500ms as a ballpark.

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

That presumes async notification from the lower layer. I wasn't, since I 
don't believe that's feasible.

I.e., I would expect:
	- seeing packets exchanged is an in-band test that can be
	  observed and serves as a keep-alive itself
	- send keepalives for the first 500ms after idle
	- stop sending keepalives after that

In the absence of keepalives, things can be changed or dropped as needed 
fairly quickly, as a result.

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

I'd like it to do something - to keep verifying that reachability is 
still possible for exactly the period that an idle TCP 'expects' there 
not to be a substantial change in the channel.

Joe

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.3 (MingW32)
Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org

iD8DBQFBltEgE5f5cImnZrsRAsVGAKCnrtCkCRYFiLXiANyX/V05KlI14ACg95wV
uCIcFvTTQGvYO0S64R73Yso=
=qZC0
-----END PGP SIGNATURE-----