Notes below... > On Feb 12, 2025, at 12:02 AM, Sebastian Moeller > <[email protected]> wrote: > > 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.
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
