From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-yk0-x234.google.com (mail-yk0-x234.google.com [IPv6:2607:f8b0:4002:c07::234]) (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 E29C921FAA9 for ; Sun, 19 Jul 2015 12:24:37 -0700 (PDT) Received: by ykfw194 with SMTP id w194so45201372ykf.0 for ; Sun, 19 Jul 2015 12:24:35 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=9HRk7AuMCyJ2BT/piAK4crpHYr7POkEIHFnRggpEsD0=; b=Oof25HoLJBzoI5Hz1KE+FzoGEOjAOlZZaKR5yzTAcsgINNnkd1+cEdfz9tFkM47b3b X8AxtiZB5xSaPB7VRx1NWEaPLCgH3SekUKGUbhmfAJK/xtRSZdTU3RZwkkz9W+N+M0U+ Q1sALpJc8yfrIHPnmvMadD4rHFSwMrmq5ZCrxjccAzVeE8qmbFtmJh0pd4agd+sGTkuR vqJ5knjLbv+EJryq0UYDPwRoX1seGJwGb+NGhred6yJ78VPCetSo7/KWpcF8QezwhuZZ DxAg5lrYQyXytCKg2Vocy9rB0JyeTiSZIGHo0q/NSnADQqXqKHFvKYXOu4bUoMZwbDe9 ye3A== MIME-Version: 1.0 X-Received: by 10.129.145.210 with SMTP id i201mr25044108ywg.133.1437333875758; Sun, 19 Jul 2015 12:24:35 -0700 (PDT) Received: by 10.37.60.133 with HTTP; Sun, 19 Jul 2015 12:24:35 -0700 (PDT) Received: by 10.37.60.133 with HTTP; Sun, 19 Jul 2015 12:24:35 -0700 (PDT) In-Reply-To: <33363.1437323022@ccr.org> References: <33363.1437323022@ccr.org> Date: Sun, 19 Jul 2015 22:24:35 +0300 Message-ID: From: Jonathan Morton To: "Mike O'Dell" Content-Type: multipart/alternative; boundary=94eb2c093a44169d65051b3f5fb9 Cc: cerowrt-devel@lists.bufferbloat.net Subject: Re: [Cerowrt-devel] Cerowrt-devel Digest, Vol 44, Issue 24 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: Sun, 19 Jul 2015 19:25:06 -0000 --94eb2c093a44169d65051b3f5fb9 Content-Type: text/plain; charset=UTF-8 > We were on the verge of enabling it on our (the UUNET) end when Louis Mamakos identified the fundamental show-stopper to doing it. > > It gives DOS attacks nuclear weapons. > > Simply set the DOS packets to the highest priority and pound away. I identified this problem when designing cake, and came up with a solution: Every request for higher priority (low latency) is also interpreted as a relinquishment of rights over high bandwidth. In an early version, this tenet was enforced using hard limits. This worked as designed, but caused problems for users attempting to tune their bandwidth setting using best effort traffic, since there was also a least effort class below that. In the current version, a bandwidth threshold is used instead. If the traffic in the class remains below the threshold, then they get the (non strict) priority requested. If it strays above, the priority is demoted below other classes instead. In the absence of competing traffic, any class can use the full available bandwidth, but there's always room for other classes to start up. None of this behaviour is specified, suggested or even identified as desirable in the relevant RFCs. I had to invent it out of whole cloth, after recognising that Diffserv is simply not specified in a way that can be practically implemented, or from an implementor's point of view. The old version of the TOS byte was much clearer in that respect - three bits of precedence, three or four bits of routing preferences (although the latter was also poorly specified, it was at least clear what it meant). Frankly I think IETF dropped the ball there. "Rough consensus and working code." I find it difficult to believe that they had working code implementing a complete Diffserv system. - Jonathan Morton --94eb2c093a44169d65051b3f5fb9 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable

> We were on the verge of enabling it on our (the UUNET) = end when
Louis Mamakos identified the fundamental show-stopper to doing it.
>
> It gives DOS attacks nuclear weapons.
>
> Simply set the DOS packets to the highest priority and pound away.

I identified this problem when designing cake, and came up w= ith a solution:=C2=A0 Every request for higher priority (low latency) is al= so interpreted as a relinquishment of rights over high bandwidth.

In an early version, this tenet was enforced using hard limi= ts. This worked as designed, but caused problems for users attempting to tu= ne their bandwidth setting using best effort traffic, since there was also = a least effort class below that.

In the current version, a bandwidth threshold is used instea= d. If the traffic in the class remains below the threshold, then they get t= he (non strict) priority requested. If it strays above, the priority is dem= oted below other classes instead. In the absence of competing traffic, any = class can use the full available bandwidth, but there's always room for= other classes to start up.

None of this behaviour is specified, suggested or even ident= ified as desirable in the relevant RFCs. I had to invent it out of whole cl= oth, after recognising that Diffserv is simply not specified in a way that = can be practically implemented, or from an implementor's point of view.= The old version of the TOS byte was much clearer in that respect - three b= its of precedence, three or four bits of routing preferences (although the = latter was also poorly specified, it was at least clear what it meant).

Frankly I think IETF dropped the ball there. "Rough con= sensus and working code." I find it difficult to believe that they had= working code implementing a complete Diffserv system.

- Jonathan Morton

--94eb2c093a44169d65051b3f5fb9--