Re: What to do about multipath in QUIC

[Spencer Dawkins at IETF <[e-mail]>]

Two things ...  one for Yanmei, one for Mikkel.

On Thu, Nov 12, 2020 at 5:11 AM Mikkel Fahnøe Jørgensen <[e-mail]>
wrote:

> Hi Yanmei Liu
>
> I think this sounds like a good approach. It takes all the work an
> application would otherwise have to do and hides the complexity, without
> completely introducing a lot of new protocol complexity. This allows an
> application to open a stream and keep working on it regardless of which
> connections are currently alive.
>
> I wonder if there are cases where this is a bit too heavy. For example
> handshakes could perhaps be simpler on secondary connections.
>
> Also I wonder about privacy. For example if it is easy to detect that to
> concurrent connections belong to the same endpoint, fingerprinting might be
> easier. I guess that would always be a problem for MP.
>

For Mikkel,

ISTM that we are wobbling between "true multipath is easier to track" and
"connection migration is the weakest form of multipath, so if multipath is
trackable, so is connection migration", and I wonder if someone could point
me to an analysis of "how to avoid tracking for connection migration" - one
strategy I've learned a lot about at/since the virtual interim was
validating multiple paths early in the life of a connection, so that
failover can happen quickly, for instance.

One strategy that's happening in my world is "open one connection per QoS,
on each path". In my world, that's a total of four connections (the reasons
why don't matter). Is it better to open two connections on one path, and
wait SOME_RANDOM_TIME to open connections on the other path, or to open all
four paths roughly simultaneously?

I'm asking this in QUIC, because QUIC connection migration isn't limited to
two paths, and ISTM that the more paths you are going to use, the more we
should pay attention to tracking. I'm not a genius of privacy, but some of
them are here, and more are certainly available if we needed them, so I'd
like to understand the thinking here.


> There are also subtleties such as idle-timeout. What if each connection
> has a different timeout, is it only the sub connection that dies, or the
> entire connection?  There could even be a case where connections remain
> alive without any currently open sub-connection in order to deal with
> aggressive NAT gateways etc.
>
> If secondary handshakes get simplified, I suspect it is more of an
> implementation whether to see it as sub-connections, or just protocol
> messages on different paths.
>
> - Mikkel
>
> On 12 November 2020 at 11.48.50, Yanmei Liu ([e-mail])
> wrote:
>
> Hi Lucas,
>
> > >
> > > 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.
>
> For Yanmei,

>
> I
> strongly agree that we need to establish some common ground on terms and capabilities,
> so I’d like to explain some design considerations in [draft-an-multipath-quic](
> https://tools.ietf.org/html/draft-an-multipath-quic-00
> ), and we hope to get more feedbacks.
>
> I think "we need to establish some common ground on terms and
capabilities" is exactly right.
>
>
If I understood David Scinazi's comment to me about this at the virtual
interim, he found the steering/switching/splitting characterization in my
presentation helpful, so I started working on an individual draft in Github
here -
https://github.com/SpencerDawkins/draft-dawkins-quic-what-to-do-with-multipath
- to begin capturing understandings of ways in which multiple paths might
be used, and different strategies for using them.

The current version of the draft uses language that's ATSSS-specific,
although I don't think the ideas are closely tied to ATSSS. As I said in
the draft,

   This section uses terminology from 3GPP ATSSS {Access Traffic
   Steering, Switch and Splitting, [TS23501]) to describe three
   different patterns of packet forwarding that could be used when
   multiple disjoint paths are available.  Note that these terms
   describe concepts that are not ATSSS-specific, and could apply to any
   multipath environment.  If terminology more accessible to IETF QUIC
   working group participants presents itself, I'll change it.

If people agree that common ground on terms and capabilities would be
useful, they are invited to contribute.

And thanks for bringing your work to the QUIC working group.

Best,

Spencer