[Int-area] Re: [tsvwg] Re: New Version Notification fo r draft-white-intarea-reordering-04.txt

Thanks Alex.

I'm not particularly knowledgeable on DSL technology but I did a quick scan through G.998.4 and it appears to me that this is describing an L1-ish feature where a stream of data (e.g. IP packets) would be chunked into 53, 64 or 65 byte chunks, and then a negotiated integer number of chunks would get packaged into a larger FEC frame (DTU) that has a sequence number (SID). I agree that seems less clear that resequencing could be avoided in this context, since the DTUs may not align with IP packet boundaries.  But, I may be missing something.

-Greg


On 8/5/26, 4:32 AM, "Alex Burr" <[email protected] <mailto:[email protected]>> wrote:


Hi Greg,


For reference, similar reordering is done in the ITU protocol G.998.4 (for impulse noise protection) with a 64ms delay_max. This seems to have been incorporated into G.9701 and G.9711, but with delay_max reduced to 16ms (specified to deal with impulse noise of up to 10ms duration, so some latency cost is inevitable). There are also channel bonding options which may be relevant. ( It's >10 years since I worked on this stuff, so don't take this as a thorough review).


It is not clear to me if it is possible to avoid re-sequencing with these standards as specified, or if intervening mechanisms preclude this. 


It may be worth noting that in all of the above standards the re-sequencing, while serving a similar function to the ones already cited, is formally in the "Physical Layer Specification", i.e L1, not L2. So it may be that the audience for this doc is not only L2 designers.


FWIW it seems anomalous that this draft updates a BCP with normative language, but is "Intended Status: Informational". But I guess this is still under discussion. 


best,


Alex


On Tuesday, 7 July 2026 at 17:22, Greg White <[email protected] <mailto:[email protected]>> wrote:


> FYI
> 
> On 7/6/26, 5:25 PM, "[email protected] <mailto:[email protected]> <mailto:[email protected] <mailto:[email protected]>>" <[email protected] <mailto:[email protected]> <mailto:[email protected] <mailto:[email protected]>>> wrote:
> 
> 
> A new version of Internet-Draft draft-white-intarea-reordering-04.txt has been
> successfully submitted by Greg White and posted to the
> IETF repository.
> 
> 
> Name: draft-white-intarea-reordering
> Revision: 04
> Title: Proposal for Updates to Guidance on Packet Reordering
> Date: 2026-07-06
> Group: Individual Submission
> Pages: 12
> URL: https://www.ietf.org/archive/id/draft-white-intarea-reordering-04.txt <https://www.ietf.org/archive/id/draft-white-intarea-reordering-04.txt> <https://www.ietf.org/archive/id/draft-white-intarea-reordering-04.txt> <https://www.ietf.org/archive/id/draft-white-intarea-reordering-04.txt&gt;>
> Status: https://datatracker.ietf.org/doc/draft-white-intarea-reordering/ <https://datatracker.ietf.org/doc/draft-white-intarea-reordering/> <https://datatracker.ietf.org/doc/draft-white-intarea-reordering/> <https://datatracker.ietf.org/doc/draft-white-intarea-reordering/&gt;>
> HTML: https://www.ietf.org/archive/id/draft-white-intarea-reordering-04.html <https://www.ietf.org/archive/id/draft-white-intarea-reordering-04.html> <https://www.ietf.org/archive/id/draft-white-intarea-reordering-04.html> <https://www.ietf.org/archive/id/draft-white-intarea-reordering-04.html&gt;>
> HTMLized: https://datatracker.ietf.org/doc/html/draft-white-intarea-reordering <https://datatracker.ietf.org/doc/html/draft-white-intarea-reordering> <https://datatracker.ietf.org/doc/html/draft-white-intarea-reordering> <https://datatracker.ietf.org/doc/html/draft-white-intarea-reordering&gt;>
> Diff: https://author-tools.ietf.org/iddiff?url2=draft-white-intarea-reordering-04 <https://author-tools.ietf.org/iddiff?url2=draft-white-intarea-reordering-04> <https://author-tools.ietf.org/iddiff?url2=draft-white-intarea-reordering-04> <https://author-tools.ietf.org/iddiff?url2=draft-white-intarea-reordering-04&gt;>
> 
> 
> Abstract:
> 
> 
> Several link technology standards mandate that equipment guarantee
> in-order delivery of layer 2 frames, apparently due to a belief that
> this is required by higher layer protocols. To meet this requirement
> they implement a "resequencing" operation to restore the original
> packet order. This can introduce delays that result in net
> degradation of performance. Modern TCP and QUIC implementations
> support features that significantly improve their tolerance to out-
> of-order delivery. This draft is intended to provide new information
> for layer 2 technology standards regarding the need to assure in-
> order delivery to support IETF protocols.
> 
> 
> 
> 
> 
> 
> The IETF Secretariat
> 
> 
> 
> 
> 
> 
> 
> 



_______________________________________________
Int-area mailing list -- [email protected]
To unsubscribe send an email to [email protected]