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

[Brian E Carpenter <[e-mail]>]

Olivier,

On 03/06/2014 19:34, Olivier Bonaventure wrote:
> 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 )

But, of course, the great advantage of shim6, as you know, is that it
applies to all transport layers. MPTCP is very elegant but only works
for TCP applications. So we have a bit of a dilemma in this area.
It's not a v6ops issue though.

    Brian

> 
> 
>> 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
> 
>