Hi Joe, > On 12. Feb 2025, at 08:39, [email protected] wrote: > >> 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”.
[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. > >> 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. 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. > > 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... > >> 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. > > 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... > > Joe
