Subject: Re: [multipathtcp] On Thursday's Multipath TCP BOF

From: Daniel Stenberg <[email-masked]>
Date: Fri, 31 Jul 2009 11:18:31 +0200 (CEST)

(gah, sorry, I sent this response using the wrong From: so I'm reposting to 
the list-only now)

On Fri, 31 Jul 2009, Iljitsch van Beijnum wrote:

> After the BoF, Joe Touch made the point that some (unspecified) applications 
> use TCP to evaluate whether some remote endpoint is reachable, and this is a 
> feature we must retain. So if the initially chosen address pair stops 
> working, the entire session must be torn down, even if there are still other 
> working paths.

But how would these apps know what flow that is alive or not if the API is the 
exact same? A bazillion apps do their own keep-alive over TCP, but that will 
work fine as long as there's just at least one living "path".

-- 

  / daniel.haxx.se

---

From: Iljitsch van Beijnum <[email-masked]>
Date: Fri, 31 Jul 2009 11:22:42 +0200

On 31 jul 2009, at 11:18, Daniel Stenberg wrote:

> But how would these apps know what flow that is alive or not if the  
> API is the exact same? A bazillion apps do their own keep-alive over  
> TCP, but that will work fine as long as there's just at least one  
> living "path".

Consider BGP: you have internal and external BGP (iBGP and eBGP). Both  
care about whether the other end of the TCP session is still up so  
they send keepalives to check on this.

The difference is that iBGP runs across multiple hops, and if  
something in the middle goes down, iBGP is perfectly happy to ignore  
that if the session is rerouted over something else so it remains alive.

eBGP is made to run directly between two neighboring routers. If the  
link between those routers goes down, eBGP wants to know about that.  
It doesn't want the session to be rerouted.

So the iBGP-type applications that use keepalives would be happy with  
the increased redundancy in multipath TCP, but it would pretty much  
break the eBGP-type applications. So how many of these eBGP-type  
applications are there?

The solution would be for the eBGP-type applications to opt out of the  
MPTCP, but obviously they don't do that today so there is a migration  
issue. During that migration these applications would be unhappy  
unless we make the "fail often, fail fast" behavior the default,  
negating one of the benefits of MPTCP.

---

From: Daniel Stenberg <[email-masked]>
Date: Fri, 31 Jul 2009 11:38:03 +0200 (CEST)

On Fri, 31 Jul 2009, Iljitsch van Beijnum wrote:

> eBGP is made to run directly between two neighboring routers. If the link 
> between those routers goes down, eBGP wants to know about that. It doesn't 
> want the session to be rerouted.

Thanks for this fine description. Yes indeed if you use TCP to verify the 
functionality of a specific link (or even a specific network interface), mptcp 
in its current proposal may break that...

-- 

  / daniel.haxx.se