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

[Iljitsch van Beijnum <iljitsch@muada.com>]

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