Starlink has bufferbloat. Bad.
 help / color / mirror / Atom feed
From: Nick Buraglio <nick@buraglio.com>
To: Dave Taht <dave.taht@gmail.com>
Cc: David Lang <david@lang.hm>, Starlink@lists.bufferbloat.net
Subject: Re: [Starlink] dhcpv6-pd details
Date: Mon, 17 May 2021 16:02:23 -0500	[thread overview]
Message-ID: <CAGB08_fhg0WzMRQ+7DA=831qouSEjC-JunMRuwbgVo3X-PiWkQ@mail.gmail.com> (raw)
In-Reply-To: <CAA93jw46q+fucw1kiute3SyZQ8d9YAW4kJem0RdwEB-6mDRcsg@mail.gmail.com>

[-- Attachment #1: Type: text/plain, Size: 3436 bytes --]

The issue with this methodology (which I have used myself) is that it
relies on the host stack to do the heavy lifting. Our draft handles most,
if not all of this at the CPE, which will allow for a significant amount of
flexibility and reduction of complexity at the host layer. That is a fairly
large oversight in the operational model for 90% of v6 users that aren't
running BGP. One goal we have is to reduce the time to connectivity
failover and make deterministic IPv6 paths easily implemented by
non-technical folks, and to create a standard for all CPE to implement with
as minimal CPU as possible.

nb

On Mon, May 17, 2021 at 2:59 PM Dave Taht <dave.taht@gmail.com> wrote:

> On Mon, May 17, 2021 at 12:48 PM Nick Buraglio <nick@buraglio.com> wrote:
> >
> > I have this working now between my providers with straight routing and
> gateway checking, but it’s pretty easily doable other ways with platforms
> like routerOS or pfsense.
> > FWIW, I’m working with some others on an IETF draft proposal that will
> hopefully solve the plaguing problem of multiple IPv6 PD or otherwise
> provider assigned address blocks that will make a lot of that easier, too.
>
> Hmm? We solved this long ago in  cerowrt, openwrt, and in linux, by
> using "source specific routing", which is the default for many openwrt
> derived OSes.
>
> Basically it looks like this:
>
> ip route add from 2001:abcd::/56 via whatever
> ip route add from 2001:dbcd::/56 via whatever2
>
> You then distribute both sets of ipv6 addresses to the clients. Simple
> clean and it solved the bcp38 problem because there is no
> default route for any but these ipv6 addresses in the system. It works
> well for vpns also.
>
> Happy eyeballs takes care of the rest.
>
> https://datatracker.ietf.org/doc/html/draft-ietf-babel-source-specific-08
> describes how we added it to the babel routing protocol
> as well, so best hops can be easily chosen in a more complex network.
> In case I had 5+ comcast uplinks spread across a wifi campus so having
> multiple uplinks and failover was needed. It's been up and running
> for... 7 years?
>
> https://en.wikipedia.org/wiki/Source-specific_routing also made it
> into a few other places.
>
> I'm pretty certain every other OS completely missed this key feature
> of course including your mikrotik
>
>
>
>
> >
> > nb
> >
> >
> > On Mon, May 17, 2021 at 2:36 PM David Lang <david@lang.hm> wrote:
> >>
> >> On Mon, 17 May 2021, Nick Buraglio wrote:
> >>
> >> > Inline
> >> >
> >> > On Mon, May 17, 2021 at 2:15 PM Dave Taht <dave.taht@gmail.com>
> wrote:
> >> >>
> >> >> Starlink provides a router, also? I'm so confused. I thought the
> dishy
> >> >> was all there was. Care to tear it apart and describe what's in it?
> >> >
> >> > As far as the "router" is concerned, it's very much a consumer grade
> >> > device that is managed via the mobile app. I hated it, so I took it
> >> > out. It's still up in the attic. near the cable conduit, if I recall.
> >>
> >> Fantastic, I was hoping it would be something like this. I think this
> opens up a
> >> lot of more useful options (including more easily doing failover
> between the
> >> dish and other network options)
> >>
> >> David  Lang
>
>
>
> --
> Latest Podcast:
> https://www.linkedin.com/feed/update/urn:li:activity:6791014284936785920/
>
> Dave Täht CTO, TekLibre, LLC
>

[-- Attachment #2: Type: text/html, Size: 4609 bytes --]

  reply	other threads:[~2021-05-17 21:02 UTC|newest]

Thread overview: 17+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2021-05-17 18:58 Nick Buraglio
2021-05-17 19:15 ` Dave Taht
2021-05-17 19:30   ` Nick Buraglio
2021-05-17 19:36     ` David Lang
2021-05-17 19:48       ` Nick Buraglio
2021-05-17 19:59         ` Dave Taht
2021-05-17 21:02           ` Nick Buraglio [this message]
2021-05-17 23:56             ` Dave Taht
2021-05-18  2:21               ` Nick Buraglio
2021-05-18  6:51                 ` Gert Doering
2021-05-17 19:37   ` Nathan Owens
2021-05-18  8:33   ` Annika Wickert
2021-05-18 11:37     ` Nick Buraglio
2021-05-18 11:41       ` Annika Wickert
2021-05-18 14:48         ` Nick Buraglio
2021-05-18 14:50           ` Annika Wickert
2021-06-06  3:41             ` Darrell Budic

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='CAGB08_fhg0WzMRQ+7DA=831qouSEjC-JunMRuwbgVo3X-PiWkQ@mail.gmail.com' \
    --to=nick@buraglio.com \
    --cc=Starlink@lists.bufferbloat.net \
    --cc=dave.taht@gmail.com \
    --cc=david@lang.hm \
    /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