There is already work on this in ICCRG: https://tools.ietf.org/html/draft-bonaventure-iccrg-schedulers-00
From: QUIC <[email protected]> on behalf of Spencer Dawkins at IETF <[email protected]> Date: Thursday, 12. November 2020 at 19:28 To: Christian Huitema <[email protected]> Cc: "Ma, Yunfei" <[email protected]>, "Liu, Hongqiang(洪强)" <[email protected]>, healing4d <[email protected]>, Yanmei Liu <[email protected]>, Mikkel Fahnøe Jørgensen <[email protected]>, quic <[email protected]>, "安勍(莳逸)" <[email protected]> Subject: Re: What to do about multipath in QUIC FWIW ... On Thu, Nov 12, 2020 at 11:05 AM Christian Huitema <[email protected]<mailto:[email protected]>> wrote: I think we need more work on the "multi-path scheduler". We have heard of three application scenarios: maintaining the lowest RTT when sending voice segments (Apple Siri), avoiding buffering delays when playing music (Apple Music), and using two available links with equal preference (Ali Baba "high speed train"). I wish that we could distillate that into a couple of simple concepts. I'm working to capture these in https://github.com/SpencerDawkins/draft-dawkins-quic-what-to-do-with-multipath<https://protect2.fireeye.com/v1/url?k=732d78a9-2cb641af-732d3832-86ee86bd5107-819e3a2f60ca88ed&q=1&e=f5a6d870-fae3-4266-9a08-557fbd96f40c&u=https%3A%2F%2Fgithub.com%2FSpencerDawkins%2Fdraft-dawkins-quic-what-to-do-with-multipath>. Thanks, Christian, for the framing. There are others from the multipath virtual interim (for instance, sharing bandwidth if multiple paths have roughly equivalent RTTs, and using the path with the lowest RTT if they don't). So, I agree with Christian about needing more work on this, and it's not clear to me how many "multipath schedulers" we should be thinking about - but that's a question for another day. Best, Spencer
