From: Michael Richardson <mcr@sandelman.ca>
To: bloat@lists.bufferbloat.net
Subject: Re: [Bloat] I hate my ISP
Date: Sun, 03 May 2020 11:59:28 -0400 [thread overview]
Message-ID: <22241.1588521568@localhost> (raw)
In-Reply-To: <ccb7b23a-4b78-07ec-8ac8-e25f95cb98bf@gmail.com>
[-- Attachment #1: Type: text/plain, Size: 2112 bytes --]
Jan Ceuleers <jan.ceuleers@gmail.com> wrote:
>> Hello,
>>
>> So evidently Viasat doesn't know how to handle bufferbloat at all with
>> their exede satellite service. It's been really bad today. I've
>> attached flent's tcp_1up results for those interested. Note that the
>> base RTT is 600ms and upload is usually 5Mbps. I don't have the rrul
>> test results because that test kept crashing >(.
>>
>> Now I'm going to go back to watching webpages take a minute to load.
> Based on their Wikipedia page it seems that Viasat provide service
> based on geosynchronous satellites. Your poor user experience may
> therefore not be due solely to bufferbloat but rather to pure
> transmission latency.
of course, bufferbloat due to excessive ram is generally impossible to
distinguish from a link with a large latency such as a geosynchronous hop...
Lots of satellite systems have in the past done various TCP ACK stuffing or
even forced TCP proxying to fill the pipe. I don't know what the situation is
these days... I know that window scaling in TCP was one of the architectural
solutions.
In a situation with more simultaneous streams than otherwise, the satellite
link ought to be more easily filled without resort to such evil tricks.
What if the base stations don't *know* that, and they continue to attempt
to attract larger TCP flows, which are then bufferbloated in the base
stations. The base station has already ACK'ed the data, so it has to buffer
it, taking responsability for it. But, if that base station doesn't get as
many time slices as it expects, then it could well become a bufferbloat
itself.
(I wish I knew more about this. I always wanted to work in this industry.
I still want to know what Starlink will do that is "simpler than IPv6", yet
permit e2e latencies good enough for p2p game play)
--
] 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 [
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 487 bytes --]
prev parent reply other threads:[~2020-05-03 15:59 UTC|newest]
Thread overview: 4+ messages / expand[flat|nested] mbox.gz Atom feed top
2020-05-03 3:57 Taran Lynn
2020-05-03 6:13 ` Jan Ceuleers
2020-05-03 6:22 ` Taran Lynn
2020-05-03 15:59 ` Michael Richardson [this message]
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/bloat.lists.bufferbloat.net/
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=22241.1588521568@localhost \
--to=mcr@sandelman.ca \
--cc=bloat@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