Re: [Bloat] Apple ECN, Bufferbloat, CoDel
On Sun, 14 Jun 2015, Mark Andrews wrote: > NAT64 and DNS64 need to die. There are much better solutions to > providing IPv4 over IPv6 than NAT64 and DNS64 and 464XLAT that grew > from NAT64 and DNS64. Please make it "NAT64 WITH DNS64 needs to die". It is too easy to forget that there is such a thing as NAT64-FE (RFC 7269). Fortunately, NAT64-FE is not used together with DNS64 in any remotely sane scenario, so it is not going to break DNSSEC. It is also a somewhat rare beast most of us never will have to deal with (I do, and it doesn't make me happy). -- "One disk to rule them all, One disk to find them. One disk to bring them all and in the darkness grind them. In the Land of Redmond where the shadows lie." -- The Silicon Valley Tarot Henrique Holschuh ___ Bloat mailing list Bloat@lists.bufferbloat.net https://lists.bufferbloat.net/listinfo/bloat
[Bloat] SIMET: nationwide bw/latency/jitter test effort in Brazil
On Sun, 20 Jul 2014, Rich Brown wrote:
> Now if we could get them to a) allow longer/bigger tests to circumvent
> PowerBoost, and b) include a latency measurement so people could point out
> their bufferbloated equipment.
You may find this interesting:
http://simet.nic.br/
NIC.br has it deployed nation-wide in Brazil, with remote endpoint servers
in most public IXPs ("PTTMetro" IXPs, which are also managed by NIC.br).
The end user client is available over the web (java applet), and also as a
mobile app for Android and iOS. There's also an openwrt-based firmware for
a very inexpensive home-router box ("SIMET box"), which they've been giving
out to the general public so as to increase their test coverage.
SIMET does bandwidth (TCP and UDP) as well as latency and jitter
measurements, but it doesn't attempt to measure bufferbloat so I never
thought of mentioning it around here.
One interesting detail is that SIMET measurements are trusted (as in "can
have legal standing in Brazil"): the SIMET system is certified[1] by
INMETRO, Brazil's national body for scientific, industrial and legal
metrology.
There's not much material in english about SIMET, unfortunately.
Outside of Brazil, I like the Berkeley ICSI Netalyzr
(http://netalyzr.icsi.berkeley.edu/). VERY comprehensive measurements and
several network diagnostics... and it does measure worst-case steady-state
latency (aka bufferbloat).
[1] "certified" is not exactly correct. I don't know an exact word in
english for "has been verified to be correctly calibrated in accordance with
the official measurement standards and procedures", in portuguese:
"aferido".
--
"One disk to rule them all, One disk to find them. One disk to bring
them all and in the darkness grind them. In the Land of Redmond
where the shadows lie." -- The Silicon Valley Tarot
Henrique Holschuh
___
Bloat mailing list
Bloat@lists.bufferbloat.net
https://lists.bufferbloat.net/listinfo/bloat
Re: [Bloat] RFC: Realtime Response Under Load (rrul) test specification
On Tue, 06 Nov 2012, Dave Taht wrote: > I have been working on developing a specification for testing networks > more effectively for various side effects of bufferbloat, notably > gaming and voip performance, and especially web performance as > well as a few other things that concerned me, such as IPv6 behavior, > and the effects of packet classification. When it is reasonably complete, it would be nice to have it as an informational or better yet, standards-track IETF RFC. IETF RFC non-experimental status allows us to require RRUL testing prior to service acceptance, and even add it as one of the SLA metrics on public tenders, which goes a long way into pushing anything into more widespread usage. -- "One disk to rule them all, One disk to find them. One disk to bring them all and in the darkness grind them. In the Land of Redmond where the shadows lie." -- The Silicon Valley Tarot Henrique Holschuh ___ Bloat mailing list Bloat@lists.bufferbloat.net https://lists.bufferbloat.net/listinfo/bloat
Re: [Bloat] Network computing article on bloat
On Tue, 26 Apr 2011, Wesley Eddy wrote: > On 4/26/2011 2:17 PM, Dave Taht wrote: > >"Big Buffers Bad. Small Buffers Good." > > > >"*Some* packet loss is essential for the correct operation of the Internet" > > > >are two of the memes I try to propagate, in their simplicity. Even > >then there are so many qualifiers to both of those that the core > >message gets lost. > > > The second one is actually backwards; it should be "the Internet can > operate correctly with some packet loss". Right now in the real world, it CANNOT operate correctly WITHOUT the use of aggressive packet loss to throttle back flows, or the queues just fill up to the brink, and then you start dropping all packets anyway. IMO, Dave's wodring get that point across a lot better. -- "One disk to rule them all, One disk to find them. One disk to bring them all and in the darkness grind them. In the Land of Redmond where the shadows lie." -- The Silicon Valley Tarot Henrique Holschuh ___ Bloat mailing list Bloat@lists.bufferbloat.net https://lists.bufferbloat.net/listinfo/bloat
[Bloat] tcp_ecn=2 (server-mode ECN)
On Wed, 13 Apr 2011 22:44 -0600, "Dave Taht" wrote: > He'd not noticed the problem because ubuntu 10.4 (at least, he also > runs bsd) has tcp_ecn=2, which so far as I know "tries" a ECN enabled > connect then falls back to not using it. tcp_ecn=2 is "server mode ECN". It will enable ECN if, and ONLY if, the other side requests it during the initial TCP handshake. AFAICT, it effectively disables ECN on all outgoing connections and enables it on incoming connections should the other host request ECN (which it won't when it is also running in tcp_ecn=2 mode). It is also the kernel default, and AFAIK, the default on every 2010+ Linux distro stable releases. If you want to use ECN, you have to set tcp_ecn=1 in your Linux box when you're the one originating TCP connections. -- "One disk to rule them all, One disk to find them. One disk to bring them all and in the darkness grind them. In the Land of Redmond where the shadows lie." -- The Silicon Valley Tarot Henrique Holschuh ___ Bloat mailing list Bloat@lists.bufferbloat.net https://lists.bufferbloat.net/listinfo/bloat
Re: [Bloat] Usage Based Billing - It's All About Perceived Congestion
On Mon, 28 Feb 2011 13:56 -0800, "richard" wrote: > As some have remarked, UBB, especially here and now in Canada, is one > response to what we're dealing with in bufferbloat. It is not always bufferbloat that is the driving cause for UBB. In Brazil, UBB is often used to help heavily oversubscribed networks (usually by the DOCSIS networks and 3G networks) escape consumer wrath. UBB is not the only "bandwidth usage deterrent" employed here by the large broadband ISPs. Cutting down service to as low as 100kbit/s downstream and 30kbit/s upstream when the consumer goes over a monthly quota, limiting concurrent tcp sessions, and extremely severe shaping of P2P traffic are used as alternatives to UBB. Without UBB or other "bandwidth usage deterrents", the users will notice more readily that they are allotted far less than the bandwidth required to get 100% of the nominal throughput they paid for, as there just isn't enough bandwidth in the access, backhaul and even backbone networks, let alone peering and transit links. The broadband service contracts _do_ often make it clear you only are guaranteed 10% (yes, that's right, ten percent) of the maximum throughput, and also about TCP concurrent flow limits and UBB, but people will only take notice of that if they're subject to such ridiculous service levels constantly. And I very much doubt UBB is strongly related to oversubscribing just in Brazil. We need to be careful to not make bufferbloat the network bogeyman, doing so can only backfire in the long run. -- "One disk to rule them all, One disk to find them. One disk to bring them all and in the darkness grind them. In the Land of Redmond where the shadows lie." -- The Silicon Valley Tarot Henrique Holschuh ___ Bloat mailing list Bloat@lists.bufferbloat.net https://lists.bufferbloat.net/listinfo/bloat
