Subject: [tsvwg] Diffserv intercon: Bleach unrecognised DSCPs?

From: <[email-masked]>
Date: Tue, 10 Mar 2015 12:21:41 +0100

Bob,

again as agreed with you a private mail forwarded to the list.

I agree, remarking is a separate issue. I'm out for a MAY rewrite to CS0 if an unknown DSCP is received, not a MUST or SHOULD. 

In addition to David, there are some points I'd like to add:

- Some vendors boxes restore "alles to ordnung" (all to order), 
  even if operators and standards are not amused.
- I'm completing your fundamental Internet design statement by 
  "...and [be] conservative with what you send."
- I prefer simple and straight policies. I don't want to 
  worry where a packet with an unknown DSCP may pop up in my 
  network and result in funny behavior, because the 
  engineers owning that node didn't agree an important part 
  of their configuration with me. Here I indeed prefer 
  "ordnung" (i.e. a controlled way of assigning DSCPs to 
  services and getting transport of marked packets).
- transparent transit of an unknown DSCP must not result in a 
  carrier being obliged to eternally carry such a DSCP 
  transparently in Best Effort class. The guys building 
  their business model on transparent unknown DSCP transit 
  could sit in the neighbor department. I prefer to have 
  a DSCP/MPLS TC reserve and use it as desired.

The "remarking unrecognized" draft to come may offer discussion of reasonable actions. I'm not sure whether consent can be reached on a single solution.

I'm happy to contribute or pick up authorship. But I don't want to do that alone.

Regards,

Ruediger

-----Original Mail-----
From: Black, David [mailto:[email-masked]] 
Sent: Monday, 9. March 2015 16:28
To: Bob Briscoe; Geib, Rüdiger
Cc: [email-masked]; MORTON, ALFRED C (AL); Rob SHAKIR; Achilles Petras; Black, David
Subject: RE: Diffserv intercon: Bleach unrecognised?

Bob,

Thanks for starting this discussion - the DiffServ RFCs are inconsistent on this topic, IMHO.  Of the two options:

> * Subsequent RFCs have never resolved the tension in RFC2474 between:
>    a) network A handing over /all/ DSCPs remarked to what network A 
> understands
>    b) network A handing over those DSCPs it understands, and leaving 
> the rest unchanged
> * Model (b) attempts to preserve the "be liberal in what you receive"
> principle, while (a) attempts to ensure "alles ist in ordnung" - tidy 
> and deterministic.

On ingress to network a, my understanding is that (a) is widely deployed (including remarking unrecognized DSCPs to CS0) so that the "alles ist in ordnung" within a network, at least as far as the DSCPs are concerned.
There are some DSCPs that have to be dealt with on ingress, e.g., CS6 and CS7, where remarking to CS0 is likely, absent a specific agreement to do otherwise.  Beyond that, it's simpler to operate a network if one can rely on the DSCP telling the routers what's supposed to happen, and this is also true for MPLS-based networks.

> * If network C receives some DSCPs from B that are not in their SLA, 
> it's hard to know what they mean anyway, because it's a bit of a 
> mystery which network last set them.

By default, that should network B "speaking".  Speculating about what an upstream network may have done is not good - it effectively absolves network B of responsibility for the DSCPs on traffic it sends to C, which is not what should be happening.

> * It is a potential security issue to remark unrecognised DSCPs to 
> CS0, because of the possibility of lower than best efforts traffic 
> classes, e.g. discard eligible, or bulk background.
>    - Normally, an intercon SLA from A to B will identify such traffic, 
> so that B doesn't /promote/ it to a better DSCP and therefore a better 
> treatment.
>    - It is theoretically possible that the SLA for traffic from A to B 
> does not identify sub-BE traffic (e.g. because B is a big core network 
> that doesn't care), so these DSCPs appear at the border from B to C. 
> Then C will find it useful that B did not remark unrecognised DSCPs.

Here I agree - this is a known problem area w/no good answer, because the proverbial "right thing to do," namely changing CS1 to less-than- best-effort did not work out, once upon a time.

Thanks,
--David

> -----Original Message-----
> From: Bob Briscoe [mailto:[email-masked]]
> Sent: Monday, March 09, 2015 10:12 AM
> To: [email-masked]; Black, David
> Cc: [email-masked]; MORTON, ALFRED C (AL); Rob SHAKIR; Achilles 
> Petras
> Subject: Diffserv intercon: Bleach unrecognised?
> 
> Ruediger, David,
> 
> As promised, a separate thread with some thoughts on remarking 
> unrecognised traffic to CS0 (best efforts) at interconnect points.
> Sorry the order of these thoughts is a bit random...
> 
> * Subsequent RFCs have never resolved the tension in RFC2474 between:
>    a) network A handing over /all/ DSCPs remarked to what network A 
> understands
>    b) network A handing over those DSCPs it understands, and leaving 
> the rest unchanged
> * Model (b) attempts to preserve the "be liberal in what you receive"
> principle, while (a) attempts to ensure "alles ist in ordnung" - tidy 
> and deterministic.
> * Any core router should be able to classify 'none of the above'
> DSCPs in the same rule as CS0, so I don't think this is a performance issue.
> * When network B receives DSCPs from A that aren't mentioned in their 
> SLA, if model b) applies, and B is using some of the unrecognised 
> DSCPs for something else, it has to remark them to CS0 anyway.
> * If network C receives some DSCPs from B that are not in their SLA, 
> it's hard to know what they mean anyway, because it's a bit of a 
> mystery which network last set them.
> * However, there's no harm in leaving unrecognised DSCPs unchanged.
> This is not a security issue.
> * And a downstream network might be willing to work out what they mean 
> if it's important enough.
> * It is a potential security issue to remark unrecognised DSCPs to 
> CS0, because of the possibility of lower than best efforts traffic 
> classes, e.g. discard eligible, or bulk background.
>    - Normally, an intercon SLA from A to B will identify such traffic, 
> so that B doesn't /promote/ it to a better DSCP and therefore a better 
> treatment.
>    - It is theoretically possible that the SLA for traffic from A to B 
> does not identify sub-BE traffic (e.g. because B is a big core network 
> that doesn't care), so these DSCPs appear at the border from B to C. 
> Then C will find it useful that B did not remark unrecognised DSCPs.
> 
> In summary (AFAICT): a general rule /not/ to change unrecognised DSCPs 
> would be safer than one to remark them all to CS0.
> 
> 
> 
> Bob
> 
> 
> ________________________________________________________________
> Bob Briscoe,                                                  BT