Starlink has bufferbloat. Bad.
 help / color / mirror / Atom feed
From: "Dick Roy" <dickroy@alum.mit.edu>
To: "'Mikael Abrahamsson'" <swmike@swm.pp.se>,
	"'Dave Taht'" <davet@teklibre.net>
Cc: <starlink@lists.bufferbloat.net>
Subject: Re: [Starlink] 69,000 Users
Date: Wed, 30 Jun 2021 13:40:00 -0700	[thread overview]
Message-ID: <803A2F6FE03445C8AC32761B74813E19@SRA6> (raw)
In-Reply-To: <alpine.DEB.2.20.2106302031320.13354@uplift.swm.pp.se>

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

 

 

-----Original Message-----
From: Starlink [mailto:starlink-bounces@lists.bufferbloat.net] On Behalf Of
Mikael Abrahamsson
Sent: Wednesday, June 30, 2021 11:33 AM
To: Dave Taht
Cc: starlink@lists.bufferbloat.net
Subject: Re: [Starlink] 69,000 Users

 

On Wed, 30 Jun 2021, Dave Taht wrote:

 

> I don't think data caps are needed. fairness is needed.

 

[RR] Engineers always think fairness is "needed".  Corporate managers who
make the real decisions couldn't care less about "fairness".  It's all about
income - expenditures which is simply PROFIT!  When fair becomes profitable,
you'll see it. Until then,dream on.

 

LTE has pretty good airtime fairness (but FIFO per customer). Still 

doesn't work very well when there isn't enough airtime to satisfy demand.

[RR] There will NEVER be enough supply (of information carrying capacity in
the network) to meet demand all the time.  The reason is simple, until the
supply is exhausted, there's gold in them thar hills and the carriers are
not going to leave it there.  They will fill their pipes until they burst,
knowing that there is little if anything their customers will do about it
until their pain threshold is exceed, and they spend a helluva lot of money
on psychologists to let them know where that breaking point is and they aim
to get there ASAP. Why?? PROFIT and MARKET CAP!  Business 101! 

 

> I would prefer a solution that just billed for usage over a minimum.

 

Well, data caps is similar to this. People generally don't like to get 

billed automatically upon higher usage, thus data caps can be used and 

people will have to go to some self-service page and "pay more" if they're 

over the cap, to get a higher cap.

[RR] The people in charge at the carriers hate caps . they want customers
unknowingly pouring cash into their coffers. CAPs came about when consumers
complained to the regulators, not one day before! CAPs are nothing more than
a compromise that forces the carriers to let their customers know when they
are about to get sc___d. 

 

All communication networks ultimately reach an "uncomfortable equilibrium"
where all parties are unhappy, but not unhappy enough to quit the game.  

 

Thinking that there is some technical means by which 1Gbps can be shoved
through a pipe whose maximum possible throughput is only a fraction of that
data rate is misguided thinking. More importantly, fairness is in the "eye
of the beholder". One man's fairness is another man's inequity. The point is
that any algorithm for handling packets in a congested/overloaded network at
best will satisfy those that run the networks and not disappoint their
customers "too much". It's bloody obvious that finding the algorithm or
algorithms that achieve these two goals is the only path to success.

 

RR  

 

-- 

Mikael Abrahamsson    email: swmike@swm.pp.se


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

  reply	other threads:[~2021-06-30 20:40 UTC|newest]

Thread overview: 19+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2021-06-30  2:00 Daniel AJ Sokolov
2021-06-30  5:24 ` David Lang
2021-06-30  5:48   ` Dave Taht
2021-06-30  7:13     ` [Starlink] routing capability in starlinks Dave Taht
2021-06-30 14:43       ` Michael Richardson
2021-06-30 23:56         ` Nick Buraglio
2021-06-30  7:23     ` [Starlink] 69,000 Users Mike Puchol
2021-06-30  7:30       ` David Lang
2021-06-30  7:43         ` Mike Puchol
2021-06-30  7:51         ` Dave Taht
2021-06-30  9:57         ` Mikael Abrahamsson
2021-06-30 14:24           ` Dave Taht
2021-06-30 18:33             ` Mikael Abrahamsson
2021-06-30 20:40               ` Dick Roy [this message]
2021-06-30 23:33         ` Daniel AJ Sokolov
2021-07-01  0:00           ` David Lang
2021-07-01  0:03             ` Daniel AJ Sokolov
2021-07-01  0:20               ` David Lang
2021-06-30 10:53       ` Jared Mauch

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=803A2F6FE03445C8AC32761B74813E19@SRA6 \
    --to=dickroy@alum.mit.edu \
    --cc=davet@teklibre.net \
    --cc=starlink@lists.bufferbloat.net \
    --cc=swmike@swm.pp.se \
    /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