Re: [tsvwg] Re: Robustness to packet reordering

[Greg White <[e-mail]>]

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

Is there value in updating that section?  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.

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