Re: [Bloat] [Rpm] [Starlink] [LibreQoS] net neutrality back in the news

[Jan Ceuleers via Bloat]

On 30/09/2023 14:19, Sebastian Moeller via Bloat wrote:
>
> P.S.: Of course if we look close enough we surely can find corner-cases where 
> either the EU regulations or the translation into national law result in less 
> desirable outcomes, but "nothing is perfect" and all in all the regulations 
> seem to be "good enough". With the caveat that explicitly excluding ISP 
> interconnect from the regulations BEREC essentially pointed the way for ISPs 
> wanting to monetize their eye-balls twice to do so via interconnects, but 
> that only works for the 800 pound gorillas and generally is not a game 
> smaller ISPs can play. I do understand why BEREC wants to stay out of the 
> interconnection issue, as this is rather complicated and the market seems to 
> generally work okay-ish (that is not badly enough to make intervention a 
> hot-button issue for voters and hence politicians).
EU Regulations have force of law in and of themselves; they need not be
transposed into national law. That sets Regulations apart from
Directives: those do need to be transposed into national law. Having
said that many member states may adopt laws that implement Regulations,
but in case of any differences between those national laws and the
Regulations in question the Regulations will prevail in the courts.
___
Bloat mailing list
Bloat@lists.bufferbloat.net
https://lists.bufferbloat.net/listinfo/bloat

[Bloat] This is the bufferbloat mailing list

[Jan Ceuleers via Bloat]

Could I suggest that the discussion return to that topic please?
___
Bloat mailing list
Bloat@lists.bufferbloat.net
https://lists.bufferbloat.net/listinfo/bloat

Re: [Bloat] [Starlink] Annoyed at 5/1 Mbps...

[Jan Ceuleers via Bloat]

On 21/03/2023 13:31, Sebastian Moeller via Bloat wrote:
(...)
> Noki's proprietary (aka not ITU) @% Gbps PON seems to be abbreviated 25GS-PON.

25GSPON is in fact not proprietary. It was standardised by means of an
MSA (multi-source agreement) rather than through the ITU-T, but it is
standardised and not limited to a single vendor.

https://www.25gspon-msa.org/

HTH, Jan
___
Bloat mailing list
Bloat@lists.bufferbloat.net
https://lists.bufferbloat.net/listinfo/bloat

Re: [Bloat] FCC requires broadband "Nutritional Label"

[Jan Ceuleers via Bloat]

On 18/11/2022 13:36, Rich Brown via Bloat wrote:
> Even though the label only specifies "typical latency", I have a sense that 
> this is a good step forward.

Shame that the latency has to be specified in Ms (megaseconds) though.
ISPs will feel justified in rounding it down to 0.

___
Bloat mailing list
Bloat@lists.bufferbloat.net
https://lists.bufferbloat.net/listinfo/bloat

Re: [Bloat] ONTs and ITU - T G.988

[Jan Ceuleers]

On 13/01/2022 00:42, Dave Taht wrote:
> My 1st question is - are there any ONTs that actually do do pause
> frames? Or providers that configure for them?

In my (limited) experience most network operators want ONTs to be
transparent to pause frames.

> My second is - what is a cheap way to setup a lab to emulate a good,
> common, version of gpon e2e?

I'm not aware of a cheap way. You need an OLT and a few ONTs.

> Third - what OS do these things run? Who makes a "good" one?

Linux. But forwarding is offloaded so not dealt with by the Linux
networking stack.

___
Bloat mailing list
Bloat@lists.bufferbloat.net
https://lists.bufferbloat.net/listinfo/bloat

Re: [Bloat] [Cerowrt-devel] uplink bufferbloat and scheduling problems

[Jan Ceuleers]

On 01/12/2021 21:26, David P. Reed wrote:
> In any CSMA link (WiFi), there is no "up" or "down". There is only
> sender and receiver, and each station and the AP are always doing both.

Generally though the silicon used in WiFi APs is much more capable than
that used in STAs. The capabilities of (particularly STA-side) silicon
are different as they relate to uplink and downlink.

Of course for a given AP-STA link a common subset of capabilities needs
to be used, but that subset might be different in either direction.

The antennas (number and gain), receiver sensitivity and transmit power
are also different.

A simple example of a reason why uplink and downlink might be different:
the achievable bitrate on the AP-to-STA downlink might be higher than
the uplink because the AP's transmit power is higher. In order to be
able to achieve the same bitrate if the STA's transmit power is lower
the AP's receiver sensitivity would have to be that much better.

Generalising to other shared-media technologies: whenever the UL/DL link
budgets are different the link is going to by asymmetric.

Jan
___
Bloat mailing list
Bloat@lists.bufferbloat.net
https://lists.bufferbloat.net/listinfo/bloat

Re: [Bloat] fq_codel wikipedia page in progress

[Jan Ceuleers]

On 15/11/2021 23:47, Kenneth Porter wrote:
> On 11/15/2021 2:15 PM, Kenneth Porter wrote:
>>
>> I'd also suggest changing the page title to match the capitalization
>> and hyphen of the RFC.
>>
>> https://datatracker.ietf.org/doc/html/rfc8290
> 
> Following my own advice to mimic other protocol pages, I suggest that
> the title be the full, unabbreviated name of the protocol:
> 
> Flow Queue Controlled Delay Packet Scheduler and Active Queue Management
> Algorithm
> 
> Or maybe some subset of that. Use the acronym FQ-CoDel (taken from the
> RFC) in the body.

But when doing that also create a redirect page such that people who
search for FQ-CoDel find the main page.
___
Bloat mailing list
Bloat@lists.bufferbloat.net
https://lists.bufferbloat.net/listinfo/bloat

Re: [Bloat] Fwd: [Galene] Galene news

[Jan Ceuleers]

On 04/09/2021 16:20, Dave Taht wrote:
> I like galene a lot, because it's written in pure go, and has a pretty
> good implementation of the gcc congestion control algorithm. It also
> can be made to run
> on a home router, and the prospect of sending baby video from upstairs
> to downstairs and not through the cloud pleases me, as does one day
> finding some security camera system that does the same.

https://zoneminder.com/
___
Bloat mailing list
Bloat@lists.bufferbloat.net
https://lists.bufferbloat.net/listinfo/bloat

Re: [Bloat] fcc input

[Jan Ceuleers]

On 26/03/2021 20:09, Dave Taht wrote:
> I have often thought hard about trying to explain things better via
> animations, and on more than one occasion tried to find an animator
> who could turn this old 8m talk from "people as packets" into "unruly
> animals as packets".
> 
> https://www.youtube.com/watch?v=Rb-UnHDw02o&t=1657s
> 
> But that requires both money and time, and I've usually had neither.
> Grant money would be nice for a whole string of educational videos,
> but not being part of the MICA complex has made that difficult. If I
> ever get caught up on bills, and some other pressing problems, perhaps
> we could do a kickstarter campaign to get some things animated.

I have often admired Randall Munroe's ability to grasp and satirise
sometimes quite complex concepts. Perhaps he could be prevailed upon to
draw a bufferbloat-inspired cartoon? He publishes his work at xkcd.com
under a Creative Commons license.
___
Bloat mailing list
Bloat@lists.bufferbloat.net
https://lists.bufferbloat.net/listinfo/bloat

