Re: What to do about multipath in QUIC

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

Hi, Mikkel,

On Tue, Nov 10, 2020 at 8:41 AM Mikkel Fahnøe Jørgensen <[e-mail]>
wrote:

>
>
> On 10 November 2020 at 15.32.52, Kazuho Oku ([e-mail]) wrote:
>
> 2. Switching between multiple paths to serve one stream.
>
> In this case, connection migration of QUIC v1 is sufficient.
>
>
> This only works for the client. It doesn’t work server P2P.
>


> I’m alson concerned with how fast it is possible to make the switch in
> latency critical operations. Perhaps it can be done fast once, but then you
> have to wait.
>

One of the things I tool away from the multipath virtual interim was that I
had, and possibly other people had, the notion that "connection migration"
was a heavyweight operation (think, "failover to standby path"), but people
were saying that I should be thinking of it as lightweight ("once you've
validated two or more paths, you can just start sending on another path").

ISTM that "how fast it is possible to make the switch" would be the sum of

   1. How fast you can open and validate another connection - but this
   could happen before you need to use it
   2.  How fast you can send the first packet on another connection - my
   understanding is that you can just do that
   3. How you can ramp up the sending rate on another connection to roughly
   what you had achieved on the first connection - but is that critical for
   latency critical operations?

Are you thinking of other factors I'm missing here?

Best,

Spencer