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

Fri Nov 14 17:01:11 EST 2014

Hi Sebastian,

> 	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?

That is one of the open issues on the tsvwg-rtcweb-qos draft ;-).

The situation in network cores varies:

- MPLS-based: About 2 bits is all that's really widely possible.  The MPLS TC
	field that supports this is 3 bits, but has other uses.

- IP-based carrier: Harder to say, but 3 bits is a good guesstimate.  There
	was a lot of 3-bit IP Precedence support prior to RFC 2474 - that
	corresponds to the 8 class selector codepoints, and every
	additional DSCP used has network config and management cost.

- IP-based Enterprise: Ditto on pre-RFC-2474 IP Precedence, but there seems
	to be more flexibility here.  Even so, if I take all the traffic classes
	in RFC 4594, plus add an admission-controlled telephony/voice class
	(RFC 5865) I still wind up somewhere around 4 bits, and most networks
	will implement a subset of those classes, not all of them.

> 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).

Yes - WebRTC is expected to provide significant encouragement for browser adoption.

> 	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)...

Indeed it would be, and draft-geib-tsvwg-diffserv-intercon is intended as a
first step towards encouraging something better at network boundaries.

Thanks,
--David

> -----Original Message-----
> From: Sebastian Moeller [mailto:moeller0 at gmx.de]
> Sent: Friday, November 14, 2014 4:40 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 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
> >