Hi Jonathan, much appreciated!
> On Aug 26, 2023, at 14:06, Jonathan Morton <chromati...@gmail.com> wrote: > >> On 26 Aug, 2023, at 2:48 pm, Sebastian Moeller via Ecn-sane >> <ecn-s...@lists.bufferbloat.net> wrote: >> >> percentage of packets marked: 100 * (2346329 / 3259777) = 72% >> >> This seems like too high a marking rate to me. I would naively expect that a >> flow on getting a mark scale back by its cwin by 20-50% and then slowly >> increaer it again, so I expect the actual marking rate to be considerably >> below 50% per flow... > >> My gut feeling is that these steam flows do not obey RFC3168 ECN (or >> something wipes the CE marks my router sends upstream along the path)... but >> without a good model what marking rate I should expect this is very >> hand-wavy, so if anybody could help me out with an easy derivation of the >> expected average marking rate I would be grateful. > > Yeah, that's definitely too much marking. We've actually seen this behaviour > from Steam servers before, but they had fixed it at some point. Perhaps > they've unfixed it again. Hmm, I guess the next time around I will take a packet capture and see whether I see ECE (expected) and especially CWR flags in these streams... my side is a recent ubuntu (kernel from the 5.15 series I believe) with sysctl configured to negotiate ECN... > > My best guess is that they're running an old version of BBR with ECN > negotiation left on. BBRv1, at least, completely ignores ECE responses. > Fortunately BBR itself does a good job of congestion control in the FQ > environment which Cake provides, as you can tell by the fact that the queues > never get full enough to trigger heavy dropping. Yes, good point! Next time I see a big download I will take a packet capture to look for additional markers of ECN activity... Sidenote, BBRv1 ignoring ECN and not making sure to veto ECN negotiation really seems like a sub-optimal coincidence... > > The CUBIC RFC offers an answer to your question: > > <Screenshot 2023-08-26 at 3.03.03 pm.png> > > Reading the table, for RTT of 100ms and throughput 100Mbps in a single flow, > a "loss rate" (equivalent to a marking rate) of about 1 per 7000 packets is > required. The formula can be rearranged to find a more general answer. Thanks! Will look into this... Regards Sebastian > > - Jonathan Morton _______________________________________________ Bloat mailing list Bloat@lists.bufferbloat.net https://lists.bufferbloat.net/listinfo/bloat