[Bloat] [Ecn-sane] quick question

[Sebastian Moeller]

Hi Jonathan,

much appreciated! 

> On Aug 26, 2023, at 14:06, Jonathan Morton <chromatix99 at gmail.com> wrote:
> 
>> On 26 Aug, 2023, at 2:48 pm, Sebastian Moeller via Ecn-sane <ecn-sane at 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