From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-oa0-x236.google.com (mail-oa0-x236.google.com [IPv6:2607:f8b0:4003:c02::236]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by huchra.bufferbloat.net (Postfix) with ESMTPS id 474AD21F144; Fri, 16 May 2014 09:06:36 -0700 (PDT) Received: by mail-oa0-f54.google.com with SMTP id j17so3292680oag.27 for ; Fri, 16 May 2014 09:06:35 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:date:message-id:subject :from:to:cc:content-type; bh=RJD6eLDW8iwfCSeEEKuJnSGG6kFSWvA8m1AsYhMBx0Y=; b=s4M1a3qTN/azCNbSuiBp/z6YHnCXgptDCPIxyVeXJuVNz5cKhZHofMzwD/DMUmgeZL iVBqtmlnYHJZEMx7rQlW0IlsgWc+NXN7jpd510/x/3+6P1CYy0TfOe+5Uj3sG2csQtA1 VvACs8DUq7irNnsgveiJPkaP6Rkuqthtu/0nTXrsE9i1xV9pKireEUnMPvU7dUsb/hfy T5t/cRN+VOk6g7DKSflRsXRqOfg6Y/6mCVmPpS+YBNBClHBsEZ00lUXF4/7Sz080O8Hf kHXMeIqGAL30AvkFiriyL1VPIw8qLyquPCtTgFMo2N/GL5yaXT1Ar/sQMBRmDKICjNOG kKLg== MIME-Version: 1.0 X-Received: by 10.60.149.233 with SMTP id ud9mr18120717oeb.66.1400256395147; Fri, 16 May 2014 09:06:35 -0700 (PDT) Sender: gettysjim@gmail.com Received: by 10.76.73.100 with HTTP; Fri, 16 May 2014 09:06:34 -0700 (PDT) In-Reply-To: <15152.1400251979@turing-police.cc.vt.edu> References: <3583FA43-EF5B-42D7-A79C-54C87AA514D5@gmail.com> <5373EEFF.5030407@pollere.com> <1400161663.82913275@apps.rackspace.com> <5374EC39.7040902@pollere.com> <1400185975.95298344@apps.rackspace.com> <15152.1400251979@turing-police.cc.vt.edu> Date: Fri, 16 May 2014 12:06:34 -0400 X-Google-Sender-Auth: m6ofd8tV87E6vG3l8Z68LUQg9cM Message-ID: From: Jim Gettys To: Valdis.Kletnieks@vt.edu Content-Type: multipart/alternative; boundary=047d7b41c0cc06ff1504f98699fa Cc: Kathleen Nichols , cerowrt-devel , bloat Subject: Re: [Cerowrt-devel] [Bloat] fq_codel is two years old X-BeenThere: cerowrt-devel@lists.bufferbloat.net X-Mailman-Version: 2.1.13 Precedence: list List-Id: Development issues regarding the cerowrt test router project List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 16 May 2014 16:06:36 -0000 --047d7b41c0cc06ff1504f98699fa Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable On Fri, May 16, 2014 at 10:52 AM, 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 NANO= G > 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*.... > =E2=80=8BThe somebody else might be "you", in which life is much better.=E2= =80=8B once you have the concept of flows (at some level of abstraction), you can make more sane choices. =E2=80=8BPersonally, I've mostly been interested in QOS in the local networ= k: 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 > > --047d7b41c0cc06ff1504f98699fa Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable


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. =C2=A0There is almost no congestion at almost all places i= n the Internet
> at any particular time. =C2=A0You can't fix congestion locally - y= ou 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 an= ything
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 ex= perience
suck more*....
=E2=80=8BThe somebody else might be "you", in which li= fe is much better.=E2=80=8B =C2=A0once you have the concept of flows (at so= me level of abstraction), you can make more sane choices.

=E2= =80=8BPersonally, I've mostly been interested in QOS in the local netwo= rk: as "hints", for example, that it is worth more aggressive bid= ding for transmit opportunities in WiFi, for example to ensure my VOIP, tel= econferencing, gaming, music playing and other actually real time packets g= et priority over bulk data (which includes web traffic), and may need acces= s to the medium sooner than for routine applications or scavenger applicati= ons.

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

The other danger of QOS is tha= t applications may "game" its use of QOS, to get preferential tre= atment, so each network (and potentially hosts) need to be able to control = its own policy, and detect (and potentially punish) transgressors. =C2=A0Ri= ght 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. =C2=A0

This gaming danger (and a UI t= o enable policy to be set), make me think it's something we're goin= g to have to work through carefully.
=C2=A0 =C2=A0 =C2=A0= =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 - Jim



_______________________________________________
Cerowrt-devel mailing list
Cerowrt-devel@lists.= bufferbloat.net
https://lists.bufferbloat.net/listinfo/cerowrt-devel


--047d7b41c0cc06ff1504f98699fa--