From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from tuna.sandelman.ca (tuna.sandelman.ca [IPv6:2607:f0b0:f:3:216:3eff:fe7c:d1f3]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by lists.bufferbloat.net (Postfix) with ESMTPS id 7DFBC3B29D for ; Sun, 3 May 2020 11:59:30 -0400 (EDT) Received: from sandelman.ca (obiwan.sandelman.ca [209.87.249.21]) by tuna.sandelman.ca (Postfix) with ESMTP id 68C213897B for ; Sun, 3 May 2020 11:57:31 -0400 (EDT) Received: from localhost (localhost [IPv6:::1]) by sandelman.ca (Postfix) with ESMTP id 12B94135 for ; Sun, 3 May 2020 11:59:28 -0400 (EDT) From: Michael Richardson To: bloat@lists.bufferbloat.net In-Reply-To: References: <918a1b60-cc5c-593b-de0f-5890a8a3b3d7@gmail.com> X-Mailer: MH-E 8.6; nmh 1.7+dev; GNU Emacs 25.1.1 X-Face: $\n1pF)h^`}$H>Hk{L"x@)JS7<%Az}5RyS@k9X%29-lHB$Ti.V>2bi.~ehC0; <'$9xN5Ub# z!G,p`nR&p7Fz@^UXIn156S8.~^@MJ*mMsD7=QFeq%AL4m Subject: Re: [Bloat] I hate my ISP X-BeenThere: bloat@lists.bufferbloat.net X-Mailman-Version: 2.1.20 Precedence: list List-Id: General list for discussing Bufferbloat List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 03 May 2020 15:59:30 -0000 --=-=-= Content-Type: text/plain Jan Ceuleers 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 [ --=-=-= Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iQEzBAEBCAAdFiEEbsyLEzg/qUTA43uogItw+93Q3WUFAl6u6l8ACgkQgItw+93Q 3WXzUQf/VgWTHzImMXKjknvX0EjJLWP7L9Eeucg/JwW7Jzs/dHboLbicXV+MkEhp 2rhg/DNFrjHxdjBApBhZhgEi3BZ/CPhalUBC6L7tc4Ys+ipcQ47UM0aGdEtuhmSE /pDEWAYZMiy3Ln4/TneZWiGflSHPLoCgAP+za6GQWDTHCWrpcL35j4EwN5ZmAyZn ywXoHBHPd56jBARIYXrNLsb0aiEvQVe+HeGHDE/POfNDj9xJYAHPf7qm6lFsAXhk eCR5P+RbogzTbegvx+KZGaMRXqa9b7SXtw/NRB464iCvDDKd5rkYQEhG+fz08LBT eq62ayAN8lZuIURlO5IHcABwSLlniQ== =AiXJ -----END PGP SIGNATURE----- --=-=-=--