Dave (T), > 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
The dart-dscp-rtp draft is now done and in the RFC Editor's Queue. The tsvwg-rtcweb-qos draft is still a work in progress, and its aggressive use of almost every PHB and DSCP is a concern. Here's another related draft that is likely to be adopted by the tsvwg WG soon: https://datatracker.ietf.org/doc/draft-geib-tsvwg-diffserv-intercon/ > -1) They still think the old style tos imm bit is obsolete. Sigh. Am I > the last person that uses ssh or plays games? See RFC 2474, published in 1998 ... > 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. Yes. That's supposed to be the case for any AF PHB group that's supported., e.g., AF3x [AF31, AF32 and AF33]. https://datatracker.ietf.org/doc/draft-geib-tsvwg-diffserv-intercon/ > 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. I'm happy to help w/insight, advice etc. - please ask. In turn, experience w/what's more vs. less likely to work where and why would be quite useful, e.g., for the tsvwg-rtcweb-qos draft. > 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. That's UDP-only at the moment if that helps. Variable drop probability doesn't do anything useful for TCP, and there's no good experience with other congestion controlled transports - see the dart-dscp-rtp draft. > 3) Squashing inbound dscp should still be the default option... Yes, very common out there. See the tsvwg-diffserv-intercon draft which is trying to specify a few small holes to punch into that "squash to zero" default ingress DSCP behavior. Yes, I'm an optimist ... > 6) I really wish there were more codepoints for background traffic than cs1. It's worse than that - CS1 may or may not be a background codepoint, see the dart-dscp-rtp draft. Thanks, --David > -----Original Message----- > From: Dave Taht [mailto:[email protected]] > Sent: Thursday, November 13, 2014 12:27 PM > To: [email protected]; Black, David > Subject: SQM: tracking some diffserv related internet drafts better > > 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 > contradictory, > 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/files/usr/lib/sqm/functions.sh#L411 > > 1b) The cake code presently does it pretty wrong, which is eminately fixable. > > 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. > > -- > Dave Täht > > thttp://www.bufferbloat.net/projects/bloat/wiki/Upcoming_Talks _______________________________________________ Cerowrt-devel mailing list [email protected] https://lists.bufferbloat.net/listinfo/cerowrt-devel
