[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: Comments on draft-ietf-multi6-v4-multihoming-02
Iljitsch van Beijnum wrote:
On 11-nov-04, at 2:50, Joe Touch wrote:
So, are you suggesting that if we want to maintain any multihoming
bindings,
we should rely on application layer keep alives?
Certainly not. What I'm saying is that if applications want to be
sure a session remains available, they should send keepalives. Then,
if the session goes away, the app gets to hear about it without much
delay.
That's not true for TCP connections today, or anything below it - the
session remains available until it is closed, even if unused. Doesn't
this then change the semantics of 'application silence'?
I don't want unused sessions to consume bandwidth switching around,
but they shouldn't go away per se.
I completely agree. That's why the multihoming mechanism shouldn't do
keepalives on idle sessions. If the opposite behavior is desired,
applications or transports should do keepalives.
I think it's interesting to speculate why keepalives seem to be widely
used, at least by tunneling solutions, today. Perhaps it is in practice
to keep NAT state alive - that is certainly the case with at least one
of the corporate remote access "VPN" solutions I use (the one that
runs IP over TLS and punches through even the most lame NATs). If that
is true, then the need for keepalives will be much less in multi6
and we could recommend the optimistic approach (assume connectivity
is still there until something tells you it isn't).
But that assumes we have a good solution for deleting multi6 state
when it is no longer needed.
Brian
I think triggering slow start is pretty much all you can do to slow
down TCP
You mean slow-start restart, right?
I.e., you want to behave like you lost enough information that you
start from the ground-state with congestion control. It should act
like restarting after idle, more than just 'going into slow-start'.
Yes. It's been a while since I studied RFC 2001. :-)