> On Feb 11, 2025, at 11:05 PM, Sebastian Moeller > <[email protected]> wrote: > > Hi Joe, > > On 7 February 2025 23:17:38 CET, Joe Touch <[email protected]> wrote: >> >>> On Feb 7, 2025, at 2:12 PM, Ryan Hamilton <[email protected]> >>> 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. > > [SM] This really is just stating that reordering and undoing reordering have > both positive and negative effects. IMHO it completely fails to give > actionable advice how to assess and weigh these effects objectively to > conclude whether/how much reordering in a given circumstance is acceptable or > not. > In a BCP I would have wished for at least an example how this trade off is > assesses in practice... (or multiple examples if the exact circumstances > matter a lot).
Actionable advice is context dependent - it varies based on the measure of “efficiency”, “reliability”, and “increased delay”. > In a later post you assess that 13ms reordering window acceptable and in > accordance with the above recommendations, so let me ask, what is the > threshold for acceptable and non-acceptable (max) reordering-induced delays? My metric is that delay increase matter only when they are a significant fraction of the current message latency. 13ms probably under 25% of most Internet delays, if not lower. It’s also a small fraction (about 1/6) of the delay a human would notice (100ms). So its impact is small both relatively (25%) and as an absolute (1/6 of notiicible). But the point above applies - I’m using my metrics. You might use others. No absolute or more specific advice is appropriate than what the doc already says. > Without objective measures for the positive and negative effects and how to > aggregate both, I am not sure RFC3819 really is all that useful in regards to > reordering. Even a research paper with such detail would provide advice for one situation at most. BCPs provide more general advice. If what you want is a doc that says “DOCSIS v3.25 should not reorder”, that’s fine - but not a BCP. Joe