Re: [Bloat] Router congestion, slow ping/ack times with kernel 5.4.60

[Jan Ceuleers]

On 07/11/2020 13:37, Thomas Rosenstein via Bloat wrote:
> Nonetheless, I tested it and no difference :)

The relevant test would be to run your experiment while IPv6 is
completely disabled in the kernel.
___
Bloat mailing list
Bloat@lists.bufferbloat.net
https://lists.bufferbloat.net/listinfo/bloat

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.
___
Bloat mailing list
Bloat@lists.bufferbloat.net
https://lists.bufferbloat.net/listinfo/bloat

Re: [Bloat] datapoint from one vendor regarding bloat

[Jan Ceuleers]

On 11/04/2019 19:54, Jonathan Morton wrote:
>> On 11 Apr, 2019, at 1:38 pm, Mikael Abrahamsson  wrote:
>>
>> The mbs defines the MBS for the PIR bucket and the cbs defines the CBS for 
>> the CIR bucket
> 
> What do these lumps of jargon refer to?

If you're truly interested in the answer: the document Mikael links to
contains the answers.
___
Bloat mailing list
Bloat@lists.bufferbloat.net
https://lists.bufferbloat.net/listinfo/bloat

Re: [Bloat] Does VDSL interleaving+FEC help bufferbloat?

[Jan Ceuleers]

