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

Iljitsch van Beijnum <[email protected]> Fri, 19 Nov 2004 11:41:52 +0100
Newsgroups gmane.ietf.multi6
Message-ID <[email protected]>
On 18-nov-04, at 20:31, Joe Touch wrote:

> |> Persistent connections are the kind of TCP connections that might go
> |> idle for extended periods;

> | Actually I believe they are closed after a relatively short time when
> | they aren't used. And very few sessions use persistent connections 
> last
> | time I checked.

> TCP connections are not closed just because they are idle, and idle
> means no packets exchanged at all.

I was talking about HTTP connections, not about TCP in general.

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

> | I was thinking along the lines of 10 - 15 seconds for non-TCP stuff. 
> I
> | heaven't really looked in detail, but I'm pretty sure transports for 
> AV
> | streaming don't generate ACKs every 500 ms.

> Anything that doesn't generate ACKs every couple-hundred ms when the
> stream is active is asking for trouble ;-)

Any particular reason why? I think so many ACKs are excessive.

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

> | Wouldn't an outage happening right after a session goes idle and a
> | keepalive has been exchanged be such a corner case that we can safely
> | ignore it as a special case?

> I don't like ignoring corner cases, esp. where TCP is concerned.

There is ignoring and then there is ignoring. Obviously when such a 
corner case happens our mechanisms must be able to deal with it in a 
reasonably way. What I'm saying is that not having code to specifically 
handle this case and thus potentially incurring a retransmit before the 
multihoming layer does its thing is ok here.

Don't forget that outages are relatively rare. I don't find the 
situation where there is a significant hiccup when one happens 
problematic, as long as such a hiccup is short enough for sessions to 
recover and for users to wait for this. (I.e., recovering after 239 
wouldn't do, but after 5 - 10 seconds would be just fine.)