General list for discussing Bufferbloat
 help / color / mirror / Atom feed
From: "Toke Høiland-Jørgensen" <toke@toke.dk>
To: Jan Ceuleers <jan.ceuleers@gmail.com>
Cc: Jonathan Morton <chromatix99@gmail.com>,  bloat@lists.bufferbloat.net
Subject: Re: [Bloat] ultrafast broadband conference june 27-30
Date: Sat, 18 Jun 2016 12:51:49 +0200	[thread overview]
Message-ID: <87porevkfu.fsf@toke.dk> (raw)
In-Reply-To: <5765248F.5000108@gmail.com> (Jan Ceuleers's message of "Sat, 18 Jun 2016 12:38:07 +0200")

Jan Ceuleers <jan.ceuleers@gmail.com> writes:

> 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.

It is indeed the latter. However, it is correlated with DSL technology
because the equipment tend to be using binary blobs for drivers that
themselves have huge buffers; so even if the device is running Linux,
sticking FQ-CoDel on it doesn't do much good without a software rate
limiter. And also, most devices are owned by the ISP, so the consumer
can't upgrade them anyway.

So while it is nothing inherent in the technology per se, in practice it
is a fairly safe bet to say "ah, you're on DSL? Well, you are probably
suffering from bufferbloat, then".

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.

-Toke

  reply	other threads:[~2016-06-18 10:51 UTC|newest]

Thread overview: 14+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2016-06-13 16:05 Dave Taht
2016-06-15  5:43 ` Pedro Tumusok
2016-06-18  8:04 ` Jan Ceuleers
2016-06-18 10:09   ` Jonathan Morton
2016-06-18 10:20     ` Jan Ceuleers
2016-06-18 10:24       ` Jonathan Morton
2016-06-18 10:38         ` Jan Ceuleers
2016-06-18 10:51           ` Toke Høiland-Jørgensen [this message]
2016-06-18 11:06             ` Jan Ceuleers
2016-06-18 11:14               ` Toke Høiland-Jørgensen
2016-06-18 11:22                 ` Jan Ceuleers
2016-06-18 13:55                   ` Jonathan Morton
2016-06-18 14:07                     ` Dave Taht
2016-06-18 13:31                 ` Dave Taht

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=87porevkfu.fsf@toke.dk \
    --to=toke@toke.dk \
    --cc=bloat@lists.bufferbloat.net \
    --cc=chromatix99@gmail.com \
    --cc=jan.ceuleers@gmail.com \
    /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