[Bloat] [Cerowrt-devel] fq_codel is two years old

[Jim Gettys]

On Fri, May 16, 2014 at 10:52 AM, <Valdis.Kletnieks at vt.edu> wrote:

> On Thu, 15 May 2014 16:32:55 -0400, dpreed at reed.com said:
>
> > And in the end of the day, the problem is congestion, which is very
> > non-linear.  There is almost no congestion at almost all places in the
> Internet
> > at any particular time.  You can't fix congestion locally - you have to
> slow
> > down the sources across all of the edge of the Internet, quickly.
>
> There's a second very important point that somebody mentioned on the NANOG
> list a while ago:
>
> If the local router/net/link/whatever isn't congested, QoS cannot do
> anything
> to improve life for anybody.
>
> If there *is* congestion, QoS can only improve your service to the normal
> uncongested state - and it can *only do so by making somebody else's
> experience
> suck more*....
>
​The somebody else might be "you", in which life is much better.​  once you
have the concept of flows (at some level of abstraction), you can make more
sane choices.

​Personally, I've mostly been interested in QOS in the local network: as
"hints", for example, that it is worth more aggressive bidding for transmit
opportunities in WiFi, for example to ensure my VOIP, teleconferencing,
gaming, music playing and other actually real time packets get priority
over bulk data (which includes web traffic), and may need access to the
medium sooner than for routine applications or scavenger applications.

Whether it should have any use beyond the scope of the network that I
control is less than clear to me, for the reasons you state; having my
traffic screw up other people's traffic isn't high on my list of "good
ideas".

The other danger of QOS is that applications may "game" its use of QOS, to
get preferential treatment, so each network (and potentially hosts) need to
be able to control its own policy, and detect (and potentially punish)
transgressors.  Right now, we don't have those detectors or controls in
place (and how to inform naive users that their applications are asking for
priority service for no good reason) is another unanswered question.

This gaming danger (and a UI to enable policy to be set), make me think
it's something we're going to have to work through carefully.

- Jim


>
> _______________________________________________
> Cerowrt-devel mailing list
> Cerowrt-devel at lists.bufferbloat.net
> https://lists.bufferbloat.net/listinfo/cerowrt-devel
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.bufferbloat.net/pipermail/bloat/attachments/20140516/3a67bd07/attachment.html>