From: David Lang <david@lang.hm>
To: Neil Davies <neil.davies@pnsol.com>
Cc: cerowrt-devel <cerowrt-devel@lists.bufferbloat.net>,
bloat <bloat@lists.bufferbloat.net>
Subject: Re: [Cerowrt-devel] [Bloat] Check out www.speedof.me - no Flash
Date: Fri, 25 Jul 2014 14:20:53 -0700 (PDT) [thread overview]
Message-ID: <alpine.DEB.2.02.1407251415570.21739@nftneq.ynat.uz> (raw)
In-Reply-To: <BD3B1F63-8380-42A3-82E8-BDD5C90ACDE5@pnsol.com>
On Fri, 25 Jul 2014, Neil Davies wrote:
> Sebastian
>
> On 25 Jul 2014, at 15:17, Sebastian Moeller <moeller0@gmx.de> wrote:
>
>> But how do you propose to measure the (bottleneck) link capacity then?
>> It turns out for current CPE and CMTS/DSLAM equipment one typically can not
>> relay on good QoE out of the box, since typically these devices do not use
>> their (largish) buffers wisely. Instead the current remedy is to take back
>> control over the bottleneck link by shaping the actually sent traffic to stay
>> below the hardware link capacity thereby avoiding feeling the consequences of
>> the over-buffering. But to do this is is quite helpful to get an educated
>> guess what the bottleneck links capacity actually is. And for that purpose a
>> speediest seems useful.
>
>
> I totally agree that what you are trying to do is to take control "back" for
> the upstream delay and loss (which is the network level activity that directly
> influences QoE). Observationally the "constraining link" is the point at which
> the delay and loss start to grow as the the offered load is increased (there
> are interesting interactions with the scheduling in the CMTS/3GPP node B - but
> they are tractable) if we don't have direct access to the constraint (which in
> the CPE, for ADSL you have) we track that "quality attenuation" inflection
> point. Saturating the path is a bit of a sledgehammer (and has nasty
> cost/scaling implications).
The thing is that there is little effect on latency until the congestion starts,
so we can only measure the problem when there is congestion.
Saturating the link is a bit of a sledgehammer, but there really isn't any other
way to get to the worst case situation.
In terms of scaling, have the server detect that all the requests have combined
to saturate it's link, and have it tell the clients that it's overloaded, wait a
random amount of time and retry (or try another location)
cost of bandwidth for this is just something to get someone to pay for (ideally
someone with tons of bandwidth already who won't notice this sort of test, even
if there are a few going on at once.)
David Lang
next prev parent reply other threads:[~2014-07-25 21:20 UTC|newest]
Thread overview: 32+ messages / expand[flat|nested] mbox.gz Atom feed top
2014-07-20 13:19 [Cerowrt-devel] " Rich Brown
2014-07-20 13:27 ` David P. Reed
2014-07-20 18:41 ` [Cerowrt-devel] SIMET: nationwide bw/latency/jitter test effort in Brazil Henrique de Moraes Holschuh
2014-07-23 5:36 ` [Cerowrt-devel] Check out www.speedof.me - no Flash Alex Elsayed
2014-07-25 9:10 ` [Cerowrt-devel] [Bloat] " Neil Davies
2014-07-25 12:09 ` Rich Brown
2014-07-25 12:24 ` Neil Davies
2014-07-25 14:17 ` Sebastian Moeller
2014-07-25 14:25 ` Martin Geddes
2014-07-25 15:58 ` Sebastian Moeller
2014-07-25 16:32 ` Martin Geddes
2014-07-25 17:12 ` Sebastian Moeller
2014-07-25 17:14 ` Neil Davies
2014-07-25 17:17 ` Sebastian Moeller
2014-07-25 17:29 ` Martin Geddes
2014-07-25 21:13 ` David Lang
2014-07-25 22:17 ` dpreed
2014-07-25 23:26 ` David Lang
2014-07-26 13:02 ` Sebastian Moeller
2014-07-26 20:53 ` David Lang
2014-07-26 22:00 ` Sebastian Moeller
2014-07-26 22:30 ` David Lang
2014-07-26 23:14 ` Sebastian Moeller
2014-07-26 20:16 ` Neil Davies
2014-07-25 14:27 ` Neil Davies
2014-07-25 16:02 ` Sebastian Moeller
2014-07-25 21:20 ` David Lang [this message]
2014-07-25 22:29 ` Valdis.Kletnieks
2014-07-25 23:30 ` David Lang
2014-07-26 12:53 ` Sebastian Moeller
2014-07-25 15:05 ` David P. Reed
2014-07-25 15:46 ` Rich Brown
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/cerowrt-devel.lists.bufferbloat.net/
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=alpine.DEB.2.02.1407251415570.21739@nftneq.ynat.uz \
--to=david@lang.hm \
--cc=bloat@lists.bufferbloat.net \
--cc=cerowrt-devel@lists.bufferbloat.net \
--cc=neil.davies@pnsol.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