<font face="tahoma" size="2"><p style="margin:0;padding:0;font-family: tahoma; font-size: 10pt; word-wrap: break-word;">The IETF used to require rough consensus and *working code*. The latter seems to be out of fashion - especially with a zillion code points for which no working code has been produced, and worse yet, no real world testing has demonstrated any value whatsoever.</p>
<p style="margin:0;padding:0;font-family: tahoma; font-size: 10pt; word-wrap: break-word;"> </p>
<p style="margin:0;padding:0;font-family: tahoma; font-size: 10pt; word-wrap: break-word;">It's also true that almost no actual agreements exist at peering points about what to do at those points. That's why diffserv appears to be a lot of energy wasted on something that has little to do with inter-networking.</p>
<p style="margin:0;padding:0;font-family: tahoma; font-size: 10pt; word-wrap: break-word;"> </p>
<p style="margin:0;padding:0;font-family: tahoma; font-size: 10pt; word-wrap: break-word;">"intserv" was a plausible idea, because within a vertically integrated system, one can enforce regularity and consistency.</p>
<p style="margin:0;padding:0;font-family: tahoma; font-size: 10pt; word-wrap: break-word;"> </p>
<p style="margin:0;padding:0;font-family: tahoma; font-size: 10pt; word-wrap: break-word;">So my view, for what it is worth, is that there are a zillion better things to put effort into than incorporating diffserv into CeroWRT!</p>
<p style="margin:0;padding:0;font-family: tahoma; font-size: 10pt; word-wrap: break-word;"> </p>
<p style="margin:0;padding:0;font-family: tahoma; font-size: 10pt; word-wrap: break-word;">Cui bono?</p>
<p style="margin:0;padding:0;font-family: tahoma; font-size: 10pt; word-wrap: break-word;"> </p>
<!--WM_COMPOSE_SIGNATURE_START--><!--WM_COMPOSE_SIGNATURE_END-->
<p style="margin:0;padding:0;font-family: tahoma; font-size: 10pt; word-wrap: break-word;"><br /><br />On Thursday, November 13, 2014 12:26pm, "Dave Taht" <dave.taht@gmail.com> said:<br /><br /></p>
<div id="SafeStyles1415932624">
<p style="margin:0;padding:0;font-family: tahoma; font-size: 10pt; word-wrap: break-word;">> This appears to be close to finalization, or finalized:<br />> <br />> http://tools.ietf.org/html/draft-ietf-dart-dscp-rtp-10<br />> <br />> And this is complementary:<br />> <br />> http://tools.ietf.org/html/draft-ietf-tsvwg-rtcweb-qos-03<br />> <br />> While wading through all this is tedious, and much of the advice contradictory,<br />> there are a few things that could be done more right in the sqm system<br />> that I'd like to discuss. (feel free to pour a cup of coffee and read<br />> the drafts)<br />> <br />> -1) They still think the old style tos imm bit is obsolete. Sigh. Am I<br />> the last person that uses ssh or plays games?<br />> <br />> 0) Key to this draft is expecting that the AF code points on a single<br />> 5-tuple not be re-ordered, which means dumping AF41 into a priority<br />> queue and AF42 into the BE queue is incorrect.<br />> <br />> 1) SQM only prioritizes a few diffserv codepoints (just the ones for<br />> which I had tools doing classification, like ssh). Doing so with tc<br />> rules is very inefficient presently. I had basically planned on<br />> rolling a new tc and/or iptables filter to "do the right thing" to map<br />> into all 64 codepoints via a simple lookup table (as what is in the<br />> wifi code already), rather than use the existing mechanism... and<br />> hesitated<br />> as nobody had nailed down the definitions of each one.<br />> <br />> That said, I have not measured recently the impact of the extra tc<br />> filters and iptables rules required.<br />> <br />> 1a) Certainly only doing AF42 in sqm is pretty wrong (that was left<br />> over from my test patches against mosh - mosh ran with AF42 for a<br />> while until they crashed a couple routers with it)<br />> <br />> The relevant lines are here:<br />> <br />> https://github.com/dtaht/ceropackages-3.10/blob/master/net/sqm-scripts/files/usr/lib/sqm/functions.sh#L411<br />> <br />> 1b) The cake code presently does it pretty wrong, which is eminately fixable.<br />> <br />> 1c) And given that the standards are settling, it might be time to<br />> start baking them into a new tc or iptables filter. This would be a<br />> small, interesting project for someone who wants to get their feet wet<br />> writing this sort of thing, and examples abound of how to do it.<br />> <br />> 2) A lot of these diffserv specs - notably all the AFxx codepoints -<br />> are all about variable drop probability. (Not that this concept has<br />> been proven to work in the real world) We don't do variable drop<br />> probability... and I haven't the slightest clue as to how to do it in<br />> fq_codel. But keeping variable diffserv codepoints in order on the<br />> same 5 tuple seems to be the way things are going. Still I have<br />> trouble folding these ideas into the 3 basic queue system fq_codel<br />> uses, it looks to me as most of the AF codepoints end up in the<br />> current best effort queue, as the priority queue is limited to 30% of<br />> the bandwidth by default.<br />> <br />> <br />> 3) Squashing inbound dscp should still be the default option...<br />> <br />> 4) My patch set to the wifi code for diffserv support disables the VO<br />> queue almost entirely in favor of punting things to the VI queue<br />> (which can aggregate), but I'm not sure if I handled AFxx<br />> appropriately.<br />> <br />> 5) So far as I know, no browser implements any of this stuff yet. So<br />> far as I know nobody actually deployed a router that tries to do smart<br />> things with this stuff yet.<br />> <br />> 6) I really wish there were more codepoints for background traffic than cs1.<br />> <br />> --<br />> Dave Täht<br />> <br />> thttp://www.bufferbloat.net/projects/bloat/wiki/Upcoming_Talks<br />> _______________________________________________<br />> Cerowrt-devel mailing list<br />> Cerowrt-devel@lists.bufferbloat.net<br />> https://lists.bufferbloat.net/listinfo/cerowrt-devel<br />> </p>
</div></font>