From: Mikael Abrahamsson <swmike@swm.pp.se>
To: Matthew Ford <ford@isoc.org>
Cc: bloat <bloat@lists.bufferbloat.net>
Subject: Re: [Bloat] CFP: Workshop on Reducing Internet Latency
Date: Tue, 10 Dec 2013 07:48:03 +0100 (CET) [thread overview]
Message-ID: <alpine.DEB.2.02.1312100739200.24602@uplift.swm.pp.se> (raw)
In-Reply-To: <26FB3C56-AF24-497C-943A-3FDAE7B88D08@isoc.org>
On Mon, 9 Dec 2013, Matthew Ford wrote:
> The report of the Reducing Internet Latency workshop is now available:
>
> http://www.internetsociety.org/blog/2013/12/speeding-internet-reducing-latency
Reading through this I generally like it. It's a good summary and
introduction.
However, this part:
"Hiding packet losses in broadband lines using interleaving can add about
20ms of delay, even though modern transports and applications are robust
to such low packet loss levels;"
Having been part of a decently sized ADSL2+ deployment ISP, I have some
experience with this and the above doesn't match them. We actually did get
customer complaints when we were running ADSL2+ in fast-mode (no
interleaving), that the customers were getting packet losses that affected
their applications.
So I would have liked the above to not say "broadband lines" but instead
said ADSL(2+) broadband lines (because the above statement only relates to
ADSL(2+) afaik), and also that the packet losses can be non-trivial for
some and that ISPs don't turn on interleaving out of ignorance. It's hard
to measure customer impact of "errored seconds" which is the only way the
ISP can see packet losses. Also, these errored seconds can be quite
severer when it comes to number of packets dropped.
We actually did talk about having a self-service portal where the customer
could choose their preferred profile, either fast (no interleaving), 4ms
or 16 ms interleaving, and also their safety margin to 6, 9 or 12 dB. Fast
or 4ms interleaving worked well with 12 dB SNR margin (which means lower
latency but also lower access speeds), whereas 6dB margin often required
16ms interleaving to work well.
--
Mikael Abrahamsson email: swmike@swm.pp.se
next prev parent reply other threads:[~2013-12-10 6:48 UTC|newest]
Thread overview: 12+ messages / expand[flat|nested] mbox.gz Atom feed top
2013-05-29 9:54 Mat Ford
2013-05-30 2:56 ` Dave Taht
2013-06-04 17:54 ` Jim Gettys
2013-06-11 10:51 ` Matthew Ford
2013-12-09 12:49 ` Matthew Ford
2013-12-10 6:48 ` Mikael Abrahamsson [this message]
2013-12-10 7:54 ` Neil Davies
2013-12-10 8:04 ` [Bloat] ADSL2+ interleaving (Re: CFP: Workshop on Reducing Internet Latency) Mikael Abrahamsson
2013-12-10 8:07 ` Neil Davies
2013-12-10 8:48 ` [Bloat] CFP: Workshop on Reducing Internet Latency MUSCARIELLO Luca IMT/OLN
2013-12-10 9:36 ` Mikael Abrahamsson
2013-12-10 9:40 ` MUSCARIELLO Luca IMT/OLN
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=alpine.DEB.2.02.1312100739200.24602@uplift.swm.pp.se \
--to=swmike@swm.pp.se \
--cc=bloat@lists.bufferbloat.net \
--cc=ford@isoc.org \
/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