If I understood the thread correctly there are two reorderings here. The
first is about the L2 reordering because of L2 retransmission / FEC.
Then there is an additional attempt to repair the reordering of the
first, e.g. delaying all packets until the retransmission was received.
I think the question was about the second, but I may be wrong. Btw. 5G
may also use ROHC.
Regards,
Roland
Am 2/11/2025 um 4:47 PM schrieb to...@strayalpha.com:
Hi, Greg,
On Feb 10, 2025, at 2:35 PM, Greg White <g.wh...@cablelabs.com> 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 <to...@strayalpha.com>
*Date:*Friday, February 7, 2025 at 3:18 PM
*To:*Ryan Hamilton <rch=40google....@dmarc.ietf.org>
*Cc:*Martin Thomson <m...@lowentropy.net>, Greg White
<g.white=40cablelabs....@dmarc.ietf.org>, Ingemar Johansson S
<ingemar.s.johansson=40ericsson....@dmarc.ietf.org>, "quic@ietf.org"
<quic@ietf.org>, "ts...@ietf.org" <ts...@ietf.org>
*Subject:*[tsvwg] Re: Robustness to packet reordering
On Feb 7, 2025, at 2:12 PM, Ryan Hamilton
<rch=40google....@dmarc.ietf.org> 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.
