Re: What to do about multipath in QUIC

[Kazuho Oku <[e-mail]>]

2020年11月10日(火) 20:37 Mikkel Fahnøe Jørgensen <[e-mail]>:

> But this doesn’t solve the serialization of a single stream over multiple
> paths.
>

Right.

I would say that there are three categories.

1. Using different paths for different streams.

In this case, it is possible to achieve the goal by using different
connections.

2. Switching between multiple paths to serve one stream.

In this case, connection migration of QUIC v1 is sufficient.

3. Serving one stream using multiple paths concurrently.

This is the case that QUIC v1 does not support.

If there is an application that falls into the last category, then IMO it
would be worthwhile to discuss the requirements of the application (e.g.,
latency), because then we would would understand the requirements that we
need to accomplish.


>
> Also, it doesn’t really make sense to mix a video stream on QUIC on one
> path and TCP on another. That would cause all kinds of problems, not to
> mention privacy.
>
> I agree that there is a risk of a complex unnecesary feature being poorly
> implemented in QUIC. But true multipath cannot really be solved outiside of
> QUIC. I’m fine with making it optional or giving it dedicated version.
>
> Someone suggested building multipath on top of multiple QUIC connections.
> I think that is viable if it is a newer QUIC version that delagates work to
> older QUIC versions. The key point is that externally this happens
> transparently, and there are optionas for the QUIC stacks to coordinate
> locally or remotely via a signalling path. Not sure which solution is
> ultimately the best, but you build upon what you already have.
>
>
> Kind Regards,
> Mikkel Fahnøe Jørgensen
>
>
> On 9 November 2020 at 18.32.06, Roberto Peon ([e-mail]) wrote:
>
> I’m still concerned that we’re looking at solving this inside the
> connection, instead of providing a way for this to be solved irrespective
> of the connection.
> There is a fundamental routing problem we have here that we could address
> (addressing a session), but we’re not addressing with what I’m seeing
> discussed (addressing a session within the same connection object).
>
> If we consider this problem as making the session addressable, then
> applications can do it the way that makes sense for them, without having to
> put everything in every stack everywhere, plus new APIs to actually make
> them work.
>
> I’m afraid if we add multipath, it’ll be like what happened with server
> push. The lack of appropriate APIs made using it with the browser fraught
> with tradeoffs with no reasonable way for an application to fix.
>
> Solve the addressing-of-a-session problem, however, and we make it easier
> to solve the likely API problem that will accompany multipath.
>
> Example:
> I could have a virtual connection which is composed of a TCP connection on
> path A, and a QUIC connection on path B.
> .. or maybe I want to try out a new version/extension on QUIC, so I have a
> virtual connection with QUIC and QUIC+extension.
> I could declare that I’d like for data to flow down QUIC+extension path
> unless that is too slow, then duplicate the data onto the QUIC path.
>
> In my mind, the application should establishes the virtual connection, and
> provide at least one path, and can optionally add (and remove) subsequent
> paths.
> This is something we do already in “storage-land”, where diversity and
> separable failure domains are important, and where the use-cases are
> extremely diverse in latency, data-amounts, and cost.
> -=R
>
>
>
> *From: *QUIC <[e-mail]> on behalf of Behcet Sarikaya <
> [e-mail]>
> *Reply-To: *"[e-mail]" <[e-mail]>
> *Date: *Monday, November 9, 2020 at 8:58 AM
> *To: *Lucas Pardue <[e-mail]>
> *Cc: *Christian Huitema <[e-mail]>, Behcet Sarikaya <
> [e-mail]>, QUIC WG <[e-mail]>, Olivier Bonaventure <
> [e-mail]>, Mikkel Fahnøe Jørgensen <
> [e-mail]>
> *Subject: *Re: What to do about multipath in QUIC
>
>
>
> Hi Lucas, Olivier,
>
>
>
>
>
> On Mon, Nov 9, 2020 at 10:51 AM Lucas Pardue <[e-mail]>
> wrote:
>
> Hey Olivier,
>
>
>
> On Mon, Nov 9, 2020 at 4:31 PM Olivier Bonaventure <
> [e-mail]> wrote:
>
> Lucas,
> >
> > On Mon, Nov 9, 2020 at 3:55 PM Behcet Sarikaya <[e-mail]
> > <mailto:[e-mail]>> wrote:
> >
> >     Hi Folks,
> >     I agree with Mikkel's points.
> >     To Lucas: I meant my short mail sometime ago I think it was before
> >     the interim (?) where I explained that connection migration is
> >     mobility support which should (from layering point of view) be in IP
> >     layer. In fact if IP layer has this support then then no need for
> >     connection migration in QUIC, so those procedures in the code do not
> >     get executed.
> >
> >     Multipath is multiple interface support. It seems more and more like
> >     multipath probably better belongs in transport layer. Traffic in
> >     each interface may go over different networks (in my case on over T
> >     Mobile and the other AT&T). I believe a different PN is well
> >     justified in multipath as we have it in the base draft because of
> >     these traffic conditions (no offense to Christian).
> >
> >
> > I still don't see why the current features of connection migration are
> > not in some way a form of multipath.
>
> You are right, connection migration is the weakest form of multipath.
>
>
>
> Thanks. We heard use cases that would like stronger forms. I think it will
> help continue to move the discussion forward if we can establish some
> common ground on terms and capabilities.
>
>
>
> This paragraph of RFC6824 then continues as follows :
>
>     However, to the network layer, each MPTCP subflow looks
>     like a regular TCP flow whose segments carry a new TCP option type.
>     Multipath TCP manages the creation, removal, and utilization of these
>     subflows to send data.  The number of subflows that are managed
>     within a Multipath TCP connection is not fixed and it can fluctuate
>     during the lifetime of the Multipath TCP connection.
>
> This is not really connection migration and MPTCP provides much more
> multipath capabilities than connection migration.
>
>
>
> Yeah I follow. As someone coming from QUIC, the first sentence is kind of
> easily negated (which is a benefit IIUC). I think the remainder of the
> paragraph is partially satisfied by QUIC v1 if we consider
> PATH_CHALLENGE/PATH_RESPONSE and NEW_CONNECTION_ID/RETIRE_CONNECTION_ID.
> But it starts to fall apart when you want to do more complicated things. I
> think understanding the gaps in the transport signalling would be useful to
> document in isolation to any specific solution.
> draft-deconinck-quic-multipath has done some of that work already but it
> gets a little too tied up with the solution IMO.
>
>
>
>
>
>
>
> I don't think Olivier would wish to undermine the most important feature
> of multipath: multiple paths going over concurrently possible over
> different networks.
>
> Then he can not justify many features in draft-deconinck-quic-multipath.
>
>
>
> Behcet
>
> Cheers
>
> Lucas
>
>
>
>

-- 
Kazuho Oku