[prev in list] [next in list] [prev in thread] [next in thread] 

List:       ipng
Subject:    Re: [IPv6] MPTCP [was: New Version Notification for draft-fbnvv-v6ops-site-multihoming-01.txt]
From:       Brian E Carpenter <brian.e.carpenter () gmail ! com>
Date:       2023-07-17 23:48:38
Message-ID: 04905951-cf7b-f63a-acc8-53e289eb2700 () gmail ! com
[Download RAW message or body]

On 17-Jul-23 21:35, Philipp S. Tiesel wrote:
> On 2023-07-15 09:03:44 +1200, Brian E Carpenter <brian.e.carpenter@gmail.com>
> wrote in <edfbf8f4-18c6-7571-3a94-198f795dabef@gmail.com>:
> > Eduard,
> > On 14-Jul-23 23:48, Vasilenko Eduard wrote:
> > > Hi Olivier,
> > > Thanks for my education!
> > > 
> > > The list of protocol implementations is good to have.
> > > But are there any production deployments?
> > > Do they tweak routing tables manually or use some scripts?
> > > Is it only for the host with directly connected Carriers or maybe for the \
> > > network with many hosts behind the CPE/Router?
> > 
> > I don't think those are the right questions. As per Ole's and my previous \
> > messages, moving to multipath transport would be a strategic solution to MPMH and \
> > would need changes at many levels. So not really relevant to v6ops today! I think \
> > it would be good to separate the analysis into two parts: 
> > 1) What can be done today or in the near future for (potentially) thousands of \
> > sites? 2) What should be done strategically for (potentially) millions of sites?
> > 
> > For me, multipath transport is still in category 2.
> 
> I am very shaken whether I need to object here … I did my Ph.D. in this minefield \
> 5 years ago and even then, it was possible to employ some kind of multipath - even \
> one-sided with a lot of scripting and "Happy Eyeballs on Steroids". 
> The main limitatios were that
> a) it requires to set up src/dest routing to make treh paths usabele

Yes. Not only is that needed for RFC 8028 to work, but we discovered the same as \
requirement for SHIM6 to work. In fact it's needed for any form of multi-prefix \
multihoming, I think that's a theorem.

> b) it needs to be done in the application unless you move to something like TAPS as \
> communication API.

That was in fact the main motivation for SHIM6 - a shim that avoids any need for app \
changes.

> c) it needs a sofisticated system policy that does the path selection and respects \
> cost and other constrains

OK, but I don't think that's an absolute  mathematical requirement like SADR.

    Brian


> 
> Today, Apple's Network Framework is not too far from making that actually useable.
> 
> AVE!
> Philipp S. Tiesel
> 
> --
> Philipp S. Tiesel
> https://philipp.tiesel.net/
> .
--------------------------------------------------------------------
IETF IPv6 working group mailing list
ipv6@ietf.org
Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
--------------------------------------------------------------------


[prev in list] [next in list] [prev in thread] [next in thread]