[tsvwg] Re: Robustness to packet reordering

["[e-mail]" <[e-mail]>]

> On Feb 11, 2025, at 11:05 PM, Sebastian Moeller <moeller0=[e-mail]> wrote:
> 
> Hi Joe,
> 
> On 7 February 2025 23:17:38 CET, Joe Touch <[e-mail]> wrote:
>> 
>>> 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.
> 
> [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