On 04/01/2019 18:10, Dave Taht wrote:
> dsl interleave was added primarily to make multicast udp tv streams
> work better (as they are very intolerant of packet loss). Often (as in
> free's implementation) these streams are "invisible" to the overlying
> IP applications. It typically adds at least 6ms of delay to an already
> slow technology.
> 
> Do measure unloaded latency with and without it on, it's been a long
> time since I fiddled with it

Interleaving isn't a parameter that mere end-users* can influence - it
is part of the line's profile, and that's determined by the network
operator.

*: you know, the people who pay the bills...
___
Bloat mailing list
Bloat@lists.bufferbloat.net
https://lists.bufferbloat.net/listinfo/bloat

Re: [Bloat] vyatta in AT&T 5G gear

[Jan Ceuleers]

On 16/10/2018 17:14, Dave Taht wrote:
> And what was so wrong with the "everything as a file" model??

On a single box - not a lot.

On a 5G network, which might consist of 10^3 - 10^5 boxes you need
aggregation and abstraction layers.
___
Bloat mailing list
Bloat@lists.bufferbloat.net
https://lists.bufferbloat.net/listinfo/bloat

Re: [Bloat] first bufferbloat free cablemodem?

[Jan Ceuleers]

On 06/10/18 05:14, Dave Taht wrote:
> I would so love for the review on this to be true.
> 
> https://express.google.com/product/Arris-SURFboard-Cable-Modem-and-AC2350-Wi-Fi-Router-with-Arris-Secure-Home-Internet-by-McAfee/0_17937886568302066345_0
> 

Could you post a link that can be viewed from outside the US?
___
Bloat mailing list
Bloat@lists.bufferbloat.net
https://lists.bufferbloat.net/listinfo/bloat

Re: [Bloat] [Make-wifi-fast] [Cerowrt-devel] closing up my make-wifi-fast lab

[Jan Ceuleers]

On 30/08/18 22:36, bkil wrote:
> 1b.
> Let's assume that we are a good citizen using more expensive highly
> directional antennae and we live at the perimeter. Considering that

For some reason I only received this today.

Your points about the use of directional antennas should be mitigated,
at least to some degree, by the use of MIMO (for decent values of
"massive").
___
Bloat mailing list
Bloat@lists.bufferbloat.net
https://lists.bufferbloat.net/listinfo/bloat

Re: [Bloat] [Cerowrt-devel] beating the drum for BQL

[Jan Ceuleers]

On 24/08/18 15:44, Mikael Abrahamsson wrote:
> On Fri, 24 Aug 2018, Jan Ceuleers wrote:
> 
>> On 24/08/18 13:46, Jan Ceuleers wrote:
>>> On 24/08/18 10:06, Dave Taht wrote:
>>>> Random curiosity: what do various SFP+ interfaces (notably gpon) eat?
>>>
>>> I have taken a look at a couple. I see numbers in the range 1.7 - 2.2W
>>> for GPON ONTs.
>>
>> Just to be clear: that's for GPON SFP ONTs.
> 
> Just the SFP, right?

Yes
___
Bloat mailing list
Bloat@lists.bufferbloat.net
https://lists.bufferbloat.net/listinfo/bloat

Re: [Bloat] [Cerowrt-devel] beating the drum for BQL

[Jan Ceuleers]

On 24/08/18 13:46, Jan Ceuleers wrote:
> On 24/08/18 10:06, Dave Taht wrote:
>> Random curiosity: what do various SFP+ interfaces (notably gpon) eat?
> 
> I have taken a look at a couple. I see numbers in the range 1.7 - 2.2W
> for GPON ONTs.

Just to be clear: that's for GPON SFP ONTs.
___
Bloat mailing list
Bloat@lists.bufferbloat.net
https://lists.bufferbloat.net/listinfo/bloat

Re: [Bloat] [Cerowrt-devel] beating the drum for BQL

[Jan Ceuleers]

On 24/08/18 10:06, Dave Taht wrote:
> Random curiosity: what do various SFP+ interfaces (notably gpon) eat?

I have taken a look at a couple. I see numbers in the range 1.7 - 2.2W
for GPON ONTs.
___
Bloat mailing list
Bloat@lists.bufferbloat.net
https://lists.bufferbloat.net/listinfo/bloat

Re: [Bloat] [Cerowrt-devel] beating the drum for BQL

[Jan Ceuleers]

On 24/08/18 01:35, Sebastian Moeller wrote:
>   Sure, but my ISP charged 4 EUR per month for the DSL-router that adds 
> up to 12*2*4 = 96 EUR over the 2 years contract duration and to 12*5*4 = 240 
> over my renting duration; assuming that my ISP does not need to make a profit 
> on this device (after all I am renting this to be able to consume internet 
> and telephone from them) that is considerably more that 20-40 EUR. This is 
> especially farcical since until a few years ago the dsl-routers have been 
> given for "free" and when they switched to mandatory renting the baseplan 
> price was not reduced by the same amount. I guess what I want to convey is 
> while cost is imprtant it is not a goo d excuse to distribute underpowered 
> devices

A few points:

1. The CPE makers sell these devices to ISPs wholesale. The price point
they have to design to is determined by those ISPs' willingness to pay,
which is also influenced/co-determined by the market price. What ISPs
manage to rake in over the technical life span of those devices has
nothing to do with it - the CPE makers don't get a cut of the rental
charges. The economics explain the behaviour of both the ISP and the CPE
maker very well - nothing's going to change without some substantial
disruption.

2. Mandatory rental of CPE is a racket that's seen in various markets
(e.g. STBs in the cable market). It is more defendable in some
situations than in others. For example cable companies get away with it
because of a lack of sufficient standardisation (which is also not going
to be improved to the point where the STB market can be completely
opened because the standards are set by a cable industry body).

It's not so defendable in the DSL market anymore, although I can tell
you from experience that there's a lot of very poor DSL modems out there
which cause interop problems in the real world, including interference
with other people's DSL lines. The network operator having firm control
of which DSL modems are permitted onto their network helps performance
for all of their customers. But this can also be achieved by means other
than mandatory rental of CPE: there are countries where the regulator
oversees a DSL modem certification scheme, and end-users can then go out
and buy a certified device through their preferred retail outlet, at
very reasonable prices.

FWIW I bought three STBs for 50EUR from my cable company 5 years ago,
rather than renting them for 7EUR/month each.

3. ISPs and network operators will buy the cheapest CPE that meets their
needs. In respect of traffic throughput they will invariably use Ookla
to test. This is why I've been saying for quite some time that unless we
can convince Ookla to penalise bufferbloat we won't make a dent in how
CPE are designed in this respect.

Jan
___
Bloat mailing list
Bloat@lists.bufferbloat.net
https://lists.bufferbloat.net/listinfo/bloat

Re: [Bloat] [Cerowrt-devel] beating the drum for BQL

[Jan Ceuleers]

On 23/08/18 15:06, Sebastian Moeller wrote:
>   Or we could convince customers to stop buying toy router's that only 
> work under a severely limited set of circumstances and opt for devices that 
> pack enough CPU-punch to be actually adequate for modern internet speed 
> tiers, no? Now if the packet accelerator is jus there to help save energy for 
> typical cases but the CPU is powerful enough to handle a modern line with all 
> the bells and whistles customers except, then I am all for it, but if the 
> packet accelerator is just there to paper over an anemic CPU...

Not realistic, and also not environmentally friendly.

Doing packet forwarding in hardware is much more energy efficient, for
example. So not only is the hardware cheaper, it doesn't generate as
much heat, is cheaper to run, etc.

Jan
___
Bloat mailing list
Bloat@lists.bufferbloat.net
https://lists.bufferbloat.net/listinfo/bloat

Re: [Bloat] [Cerowrt-devel] fcc initial comments due sept 10

[Jan Ceuleers]

On 11/08/18 05:34, dpr...@deepplum.com wrote:
> Just to remind everyone, "Broadband" is a term invented by the cable industry 
> to describe "bundled cable TV, phone, and Internet", pretty much "aka DOCSIS".

No, it's not.

Not that's important, but the term was coined many years ago by the
telecoms industry to distinguish high-bandwidth services from
low-bandwidth ones, such as telephony, voice band modems and ISDN, which
were referred to as narrowband services.

For example, ADSL was regarded as a broadband service.
___
Bloat mailing list
Bloat@lists.bufferbloat.net
https://lists.bufferbloat.net/listinfo/bloat

[Bloat] Fwd: Fixing bufferbloat with PF and OpenBSD

[Jan Ceuleers]

 Forwarded Message 
Subject:Fixing bufferbloat with PF and OpenBSD
Date:   Wed, 04 Jul 2018 09:17:55 GMT
From:   OpenBSD Journal <>



Fixing bufferbloat with PF and OpenBSD In this post
,
Paul Smith shows how to reduce buffer bloat and improve interactive
traffic latencies.

Long time ago, Daniel Hartmeier wrote a nice piece
 on how to prioritize ACKs and small
packets using ALTQ in PF to sustain download speeds on (mostly)
assymetric links, but since then PF and queuing has undergone quite a
few changes.

To see an example on how the new rulesets should look, and how to score
more internet points on speed tests, head over to his article.
___
Bloat mailing list
Bloat@lists.bufferbloat.net
https://lists.bufferbloat.net/listinfo/bloat

Re: [Bloat] [Cerowrt-devel] Invisibility of bufferbloat and its remedies

[Jan Ceuleers]

On 20/06/18 01:41, Jonathan Morton wrote:
>> On 19 Jun, 2018, at 11:34 pm, valdis.kletni...@vt.edu wrote:
>>
>> Do we have a good cookbook on how to determine the set-rate?
> 
> On DSL, the sync rates in each direction should usually be readable from the 
> modem; they are typically reported on the router's status page.  The 
> advertised rate is less reliable, to say the least.

I'm afraid that my DSL modem doesn't belong to the "usually" case. I
have a BBox3 from Proximus (Belgium). Proximus buys these from two
manufacturers: Technicolor and Sagemcom. I have the Sagemcom variant.

Proximus went out of their way to avoid that end users be able to query
the modem for its connection parameters. There is still an indirect way
to do so in the Sagemcom variant (and so I know that my modem provides
50Mbit/s down and 10Mbit/s up) but for marketing reasons Proxinus would
prefer its users not to know. The reason is that their principal
competitor, cable operator Telenet (owned by Liberty Global) would win
the game based on raw link speed.

So whereas I have access to the information I need to be able to
configure my queues there are others who do not, and it would be good
for a generic method to exist that derives the correct parameters from
measurements.

Kathy put it more succinctly: there is a good case for monitoring.
Question is what to monitor and how to set/modify the qdisc parameters.

Jan
___
Bloat mailing list
Bloat@lists.bufferbloat.net
https://lists.bufferbloat.net/listinfo/bloat

[Bloat] Fwd: [Bug 1436945] Re: devel: consider fq_codel as the default qdisc for networking

[Jan Ceuleers]

Took 3 years after Dave approached them, but Ubuntu is finally adopting
fq_codel as the default qdisc.


 Forwarded Message 
Subject: [Bug 1436945] Re: devel: consider fq_codel as the default qdisc
for networking
Date: Thu, 24 May 2018 14:50:09 -
From: Laurent Bonnaud 
Reply-To: Bug 1436945 <1436...@bugs.launchpad.net>
To: jan.ceule...@computer.org

I also see fq_codel used as default:

# cat /proc/sys/net/core/default_qdisc
fq_codel

# ip addr
[...]
2: eth0:  mtu 1500 qdisc fq_codel state
UP group default qlen 1000


** Changed in: linux (Ubuntu)
   Status: Confirmed => Fix Released

-- 
You received this bug notification because you are subscribed to the bug
report.
https://bugs.launchpad.net/bugs/1436945

Title:
  devel: consider fq_codel as the default qdisc for networking

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1436945/+subscriptions

___
Bloat mailing list
Bloat@lists.bufferbloat.net
https://lists.bufferbloat.net/listinfo/bloat

Re: [Bloat] The Blind Men and the Elephant.

[Jan Ceuleers]

On 12/02/18 18:55, Dave Taht wrote:
> I would certainly like to see translations and outreach into China...
> Taiwan... Japan... India... Central and South America... Africa...
> 
> but to me the simpler thing would be to garner folk to ask at
> vendor/isp press conferences: "Have you implemented RFC8290 yet? If
> not, when?"

Devil's advocate: "I don't intend to implement this because, as the
document says, it is only intended for examination, experimental
implementation and evaluation. I make real products, not experimental-ones."

___
Bloat mailing list
Bloat@lists.bufferbloat.net
https://lists.bufferbloat.net/listinfo/bloat

Re: [Bloat] The Blind Men and the Elephant.

[Jan Ceuleers]

On 12/02/18 02:11, Jim Gettys wrote:
> My version is up: dunno why the ietf web site doesn't have it up yet (It
> was supposed to go up 7pm ET).
> 
> https://gettys.wordpress.com/2018/02/11/the-blind-men-and-the-elephant/
> 
> We will push this on social media first thing in the morning.  Those of
> you in Europe, please do so as well (it's best to get the ball rolling
> in the morning in Europe before the western hemisphere wakes up).
> 
> Thank you all for all of your help.  I have tried to credit everyone
> appropriately as best I can.

