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