<div dir="ltr"><div dir="ltr"><div dir="ltr"><br><div><br></div></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Thu, Apr 23, 2020 at 12:45 PM Sabri Berisha <<a href="mailto:sabri@cluecentral.net">sabri@cluecentral.net</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-style:solid;border-left-color:rgb(204,204,204);padding-left:1ex"><div><div style="font-family:tahoma,"new york",times,serif;font-size:10pt;color:rgb(0,0,0)"><div></div><div><span id="gmail-m_-7940198855264748987zwchr">----- On Apr 23, 2020, at 8:06 AM, Nick Zurku <<a href="mailto:nzurku@teraswitch.com" target="_blank">nzurku@teraswitch.com</a>> wrote:<br></span></div><div><blockquote style="border-left-width:2px;border-left-style:solid;border-left-color:rgb(16,16,255);margin-left:5px;padding-left:5px;color:rgb(0,0,0);font-weight:normal;font-style:normal;text-decoration:none;font-family:Helvetica,Arial,sans-serif;font-size:12pt"><div style="font-family:Helvetica,Arial;font-size:13px">We’re having serious throughput issues with our AS20326 pushing packets to Comcast over v4. Our transfers are either the full line-speed of the Comcast customer modem, or they’re seemingly capped at 200-300KB/s. This behavior appears to be almost stateful, as if the speed is decided when the connection starts. As long as it starts fast it will remain fast for the length of the transfer and slow if it starts slow. Traces seem reasonable and currently we’ve influenced the path onto GTT both ways. If we prepend and reroute on our side, the same exact issue with happen on another transit provider.</div></blockquote><div>Have you tried running a test to see if there may be ECMP issues? I wrote a rudimentary script once, <a href="https://pastebin.com/TTWEj12T" target="_blank">https://pastebin.com/TTWEj12T</a>, that might help here. This script is written to detect packet loss on multiple ECMP paths, but you might be able to modify it for througput. </div><div><br></div><div>The rationale behind my thinking is that if you have certain ECMP links that are oversubscribed, the TCP sessions following that path will stay "low" bandwidth. Sessions what win the ECMP lottery and pass through a non-congested ECMP path may show better performance.</div><div><br></div><div>Thanks,</div><div><br></div><div>Sabri</div></div></div></div></blockquote><div><br></div><div><br></div><div>And for a slightly more formal package to do this,</div><div>there's UDPing, developed by the amazing networking</div><div>team at Yahoo; it was written to identify intermittent </div><div>issues affecting a single link in an ECMP or L2-hashed</div><div>aggregate link pathway.</div><div><br></div><div><a href="https://github.com/yahoo/UDPing">https://github.com/yahoo/UDPing</a></div><div><br></div><div>It does have the disadvantage of being designed for</div><div>one-way measurement in each direction; that decision </div><div>was intentional, to ensure each direction was measuring </div><div>a completely known, deterministic pathway based on the</div><div>hash values in the packets, without the return trip potentially</div><div>obscuring or complicating identification of problematic links.</div><div><br></div><div>But if you have access to both the source and destination ends </div><div>of the connection, it's a wonderful tool to narrow down exactly </div><div>where the underlying problem on a hashed ECMP/aggregate </div><div>link is.</div><div><br></div><div>Matt</div><div> </div></div></div></div>