[tsvwg] Re: Robustness to packet reordering -- draft-white-intarea-reordering

[Gorry Fairhurst <[e-mail]>]

Greg, et al.

I read draft-white-intarea-reordering prior to the Bangkok IETF meeting. 
Thanks for starting this new I-D!


I see this mentions that RFC3819 does mention work on TCP Reordering 
requirements. This I think became RFC3449. That talked about relaxing 
reordering, but the advice might need updated, because rates and 
protocols have changed.

The document seems focussed on protocols like TCP and QUIC. Ir might be 
hard for lower layers to know the transport service being supported, 
e.g., when using a VPN. (Or any form of encaps/tunnel) and therefore I 
think it will be important to look to other upper layer protocol 
requirements!

I note that IPsec replay protection has been discussed a number of times 
at the IETF, and I suggest also looking at this and other encaps.

I note ROHC expectations have been discussed. Is there any implication 
for other compression methods?

One common method in lower layers as far as I know is ti preserve 
ordering within an IP flow, not for all packets across a link. That 
approach seems to resemble the operation of Ethernet aggregation- 
perhaps you could also  say a few words in the next revision?

I do think it is a useful place to dig and document - time will show if 
this is  WIT Area requirements for lower layers or the other way around 
as an INT Area spec.


Best wishes,

Gorry



