RFC 3819 came out of the PILC working group - performance implications of link
layer characteristics.
There is no current equivalent current WG; the closest would be INTAREA.
As to whether an update is needed or useful, I would encourage checking the
entire doc first and appreciating its purpose and message:
- the Internet allows reordering, drops, and duplication
upper layer protocols need to deal with that, because avoiding
It at L2 is problematic
- Internet protocols are significantly helped by a few key L2
capabilities
native subnet broadcast is one of these; if you don’t support
it at L2, it ends up needing to be emulated
- there are tradeoffs and interactions between trying to change these
assumptions
and YMMV (which is why no fixed threshold is ever going to be
appropriate)
If a new doc is actually needed, can someone please start by providing specific
examples of what might be *changed* when ti comes to that advice?
If what you want is “an evaluation of current protocols against the advice in
RFC3819”, then start with that.
Joe
—
Dr. Joe Touch, temporal epistemologist
www.strayalpha.com
> On Feb 12, 2025, at 12:30 AM, Ingemar Johansson S
> <ingemar.s.johans...@ericsson.com> wrote:
>
> 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=40cablelabs....@dmarc.ietf.org
> <mailto:g.white=40cablelabs....@dmarc.ietf.org>>
> Sent: Wednesday, 12 February 2025 00:38
> To: to...@strayalpha.com <mailto:to...@strayalpha.com>
> Cc: Ryan Hamilton <r...@google.com <mailto:r...@google.com>>; Martin Thomson
> <m...@lowentropy.net <mailto:m...@lowentropy.net>>; Greg White
> <g.wh...@cablelabs.com <mailto:g.wh...@cablelabs.com>>; Ingemar Johansson S
> <ingemar.s.johans...@ericsson.com <mailto:ingemar.s.johans...@ericsson.com>>;
> quic@ietf.org <mailto:quic@ietf.org>; ts...@ietf.org <mailto:ts...@ietf.org>
> 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: "to...@strayalpha.com <mailto:to...@strayalpha.com>"
> <to...@strayalpha.com <mailto:to...@strayalpha.com>>
> Date: Tuesday, February 11, 2025 at 8:47 AM
> To: Greg White <g.wh...@cablelabs.com <mailto:g.wh...@cablelabs.com>>
> Cc: Ryan Hamilton <rch=40google....@dmarc.ietf.org
> <mailto:rch=40google....@dmarc.ietf.org>>, Martin Thomson
> <m...@lowentropy.net <mailto:m...@lowentropy.net>>, Greg White
> <g.white=40cablelabs....@dmarc.ietf.org
> <mailto:g.white=40cablelabs....@dmarc.ietf.org>>, Ingemar Johansson S
> <ingemar.s.johansson=40ericsson....@dmarc.ietf.org
> <mailto:ingemar.s.johansson=40ericsson....@dmarc.ietf.org>>, "quic@ietf.org
> <mailto:quic@ietf.org>" <quic@ietf.org <mailto:quic@ietf.org>>,
> "ts...@ietf.org <mailto:ts...@ietf.org>" <ts...@ietf.org
> <mailto:ts...@ietf.org>>
> Subject: Re: [tsvwg] Robustness to packet reordering
>
> Hi, Greg,
>
>
> On Feb 10, 2025, at 2:35 PM, Greg White <g.wh...@cablelabs.com
> <mailto: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 <mailto:to...@strayalpha.com>>
> Date: Friday, February 7, 2025 at 3:18 PM
> To: Ryan Hamilton <rch=40google....@dmarc.ietf.org
> <mailto:rch=40google....@dmarc.ietf.org>>
> Cc: Martin Thomson <m...@lowentropy.net <mailto:m...@lowentropy.net>>, Greg
> White <g.white=40cablelabs....@dmarc.ietf.org
> <mailto:g.white=40cablelabs....@dmarc.ietf.org>>, Ingemar Johansson S
> <ingemar.s.johansson=40ericsson....@dmarc.ietf.org
> <mailto:ingemar.s.johansson=40ericsson....@dmarc.ietf.org>>, "quic@ietf.org
> <mailto:quic@ietf.org>" <quic@ietf.org <mailto:quic@ietf.org>>,
> "ts...@ietf.org <mailto:ts...@ietf.org>" <ts...@ietf.org
> <mailto: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
> <mailto: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.
