<div dir="ltr"><div dir="ltr">On Fri, Jul 26, 2019 at 11:05 AM Dave Taht <<a href="mailto:dave.taht@gmail.com">dave.taht@gmail.com</a>> wrote:</div><div class="gmail_quote"><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
1) BBRv2 is now available for public hacking. I had a good readthrough<br>
last night.<br>
<br>
The published tree applies cleanly (with a small patch) to net-next.<br>
I've had a chance to read through the code (lots of good changes to<br>
bbr!).<br>
<br>
Although neal was careful to say in iccrg the optional ecn mode uses<br>
"dctcp/l4s-style signalling", he did not identify how that was<br>
actually applied<br>
at the middleboxes, and the supplied test scripts<br>
(gtests/net/tcp/bbr/nsperf) don't do that. All we know is that it's<br>
set to kick in at 20 packets. Is it fq_codel's ce_threshold? red? pie?<br>
dualpi? Does it revert to drop on overload?<br></blockquote><div><br></div><div>As mentioned in the ICCRG session, the TCP source tree includes the scripts used to run the tests and generate the graphs in the slide deck. Here is the commit I was mentioning:</div><div><br></div><div>   <a href="https://github.com/google/bbr/commit/e76d4f89b0c42d5409d34c48ee6f8d32407d4b8d">https://github.com/google/bbr/commit/e76d4f89b0c42d5409d34c48ee6f8d32407d4b8d</a><br></div><div><br></div><div>So you can look at exactly how each test was run, and re-run those tests yourself, with the v2alpha code or any experimental tweaks you might make beyond that.</div><div><br></div><div>To answer your particular question, the ECN marks were from a bottleneck qdisc configured as:</div><div class="gmail_quote"><br></div><div class="gmail_quote">  codel ce_threshold 242us limit 1000 target 100ms<br></div><div><br></div><div>I'm not claiming that's necessarily the best mechanism or set of parameters to set ECN marks. The 20-packet number comes from the DCTCP SIGCOMM 2010 paper's recommendation for 1Gbps bottlenecks. I just picked this kind of approach because the bare metal router/switch hardware varies, so this is a simple and easy way for everyone to experiment with the exact same ECN settings.</div><div><br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
Is it running on bare metal? 260us is at the bare bottom of what linux<br>
can schedule reliably, vms are much worse.</blockquote><div><br></div><div>I have tried both VMs and bare metal with those scripts, and of course the VMs are quite noisy and the bare metal results much less noisy. So the graphs are from runs on bare metal x86 server-class machines.</div><div><br></div><div>neal</div><div><br></div></div></div>