Jim, an important audience for this blog is in China - that's where a
lot of the R&D of home routers happens. I know that China is currently
rushing to get things finished before Chinese New Year. I submit that
you need to think about a relaunch when China is back.
___
Bloat mailing list
Bloat@lists.bufferbloat.net
https://lists.bufferbloat.net/listinfo/bloat

Re: [Bloat] [Make-wifi-fast] benefits of ack filtering

[Jan Ceuleers]

On 03/12/17 11:35, Juliusz Chroboczek wrote:
> I'm lost here.  What exact problem is the ACK hack supposed to work
> around?  Ridiculous amount of asymmetry in the last-hop WiFi link, or
> outrageous amounts of asymmetry in a transit link beyond the last hop?

My understanding is that the issue that gave rise to this discussion was
concerned with upstream bandwidth conservation in the uplink of a DOCSIS
network by the cable modem dropping a large percentage of upstream TCP ACKs.

One element of that discussion was the question as to whether it was OK
for middleboxes (such as in this case cable modems) to reduce the number
of TCP ACKs, or whether instead the TCP stacks in the endpoints should
be made to send fewer such ACKs in the first place.

I then added more confusion by saying that in the case of wifi-connected
endpoints the upstream TCP ACKs also compete for airtime with the
downstream flow. Of course this no longer has anything to do with the
cable modem.
___
Bloat mailing list
Bloat@lists.bufferbloat.net
https://lists.bufferbloat.net/listinfo/bloat

Re: [Bloat] benefits of ack filtering

[Jan Ceuleers]

On 01/12/17 01:28, David Lang wrote:
> Stop thinking in terms of single-flow benchmarks and near idle
> 'upstream' paths.

Nobody has said it so I will: on wifi-connected endpoints the upstream
acks also compete for airtime with the downstream flow.
___
Bloat mailing list
Bloat@lists.bufferbloat.net
https://lists.bufferbloat.net/listinfo/bloat

Re: [Bloat] Steam In Home Streaming on ath9k wifi

[Jan Ceuleers]

Resending with the from-address with which I'm subscribed to the list

On 26/11/17 18:53, Dave Taht wrote:
> On Sun, Nov 26, 2017 at 2:05 AM, Jonathan Morton  
> wrote:
>> Another explanation for latency spikes on the order of 100ms is that a
>> periodic (and wholly unnecessary) scan for other APs is run, which requires
>> the wifi radio to be temporarily tuned away from the currently associated
>> AP's frequency.
> 
> I'd written that up here:
> 
> http://blog.cerowrt.org/post/disabling_channel_scans/
> 
> Which was improved in some release of network manager
> 
> https://bugs.launchpad.net/ubuntu/+source/network-manager/+bug/373680

Dave,

