[Starlink] When do you drop? Always!
Ulrich Speidel
u.speidel at auckland.ac.nz
Mon Mar 13 17:42:06 EDT 2023
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).
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).
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.
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!
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.
On 14/03/2023 10:02 am, Dave Taht via Starlink wrote:
> Attached is a picture of what slow start looks like on a 100Mbit plan
> (acquired via the libreqos testbed, our tests vary, but if you would
> like to see many ISP plans tested against (presently) cake, feel free
> to click on https://payne.taht.net
> <https://payne.taht.net>
> - it is not up all the time, nor
> are the tests the same all the time, for details as to what is
> running, please join us in the #libreqos:matrix.org chatroom)
>
> An overall point I have been trying to make is that *at some point*,
> any sufficiently long flow will exceed the available fifo queue
> length, and drop packets, sometimes quite a lot. That is a point, the
> high water mark, worth capturing the bandwidth in, say, the prior
> 100ms. To me packet behaviors look a lot like musical waveforms,
> especially when sampled at the appropriate nyquist rate for the
> bandwidth and rtt. Out of any waveform, these days, I can usually pick
> out what AQM (if any) is in action. I hope one day soon, more people
> see patterns like these, and glean a deeper understanding.
>
> I also keep hoping for someone to lean in, verify, and plot some
> results I got recently against mkeown´s theories of buffersizing,
> here:
>
> https://blog.cerowrt.org/post/juniper/
> <https://blog.cerowrt.org/post/juniper>
>
> I don´t trust my results, especially when they are this good.
>
> _______________________________________________
> Starlink mailing list
> Starlink at lists.bufferbloat.net
> https://lists.bufferbloat.net/listinfo/starlink
>
--
****************************************************************
Dr. Ulrich Speidel
School of Computer Science
Room 303S.594 (City Campus)
The University of Auckland
u.speidel at auckland.ac.nz
http://www.cs.auckland.ac.nz/~ulrich/
****************************************************************
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.bufferbloat.net/pipermail/starlink/attachments/20230314/4c2be901/attachment-0001.html>
More information about the Starlink
mailing list