From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mout.gmx.net (mout.gmx.net [212.227.15.18]) (using TLSv1.2 with cipher DHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by lists.bufferbloat.net (Postfix) with ESMTPS id A14833B2A2 for ; Wed, 12 Oct 2016 16:19:05 -0400 (EDT) Received: from android-46c2400c2dc9e9b2.lan ([80.135.113.61]) by mail.gmx.com (mrgmx003) with ESMTPSA (Nemesis) id 0MOOdZ-1bpBK623nx-005sh2; Wed, 12 Oct 2016 22:19:03 +0200 User-Agent: K-9 Mail for Android In-Reply-To: References: <4D2419FB-6649-4250-9D42-E6EDECFFCCDE@gmail.com> <95CB6153-524D-499A-8E85-231C5098A4DB@gmx.de> <42DC9EF5-80A0-439E-9507-085A0F566B22@gmx.de> MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable From: Sebastian Moeller Date: Wed, 12 Oct 2016 22:19:05 +0200 To: Jonathan Morton ,ching lu CC: cake@lists.bufferbloat.net Message-ID: X-Provags-ID: V03:K0:1Uz+UfgFFN1k+SxhZY/9lyQkQ+ceOgvOjiw73htLe0zbqBWsTsQ jWiEmf91l6PPWc69ZAO9AGe4F1nGQFTm0opf/R+Q+E6JrrYGuBA4Vetk0Ivt9TG4S/RmYop 8yqFy+nqmLN9u+kFfIU8bgyxjARcrRan0s4Ngvpp44nnCFuo5GrmyUgAEqpHx3rtS04hiTE QHZCt/pCfcYxK8GNJUUmg== X-UI-Out-Filterresults: notjunk:1;V01:K0:N5K8Sklp5Ng=:k8M9qF1zTe0aTu2D0jMA9K h+p8oJsCWvuJwafPhml7ewbKjkknn1Z/7oZW/fSzlP0zMaWEBjnyQ6m55e00+ryUB6Zepbvzo 8irma5EpdukylcrvkZ8khzdhJn5wzr510NtqY07DH1bcL1H7/gNS0F6vvKTt9kXqykyNMBADP Fx5jPTO25h2X3Poxgz0hgApXADxPgRn8+91tX8IBHLN3Swr9P4syQjJ9/IvSCld/EvCe0xw/x 8BBghqJYEVwb183tKF2GloE7s+inT3HQaDHypqdyb84DP7r5t3rr3gnRocIx2SOu6f1badAJc aufHLfGFNDUBzClV5TULOf+PQT3WGE22820DwvJ4SPyaAbmB+EkwEixEnzgc0n/W7BOpF6GzS ovQHLaedujOz07Ba18bkqD6fNwacnuAL6PkhAzDWE0fXOph5XtUDXkrryXrCIaBZ5on+LFg3Z yhbKiVbVrxdDr4uxYPE0lj0duuGsnZCie8wbs2CfM0+m8RtyI5DwqQvrT1MnB6LCqayj1LkQA HegpaXwZ+pickZ/bBuH6ZJnttS9BNCe/moU1JTFYLyukHu3ckdY4iLzyfGOPZnKxq9073IJA7 FBl1VOSG7bCESTXPfhmDQYo0Fa1MqF/SxJwgbJ+acXVQHn/F3Q0R0WLbPoX5tJIFl4xhJhhYY Ox91q4acJKmkQtqB95rl4rbm0qt34ULyWsSv99KpHIPVRyooe1ipfreFMhj0s5LCuvANr04Zu ov/Slcyi5iBbfejU6v70hq07InZxM+Wwg0/PY6nRMmkGB/X1vYxpYMBwDcAR4RXGJfkI7PAor GI+rTaS Subject: Re: [Cake] diffserv based on firewall mark X-BeenThere: cake@lists.bufferbloat.net X-Mailman-Version: 2.1.20 Precedence: list List-Id: Cake - FQ_codel the next generation List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 12 Oct 2016 20:19:06 -0000 Hi there, On October 12, 2016 5:36:32 PM GMT+02:00, Jonathan Morton wrote: > >> On 12 Oct, 2016, at 15:40, ching lu wrote: >>=20 >> DSCP -> unreliable, easily spoofed by attacker > >I=E2=80=99d like to address the =E2=80=9Ceasily spoofed by attacker=E2=80= =9D point >specifically=2E > >Cake=E2=80=99s interpretation of Diffserv is as a three-way tradeoff betw= een >throughput priority, latency priority, and altruism=2E If you choose a >DSCP meaning =E2=80=9Clow latency=E2=80=9D such as CS6 or EF, Cake gives = it higher >weight than average, but *only* if the aggregate bandwidth of >supposedly low-latency traffic is below a reasonable fraction of the >link bandwidth=2E Beyond that point, it gets *lower* weight than >average, but is still able to use spare bandwidth that happens to be >available=2E > >There is no way to get =E2=80=9Cabsolute priority=E2=80=9D, which this ty= pe of attacker >would presumably want, just by setting a particular DSCP=2E The default >=E2=80=9Cbest effort=E2=80=9D DSCP is in fact interpreted as =E2=80=9Cthr= oughput priority=E2=80=9D, >which is what most bulk traffic wants=2E In this respect, Cake differs >from the original IP Precedence specification (which is long obsolete) >and most other naive Diffserv implementations=2E > >In short, Cake does not unreasonably *trust* the DSCP field, but >instead offers explicit incentives for traffic to set it correctly=2E=20 With the slight complication that there is no canonically agreed upon valu= e for correct, and cake' does not make it easy to predict how much traffic = a specific priority tier will allow before degrading the requested priority= , no? In short cake adds to the confusion independent of whether cake's rat= ionale is sane=2E=2E=2E=20 >This adheres to the relevant PHB specifications, which are published as >RFCs and thus can be used as a standard=2E The problem I see is that in the DSCP RFC it is explicitly stated that mar= kings only are supposed/guaranteed to have meaning inside a dscp domain=2E= =2E=2E With the home net typically being regarded as a domain independent o= f the ISPs=2E=2E=2E > >The CS1 or =E2=80=9CBackground=E2=80=9D DSCP is the one with an altruisti= c meaning=2E It >has low priority whichever side of the bandwidth threshold it lies, so >it always mostly yields to other traffic=2E Clients are of course >permitted to not set it, but that=E2=80=99s what your firewall rules are = for=2E=20 >The Diffserv spec explicitly allows you to change the DSCP on entry to >your own network, which is what I suggested in my first reply=2E They even recommend that IIRC, including recommending re-mapping to zero i= f in doubt=2E Best Regards Sebastian > >Setting the DSCP with iptables rules should work just as well and in >the same way as using the =E2=80=9Cfirewall mark=E2=80=9D functionality a= s you already >do=2E Set it up that way in the first instance, directly replacing each >HTB+fq_codel combination with a Cake instance, and see how it works > > - Jonathan Morton