Re: [tsvwg] COMMENT PLEASE: Which DSCP value should we use for LE PHB?

[<[e-mail]>]

Gorry, all,

let me sum up what I think we've discussed. I think there was some support, but no consensus for b) . c) only saw me speaking up for it explicitely, but it might be a pragmatic way out (I can't judge how much effort the IETF pool discussion will take, however). The trouble is caused by bit mask based DSCP re-marking. I don't expect bit-mask based DSCP classification and re-marking to disappear, as it allows for transport of multiple (re-marked) DSCP by a simple configuration.

There's consensus that a DSCP 000 xyz is a good choice for a LE PHB, I think. 

In general, any configuration should be simple, hence I expect a Diffserv domain:
- to classify and re-mark DSCPs based on bit-masks (a commodity at least in some routers).
- to classify DSCPs by a bit-mask and re-mark to a single DSCP (I'd like to understand whether that is desirable).
- I didn't check whether there's a feature like "re-mark AFx to AFy" (I can't recall to have heard of that).

Related to an LE PHB, a sending domain might be sending any standard/non- standard DSCP across an interconnection without an SLA. This traffic may experience (bit-mask based) DSCP re-marking by the receiving domain. Should that happen:

a) if all unknown DSCPs are re-marked to default DSCP, that's not an issue.

b) the receiver might re-mark based on bit-masks. Then
  Any AFv DSCP might continue as 000xy0 after a bit-mask based re-mark. If z = 0 for the LE DSCP, in 
  the case of congestion, this may cause a flow to be re-ordered. Depending on the choice of LE DSCP, 
  the drop rate of a re-marked AFv1 or AFv2 may be higher than that of AFv2 or AFv3.

c) if the LE DSCP is 000xy1, bit-mask based re-marking is less harmful. The proposed DSCP is from a 
     reserved pool and this needs to settled within IETF. 

Regards,

Ruediger