From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-ob0-x22d.google.com (mail-ob0-x22d.google.com [IPv6:2607:f8b0:4003:c01::22d]) (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 4940021F1B8 for ; Thu, 13 Nov 2014 09:26:40 -0800 (PST) Received: by mail-ob0-f173.google.com with SMTP id wn1so11211721obc.18 for ; Thu, 13 Nov 2014 09:26:39 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:date:message-id:subject:from:to:content-type :content-transfer-encoding; bh=IX8SLI70gsIr62vyqvwFvi3gLmxMVuB7yvWT1ZvoddA=; b=b82o71Jnj1BLprQ7QZiBV/E9V61OoPKHIFRDSdJei//8iB+4/dknv6ZdJ4mdnFvAX8 NUGdtEgJFTQMhOesRf96ZhgzsXwY8N6HIlxLzAjNGntRlDOmQkoHnrMcBQeKLRhpV1aK ZOQ6gRN1v+rWBrnzpqnfhdXoXR89s5nkB9IDNjfjBluxG5aalq1e+WM36SWuLTa8X4rs CvGtaYa9QnOQb1PEZ0JlaG44cuiUjQV2ieURATOhzCSwrsSToKSexmn0ICfi/b5OBJ2C SIMDx8E6RjX2GkxOVd594/h3BgkMgAoKieBI8l4v71eyL8CPSFL+LL8IaHfuhfeWwpNb Bg5g== MIME-Version: 1.0 X-Received: by 10.202.218.11 with SMTP id r11mr2979096oig.28.1415899599881; Thu, 13 Nov 2014 09:26:39 -0800 (PST) Received: by 10.202.227.211 with HTTP; Thu, 13 Nov 2014 09:26:39 -0800 (PST) Date: Thu, 13 Nov 2014 09:26:39 -0800 Message-ID: From: Dave Taht To: "cerowrt-devel@lists.bufferbloat.net" , david.black@emc.com Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Subject: [Cerowrt-devel] SQM: tracking some diffserv related internet drafts better 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: Thu, 13 Nov 2014 17:27:09 -0000 This appears to be close to finalization, or finalized: http://tools.ietf.org/html/draft-ietf-dart-dscp-rtp-10 And this is complementary: http://tools.ietf.org/html/draft-ietf-tsvwg-rtcweb-qos-03 While wading through all this is tedious, and much of the advice contradict= ory, there are a few things that could be done more right in the sqm system that I'd like to discuss. (feel free to pour a cup of coffee and read the drafts) -1) They still think the old style tos imm bit is obsolete. Sigh. Am I the last person that uses ssh or plays games? 0) Key to this draft is expecting that the AF code points on a single 5-tuple not be re-ordered, which means dumping AF41 into a priority queue and AF42 into the BE queue is incorrect. 1) SQM only prioritizes a few diffserv codepoints (just the ones for which I had tools doing classification, like ssh). Doing so with tc rules is very inefficient presently. I had basically planned on rolling a new tc and/or iptables filter to "do the right thing" to map into all 64 codepoints via a simple lookup table (as what is in the wifi code already), rather than use the existing mechanism... and hesitated as nobody had nailed down the definitions of each one. That said, I have not measured recently the impact of the extra tc filters and iptables rules required. 1a) Certainly only doing AF42 in sqm is pretty wrong (that was left over from my test patches against mosh - mosh ran with AF42 for a while until they crashed a couple routers with it) The relevant lines are here: https://github.com/dtaht/ceropackages-3.10/blob/master/net/sqm-scripts/file= s/usr/lib/sqm/functions.sh#L411 1b) The cake code presently does it pretty wrong, which is eminately fixabl= e. 1c) And given that the standards are settling, it might be time to start baking them into a new tc or iptables filter. This would be a small, interesting project for someone who wants to get their feet wet writing this sort of thing, and examples abound of how to do it. 2) A lot of these diffserv specs - notably all the AFxx codepoints - are all about variable drop probability. (Not that this concept has been proven to work in the real world) We don't do variable drop probability... and I haven't the slightest clue as to how to do it in fq_codel. But keeping variable diffserv codepoints in order on the same 5 tuple seems to be the way things are going. Still I have trouble folding these ideas into the 3 basic queue system fq_codel uses, it looks to me as most of the AF codepoints end up in the current best effort queue, as the priority queue is limited to 30% of the bandwidth by default. 3) Squashing inbound dscp should still be the default option... 4) My patch set to the wifi code for diffserv support disables the VO queue almost entirely in favor of punting things to the VI queue (which can aggregate), but I'm not sure if I handled AFxx appropriately. 5) So far as I know, no browser implements any of this stuff yet. So far as I know nobody actually deployed a router that tries to do smart things with this stuff yet. 6) I really wish there were more codepoints for background traffic than cs1= . --=20 Dave T=C3=A4ht thttp://www.bufferbloat.net/projects/bloat/wiki/Upcoming_Talks