On 11/03/2025 19:44, Greg White wrote:
>
> FYI, we (Ingemar, Dibakar Das, and I) have put together a draft which 
> is on the agenda for Intarea on Monday evening next week.
>
> The current WIP can be found at: 
> https://gwhitecl.github.io/draft-white-intarea-reordering/draft-white-intarea-reordering.html
>
> There is also a version on the Datatracker, but the above version is a 
> bit more complete.
>
> -Greg
>
> *From: *Ingemar Johansson S <[e-mail]>
> *Date: *Wednesday, February 12, 2025 at 1:30 AM
> *To: *Greg White <g.white=[e-mail]>, 
> "[e-mail]" <[e-mail]>
> *Cc: *Ryan Hamilton <[e-mail]>, Martin Thomson 
> <[e-mail]>, Greg White <[e-mail]>, 
> "[e-mail]" <[e-mail]>, "[e-mail]" <[e-mail]>, 
> Ingemar Johansson S <[e-mail]>
> *Subject: *RE: [tsvwg] Robustness to packet reordering
>
> Hi
>
> I think a draft would be good. I can definitely help and add the 5G 
> specifics.
> There is a cost aspect with large reordering buffers in UEs 
> (terminals) and  network nodes for 5G as well and given that link 
> throughput increases so will also memory. But I think the main driver 
> behind my interest is to limit head of line blocking.
> Historically, reordering buffers in 5G (and before) has been to 
> improve TCP performance. Now that TCP and other protocols have 
> potential to be more robust against packet reordering then I think 
> that it is time to reconsider how things are done.
>
> And with address to Sebasians and Joes discussion, yes, these are 
> relevant arguments and there is probably no “one shoe fits all”. I am 
> for instance not that keen to allow packets to go completely out of 
> sequence from 5G access as retransmissions on the MAC layer are quite 
> common, but that is perhaps more of concern for a number of transport 
> protocol stacks that do not work well when subject out of sequence 
> delivery.
>
> There is concern about performance for RoHC, RoHC is to day mainly 
> used for VoLTE and VoNR which has its own data radio bearer. I see 
> little utility with RoHC otherwise.
>
>
>
> One question, would this be a relevant discussion point at the next 
> IETF ?, and if so, which WG ?.
>
> /Ingemar
>
> *From:*Greg White <g.white=[e-mail]>
> *Sent:* Wednesday, 12 February 2025 00:38
> *To:* [e-mail]
> *Cc:* Ryan Hamilton <[e-mail]>; Martin Thomson 
> <[e-mail]>; Greg White <[e-mail]>; Ingemar 
> Johansson S <[e-mail]>; [e-mail]; 
> [e-mail]
> *Subject:* Re: [tsvwg] Robustness to packet reordering
>
> I really think that https://www.rfc-editor.org/rfc/rfc3819#section-15 
> is lacking.  It doesn’t seem to me that it is a case of the advice 
> there not being heeded.  The advice appears to be that you’d better 
> provide guaranteed in-order delivery unless you want to have terrible 
> TCP performance and broken header compression.  It didn’t omit 
> mentioning that it is the header compression receiver’s responsibility 
> to handle reordering, it outright says that it is the subnetwork’s 
> responsibility.  For a BCP, I think we need to be more clear.
>
> The fact that all 5G, Wi-Fi and DOCSIS gear (perhaps other links too) 
> on the planet have specialized protocol functions (frame sequence 
> numbering, resequencing buffers, multiple simultaneous resequencing 
> contexts, logic to handle sequence loss, etc.) to do this feature that 
> we mostly agree is objectively bad, is also evidence that we should be 
> more clear on this point.  The DOCSIS spec for example has 52 pages of 
> text that discuss resequencing requirements, and every cable modem 
> (these are cost sensitive) is required to support 16 simultaneous 
> resequencing contexts (to handle multiple simultaneous service 
> offerings) each of which is required to support up to 13ms of data.  
> I’ve also been told that there was a recent proposal to eliminate 
> resequencing requirements in 802.11 for Wi-Fi 8, but it was abandoned.
>
> I don’t know about other sections in the document, but I do think we 
> should provide new clarity on the topic of packet reordering.  I’ll 
> put together a strawman draft, but would welcome help.
>
> -Greg
>
> *From: *"[e-mail]" <[e-mail]>
> *Date: *Tuesday, February 11, 2025 at 8:47 AM
> *To: *Greg White <[e-mail]>
> *Cc: *Ryan Hamilton <rch=[e-mail]>, Martin Thomson 
> <[e-mail]>, Greg White 
> <g.white=[e-mail]>, Ingemar Johansson S 
> <ingemar.s.johansson=[e-mail]>, "[e-mail]" 
> <[e-mail]>, "[e-mail]" <[e-mail]>
> *Subject: *Re: [tsvwg] Robustness to packet reordering
>
> Hi, Greg,
>
>     On Feb 10, 2025, at 2:35 PM, Greg White <[e-mail]> wrote:
>
>     Joe,
>
>     Thanks for pointing to that reference.  I assume that is the most
>     definitive guidance that the IETF has given to L2 networks on the
>     topic, and any future changes to that guidance could take the form
>     of updates to RFC3819.
>
>     I agree with you that the sentence you quoted seems reasonable,
>     but in the context of the rest of the text in that section in
>     RFC3819, it seems to me that the warnings about TCP performance
>     and header compression might undercut the recommendation.
>
> The warnings are about compression - and still apply. If the 
> compression algorithm includes dependencies between sequences of 
> packets, then those sequences have to be restored for the compressor 
> to work. Perhaps what isn’t said is that if the compressor has such 
> dependencies, then IT should perform the needed reordering, rather 
> than expecting the network to do so for it. The prior section 
> addresses the impact of loss on compression, but overlooked the impact 
> of reordering.
>
>      I think many L2 designers consider TCP performance to be
>     important (even if they don’t know the details of current
>     implementations), and they also might not be willing to take the
>     risk that their link would break someone’s header compression
>     scheme (users do lots of different things!).
>
> Yes, but again this argues for the compressor to reorder, not L2.
>
>     Is there value in updating that section?
>
> Certainly the entire doc could include more recent references and 
> could be subbed for omissions such as above, perhaps providing more 
> comprehensive advice up front, e.g.,:
>
> - whatever you expect L2 to do, do at the ends of L3 in or in front of 
> protocols that depend on those features
>
> - but do NOT engineer the entire L2 for any of those features
>
> But in a sense that’s just reinforcing the advice in the E2E paper, 
> which doesn’t need (IMO) to be revised simply to refer to more recent 
> examples.
>
>     At a minimum we could point to RACK, L4S and the QUIC packet
>     reordering threshold along with whatever consensus we can develop
>     around the idea that transports that are interested in performance
>     already (or at least can) implement reordering tolerance, and that
>     the benefits of minimizing delay outweigh any slight benefits
>     provided to older transport implementations.  That said, this
>     thread has seen several opinions (not all in agreement) so it
>     might be challenging to get consensus.
>
> And that’s part of the issue as well; to the extent that our docs lack 
> clear, direct advice, it can be the result of the consensus process.
>
> I don’t particularly think an update is warranted - IMO, what’s needed 
> is for the advice that’s there to be heeded.
>
> Joe
>
>     -Greg
>
>     *From:*Joe Touch <[e-mail]>
>     *Date:*Friday, February 7, 2025 at 3:18 PM
>     *To:*Ryan Hamilton <rch=[e-mail]>
>     *Cc:*Martin Thomson <[e-mail]>, Greg White
>     <g.white=[e-mail]>, Ingemar Johansson S
>     <ingemar.s.johansson=[e-mail]>,
>     "[e-mail]" <[e-mail]>, "[e-mail]" <[e-mail]>
>     *Subject:*[tsvwg] Re: Robustness to packet reordering
>
>         On Feb 7, 2025, at 2:12 PM, Ryan Hamilton
>         <rch=[e-mail]> wrote:
>
>     ….
>
>         Let's not hobble the performance of modern protocols in order
>         to *potentially* provide minimal improvements to the
>         performance of obsolete implementations.
>
>     Agreed. As I noted, RFC3819 still has imo the best advice:
>
>        This suggests that subnetwork implementers should try to avoid
>     packet
>
>        reordering whenever possible, but not if doing so compromises
>
>        efficiency, impairs reliability, or increases average packet delay.
>