<html><head>
<meta http-equiv="Content-Type" content="text/html; charset=utf-8">
</head>
<body>
<p>A few years back, we looked at flow size distributions of traffic
into the Cook Island's Rarotonga via their O3b MEO satellite link
(read: RTT > 120 ms for everything).</p>
<p>Roughly speaking, the interesting insight was that around half of
the TCP traffic by byte volume was sitting in flows of at most 10
packets. Now 10 packets is the size of the initial cwnd in most
currently deployed TCP stack instances, meaning by and large this
part of the traffic isn't really subject to congestion control or
flow control at all: The up to 10 packets usually get sent out in
one go (unless one or more get lost and need to be retransmitted,
but that's rare). <br>
</p>
<p>Most of this small fry traffic consists of HTTP responses with
HTML, CSS and JavaScript files and small / thumbnail images. In
fact, a lot of web sites don't contain objects much larger than
this. So basically, when dealing with this sort of traffic, TCP
never really gets out of slow start mode.<br>
</p>
<p>If you ramp up demand on a link like this (=add users), then
these small size flows end up squeezing out the larger flows that
go through the slow start / back-off / recovery cycle their
respective TCP flavour prescribes, which gives them a competitive
disadvantage. Typical symptom when you're on a link affected by
this: You can check your e-mail OK as long as you don't take an
interest in the attachments!</p>
<p>The problem here is that unless you have a way of breaking up
that small fry traffic, anything traffic at all that responds to
drop- or ECN-induced congestion control of any sort gets put on
the back foot. Bufferbloating just delays the congestion control
response (helpful for large flows) at the expense of suppressing
cwnd growth in slow start (not helpful for large flows). Long RTTs
put that right into focus - MEO and GEO sats are a good teacher
there. <br>
</p>
<div class="moz-cite-prefix">On 14/03/2023 10:02 am, Dave Taht via
Starlink wrote:<br>
</div>
<blockquote type="cite" cite="mid:CAA93jw4JfQsmtYkf3nOHkdtH7N3yHXO1tPiiL9y7Gz=s7FrVNA@mail.gmail.com">
Attached is a picture of what slow start looks like on a 100Mbit
plan<br>
(acquired via the libreqos testbed, our tests vary, but if you
would<br>
like to see many ISP plans tested against (presently) cake, feel
free<br>
to click on <a href="https://payne.taht.net" moz-do-not-send="true">https://payne.taht.net</a> - it is not up
all the time, nor<br>
are the tests the same all the time, for details as to what is<br>
running, please join us in the #libreqos:matrix.org chatroom)<br>
<br>
An overall point I have been trying to make is that *at some
point*,<br>
any sufficiently long flow will exceed the available fifo queue<br>
length, and drop packets, sometimes quite a lot. That is a point,
the<br>
high water mark, worth capturing the bandwidth in, say, the prior<br>
100ms. To me packet behaviors look a lot like musical waveforms,<br>
especially when sampled at the appropriate nyquist rate for the<br>
bandwidth and rtt. Out of any waveform, these days, I can usually
pick<br>
out what AQM (if any) is in action. I hope one day soon, more
people<br>
see patterns like these, and glean a deeper understanding.<br>
<br>
I also keep hoping for someone to lean in, verify, and plot some<br>
results I got recently against mkeown´s theories of buffersizing,<br>
here:<br>
<br>
<a href="https://blog.cerowrt.org/post/juniper" moz-do-not-send="true">https://blog.cerowrt.org/post/juniper/</a><br>
<br>
I don´t trust my results, especially when they are this good.<br>
<br>
<fieldset class="moz-mime-attachment-header"></fieldset>
<pre class="moz-quote-pre" wrap="">_______________________________________________
Starlink mailing list
<a class="moz-txt-link-abbreviated" href="mailto:Starlink@lists.bufferbloat.net">Starlink@lists.bufferbloat.net</a>
<a class="moz-txt-link-freetext" href="https://lists.bufferbloat.net/listinfo/starlink">https://lists.bufferbloat.net/listinfo/starlink</a>
</pre>
</blockquote>
<pre class="moz-signature" cols="72">--
****************************************************************
Dr. Ulrich Speidel
School of Computer Science
Room 303S.594 (City Campus)
The University of Auckland
<a class="moz-txt-link-abbreviated" href="mailto:u.speidel@auckland.ac.nz">u.speidel@auckland.ac.nz</a>
<a class="moz-txt-link-freetext" href="http://www.cs.auckland.ac.nz/~ulrich/">http://www.cs.auckland.ac.nz/~ulrich/</a>
****************************************************************
</pre>
</body>
</html>