Thanks, but that's not the same problem I experienced. Yours was
entirely client-side (i.e. it was behaviour of Network Manager). My
problem was due to the AP asking the client to periodically perform
scans (by means of hostapd's obss_interval parameter).

Similar (but not the same) symptoms - different cause.

Jan


___
Bloat mailing list
Bloat@lists.bufferbloat.net
https://lists.bufferbloat.net/listinfo/bloat

Re: [Bloat] Steam In Home Streaming on ath9k wifi

[Jan Ceuleers]

On 26/11/17 14:03, Jan Ceuleers wrote:
> Disabling the scans needed to be done on the AP side though (in
> hostapd.conf):
> 
> # If set non-zero, require stations to perform scans of overlapping
> # channels to test for stations which would be affected by 40 MHz traffic.
> # This parameter sets the interval in seconds between these scans.
> Setting this
> # to non-zero allows 2.4 GHz band AP to move dynamically to a 40 MHz
> channel if
> # no co-existence issues with neighboring devices are found.
> 
> This was set to 10 when I did the first test. I have now reset it to 0
> (the default) which results in the above improved stats.

I failed to mention the name of the hostapd.conf parameter in question.
Sorry about that. It's

obss_interval=0

Jan
___
Bloat mailing list
Bloat@lists.bufferbloat.net
https://lists.bufferbloat.net/listinfo/bloat

Re: [Bloat] Steam In Home Streaming on ath9k wifi

[Jan Ceuleers]

On 26/11/17 12:54, Steinar H. Gunderson wrote:
> It's not about the AP, it's about the client. (APs can detect extension
> channel interference without doing a scan, although I don't know if you need
> this fallback at all on 5 GHz.)

You are absolutely right. I have disabled the scans and now the stats
for the same test look like this:

100 packets transmitted, 100 received, 0% packet loss, time 99153ms
rtt min/avg/max/mdev = 1.225/2.403/49.129/5.933 ms

Disabling the scans needed to be done on the AP side though (in
hostapd.conf):

# If set non-zero, require stations to perform scans of overlapping
# channels to test for stations which would be affected by 40 MHz traffic.
# This parameter sets the interval in seconds between these scans.
Setting this
# to non-zero allows 2.4 GHz band AP to move dynamically to a 40 MHz
channel if
# no co-existence issues with neighboring devices are found.

This was set to 10 when I did the first test. I have now reset it to 0
(the default) which results in the above improved stats.

Thanks, Jan
___
Bloat mailing list
Bloat@lists.bufferbloat.net
https://lists.bufferbloat.net/listinfo/bloat

Re: [Bloat] Steam In Home Streaming on ath9k wifi

[Jan Ceuleers]

On 26/11/17 11:05, Jonathan Morton wrote:
> Another explanation for latency spikes on the order of 100ms is that a
> periodic (and wholly unnecessary) scan for other APs is run, which
> requires the wifi radio to be temporarily tuned away from the currently
> associated AP's frequency.

My understanding is that APs that operate on channels that are wider
than 20MHz must back off to 20MHz in case they detect other SSIDs that
are competing for the wider channel. So this is clearly "unnecessary"
from the point of view of the AP itself, but it does make the AP a
better citizen to be aware of who else is trying to access the medium.
___
Bloat mailing list
Bloat@lists.bufferbloat.net
https://lists.bufferbloat.net/listinfo/bloat

Re: [Bloat] Steam In Home Streaming on ath9k wifi

[Jan Ceuleers]

On 26/11/17 08:29, Caleb Cushing wrote:
> from desktop
> 
> Pinging 192.168.1.105 with 32 bytes of data:
> Reply from 192.168.1.105 : bytes=32 time<1ms TTL=128

I've also performed a ping test via wifi to the AP. Here are the stats
for 100 pings:

100 packets transmitted, 100 received, 0% packet loss, time 99156ms
rtt min/avg/max/mdev = 1.280/6.938/93.746/17.846 ms

Both the laptop and the AP have ath9k cards. The laptop runs Ubuntu
16.04 and the AP runs Debian Jessie. Both have achieved NTP sync.

The vast majority of the ping RTTs are below 2ms, but there are
occasional spikes of multiple tens of ms. I expect that this is due to
the fact that the laptop isn't the only STA that is associated with the AP.
___
Bloat mailing list
Bloat@lists.bufferbloat.net
https://lists.bufferbloat.net/listinfo/bloat

Re: [Bloat] Fixing bufferbloat in 2017

[Jan Ceuleers]

On 28/11/16 03:16, Jim Gettys wrote:
> Ookla may have made themselves long term irrelevant by their recent
> behavior.  When your customers start funding development of a
> replacement (as Comcast has), you know they aren't happy.
> 
> So I don't sweat Ookla: helping out the Comcast test effort is probably
> the best way to get bufferbloat in front of everyone, and best yet, the
> code for the tests is out there.

I do hope you're right Jim, but I still worry that Ookla is heavily
entrenched in carriers' test labs. This position has, I believe, come
about not because of Ookla's expertise in network testing but rather
because of market pull (i.e. speedtest.net's huge popularity with
end-users).

As long as both of these positions remain (i.e. Ookla's mind share of
end-users and their resulting market share in the labs of large
purchasers of CPE) their lack of interest in bufferbloat is going to
keep this topic off the agenda in a large part of the industry.

Unless Ookla can be coerced somehow.

I have previously suggested standardising network throughput testing
methods and "grading" criteria. If there's an RFC on this subject
carriers are going to be interested in conformance to it and will
pressure their suppliers (of network testing gear, of CPE etc).
___
Bloat mailing list
Bloat@lists.bufferbloat.net
https://lists.bufferbloat.net/listinfo/bloat

Re: [Bloat] fixing bufferbloat in 2017

[Jan Ceuleers]

On 22/11/16 16:32, Dave Taht wrote:
> What's left to do?

Furthering adoption of the code that contains the bloat-related
improvements.

In my view, the single biggest potential contributor towards driving
such adoption would be for Ookla to start measuring and reporting
bufferbloat, thereby putting it on the agenda of both end users and
carriers (who use Ookla's servers to qualify equipment in their labs).
That would in turn put it on the agenda of equipment manufacturers.

___
Bloat mailing list
Bloat@lists.bufferbloat.net
https://lists.bufferbloat.net/listinfo/bloat

Re: [Bloat] bufferbloat at high edge rates

[Jan Ceuleers]

On 15/11/16 16:23, James Cloos wrote:
>> "j" == jb   writes:
> 
> j> It can be downloaded here from the sticky:
> j>http://www.dslreports.com/forum/speedtestbinary
> 
> That links to:
> 
>  
> http://www.dslreports.com/r0/download/2293455~bc6f17b1568921811497422ad3fff3b5/dslrcli-linux-amd64.zip
> 
> but that just downloads a text file, not a zip file.

Read that text file.
___
Bloat mailing list
Bloat@lists.bufferbloat.net
https://lists.bufferbloat.net/listinfo/bloat

Re: [Bloat] 22 seconds til bloat on gfiber?

[Jan Ceuleers]

On 27/10/16 21:48, Aaron Wood wrote:

> That sounds like it was in the right ballpark.  Trenching is so
> expensive, only doing it every couple decades sounds like a reasonable
> plan (even better if you trench conduit that you can run replaceable
> cables in (which is what AT&T did when they took U-Verse into the Santa
> Cruz mountains).

Yes, except that in the years leading up to 2000/2001 everyone had the
attitude "build it and they will come", meaning that there was a race
for everyone to get their own fiber into the ground which actually drove
the cost up rather than down, due to a lack of capacity in the
contracting sector, and also because lots of governments and local
authorities saw this stqggering peak in network construction activity as
an opportunity to make lots of money from rights of way.


___
Bloat mailing list
Bloat@lists.bufferbloat.net
https://lists.bufferbloat.net/listinfo/bloat

Re: [Bloat] 22 seconds til bloat on gfiber?

[Jan Ceuleers]

On 26/10/16 03:05, Benjamin Cronce wrote:
> Sorry to side track
> 
> 1:1 split bandwidth wise, still a 1:16 or whatever fiber split. Each
> port can handle 40Gb/s, which is 32 lambdas of 1.25Gb/s, each customer
> getting their own lambda. The ONT can either be WDM-PON or GPON with an
> inline filter. A Google Fiber engineer actually had this in his blog a
> long while back, talking about their design and the "dedicated" aspect
> of an unshared GPON. PON can only handle about a 32 split before the
> signal strength gets too low toe be practical. If each group of
> customers shared a lambda, they would need too many split or repeaters,
> which is more impractical.

I am aware of GPON deployments with splitting factors of 64 and higher,
and these do not (at all) pose a problem with the optical power budget.

> I'm not entirely sure which part you mean "impractical".

What I mean is that the OLT optics become very expensive if you need to
support as many lambdas as you have customers. You'd furthermore need an
OLT port for much fewer customers (e.g. 1 port per 64 or 128 customers)
than the thousands you can support on a (shared) GPON port on a single
lambda.

Also on the ONT side there is the danger of spiraling cost in that I
don't think it is economically feasible yet to incorporate tunable
lasers in the CPE, certainly not across 64 or 128 lambdas, meaning that
you'd need as many hardware variants of the ONT as you have lambdas.

But maybe I'm wrong.
___
Bloat mailing list
Bloat@lists.bufferbloat.net
https://lists.bufferbloat.net/listinfo/bloat

Re: [Bloat] 22 seconds til bloat on gfiber?

[Jan Ceuleers]

On 25/10/16 00:10, Benjamin Cronce wrote:
> WDM-PON, giving each customer their own lambda of bandwidth. Effectively
> a 1:1 split.

Not quite. All it means is that multiple PONs coexist on the same
outside plant, each on a different wavelength, and each serving multiple
end-users. Allows for higher densities.

What you suggest could be done but would quickly become impractical.
___
Bloat mailing list
Bloat@lists.bufferbloat.net
https://lists.bufferbloat.net/listinfo/bloat

Re: [Bloat] ultrafast broadband conference june 27-30

[Jan Ceuleers]

On 18/06/16 13:14, Toke Høiland-Jørgensen wrote:
> Yup. Unfortunately we've had no luck thus far.
> 
> https://www.dslreports.com/speedtest is an alternative speedtest that
> does include bufferbloat scores.

Yes, but it isn't used by ISPs when they qualify product.

Would it be worth pursuing an RFC on how to properly test the
performance of an internet access circuit and/or of a path across an IP
network? RFC compliance might be a tool to get Ookla to take notice.
___
Bloat mailing list
Bloat@lists.bufferbloat.net
https://lists.bufferbloat.net/listinfo/bloat

Re: [Bloat] ultrafast broadband conference june 27-30

[Jan Ceuleers]

On 18/06/16 12:51, Toke Høiland-Jørgensen wrote:
> I know of at least one DSL vendor who supposedly has started paying
> attention after pressure from a clueful ISP; not idea if they started
> shipping non-bloated products yet.

Got it.

To get more ISPs interested in this subject we need to get Ookla to take
account of bufferbloat. So long as speedtest.net and the Ookla servers
many ISPs have in their labs ignore latency under load there will not be
any pressure on the CPE industry to clean up its act.
___
Bloat mailing list
Bloat@lists.bufferbloat.net
https://lists.bufferbloat.net/listinfo/bloat

Re: [Bloat] ultrafast broadband conference june 27-30

[Jan Ceuleers]

On 18/06/16 12:24, Jonathan Morton wrote:
>> So it seems that you and I agree that it's not G.fast itself that is
>> bloated, but the lack of proper buffer management in certain (most?) DSL
>> modems, regardless of whether they support G.fast or some other flavour
>> of DSL.
> 
> Right.  We’re hoping that G.fast, being a new link technology, has
> taken on board some of the extensive research into buffer sizing and
> management, in typical device implementations.  But we’re not holding
> our breath - the industry is rather stubborn on this point.

We're still not on the same page. So let me again try to decode what you
(and perhaps Dave) are saying:

Either you perceive the problem to be located in the link technology
(i.e. DSL generally or only specific flavours of it). If this is the
case what needs to be fixed is the standard so that implementations
thereof will improve.

Or else you perceive the problem to be located in the CPE that implement
DSL, but in the layer above the DSL link layer. In this case what needs
to be fixed is those implementations, probably starting by the reference
firmware written by chipset vendors.

I think it's the latter. If it's the former then indeed don't hold your
breath because the standardisation is done and dusted.

___
Bloat mailing list
Bloat@lists.bufferbloat.net
https://lists.bufferbloat.net/listinfo/bloat

Re: [Bloat] ultrafast broadband conference june 27-30

[Jan Ceuleers]

On 18/06/16 12:09, Jonathan Morton wrote:
> These buffers are not inherent to the link technology.
> If they were, we’d be calling for different link technology.

Thanks for confirming my suspicions. But this is exactly what Dave was
doing, since he blamed the uplink bloat on "g.fast technologies".

So it seems that you and I agree that it's not G.fast itself that is
bloated, but the lack of proper buffer management in certain (most?) DSL
modems, regardless of whether they support G.fast or some other flavour
of DSL.

Thx, Jan
___
Bloat mailing list
Bloat@lists.bufferbloat.net
https://lists.bufferbloat.net/listinfo/bloat

Re: [Bloat] ultrafast broadband conference june 27-30

[Jan Ceuleers]

On 13/06/16 18:05, Dave Taht wrote:
> Is anyone going to this? I sure hope the g.fast technologies have
> their uplink bloat fixed, at least.

Dave,

(Been trying to send this for the past few days unsuccessfully; perhaps
the DNS gremlins caused it to bounce. Now sending via gmail).

As I'm sure everyone here knows DSL uses interleaving in order to
achieve coding gain in the face of impulse noise. DSL has to operate in
environments that are rich in such noise so although it is possible to
turn interleaving off pretty much every operator has it on, if for no
other reason than to avoid IPTV artefacts.

This does not meet at least my understanding of the definition of
bufferbloat, in that interleaving introduces a static amount of latency
(i.e. latency that does not vary with load).

But it's perhaps also not what you were talking about because you
mentioned the uplink. Not sure what you meant. Still, other than the use
of ATM and coding I'm not aware of buffering in DSL. Certainly no
dynamic buffers that absorb traffic under load.

Could you enlighten me? I know that you're a busy man; a few keywords
for me to stick into google would be great.

Thanks, Jan
___
Bloat mailing list
Bloat@lists.bufferbloat.net
https://lists.bufferbloat.net/listinfo/bloat

Re: [Bloat] Speed tests - attribution of latency to relevant network hops

[Jan Ceuleers]

On 30/07/15 15:04, Bill Ver Steeg (versteb) wrote:
> You do have to be careful using ttl tricks and/or ICMP packets for 
> fine-grained timing measurements. On many middleboxes, there is a "fast path" 
> that is done in a highly optimized manner (often in silicon) and a "slow 
> path". In a non-zero number of cases, you will be in the fast path for normal 
> packets and in the slow path for unusual packets. 

Yes, understood and agreed.

But I think it would already be very enlightening to lots of users (and
also assist the "make wifi faster" efforts) to understand how much of
the bloat sits in the part of the network that they can fix themselves,
how much of it they can hold their service provided accountable for and
how much of it they essentially have to put up with because it's
inherent to the way they're plumbed into the interweb.

So perhaps it's not possible to break the dslreports bloat graphs down
into the three segments that I described, because all we have available
is ICMP and the TTL field, but even a graphical representation of a
traceroute-while-idle and a traceroute-under-load would be a step forward.

> What you describe will work for the vast majority of cases, but there will be 
> situations in which you will get misleading results. You would need to handle 
> the timing differences when the slow path was MUCH slower than the fast path 
> and it distorted the results. You would also have to handle some weird edge 
> conditions. The worst case that springs to mind would be a bloated buffer 
> somewhere in a device's fast path (due to lots of "normal" packets), but the 
> slow path on the same device is not congested and thus actually has less 
> delay for this single packet.

My first thought was that I'd expect that the fast path queues in which
packets might spend a non-negligible amount of time would sit on the
egress side of the box rather than on the ingress side, and that it is
only the ingress queue that would affect both fast-path and slow-path
traffic. But I guess that this depends heavily on the architecture of
the box, so you're probably right.

Jan

___
Bloat mailing list
Bloat@lists.bufferbloat.net
https://lists.bufferbloat.net/listinfo/bloat

Re: [Bloat] Speed tests - attribution of latency to relevant network hops

[Jan Ceuleers]

On 30/07/15 06:52, Mikael Abrahamsson wrote:
> On Wed, 29 Jul 2015, David Lang wrote:
> 
>> unless you measure it per hop, how are you going to attribute it to
>> each hop? and unless you have a server at that layer to talk to, how
>> do you know what the latency or bandwidth is?
> 
> Measuring latency is doable (using the same mechanism that traceroute
> with for instance max-ttl 5), but I don't know how much of this is
> available to your web application?
> 
> If you sent 5 packets with TTL 1-5 and measured the time to get back the
> ttl-expired-in-transit ICMP, you could get an indication where the
> latency increase was happening.

Yes, that's what I had in mind.
___
Bloat mailing list
Bloat@lists.bufferbloat.net
https://lists.bufferbloat.net/listinfo/bloat

[Bloat] Speed tests - attribution of latency to relevant network hops

[Jan Ceuleers]

Dear list,

Now that dslreports has set the benchmark on combining speed testing
with latency measurements I was thinking about what the next steps could
be. Here's what I came up with:

Would it be useful to try and attribute the latency to certain relevant
network hops, like so:

First hop: round-trip latency of the link connecting the user's machine
to their local network. This could be wifi or Ethernet in a home or
office environment; it could be wifi or cellular in a public
environment, etc.

Local network: round-trip latency to the first upstream port that has a
public IP address. Of course this is only useful if the user's machine
doesn't already have a routable IP address.

ISP: round-trip latency to the second upstream port that has a public IP
address. So this would be the DSLAM/BRAS/CMTS or whatever access
concentrator the ISP uses.

This would probably need to be based on ping. Which IP addresses to ping
would initially need to be found out through traceroute-like methods.

If we can then get users to tell us not only what Internet access
technology they use (i.e. cable, DSL, GPON etc) but also what local
access technology (i.e. wifi, Ethernet etc) we'd know how to attribute
the above numbers to technologies.

Jan
___
Bloat mailing list
Bloat@lists.bufferbloat.net
https://lists.bufferbloat.net/listinfo/bloat

Re: [Bloat] Graph of bloat

[Jan Ceuleers]

On 08/07/15 18:32, Dave Taht wrote:
> Judging from that graphic... I don't think huff and puff was designed
> for the bufferbloated era! so the question remains, in hal's tests,
> did ntp adjust the clock backwards?

Dave,

No, ntpd did not adjust the time backwards.

What's going on in that graph is that it shows the different approach
that Google has taken to leap second insertion relative to ntpd's
implementation (which aligns with the standard).

Ntpd inserts a leap second by having the last UTC minute of the last day
of (in this case) June 30th last for 61 seconds rather than 60. The
extra second is number 60, after seconds 0 through 59. This is plotted
on the x axis.

The time reported by the Google server is compared to this on the y
axis. 10 hours prior to UTC midnight they slow down the clock by
1/72000, such that at the end of those 72000 seconds (20 hours) one more
"real" second will have passed than is reflected in the time reported by
the clock.

So obviously this means that during the 10 hours prior to UTC midnight
an offset is gradually built up between the Google servers and the rest
of the world, reaching half a second just prior to midnight. After the
leap second insertion on the standard server the sign of the offset is
inverted and the offset between the two begins to decline. 10 hours
after UTC midnight the Google servers return the rate of their clocks to
the normal "1 second per second" rate.

Anyway: Hal shared this because of the artifacts below the main graph
and he posits (quite reasonably) that this was due to bufferbloat.

Jan
___
Bloat mailing list
Bloat@lists.bufferbloat.net
https://lists.bufferbloat.net/listinfo/bloat

Re: [Bloat] Graph of bloat

[Jan Ceuleers]

On 08/07/15 18:11, Jan Ceuleers wrote:
> On 08/07/15 17:55, Dave Taht wrote:
>> That is a very interesting graph! Does ntp adjust system time backward
>> based on getting nearly all it's samples with well over a 1/2 second
>> of induced delay?
> 
> If there is a consistent asymmetrical delay then yes.

Let me qualify that "yes".

Normally ntpd will ensure that the system time as observed by the kernel
and applications always increases monotonically. The exception is where
the system time differs too much from what ntpd considers to be the
correct time and where ntpd is given permission to step the time (e.g.
using the -g command-line switch). In this case ntpd can step backwards.

What I meant in my previous message is that ntpd's idea of true time is
arrived at based on the assumption that the network delay is the same in
both directions to its servers. So if there is a systematically
different delay in one direction relative to the other then this
assumption falls down and ntpd's assessment of true time will be skewed.

The huff-n-puff filter helps in cases where the asymmetry in the delay
is not systematic, e.g. where the upstream channel does not suffer from
bufferbloat.

Jan
___
Bloat mailing list
Bloat@lists.bufferbloat.net
https://lists.bufferbloat.net/listinfo/bloat

Re: [Bloat] Graph of bloat

[Jan Ceuleers]

On 08/07/15 17:55, Dave Taht wrote:
> That is a very interesting graph! Does ntp adjust system time backward
> based on getting nearly all it's samples with well over a 1/2 second
> of induced delay?

If there is a consistent asymmetrical delay then yes.

If the delay asymmetry is not persistent (but only occurs during up or
downloads) then the so-called huff-n-puff filter can be used to factor
it out.

https://www.eecis.udel.edu/~mills/ntp/html/huffpuff.html

Jan

___
Bloat mailing list
Bloat@lists.bufferbloat.net
https://lists.bufferbloat.net/listinfo/bloat

[Bloat] Fwd: [Bug 1436945] Re: devel: consider fq_codel as the default qdisc for networking

[Jan Ceuleers]

Disappointing...


 Forwarded Message 
Subject: [Bug 1436945] Re: devel: consider fq_codel as the default qdisc
for networking
Date: Wed, 08 Jul 2015 10:50:05 -
From: Andy Whitcroft 
Reply-To: Bug 1436945 <1436...@bugs.launchpad.net>
To: jan.ceule...@computer.org

** Changed in: linux (Ubuntu)
Milestone: ubuntu-15.03 => ubuntu-15.07

-- 
You received this bug notification because you are subscribed to the bug
report.
https://bugs.launchpad.net/bugs/1436945

Title:
  devel: consider fq_codel as the default qdisc for networking

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1436945/+subscriptions



___
Bloat mailing list
Bloat@lists.bufferbloat.net
https://lists.bufferbloat.net/listinfo/bloat

Re: [Bloat] Question about fq_codel vs modem buffers

[Jan Ceuleers]

On 02/05/15 04:49, Rich Brown wrote:
> But I don't know enough about the physical characteristics of
cable/dsl links to understand how they actually work, nor how fq_codel
can (or can't) accommodate degradation.

I know a little about the DSL PHY behaviour.

It is possible for line conditions to degrade, forcing the modems (i.e.
the one in the DSLAM and the one in the CPE) to retrain. It is also
possible that the newly-negotiated line rate is lower than the
previous-one, so the end user would indeed see a reduction in the
available bandwidth.

However, DSL operators (the good-ones anyway) measure, log and manage
the headroom between signal and noise on a per-line basis, so as to
avoid this kind of instability. This is the case particularly for
operators who also provide video services over DSL because retrains
(which take quite a few seconds) kill the user experience.

Take my line for example. I don't exactly know the length of my line to
the DSLAM but it must be at least 1200m. Up until a few months ago I had
25.5Mbit/s down and 2Mbit/s up using VDSL2 without vectoring. But I know
that my service provider, being in stiff competition with cable, has
been silently upping the bandwidth of people's lines by first gathering
stats on each individual line for a few months, and then, using a
feature called dynamic line management that allows them to model the
expected impact of increasing the rate of one line on the noise
(crosstalk) experienced by the other lines in the same cable bundle,
determine how far they can stretch each line.

I now have 30M down and 2M up, still without vectoring, and with a
training margin as reported by the modem of 9.6dB. (Before the speed
upgrade I vaguely remember it being something like 14dB).

So anyway: retrains are supposed to be very exceptional and indicative
of something being wrong.

By the way: another way for DSL operators to improve stability is to use
interleaving. Specifically: interleaving helps to improve stability in
the face of impulse noise at the expense of increased latency (which is
why I mention it here).

Jan

___
Bloat mailing list
Bloat@lists.bufferbloat.net
https://lists.bufferbloat.net/listinfo/bloat

Re: [Bloat] Adblock - or another extension - is incorrectly blocking the speed test

[Jan Ceuleers]

On 26/04/15 06:17, jb wrote:
> The warning is correct in that it is probably NOSCRIPT. I think.
> All the speed test knows is that an API call to all servers was brutally
> failed
> in an unexpected way. There is no visibility into what caused the
> failure, only
> that it should not occur in a clean browser. If you open the console
> you can probably see more than the javascript gets told.

Hi Justin,

I think the problem is that you may be referring to the test servers by
IP address rather than by DNS names. Here is why I think that:

I picked Noscript's "disable everywhere" option, then successfully ran
the test. I was then able to see in Noscript which sites were running
scripts and saw a number of IP addresses among them. I then added these
IP addresses to the whitelist, re-enabled Noscript and verified that I
was able to still run the test.

If you are able to put all of these servers in a DNS domain under your
control then a single whitelist entry in Noscript would make them all
work, and not just the ones that are being picked at my location.

By the way: I then re-enabled Adblock and was still able to run the
test. So I recommend blaming Noscript in the error message rather than
Adblock (and then perhaps also mentioning the whitelist rule that fixes it).

Thanks, Jan

___
Bloat mailing list
Bloat@lists.bufferbloat.net
https://lists.bufferbloat.net/listinfo/bloat

Re: [Bloat] Adblock - or another extension - is incorrectly blocking the speed test

[Jan Ceuleers]

On 25/04/15 13:44, jb wrote:
> The message appears when the speed test is blocked from reaching a test
> server.
> 
> It has turned out to be almost always either Adblock, AdblockPlus or
> NOSCRIPT
> 
> The error message is correct, at least, has been so far: it is always an
> extension
> and whatever extension it is, does not report to what it is doing, just
> rips a hole
> in the browser.

Justin,

I do have other extensions besides Adblock (including NoScript), but
when I get this error message I had permitted all scripts from sites I
don't distrust to run (so excluding any google/fb/twitter/... stuff that
doesn't belong) and as I said I had completely disabled AdBlock.

What I mean about the error message being incorrect is that it doesn't
tell me what the problem is, and makes an assumption about the cause of
that problem. So what server does traffic not get through to? I then
have a shot at finding out which protocol and port so that I can further
debug.

On another note: why the warnings about use of the speed test through a
proxy? Why would that invalidate the test? I run a squid instance on my
side of my DSL line, and I don't notice any significant differences in
the results with and without proxy.

Thanks, Jan

___
Bloat mailing list
Bloat@lists.bufferbloat.net
https://lists.bufferbloat.net/listinfo/bloat

[Bloat] Adblock - or another extension - is incorrectly blocking the speed test

[Jan Ceuleers]

Dear list,

I'm unable to use the speed test with either of my main browsers
(Firefox and Chrome, both under Linux) because of the above error
message. Even if I temporarily completely disable Adblock.

What is the problem here? Because what is incorrect is the error
message, not my use of browser extensions.

Thanks, Jan
___
Bloat mailing list
Bloat@lists.bufferbloat.net
https://lists.bufferbloat.net/listinfo/bloat

Re: [Bloat] The Dark Problem with AQM in the Internet?

[Jan Ceuleers]

On 08/28/2014 06:35 PM, Fred Baker (fred) wrote:
> When a message is lost due to an error, how do you determine whose fault
> it is?

Links need to be engineered for the optimum combination of power,
bandwidth, overhead and residual error that meets requirements. I agree
with your implied point that a single error is unlikely to be indicative
of a real problem, but a link not meeting requirements is someone's fault.

So like Jerry I'd be interested in an ability for endpoints to be able
to collect statistics on per-hop loss probabilities so that admins can
hold their providers accountable.

Jan

___
Bloat mailing list
Bloat@lists.bufferbloat.net
https://lists.bufferbloat.net/listinfo/bloat

Re: [Bloat] sigcomm wifi

[Jan Ceuleers]

On 08/21/2014 09:57 PM, Steinar H. Gunderson wrote:
> I'll stop preaching the Cisco gospel soon (well, e.g. Aruba would probably
> also do just the same thing :-) ), but in a WLC-based solution, there's a
> setting to just refuse the first few associations on 2.4 GHz if it detects
> the client is 5 GHz capable. It's a hack, but it pushes people over to 5 GHz
> quite effectively.

How does that work in the light of STA MAC address randomisation during
the scan stage? As I understand it, such STAs only use their "real" MAC
address for actually connecting to the AP, but hide their identity in
probe requests. So a dual-band AP can't rely on a STA's MAC address
being the same in both bands.
___
Bloat mailing list
Bloat@lists.bufferbloat.net
https://lists.bufferbloat.net/listinfo/bloat

Re: [Bloat] [aqm] the side effects of 330ms lag in the real world

[Jan Ceuleers]

On 04/29/2014 07:01 PM, Toke Høiland-Jørgensen wrote:
> However, as that graph shows, it is quite possible to completely avoid
> bufferbloat by deploying the right shaping. And in that case fibre
> *does* have a significant latency advantage. The best latency I've seen
> to the upstream gateway on DSL has been ~12 ms.

I am not an expert, but I believe that this is due to the use of
interleaving. This is a method to improve the strength of forward error
correction by spreading out the effects of impulse noise on DSL lines
across multiple reed-solomon-protected codewords at the expense of latency.

The topic is briefly discussed on the ADSL Wikipedia page.

___
Bloat mailing list
Bloat@lists.bufferbloat.net
https://lists.bufferbloat.net/listinfo/bloat

Re: [Bloat] TCP TFO client behaviour

[Jan Ceuleers]

On 12/11/2012 05:59 PM, Eric Dumazet wrote:
> I really wonder why this is sent to these lists instead of netdev ?

Some of us (well: me) have been banned from netdev. As a matter of fact:
not only from netdev, but from the whole of vger.kernel.org.

For asking the networking maintainer to tone down his foul language.
Networking maintainer who is also vger admin...
___
Bloat mailing list
Bloat@lists.bufferbloat.net
https://lists.bufferbloat.net/listinfo/bloat

Re: [Bloat] Dashboard dedicated to BufferBloat issue

[Jan Ceuleers]

On 09/21/2012 11:09 AM, Branco Camporeto wrote:
> For helping me and tracking all events about bufferbloat, I did this
> public dashboard. http://www.netvibes/bufferbloat
> I keep updating it.

I suspect that URL should be http://www.netvibes.com/bufferbloat

Jan


___
Bloat mailing list
Bloat@lists.bufferbloat.net
https://lists.bufferbloat.net/listinfo/bloat

Re: [Bloat] the observed sack oddity

[Jan Ceuleers]

On 10/11/2011 03:09 PM, David Täht wrote:

I have put up screenshots of tcptrace -G and xplot.org's analysis of my
most recent capture of an ipv6 connection over freebox (wired) from a
debloat-testing kernel here in france (pre 3.1 by a lot) to a 2.6.16
kernel (the aformentioned netsonar box) in redwood city, ca, both
running tcp cubic, over ipv6.


David, Eric,

Since the both of you are in France, would it be an idea to get together?

Cheers, Jan
___
Bloat mailing list
Bloat@lists.bufferbloat.net
https://lists.bufferbloat.net/listinfo/bloat