[Bloat] Packet loss in FCC press release

[Bloat] Packet loss in FCC press release

[Eggert, Lars]

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

Hi,

did anyone notice the second sentence in paragraph below from the FCC's press release at http://transition.fcc.gov/Daily_Releases/Daily_Business/2015/db0226/DOC-332260A1.pdf:

> In addition to the existing transparency rule, which was not struck down by the court, the Order requires that broadband providers disclose, in a consistent format, promotional rates, fees and surcharges and data caps. Disclosures must also include packet loss as a measure of network performance, and provide notice of network management practices that can affect service.

"Packet loss as a measure of network performance" being the only such measure explicitly called out doesn't leave me with the warm fuzzy feeling that the folks the factors affecting QoE over IP networks. ISPs are being incentivized to optimize for reduced packet loss, and we know how that goes.

Lars

[-- Attachment #2: Message signed with OpenPGP using GPGMail --]
[-- Type: application/pgp-signature, Size: 273 bytes --]

Re: [Bloat] Packet loss in FCC press release

[Jonathan Morton]

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

It's not ideal, but I'm not quite as worried about that as you might be.
There are several potential causes of packet loss in a network, and
increasing buffer sizes is only likely to have a minor and temporary effect
on one of them.

Meanwhile, increased deployment of ECN would permit adding AQM as a means
to decrease packet loss.

Random packet loss due to poor quality lines, and also due to dumb policers
and overloaded core routers, is probably what's intended here.

- Jonathan Morton

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

Re: [Bloat] Packet loss in FCC press release

[Dave Taht]

On Fri, Feb 27, 2015 at 7:47 AM, Jonathan Morton <chromatix99@gmail.com> wrote:
> It's not ideal, but I'm not quite as worried about that as you might be.
> There are several potential causes of packet loss in a network, and
> increasing buffer sizes is only likely to have a minor and temporary effect
> on one of them.

Clearly establishing that 0 packet loss (without ECN) is bad, that
some range of rates of packet loss relative to
bandwidth is GOOD, and levels above that indicative of a problem,
would nice. I can envision a meter
designed to show that.

>
> Meanwhile, increased deployment of ECN would permit adding AQM as a means to
> decrease packet loss.
>
> Random packet loss due to poor quality lines, and also due to dumb policers
> and overloaded core routers, is probably what's intended here.
>
> - Jonathan Morton
>
>
> _______________________________________________
> Bloat mailing list
> Bloat@lists.bufferbloat.net
> https://lists.bufferbloat.net/listinfo/bloat
>



-- 
Dave Täht
Let's make wifi fast, less jittery and reliable again!

https://plus.google.com/u/0/107942175615993706558/posts/TVX3o84jjmb

Re: [Bloat] Packet loss in FCC press release

[Rick Jones]

On 02/27/2015 07:47 AM, Jonathan Morton wrote:
> It's not ideal, but I'm not quite as worried about that as you might be.
> There are several potential causes of packet loss in a network, and
> increasing buffer sizes is only likely to have a minor and temporary
> effect on one of them.
>
> Meanwhile, increased deployment of ECN would permit adding AQM as a
> means to decrease packet loss.
>
> Random packet loss due to poor quality lines, and also due to dumb
> policers and overloaded core routers, is probably what's intended here.

Between having been raised in DC, and a wise old engineer teaching me 
the correct spelling is ass-u-me, I would suggest getting explicit 
clarification from the FCC is warranted.

rick jones

Re: [Bloat] Packet loss in FCC press release

[Matt Mathis]

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

You are failing to make a distinction between the edges (access) and the
core (ISP's backbone and interconnects).

At the edges, where multiplexing is relatively low and queueing is
required, loss or ECN is necessary to regulate queue occupancy.

In the core, where traffic is highly aggregated and queues are generally
tiny, (excess) loss indicates insufficient capacity, and that some users
are suffering due to other people's traffic.   In the core losses (or
queueing) are nearly always a bad thing.

This one sentence is sufficient to solve much of the net neutrality problem.

See: https://tools.ietf.org/html/draft-ietf-ippm-model-based-metrics-03

Thanks,
--MM--
The best way to predict the future is to create it.  - Alan Kay

Privacy matters!  We know from recent events that people are using our
services to speak in defiance of unjust governments.   We treat privacy and
security as matters of life and death, because for some users, they are.

On Fri, Feb 27, 2015 at 8:35 AM, Dave Taht <dave.taht@gmail.com> wrote:

> On Fri, Feb 27, 2015 at 7:47 AM, Jonathan Morton <chromatix99@gmail.com>
> wrote:
> > It's not ideal, but I'm not quite as worried about that as you might be.
> > There are several potential causes of packet loss in a network, and
> > increasing buffer sizes is only likely to have a minor and temporary
> effect
> > on one of them.
>
> Clearly establishing that 0 packet loss (without ECN) is bad, that
> some range of rates of packet loss relative to
> bandwidth is GOOD, and levels above that indicative of a problem,
> would nice. I can envision a meter
> designed to show that.
>
> >
> > Meanwhile, increased deployment of ECN would permit adding AQM as a
> means to
> > decrease packet loss.
> >
> > Random packet loss due to poor quality lines, and also due to dumb
> policers
> > and overloaded core routers, is probably what's intended here.
> >
> > - Jonathan Morton
> >
> >
> > _______________________________________________
> > Bloat mailing list
> > Bloat@lists.bufferbloat.net
> > https://lists.bufferbloat.net/listinfo/bloat
> >
>
>
>
> --
> Dave Täht
> Let's make wifi fast, less jittery and reliable again!
>
> https://plus.google.com/u/0/107942175615993706558/posts/TVX3o84jjmb
> _______________________________________________
> Bloat mailing list
> Bloat@lists.bufferbloat.net
> https://lists.bufferbloat.net/listinfo/bloat
>

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