<div dir="auto">It sounds like the sender has a buffer bloat issue. I see the same thing with bittorrent and tcp. If I rate limit my 150mb connection to 100mb, I will see about 30-40mb of retransmissions, for a total of ~135mb of ingress. Even though I limit only to 100mb.<div dir="auto"><br></div><div dir="auto">If I trace route the offending senders, I always see a 3000ms+ ping 1-2 hops before I reach them. </div><div dir="auto"><br></div><div dir="auto">Tcp treats the buffer bloat as packet loss, flooding the receiver. </div></div><div class="gmail_extra"><br><div class="gmail_quote">On Dec 9, 2016 1:20 PM, "George Amanakis" <<a href="mailto:g_amanakis@yahoo.com">g_amanakis@yahoo.com</a>> wrote:<br type="attribution"><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">Dear All,<br>
<br>
regarding the issue about WAN ingress rate with many concurrent TCP downloads, it seems that all the excess ingress rate on the WAN interface are TCP retransmission packets (Wireshark). After the latest commit 78ff814 in cobalt, ping times while using TCP BitTorrent improved from ~1000ms to ~300ms (concurrent connections 55). If I reduce the concurrent connections to 30 I get ping times lower than 70ms.<br>
<br>
Best regards,<br>
George<br>
______________________________<wbr>_________________<br>
Cake mailing list<br>
<a href="mailto:Cake@lists.bufferbloat.net">Cake@lists.bufferbloat.net</a><br>
<a href="https://lists.bufferbloat.net/listinfo/cake" rel="noreferrer" target="_blank">https://lists.bufferbloat.net/<wbr>listinfo/cake</a><br>
</blockquote></div></div>