[tsvwg] Re: Robustness to packet reordering

[Sebastian Moeller <[e-mail]>]

Hi Joe,


> On 12. Feb 2025, at 16:45, [e-mail] wrote:
> 
> 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.

[SM] It is also not actionable practical advice, but in a BCP it should be exactly that... this is verbiage of little utility.

> 
>>>> 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.

[SM] Please cite which you want to consider and how you assessed 1000s of 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.

[SM] Which you did not take, you argued that 100ms is the perception thresholds for humans, glad we agree that that is not so.

> 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.

[SM] Again, how did you come up with these two numbers... 

> 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).

[SM] I am well aware, this is why I argue that any advice for permissible re-ordering that is based on path RTTs is essentially of little utility as the element having other decide about reordering has no reliable knowledge of that RTT.

> 
>>> 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.

[SM] If I want to know how much reordering is recommended thgis text really does not help me at all, except it tells me the IETF does not know either...

> 
> 
>>>> 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?

[SM] I say this a last time, the section we keep citing really does not help me deciding about if/how much reordering is acceptable, all it tells me there are "pos" and "cons"... hardly actionable advice and not practical.

> 
> Latency, efficiency, and reliability are all subjective.

[SM] No these are not, there need to be agrred up measures how to assess these, what might be subjective is, how much/little is acceptable for a given use-case. But even that is IMHO not helpful, e.g. for traditional TCP we know its it 3 dupACKs we want to avoid, nothing subjective here.

> 
>>> 
>>> 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.

[SM] Sorry, to disagree.

> 
> Basically don’t design L2 to reorder if you can help it.

[SM] That horse has left the stable long ago... link layer retransmits as means to create links of a desired bit error rate are IMHO ubiquitous by now, that is one trick L1/L2 designers are not going to give up, so we will mostly trigger the "can not help it" condition, and there the BCP lacks in specificity.


> Don’t try to help the endpoints if, in doing so, you create make reordering (subjectively) worse.

[SM] That is a conditional that depends IMHO on use-cases, but the L2 designer likely will not know what use-cases will actually happen.

I guess, I will stop here, we differ in our assessment of the BCP text, and it seems we will not convince each other, so with all respect, thanks for the discussion.

Sebastian


> 
> Joe
>