Starlink has bufferbloat. Bad.
 help / color / mirror / Atom feed
From: Dave Taht <dave.taht@gmail.com>
To: Sebastian Moeller <moeller0@gmx.de>
Cc: Dave Taht via Starlink <starlink@lists.bufferbloat.net>
Subject: Re: [Starlink] a puzzling starlink uplink trace
Date: Thu, 31 Aug 2023 06:42:45 -0700	[thread overview]
Message-ID: <CAA93jw4MZ+dpGzh1XxJjqB3cpDRyzhPtoh48zicPUD4OG2PRHQ@mail.gmail.com> (raw)
In-Reply-To: <AA3FD0DC-14C7-4FAC-A3EC-451617330D02@gmx.de>

On Wed, Aug 30, 2023 at 12:43 PM Sebastian Moeller <moeller0@gmx.de> wrote:
>
> Hi Dave,
>
>
> you probably know already, but
> mtr -ezb4 www.heise.de
> will report compliant MPLS segments:

Despite any reputation for omniscience I may have acquired, I was an
ipv6 bigot in the era when MPLS was being specced, and somewhat
willfully ignored it, and did not know traceroute and mtr had gained
the ability to see it.

It would be kind of neat (for business services at least), if starlink
offered MPLS to the router. It would make some things easier. Nobody
to this day seems to know what the dishy to ground station actually
is, although a lot of folk seem to be speculating it is mpls, my bet
is still something custom that has a destination and encrypted
payload....



>                                                                                           My traceroute  [v0.95]
> 123-1234567.local (192.168.42.229) -> www.heise.de (193.99.144.85)                                                                                                               2023-08-30T21:39:48+0200
> Keys:  Help   Display mode   Restart statistics   Order of fields   quit
>                                                                                                                                                                  Packets               Pings
>  Host                                                                                                                                                          Loss%   Snt   Last   Avg  Best  Wrst StDev
>  1. AS???    192.168.42.1 (192.168.42.1)                                                                                                                        0.0%  1067    0.9   0.6   0.5   9.1   0.4
>  2. AS6805   loopback1.0003.acln.06.ham.de.net.telefonica.de (62.52.201.200)                                                                                    0.0%  1067   12.3  22.5   9.9 172.7  17.5
>  3. AS6805   bundle-ether10.0002.dbrx.06.ham.de.net.telefonica.de (62.53.2.98)                                                                                  0.7%  1067   12.4  12.0  10.3  16.5   0.7
>  4. AS6805   ae7-0.0001.corx.06.ham.de.net.telefonica.de (62.53.15.0)                                                                                           0.0%  1067   18.7  19.2  17.2  48.9   2.4
>     [MPLS: Lbl 16624 TC 0 S 1 TTL 1]
>  5. AS6805   ae6-0.0002.corx.02.fra.de.net.telefonica.de (62.53.0.49)                                                                                           0.0%  1067   41.6  19.6  17.2  51.6   3.9
>     [MPLS: Lbl 16624 TC 0 S 1 TTL 1]
>  6. AS6805   bundle-ether2.0001.cord.01.off.de.net.telefonica.de (62.53.0.199)                                                                                  0.0%  1067   19.0  19.3  17.7  87.1   2.2
>     [MPLS: Lbl 16624 TC 0 S 1 TTL 1]
>  7. AS6805   bundle-ether1.0002.corp.01.off.de.net.telefonica.de (62.53.28.171)                                                                                 0.0%  1067   22.9  19.2  17.5  29.7   0.9
>  8. AS???    ipv4.de-cix.fra.de.as12306.plusline.net (80.81.192.132)                                                                                            0.0%  1066   18.5  19.7  18.2  93.0   2.5
>  9. AS12306  82.98.102.71 (82.98.102.71)                                                                                                                        0.0%  1066   19.6  19.4  17.7  69.5   1.7
>     [MPLS: Lbl 24002 TC 0 S 1 TTL 1]
> 10. AS12306  82.98.102.23 (82.98.102.23)                                                                                                                        0.0%  1066   17.8  19.8  17.4 197.7   9.9
> 11. AS12306  212.19.61.13 (212.19.61.13)                                                                                                                        0.0%  1066   19.8  19.6  17.5 155.7   6.1
> 12. AS12306  www.heise.de (193.99.144.85)                                                                                                                       0.1%  1066   19.6  19.1  17.6  63.7   1.5
>
> Not that these do not already stick out as hops at different locations (here Hamburg (ham), Frankfurt (fra) and Offenbach)) all with more or less identical distance-independent RTTs.
>
> Other than that quite intriguing puzzle, I wonder whether we could teach flent to run a bidirectional traceroute/mtr as part of its measurements..?
>
> Regards
>         Sebastian
>
>
> > On Aug 30, 2023, at 20:07, Dave Taht via Starlink <starlink@lists.bufferbloat.net> wrote:
> >
> > In the attached 5 minute plot from a few days ago (I can supply the
> > flent.gz files if anyone wants them), I see a puzzling spike at T+155s
> > to nearly 90ms of baseline latency, then down to 20ms. No degree of
> > orbital mechanics can apply to this change, even factoring in an over
> > the horizon connection, routing packets on the ground through LA to
> > seattle, and back, or using a couple ISLs, can make this add up for
> > me. A combination of all that, kind of does make sense.
> >
> > The trace otherwise shows the sawtooth pattern of a single tcp flow ,
> > a loss (sometimes catastrophic) at every downward bandwidth change.
> >
> > An assumption I have long been making is the latency staircase effect
> > (see T+170) forward is achieving the best encoding rate at the
> > distance then seen, the distance growing and the encoding rate falling
> > in distinct steps, with a fixed amount of buffering, until finally
> > that sat starts falling out of range, and it choses another at T+240s.
> >
> > But jeeze, a 70ms baseline latency swing? What gives?  I imagine
> > somehow correlating this with a mpls enabled traceroute might begin to
> > make some sense of it, correlated by orbital positions....
> >
> >
> > --
> > Oct 30: https://netdevconf.info/0x17/news/the-maestro-and-the-music-bof.html
> > Dave Täht CSO, LibreQos
> > <thestarlinkmystery.png>_______________________________________________
> > Starlink mailing list
> > Starlink@lists.bufferbloat.net
> > https://lists.bufferbloat.net/listinfo/starlink
>


-- 
Oct 30: https://netdevconf.info/0x17/news/the-maestro-and-the-music-bof.html
Dave Täht CSO, LibreQos

  reply	other threads:[~2023-08-31 13:42 UTC|newest]

Thread overview: 10+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2023-08-30 18:07 Dave Taht
2023-08-30 19:43 ` Sebastian Moeller
2023-08-31 13:42   ` Dave Taht [this message]
2023-08-31 14:31     ` Sebastian Moeller
2023-08-31  8:56 ` Alexandre Petrescu
2023-08-31  9:13   ` Alexandre Petrescu
2023-08-31 11:43     ` David Lang
2023-08-31 13:36     ` Dave Taht
2023-08-31 13:54       ` David Lang
2023-09-15 11:17       ` Alexandre Petrescu

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

  List information: https://lists.bufferbloat.net/postorius/lists/starlink.lists.bufferbloat.net/

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=CAA93jw4MZ+dpGzh1XxJjqB3cpDRyzhPtoh48zicPUD4OG2PRHQ@mail.gmail.com \
    --to=dave.taht@gmail.com \
    --cc=moeller0@gmx.de \
    --cc=starlink@lists.bufferbloat.net \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox