From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from ccr.org (static-96-255-157-131.washdc.fios.verizon.net [96.255.157.131]) by huchra.bufferbloat.net (Postfix) with ESMTP id 8445021F9AF for ; Sun, 19 Jul 2015 09:23:42 -0700 (PDT) Received: by ccr.org (Postfix, from userid 1001) id 4897C119C52; Sun, 19 Jul 2015 12:23:42 -0400 (EDT) Received: from ccr.org (localhost [127.0.0.1]) by ccr.org (Postfix) with ESMTP id 45060119C19 for ; Sun, 19 Jul 2015 12:23:42 -0400 (EDT) To: cerowrt-devel@lists.bufferbloat.net In-reply-to: References: Comments: In-reply-to cerowrt-devel-request@lists.bufferbloat.net message dated "Sat, 18 Jul 2015 12:00:01 -0700." X-Mailer: MH-E 8.4; nmh 1.2; GNU Emacs 24.2.1 Date: Sun, 19 Jul 2015 12:23:42 -0400 Message-ID: <33363.1437323022@ccr.org> From: Mike O'Dell 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 16:24:11 -0000 Sigh..... The most sophisticated QoS mechanism ever deployed in any material manner is the one which was ATM's raison d'etre. And ya know what? IT WASN'T USED! well, it was used a little - to give real-time video the goose over IP traffic in certain USG networks, but that was only TWO classes of service. I was at the meeting where DiffServ was invented and it was *NEVER* imagined for an instant that only a very small number of the bit patterns made any sense at all. Why? Because the ability to make the network behave differently is profoundly limited. However, at UUNET we decided that for most customers, the customer tail was the fundamental source of congestion. Hence, if we honored Diffmarks in the customer direction on the tails, the customer's site border router could honor them in the ISP direction and we'd find out quickly how much good it really does. We understood that it only worked on-net, but it was relatively easy to try. 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. The Diffserve model doesn't include any fairness guarantees, certainly the router implementations at the time didn't provide them and it isn't clear how that should work depending on how one interprets the Diffmarks. Note that if the ISP network is large, ingress source address filters don't do any good. There's plenty of room to have a botnet able to crush things all of it "on net". The fundamental problem with doing anything to police traffic in the customer-bound direction is that it requires imputing the desire of the customer to receive each and every packet. I haven't heard of any scheme for the requisite mind-reading which is implementable and doesn't contain the seeds of its own destruction by adversarial manipulation. So I have serious heartburn with Diffserv fundamentally. The notion that there could ever be that many different viable QoS flavors is, in my opinion, completely *absurd*. So, if you wanna try to do it in the ISP-bound direction, Party on, dudes! But don't expect much from the effort. Harumph -mo