On Fri, May 16, 2014 at 10:52 AM, <Valdis.Kletnieks@vt.edu> wrote:
On Thu, 15 May 2014 16:32:55 -0400, dpreed@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@lists.bufferbloat.net
https://lists.bufferbloat.net/listinfo/cerowrt-devel