Hi, Mikkel, On Fri, Nov 6, 2020 at 3:34 PM Mikkel Fahnøe Jørgensen <[email protected]> wrote:
> Below > > On 6 November 2020 at 20.02.31, Spencer Dawkins at IETF ( > [email protected]) 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 > > >
