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

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