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

Fri Nov 14 16:39:45 EST 2014

Hi David,

On Nov 14, 2014, at 21:49 , Black, David <david.black at emc.com> wrote:

>> 	I could be completely off my rocker, but that scheme would work
>> perfectly if the edge and the core would use 3 bits each max then the core can
>> just move the edge bits 0-2 to the so far empty bits 3-5 on ingres
> 
> "so far empty" ... not exactly ... AFxx and EF use those bits:
> 
> http://www.iana.org/assignments/dscp-registry/dscp-registry.xhtml#dscp-registry-1

	Well, I guess I forgot the smiley face there. But looking at information I just learned from the intercom RFC you referenced: if the core really only has room for 3bits of DS marking can the edge actually expect to use more than three bits of DS marking in a meaningful way? Thanks for the link that helps me bait to understand the beauty of DSCP, including that none intended to use of 64 concurrent code points ;) (only 32 of which 10 seem not assigned yet). in that light the 15 proposed code points for browsers spann half the standard pool (actually rather 68%) using the diffserv “dynamic range” quite well. I think I start to realize that there is basically one chance to change browser marking behaviour and it is much easier to map down to fewer priority queues than it is to introduce new “standard” marking later (heck it will probably tricky enough to get the proposed scheme implemented in all popular dowsers in a timely fashion).

> 
>> and back
>> to 0-2 on egress and each can do their own thing. On the other hand, if the
>> core does not actually use the edge markings then it could also jus ts quash
>> them nd the edge would not be any wiser.
> 
> The core should be mapping edge markings to core markings and then to some
> sort of edge marking at the far edge.  

	Sure, but with only 3 bits worth of core marking space, the egress marking will also just contain 8 combinations (unless a side channel to transfer the original marking or DPI is used in addition to the existing core markings). But this is really not my area of expertise as I have amply shown...

> I'd prefer to view terms like "squash"
> and "shift" as implementation-specific decisions about how to do those mappings.

	I happily agree, mapping is a more general term, so no more squashing just "map to zero” ;)

> 
> DiffServ allows implementers and network operators to do what they want with
> DSCPs, with the exception of the CSx DSCPs (details are in RFC 2474, some of
> which are already in this discussion).

	But the “do what they want part” is what makes using DSCPs across network boundaries so taxing/frustrating as even my EF marked packets might end up in my ISPs scavenger class… (First allowed "map to zero” followed by a DPI based new marking, I think that would be RFC conform)...

Best Regards
	Sebastian

> 
> Thanks,
> --David
> 
> 
>> -----Original Message-----
>> From: Sebastian Moeller [mailto:moeller0 at gmx.de]
>> Sent: Friday, November 14, 2014 3:36 PM
>> To: Black, David
>> Cc: Dave Täht; cerowrt-devel at lists.bufferbloat.net; draft-ietf-tsvwg-rtcweb-
>> qos at tools.ietf.org; draft-ietf-dart-dscp-rtp at tools.ietf.org
>> Subject: Re: [Cerowrt-devel] tracking some diffserv related internet drafts
>> better
>> 
>> Hi Dave(s),
>> 
>> On Nov 13, 2014, at 19:45 , Black, David <david.black at emc.com> wrote:
>> 
>>> 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/
>> 
>> 	I could be completely off my rocker, but that scheme would work
>> perfectly if the edge and the core would use 3 bits each max then the core can
>> just move the edge bits 0-2 to the so far empty bits 3-5 on ingress and back
>> to 0-2 on egress and each can do their own thing. On the other hand, if the
>> core does not actually use the edge markings then it could also jus ts quash
>> them nd the edge would not be any wiser.
>> 
>> Best Regards
>> 	Sebastian
>> 
>> 
>>> 
>>> 
>>>> -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 at gmail.com]
>>>> Sent: Thursday, November 13, 2014 12:27 PM
>>>> To: cerowrt-devel at 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
>>> _______________________________________________
>>> Cerowrt-devel mailing list
>>> Cerowrt-devel at lists.bufferbloat.net
>>> https://lists.bufferbloat.net/listinfo/cerowrt-devel
> 