Re: [Cake] ieee vs ietf stds for dscp mappings

[Sebastian Moeller <moeller0@gmx.de>]

Hi Jonathan,

thanks for the long reply.

On Nov 14, 2015, at 17:46 , Jonathan Morton <chromatix99@gmail.com> wrote:

> 
>> On 14 Nov, 2015, at 17:53, Sebastian Moeller <moeller0@gmx.de> wrote:
>> 
>> Is anybody actually using any of that? The set of differences between the schemes as RFCd for the different technologies makes me believe nobody is ever using more than one of those domains.
> 
> That’s part of the problem.  The various recommendations conflict with each other and with actual practice.

	That is the base for my hypothesis that they are not used in conjunction, as that would not work too well. On the other hand maybe it works good enough/ better than without DSCP so people might just not care about the fine print?

> 
> Note in particular the different treatments just of CS0 (default, and defined as Best Effort) and CS1 (defined as Background Traffic) - RFC 7561 actually gets them backwards!  The Szigeti-Baker draft is relatively sane and comprehensive, even though it differs from Cake’s schema in detail.
> 
> The core of the problem is that Diffserv was originally specified without a complete, working implementation of its PHBs (Per Hop Behaviours).  AFAIK, no such implementation exists to date - certainly no public one.  So there are ad-hoc, locally-defined approximations all over the place, and my chart illustrates some of that.
> 
> As well as the PHBs being poorly defined, it has become general practice for *networks* to set the DSCPs on traffic passing through them, rather than applications setting them at the endpoints.  This makes it difficult for applications to express their traffic characteristics and transport needs in general.  However, I think this practice has arisen because applications have not bothered to set their own DSCPs, due to their having no effect in most networks.

	Well any equipment actually looking at the DSCP will need to consider whether the network owner approved of that marking. In other swords it might make a lot of sense to separate the 6b bits into 2 groups of 3 bits, one group for the current network’s effective markings and three for the endpoints to signal their intent. I realize that this still has the issue that one needs to trust the upstream enough to not have fudged the intent bits… but at least this idea realizes that the 6 bits have different parties interested in using them… I guess the only solution for the trust thing is a tunneled connection, then one only needs to trust the sender to accept the encrypted IP header’s DSCP markings.

> 
> Dave noted previously that a lot of traffic gets marked as CS1 in Comcast’s network.  I’ve recently noticed the same about the Elisa/Saunalahti network over here, having got myself a 4G-capable receiver that came with a prepaid 1-month Saunalahti SIM.  DNA, my usual network, does something different - not sure whether it just doesn’t bother changing DSCPs, or does something more complex.

	It might just do proper hygiene and rem app everything to DSCP 0 as not to leak internal network details outside DNA’s own network; I believe this is a functionality cake hold learn (I think Kevin implemented a branch allowing that…)

Best Regards
	Sebastian

> 
> - Jonathan Morton
>