General list for discussing Bufferbloat
 help / color / mirror / Atom feed
From: Jonathan Morton <chromatix99@gmail.com>
To: "Holland, Jake" <jholland@akamai.com>
Cc: Mikael Abrahamsson <swmike@swm.pp.se>,
	"bloat@lists.bufferbloat.net" <bloat@lists.bufferbloat.net>
Subject: Re: [Bloat] datapoint from one vendor regarding bloat
Date: Fri, 12 Apr 2019 03:37:12 +0300	[thread overview]
Message-ID: <79BAAF74-7E32-4361-AE5C-A0008EF8BE12@gmail.com> (raw)
In-Reply-To: <ACA7922F-7CBD-4441-AC79-096B67723F90@akamai.com>

> On 12 Apr, 2019, at 2:56 am, Holland, Jake <jholland@akamai.com> wrote:
> 
> But in practice do you expect link speed changes to be a major issue?

For wireline, consider ADSL2+.  Maximum downstream link speed is 24Mbps, impaired somewhat by ATM framing but let's ignore that for now.  A basic "poverty package" might limit to 4Mbps; already a 6:1 ratio.  In rural areas the "last mile" copper may be so long and noisy for certain individual subscribers that only 128Kbps is available; this is now a 192:1 ratio, turning 10ms into almost 2 seconds if uncompensated from the headline 24Mbps rate.  Mind you, 10ms is too short to get even a single packet through at 128Kbps, so you'd need to put in a failsafe.

That's on wireline, where link speed changes are relatively infrequent and usually minor, so it's easy to signal changes back to some discrete policer box (usually called a BRAS in an ADSL context).  That may be what you have in mind.

One could, and should, also consider wireless technologies.  A given handset on a given SIM card may expect 100Mbps LTE under ideal conditions, in a major city during the small hours, but might only have a dodgy EDGE signal on a desolate hilltop a few hours later.  (Here in Finland, cell coverage was greatly improved in rural areas by cascading old 2G equipment from urban areas that received 3G upgrades, so this is not at all uncommon.)  In general, wireless links change rate rapidly and unpredictably in reaction to propagation conditions as the handset moves (or, for fixed stations, as the weather changes), and the ratio of possible link rates is even more severe than the ADSL example above.

Often a "poverty package" is implemented through a shaper rather than a policer, backed by a dumb FIFO on which no right-sizing has been considered (even though the link rate is obviously known in advance).  On one of these, I have personally experienced 40+ seconds of delay, rendering the connection useless for other purposes while any sort of sustained download was in progress.  In fact, that's one of the incidents which got me seriously interested in congestion control; at the time, I hacked the Linux TCP stack to right-size the receive window, and directed most of my traffic through a proxy running on that machine.  This was sufficient to restore some usability.

I find it notable that ISPs mostly consider only policers for congestion signalling, and rarely deploy even these to all the places where congestion may reasonably occur.

 - Jonathan Morton


  reply	other threads:[~2019-04-12  0:37 UTC|newest]

Thread overview: 12+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2019-04-11 10:38 Mikael Abrahamsson
2019-04-11 12:45 ` Sebastian Moeller
2019-04-11 17:33   ` Sebastian Moeller
2019-04-11 17:54 ` Jonathan Morton
2019-04-11 18:00   ` Holland, Jake
2019-04-11 18:28     ` Jonathan Morton
2019-04-11 23:56       ` Holland, Jake
2019-04-12  0:37         ` Jonathan Morton [this message]
2019-04-12  0:45           ` Holland, Jake
2019-04-12  9:47       ` Mikael Abrahamsson
2019-04-11 18:02   ` Jan Ceuleers
2019-04-11 18:27   ` Luca Muscariello

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=79BAAF74-7E32-4361-AE5C-A0008EF8BE12@gmail.com \
    --to=chromatix99@gmail.com \
    --cc=bloat@lists.bufferbloat.net \
    --cc=jholland@akamai.com \
    --cc=swmike@swm.pp.se \
    /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