[tsvwg] Re: Robustness to packet reordering

["[e-mail]" <[e-mail]>]

> On Feb 11, 2025, at 3:37 PM, Greg White <g.white=[e-mail]> wrote:
> 
> 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 matters for every current compression defined at the time and TCP as it was defined at the time. None of that has changed.

We can always give examples of newer protocols that don’t have those effects, but that alone is never a sufficient reason to update an RFC - that should be assumed when applying the advice in every RFC anyway.

The core advice is that the network should never do the reordering if it affects efficiency, reliability, OR INCREASES DELAY. If you can do reordering without those effects, sure - go ahead. However, NOWHERE in that section does it say “provide GUARANTEED in-order delivery”. 

> 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.

That advice is not advice to subnetwork (link layer network) designers; that’s advice to compression protocol designers.
ROHC in RFC4995, e.g., already provides that advice (emphasis mine):


   In addition, a header compression scheme should handle the often
   non-trivial residual errors, i.e., where the lower layer may pass a
   packet that contains undetected bit errors to the decompressor.  It
   should also handle **loss and reordering** before the compression point,
   as well as on the link between the compression and decompression
   points [7 <https://datatracker.ietf.org/doc/html/rfc4995#ref-7>].

> 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. 

How so? If they’re doing these things without affecting “efficiency, reliability, or increasing delay”, then they’re following RFC 3819. If not, then they already have explicit text they’re violating - what do you think will fix that, uppercase? 

> 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.

So the question is whether 13ms is increasing delay or not; unless you’re doing day trading, that’s probably not a bad tradeoff to reduce TCP or compressor loss.

If you disagree, then this is an issue to take up with DOCSIS or other standards bodies. 

> 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.

I just don’t see much more than writing side paragraphs to “foot-stomp” text that’s already there. The issue here isn’t the RFC, but rather who is or is not listening to it.

IMO, you’d need to show much specific advice about link design that is absent. Right now, the missing advice is more “don’t do things that need links to be fixed”, but isn’t that what the whole of RFC 3819 really says?

Joe

>  
> -Greg
>  
> From: "[e-mail] <mailto:[e-mail]>" <[e-mail] <mailto:[e-mail]>>
> Date: Tuesday, February 11, 2025 at 8:47 AM
> To: Greg White <[e-mail] <mailto:[e-mail]>>
> Cc: Ryan Hamilton <rch=[e-mail] <mailto:rch=[e-mail]>>, Martin Thomson <[e-mail] <mailto:[e-mail]>>, Greg White <g.white=[e-mail] <mailto:g.white=[e-mail]>>, Ingemar Johansson S <ingemar.s.johansson=[e-mail] <mailto:ingemar.s.johansson=[e-mail]>>, "[e-mail] <mailto:[e-mail]>" <[e-mail] <mailto:[e-mail]>>, "[e-mail] <mailto:[e-mail]>" <[e-mail] <mailto:[e-mail]>>
> Subject: Re: [tsvwg] Robustness to packet reordering
>  
> Hi, Greg,
> 
> 
>> On Feb 10, 2025, at 2:35 PM, Greg White <[e-mail] <mailto:[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] <mailto:[e-mail]>>
>> Date: Friday, February 7, 2025 at 3:18 PM
>> To: Ryan Hamilton <rch=[e-mail] <mailto:rch=[e-mail]>>
>> Cc: Martin Thomson <[e-mail] <mailto:[e-mail]>>, Greg White <g.white=[e-mail] <mailto:g.white=[e-mail]>>, Ingemar Johansson S <ingemar.s.johansson=[e-mail] <mailto:ingemar.s.johansson=[e-mail]>>, "[e-mail] <mailto:[e-mail]>" <[e-mail] <mailto:[e-mail]>>, "[e-mail] <mailto:[e-mail]>" <[e-mail] <mailto:[e-mail]>>
>> Subject: [tsvwg] Re: Robustness to packet reordering
>>  
>>  
>>> On Feb 7, 2025, at 2:12 PM, Ryan Hamilton <rch=[e-mail] <mailto: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.