Re: [Cerowrt-devel] tracking some diffserv related internet drafts better

["Black, David" <david.black@emc.com>]

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:dave.taht@gmail.com]
> Sent: Thursday, November 13, 2014 12:27 PM
> To: cerowrt-devel@lists.bufferbloat.net; 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