Re: What to do about multipath in QUIC

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

Hi, Mikkel,

On Fri, Nov 6, 2020 at 3:34 PM Mikkel Fahnøe Jørgensen <[e-mail]>
wrote:

> Below
>
> On 6 November 2020 at 20.02.31, Spencer Dawkins at IETF (
> [e-mail]) wrote:
>
> I'm not sure what the protocol difference is between the two cases. I
> understand the difference between sending on one path and sending on
> another path, but once you've started sending on two (or more) paths, I'm
> not sure what the protocol requirement is to stop sending on one of them.
>
> I'm even more confused if we're talking about sending datagrams, rather
> than reliable streams.
>
> I understand why a scheduler might want to limit itself to sending on one
> path in normal operation, but I'm trying to understand a different point.
>
> Largely, the machinery that has to do with loss detection, bandwidth
> estimation, congestion control, packet numbering is all set up to deal with
> a single path in QUIC v1. When you migrate, you accept do a transactional
> handover so both parties agree on the change, and you are very careful not
> to get out of sync by one party changing path too frequently, and then
> there are some issues with dealing with adversaries. You still allow for a
> few packets on the old path, but but you can strictly place them as
> originating from a point in the past (sort of like ballots being stamped no
> later than election day).
>
> With multiple paths, you have to decide have you number packets on
> different paths and how you estimate loss, etc., and also more esoteric
> details like spin bits and privacy in this context.
>
> Ordering packets on multiple paths in the same stream is of course more of
> a challenge in this case, as you point out, since packet numbering alone
> might no longer be enough. But as stated, it there is a lot more to it than
> just sequencing frames. Sequencing is a relatively small problem. The
> bigger issues also apply to unordered datagrams.
>
Thanks - that was helpful, at least to me.

> Of course, these problems are far from unsolvable, it just takes som work.
> The question is if it is worth the effort, given what you can already do
> without true multipath, and if it is, exactly what are the important use
> cases. And more remotely, if the additional API complexity with priotising
> paths work out in praxis.
>
I agree.

Best,

Spencer

> Mikkel
>
>
>