Development issues regarding the cerowrt test router project
 help / color / mirror / Atom feed
From: Jonathan Morton <chromatix99@gmail.com>
To: Sebastian Moeller <moeller0@gmx.de>
Cc: cerowrt-devel <cerowrt-devel@lists.bufferbloat.net>,
	bloat <bloat@lists.bufferbloat.net>
Subject: Re: [Cerowrt-devel] [Bloat]  Marketing problems
Date: Sun, 27 Jul 2014 16:00:37 +0300	[thread overview]
Message-ID: <CAJq5cE3HuS6-GMD_HQK33KOC=yO5NEdmOn=WmeaYYda1LepHng@mail.gmail.com> (raw)

[-- Attachment #1: Type: text/plain, Size: 1873 bytes --]

A marketing number?  Well, as we know, consumers respond best to "bigger is
better" statistics. So anything reporting delay or ratio in the ways
mentioned so far is doomed to failure - even if we convince the industry
(or the regulators, more likely) to adopt them.

Another problem that needs solving is that marketing statistics tend to get
gamed a lot.  They must therefore be defined in such a way that gaming them
is difficult without actually producing a corresponding improvement in the
service.  That's similar in nature to a security problem, by the way.

I have previously suggested defining a "responsiveness" measurement as a
frequency. This is the inverse of latency, so it gets bigger as latency
goes down. It would be relatively simple to declare that responsiveness is
to be measured under a saturating load.

Trickier would be defining where in the world/network the measurement
should be taken from and to. An ISP which hosted a test server on its
internal network would hold an unfair advantage over other ISPs, so the
sane solution is to insist that test servers are at least one neutral
peering hop away from the ISP. ISPs that are geographically distant from
the nearest test server would be disadvantaged, so test servers need to be
provided throughout the densely populated parts of the world - say one per
timezone and ten degrees of latitude if there's a major city in it.

At the opposite end of the measurement, we have the CPE supplied with the
connection. That will of course be crucial to the upload half of the
measurement.

While we're at it, we could try redefining bandwidth as an average, not a
peak value. If the ISP has a "fair usage cap" of 300GB per 30 days, then
they aren't allowed to claim an average bandwidth greater than 926kbps.
National broadband availability initiatives can then be based on that
figure.

- Jonathan Morton

[-- Attachment #2: Type: text/html, Size: 2052 bytes --]

             reply	other threads:[~2014-07-27 13:00 UTC|newest]

Thread overview: 2+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2014-07-27 13:00 Jonathan Morton [this message]
2014-07-27 13:21 ` Sebastian Moeller

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='CAJq5cE3HuS6-GMD_HQK33KOC=yO5NEdmOn=WmeaYYda1LepHng@mail.gmail.com' \
    --to=chromatix99@gmail.com \
    --cc=bloat@lists.bufferbloat.net \
    --cc=cerowrt-devel@lists.bufferbloat.net \
    --cc=moeller0@gmx.de \
    /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