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