Re: [v6ops] source address failover [PI [ULA draft revision #2 Regarding isolated networks]]

[Olivier Bonaventure <[e-mail]>]

Gert, Brian,
>
> On Tue, Jun 03, 2014 at 08:42:55AM +1200, Brian E Carpenter wrote:
>> On 02/06/2014 20:17, Gert Doering wrote:
>> ...
>>> OTOH, proper source address failover on "host" to source address B would
>>> very nicely solve this whole category of connectivity issues - and (by
>>> enforcing halfway symmetric return traffic via ISP B) would actually solve
>>> it *better* than BGP routing, which might need manual fiddling with the
>>> router to remove "ISP C" from the path.
>>
>> I know that shim6 isn't popular around here, but if you actually
>> want to achieve this effect - for any transport protocol, and
>> any application protocol, unmodified - run linshim6 at both ends.

Having worked actively with both shim6 and Multipath TCP and supervised 
their implementation in the Linux kernel, I'm convinced that solving the 
problem in the transport layer is much better than in the network layer. 
Multipath TCP can deal with the case that you discuss and we'd be happy 
to perform tests with the Multipath TCP implementation in the Linux 
kernel (see http://www.multipath-tcp.org )


> I've heard very good results about failover tests with shim6 (much faster
> convergence than BGP).

shim6 would converge faster, but Multipath TCP is even better. It gives 
you many additional features that cannot be provided by shim6 alone. 
Multipath TCP gets continuous feedback about the quality of the Internet 
paths that it uses. It can detect failures and move traffic away from 
congested links. With a network-level solution like shim6 or LISP, one 
hides the changes in the path to the transport protocol. This is not a 
good idea because the congestion control scheme sends packets over paths 
that it cannot control.


> I'm not convinced we particularily *need* it, though, as - as far as I
> understood - shim6 will primarily serve to ensure session survivability,
> while in most scenarios, sessions are so shortlived that "oh, ISP broken,
> use other one" will be a matter of clicking reload in the browser...

There are many short sessions, but most of the traffic is transported in 
very long TCP flows. Furthermore, the deployent of SPDY will increase 
the lifetime of the TCP connections.

> Or will it also take care of selective non-reachability at session setup
> ("something in the ISP A path to Z broken")?

Multipath TCP  could be tuned to do that. There are many use cases where 
Multipath TCP would provide lots of benefits for failover, traffic 
engineering, ... Feel free to bring this operator input to the mptcp 
mailing list



Olivier


-- 
INL, ICTEAM, UCLouvain, Belgium, http://inl.info.ucl.ac.be