<div dir="auto">thanks for the info. This is a possibility, as I have 5ms latency to their servers with 50mbit of bandwidth.</div><div class="gmail_extra"><br><div class="gmail_quote">On May 21, 2017 8:49 AM, "Benjamin Cronce" <<a href="mailto:bcronce@gmail.com">bcronce@gmail.com</a>> wrote:<br type="attribution"><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr">All current TCP implementations have a minimum window size of two segments. If you have 20 open connections, then the minimum bandwidth TCP will attempt to consume is (2 segments * 20 connection)/latency. If you have very low latency relative to your bandwidth, the sender will not respond to congestion.</div><div class="gmail_extra"><br><div class="gmail_quote">On Thu, Apr 6, 2017 at 9:47 PM, cloneman <span dir="ltr"><<a href="mailto:cloneman@gmail.com" target="_blank">cloneman@gmail.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="auto">Hi, <div dir="auto"><br></div><div dir="auto">Appologies in advance if this is the wrong place to ask, I haven't been able to locate an official discussion board. </div><div dir="auto"><br></div><div dir="auto">I'm looking for any comments on Steam's game distribution download system - specifically how it defeats any bufferbloat mitigation system I've used.  </div><div dir="auto"><br></div><div dir="auto">It seems to push past inbound policers, exceeding them by about 40%. That is to say, if you police steam traffic to half of your line rate, enough capacity will remain to avoid packet loss, latency, jitter etc. Obviously this is too much bandwidth to reserve. </div><div dir="auto"><br></div><div dir="auto">Without any inbound control, you can expect very heavy packet loss and jitter. With fq_codel or sfq and taking the usual recommended 15% off the table, you get improved, but still unacceptable performance in your small flows / ping etc. </div><div dir="auto"><br></div><div dir="auto">The behavior can be observed by downloading any free game on their platform. I'm trying to figure out how they've accomplished this and how to mitigate this behavior. It operates with 20 http connections simultaneously, which is normally not an issue (multiple web downloads  perform well under fq_codel) </div><div dir="auto"><br></div><div dir="auto">Note: in my testing cable and vdsl below 100mbit were vulnerable to this behavior, while fiber was immune.</div><div dir="auto"><br></div><div dir="auto">Basically there are edge cases on the internet that like to push too many bytes down a line that is dropping or delaying packets. I would like to see more discussion on this issue. </div><div dir="auto"><br></div><div dir="auto">I haven't tried tweaking any of the parameters / latency targets in fq_codel. </div><div dir="auto"><br></div></div>
<br>______________________________<wbr>_________________<br>
Bloat mailing list<br>
<a href="mailto:Bloat@lists.bufferbloat.net" target="_blank">Bloat@lists.bufferbloat.net</a><br>
<a href="https://lists.bufferbloat.net/listinfo/bloat" rel="noreferrer" target="_blank">https://lists.bufferbloat.net/<wbr>listinfo/bloat</a><br>
<br></blockquote></div><br></div>
</blockquote></div></div>