[Bloat] I hate my ISP

[Bloat] I hate my ISP

[Taran Lynn]

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

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.

Best, Taran

[-- Attachment #2: tcp_1up-2020-05-02T204707.924619.flent.gz --]
[-- Type: application/gzip, Size: 10880 bytes --]

Re: [Bloat] I hate my ISP

[Jan Ceuleers]

On 03/05/2020 05:57, Taran Lynn 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.

Re: [Bloat] I hate my ISP

[Taran Lynn]

I doubt its pure transmission latency. Most of the time I consistently
get ~600ms RTT, and its only this Saturday, when internet usage spikes,
that it's been really bad. Plus, you can clearly see the saw tooth
pattern of AIMD congestion control in the ping graphs, with amplitudes
of up to several seconds. I feel pretty confident in saying that this is
bufferbloat.

On 5/2/20 11:13 PM, Jan Ceuleers wrote:
> On 03/05/2020 05:57, Taran Lynn 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.
> _______________________________________________
> Bloat mailing list
> Bloat@lists.bufferbloat.net
> https://lists.bufferbloat.net/listinfo/bloat
> 

Re: [Bloat] I hate my ISP

[Michael Richardson]

[-- 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 --]