<div dir="ltr"><div dir="ltr"><div class="gmail_default" style="font-family:monospace,monospace">Hey Adam,</div><div class="gmail_default" style="font-family:monospace,monospace"><br></div></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"><div lang="EN-CA"><div class="gmail-m_397710581239347116WordSection1"><p class="MsoNormal">I’m looking for a practical guide – i.e. specifically NOT an academic paper, thanks anyway – to predicting the effect of increased (or decreased) latency on my user’s applications.</p></div></div></blockquote><div><br></div><div><div class="gmail_default" style="font-family:monospace,monospace">This makes answering difficult. Because you may be looking for a simpler answer than what is available.</div></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"><div lang="EN-CA"><div class="gmail-m_397710581239347116WordSection1">
<p class="MsoNormal">Specifically, I want to estimate how much improvement there will be in {bandwidth, application XYZ responsiveness, protocol ABC goodput, whatever} if I decrease the RTT between the user and the server by 10msec, or by 20msec, or by 40msec.</p></div></div></blockquote><div><br></div><div class="gmail_default" style="font-family:monospace,monospace">TCP single flow throughput is TcpWindow / RTT. But all modern stacks have TcpWindow scaling (does not mean all devices have), allowing it to grow beyond the default 0xffff. However, most TCP implementations burst window growth, and window grows exponentially, this means if there is speed step-down in-transit (100G => 10G, or such, which is below sender's rate) then transit device needs to be able to slurp the window growth amount of bytes, otherwise there is packet loss and window cannot grow and single flow cannot attain the max_rate. This means with lower RTT you need to buffer less, and devices with tiny buffers can be a lot cheaper than devices with large buffers.</div><div class="gmail_default" style="font-family:monospace,monospace">Even though most OS support window scaling, there is often a limit to how large it is allowed to grow, because it's an attack vector for DRAM DOS. </div><div class="gmail_default" style="font-family:monospace,monospace"><br></div><div class="gmail_default" style="font-family:monospace,monospace">Example1, no window scaling, 100ms:</div><div class="gmail_default" style="font-family:monospace,monospace">0xffff bytes / 100ms == 5.2Mbps</div><div class="gmail_default" style="font-family:monospace,monospace"><br></div><div class="gmail_default" style="font-family:monospace,monospace">Example2, no window scaling, 60ms:</div><div class="gmail_default" style="font-family:monospace,monospace">0xffff bytes / 60ms == 8.7Mbps</div><div class="gmail_default" style="font-family:monospace,monospace"><br></div><div class="gmail_default" style="font-family:monospace,monospace">Example3, no window scaling, 5ms:</div><div class="gmail_default" style="font-family:monospace,monospace">0xffff bytes / 5ms == 104.8Mbps</div><div class="gmail_default" style="font-family:monospace,monospace"><br></div><div class="gmail_default" style="font-family:monospace,monospace">I believe you can multiply the numbers by 8x, to get performance your modern window users experience. As I believe windows restricts window-size by limiting allowable scaling factor to 8x. </div><div class="gmail_default" style="font-family:monospace,monospace"><br></div><div class="gmail_default" style="font-family:monospace,monospace">Example4, arbitrary window scaling, 100ms, 10Gbps receiver, 100Gbps sender:</div><div class="gmail_default" style="font-family:monospace,monospace">100ms * 10Gbps == 125MB, you need tcp window to scale to 125MB to achieve 10Gbps on this path, and you need step-down device 100G=>10G to have 62.5MB buffer, while window grows from 62.5MB to 125MB and sender burst that data @ 100Gbps.</div><div class="gmail_default" style="font-family:monospace,monospace"><br></div><div class="gmail_default" style="font-family:monospace,monospace">The Example4 is easy to fix, by not bursting the window growth, but by rather doing bandwidth estimation and send the window growth at estimated receiver rate, removing almost all need for transit buffering. However if we were to migrate to such congestion control, classical congestion control like reno, would out-compete it during congestion, so well behaved TCP streams would get increasingly little capacity as their bandwidth estimation would keep going down, and reno would win increasingly more capacity.</div><div class="gmail_default" style="font-family:monospace,monospace"><br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div lang="EN-CA"><div class="gmail-m_397710581239347116WordSection1">
<p class="MsoNormal">Ultimately, this goes into MY calculator – we have the usual north-american duopoly on last-mile consumer internet here; I’m connected directly to only one of the two.  There’s a cost $X to improve connectivity so I’m peered with both,
 how do I tell if it will be worthwhile?</p></div></div></blockquote><div><br></div><div class="gmail_default" style="font-family:monospace,monospace">Based on your questions I'd estimate you do not have a business case to latency optimize if it carries a premium. The most to benefit would probably be for competitive gamers, but they may be bad users on average being subsidized by light users, so it's not entirely clear if you want to invest to attract them.</div><div class="gmail_default" style="font-family:monospace,monospace"><br></div><div class="gmail_default" style="font-family:monospace,monospace"><br></div><div class="gmail_default" style="font-family:monospace,monospace">-- </div><div class="gmail_default" style="font-family:monospace,monospace"><span style="font-family:Arial,Helvetica,sans-serif"> ++ytti</span></div></div></div>