And yet, we still can see network buffering to maintain packet ordering in new work today, including work specifically targeted at QUIC.
In the “CCID5” ANRW talk from Monday’s 2nd session, a reordering buffer was mentioned in the transparent proxy for the MP-DCCP tunnel they’re wrapping QUIC packets in to get multipath traffic-splitting during transport within wireless carriers (a proposal coming soon to tsvwg): https://irtf.org/anrw/2021/program.html#:~:text=nathalie%20romo%20moreno I asked specifically about the reordering buffer at the mic, since this kind of thing has made me sad before. (There was also a side discussion in the chat.) I got the impression they believe they’re seeing some benefits to apps by including this reordering buffer in the network, citing the wider range of reordering that you get for split-path transport (as compared to the L2 forwarding case). If there’s endpoint implementations that aren’t doing a good enough job here and therefore we’re seeing new network deployments that introduce buffering because their measurements indicate it’s helpful on common use cases, it could be worthwhile to get this straightened out before it gets too normalized and we start having networks reintroduce hol-blocking in a way that hurts some QUIC use cases in the name of helping others. Although I expect this can and should be solved at the endpoints, if there is data showing that the ordering solves a real problem with current implementations, reasonable people can reasonably conclude that network buffering to maintain packet order is a good idea. (Note: UDP client-side port might be an option for a network-visible signal that might “just work” for many (hopefully most?) ordering schemes to avoid buffering for ordering, but it might need some API support and it might lead to some other kinds of ugly nat problems if there’s too many flows doing it...) +Anna, Nathalie and Markus. Hopefully they can comment on this also. Best, Jake From: David Schinazi <[email protected]> Date: Wed,2021-07-28 at 2:16 PM To: Roberto Peon <[email protected]> Cc: Ian Swett <[email protected]>, "[email protected]" <[email protected]>, "Das, Dibakar" <[email protected]>, Alan Frindell <[email protected]>, "[email protected]" <[email protected]>, Kirill Pugin <[email protected]> Subject: Re: [Mops] Reminder: Video Ingest over QUIC Side Meeting Friday 7/30 18:00 UTC Why would we need a signal here? This applies to all traffic, be it TCP QUIC or anything else. Firmwares introducing latency to reorder packets was a reaction to bad implementations of TCP from a long time ago that have been fixed in systems that care about performance. In today's world, L2 is better off delivering any and all packets in the order they arrive instead of introducing buffer bloat. David On Wed, Jul 28, 2021 at 1:24 PM Roberto Peon <[email protected]<mailto:[email protected]>> wrote: The ideal would be to have public bits that were intended to be interpreted by (as you say, visible to) those layers so any L2 could adapted appropriately without reinventing the wheel. It isn’t just the local radio firmware that one needs to worry about—it is also the basestation(s) that may be “helping”. Separately, but also important, is being able to get signals from the application about what tradeoffs should be at the network. I believe that this dovetails into many of the multipath issues, btw. A couple potentially interesting params are: A bit to say please don’t HoL block Some kind of mechanism(s) to bound retries (e.g. “don’t retry bit”, but that is obviously not as expressive as throw out packet older than X microseconds) -=R From: QUIC <[email protected]<mailto:[email protected]>> on behalf of Ian Swett <[email protected]<mailto:[email protected]>> Date: Wednesday, July 28, 2021 at 12:42 PM To: "Das, Dibakar" <[email protected]<mailto:[email protected]>> Cc: Alan Frindell <[email protected]<mailto:[email protected]>>, "[email protected]<mailto:[email protected]>" <[email protected]<mailto:[email protected]>>, "[email protected]<mailto:[email protected]>" <[email protected]<mailto:[email protected]>>, Kirill Pugin <[email protected]<mailto:[email protected]>> Subject: Re: Reminder: Video Ingest over QUIC Side Meeting Friday 7/30 18:00 UTC Hi, I can't answer for Alan, but my belief is yes. Client wifi stacks sometimes also do some reordering(and introduce the corresponding latency), so if we could design an indication that in-order delivery has no value, it could be fairly widely applicable. That being said, I don't know what the right mechanism is? Would we need something visible to a network or can we get away with a socket option that propagates to the local 5G network or Wifi firmware when possible? Ian On Wed, Jul 28, 2021 at 3:15 PM Das, Dibakar <[email protected]<mailto:[email protected]>> wrote: Hi Kirill, Alan, I could not attend the call this week and wont be able to attend this side meeting either. But I had a general question about the performance of all such QUIC based protocols over wireless. Typically, the 5G and WiFI MAC layers deliver frames in-order which sort of recreates the HOL blocking problem at lower layers. I would expect this to in turn prevent the QUIC protocol to achieve its full performance gains at least in some congested network scenarios. Considering that in-order delivery is made optional in 5G PDCP, I was wondering if there could be a value to have some signaling defined in the QUIC (or RUSH ?) protocol that would allow lower layers to make better decision about whether to enable/disable in-order delivery for certain streams. I apologize in advance if this is not the right venue to ask questions. Regards, Dibakar From: QUIC <[email protected]<mailto:[email protected]>> On Behalf Of Alan Frindell Sent: Wednesday, July 28, 2021 8:42 AM To: [email protected]<mailto:[email protected]>; [email protected]<mailto:[email protected]>; QUIC WG <[email protected]<mailto:[email protected]>>; [email protected]<mailto:[email protected]> Cc: Kirill Pugin <[email protected]<mailto:[email protected]>> Subject: Reminder: Video Ingest over QUIC Side Meeting Friday 7/30 18:00 UTC Video Ingest over QUIC Side Meeting Friday 7/30 18:00 UTC / 11 Pacific Link to draft agenda and video conference details: https://github.com/afrind/draft-rush/blob/main/meeting-materials/agenda.2021.07.03.md<https://urldefense.com/v3/__https:/github.com/afrind/draft-rush/blob/main/meeting-materials/agenda.2021.07.03.md__;!!GjvTz_vk!E0SzSsjcIQqc-TDdIf5-y7XjoWfnEA-7r9fdRAjEKZXc1GYhGomlKIXMwmDZ0Ls$> -Alan
