[tsvwg] Re: Robustness to packet reordering

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

Notes below...

> On Feb 12, 2025, at 12:02 AM, Sebastian Moeller <moeller0=[e-mail]> wrote:
> 
> Hi Joe,
> 
>> On 12. Feb 2025, at 08:39, [e-mail] wrote:
>> 
>>> 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”.
> 
> [SM] Even if I accept that argument, that still does not address the lack of practical examples if need be for different contexts. Respectfully, the proposed method to assess acceptable reordering needs to have terms for modelling the context.

This isn’t a research plan document, nor should it be.

>>> 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).
> 
> [SM] That is IMHO, by all means tricky advice for a specific link/link layer as the OWDs of the affected packets are unknown to the link layer... Also assuming humans are blind to delays < 100ms is a statement that would need to be backed-up by psychophysics.

It is (to a rough approximation). By thousands of cognitive psychology experiments.

> I give you https://human-factors.arc.nasa.gov/publications/p39-mania-1.pdf "From the results of these two studies, it can be inferred that the Just Noticeable Difference (JND) for latency discrimination by trained observers averages ~15 ms or less, independent of scene complexity and real-world meaning."  15ms not 100ms... If we, for the sake of the argument accept these 15ms, then 13ms would be close by your chosen method but still justifiable.

There are a variety of delays that such studies measure - minimum perceived latency differences, impact of latency on interaction, etc. 

But this basically makes my “YMMV” point. If you’re doing a game where you need to decide if two things happen at the same time, 13ms matters. If you’re using the web for remote editing, the threshold is more like 50ms. The point where the delay starts to become a pain is around 100ms.

Note that this is E2E latency; L2 designers have no way of knowing if their L2 is the entire E2E path or just part of it, so they basically should be playing with the fraction of delay they contribute (at best).

>> 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.
> 
> [SM] That would however mean, the amount of torleable re-ordering delay is subjective, and that is hardly worth putting into a BCP as that is the default...

That’s the point - the doc already says this in (IMO) a well crafted way:

   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.

>>> 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.
> 
> [SM] Sorry, that BCP gives advice so generally as to be essentially of no practical utility. See, I believe that the P in BCP should have meaning, and as long as we expand it to practice and not policy, a BCP should have practical utility... but I understand I am in  the rough here.

I’m sorry, but doesn’t this contradict what you observed just above?

Latency, efficiency, and reliability are all subjective.

>> 
>> If what you want is a doc that says “DOCSIS v3.25 should not reorder”, that’s fine - but not a BCP.
> 
> [SM] No I want BCPs to give actionable advice and/or practical examples if a question is deemed so context dependent that only non-specific general guidelines can be given…

It gives actionable advice that is intentionally subjective.

Basically don’t design L2 to reorder if you can help it. Don’t try to help the endpoints if, in doing so, you create make reordering (subjectively) worse.

Joe