Starlink has bufferbloat. Bad.
 help / color / mirror / Atom feed
From: Dave Taht <dave.taht@gmail.com>
To: Nishanth Sastry <n.sastry@surrey.ac.uk>
Cc: Michael Richardson <mcr@sandelman.ca>,
	Rick Taylor <rick@tropicalstormsoftware.com>,
	 Kevin Shortt <kevin.shortt@airbus.com>,
	"Edward J. Birrane" <Edward.Birrane@jhuapl.edu>,
	 Starlink BufferBloat List <starlink@lists.bufferbloat.net>,
	"Juan A. Fraire" <juanfraire@gmail.com>,
	 Erik Kline <ek.ietf@gmail.com>, Joerg Ott <ott@in.tum.de>
Subject: Re: [Starlink] IETF side meeting on satellite and deep space networks (Tue Mar 18)
Date: Thu, 6 Mar 2025 17:10:58 -0600	[thread overview]
Message-ID: <CAA93jw57bwPEFLN8eMmLD0O_0WsAk=R12j8kgMLgYCsdfX_ftg@mail.gmail.com> (raw)
In-Reply-To: <1AB77B58-47CA-4363-9A98-768F36C39DCE@surrey.ac.uk>

Without attracting the major players (starlink, nasa, oneweb, etc,
etc) to an effort here, I don't know what we could do
to move forward in these areas.

NASA had published a comms architecture for the earth-moon corredor
a.few years back that was an awesome mess of competing technologies,
hardly an architecture at all. (I can go find it)


On Thu, Mar 6, 2025 at 4:37 PM Nishanth Sastry <n.sastry@surrey.ac.uk> wrote:
>
> Hi Michael
>
> Did you consider rechartering dtnrg ?
>
> IMHO most of the LEO stuff is quite far from DTNRG and needs its own home; although strong overlaps exist between some of the bundle protocol ideas and DTN. (There was also Kevin Fall’s Interplanetary Internet and IPNSIG).
>
> It seems to me that there is research needed in predictable routing flaps. Most routing protocols today assume that failures are random.
>
> Totally agree!
>
> Best Wishes
> nishanth
>
> On 6 Mar 2025, at 18:48, Michael Richardson wrote:
>
> Nishanth Sastry via Starlink <starlink@lists.bufferbloat.net> wrote:
> > Great question. One clear and easy answer is that this is meant to be
> > an IRTF group rather than an IETF group, so with more of a focus on
> > identifying long-term research issues (that are of interest to the IETF
> > community) rather than on forming standards. We think there is a need
> > for an IRTF-lens to draw clear boundaries, identify overlaps, and
> > connect interfaces across architectures (e.g., Bundle Protocol/IP),
> > different variants the space domain (LEO/DeepSpace), phenomena
> > (Delay/Disruptions down to relativistic effects), and entities (IETF,
> > CCSDS, IOAG, but also the private players in the space, like
> > Starlink).
>
> Did you consider rechartering dtnrg ?
>
> > That said, the meeting is really to figure out what the community
> > thinks there is a need for, and indeed, whether there is a need for
> > something like this. Why not come to the meeting (virtually or in
> > person) to provide your views and inputs on things we could/should do?
> > Of course, appreciate that the Bangkok timezone may not work out for
> > some, but if we manage to get this going, we are hoping to have regular
> > activities in other IETF meetings which will be in other time zones.
>
> It seems to me that there is research needed in predictable routing flaps.
> Most routing protocols today assume that failures are random.
>
> There is some work in RPL (RFC6550) as related to 6TISCH (TSCH) where
> channels come and go already, but that is multiple times/second vs multiple
> times/hour.
>
> --
> ] Never tell me the odds! | ipv6 mesh networks [
> ] Michael Richardson, Sandelman Software Works | IoT architect [
>
> ] mcr@sandelman.ca http://www.sandelman.ca/ | ruby on rails [



-- 
Dave Täht CSO, LibreQoS
"A perfect storm" - https://www.youtube.com/watch?v=CQX1PmRULU0

  reply	other threads:[~2025-03-06 23:11 UTC|newest]

Thread overview: 13+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2025-03-05 16:31 Nishanth Sastry
2025-03-05 19:22 ` Dave Taht
2025-03-05 21:25   ` Nishanth Sastry
2025-03-06 18:48     ` Michael Richardson
2025-03-06 22:37       ` Nishanth Sastry
2025-03-06 23:10         ` Dave Taht [this message]
2025-03-06 23:45           ` Michael Richardson
2025-03-07 10:28           ` mohan
2025-03-07 15:09             ` Nishanth Sastry
2025-03-11 23:03               ` Sirapop Theeranantachai
2025-03-05 19:37 ` Ulrich Speidel
2025-03-05 20:31   ` J Pan
2025-03-07  0:03 Nitinder Mohan

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='CAA93jw57bwPEFLN8eMmLD0O_0WsAk=R12j8kgMLgYCsdfX_ftg@mail.gmail.com' \
    --to=dave.taht@gmail.com \
    --cc=Edward.Birrane@jhuapl.edu \
    --cc=ek.ietf@gmail.com \
    --cc=juanfraire@gmail.com \
    --cc=kevin.shortt@airbus.com \
    --cc=mcr@sandelman.ca \
    --cc=n.sastry@surrey.ac.uk \
    --cc=ott@in.tum.de \
    --cc=rick@tropicalstormsoftware.com \
    --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