Subject: [tsvwg] Why a new DSCP can help with Lower Effort deployment

From: Roland Bless <[email-masked]>
Date: Thu, 23 Jul 2015 19:12:46 +0200

Hi,

Bob Briscoe commented (to the proposal of using
000010 as new DSCP for LE) that we may simply burn another
DSCP and gain nothing. I don't think so, because we at least
get rid of the ambiguity DSCP CS1 => CS PHB (RFC 2474) or
DSCP CS1 => LE PDB (RFC 3662). This would be at least a step
forward.

So let's assume an application wants to use Lower Effort
as defined in RFC 3662. The following cases may occur:
1.) Marked as DSCP CS1
   a.) handled as LE [good]
   b.) bleached => handled as BE [maybe bad (I)]
   c.) dropped [app must be prepared for this (II)]
   d.) handled as in RFC2474 => priority inversion [bad]

2.) Marked as DSCP LE = 000010
   a.) handled as LE [good]
   b.) bleached => handled as BE [maybe bad (I)]
   c.) dropped [app must be prepared for this (II)]

(I) the original intent of LE is to not harm the BE traffic
(II) "the network makes no commitment to deliver LE packets"

So with a new DSCP outcome d.) will disappear, which IMHO is
a good thing.

Regards,
 Roland

---

From: Brian E Carpenter <[email-masked]>
Date: Fri, 24 Jul 2015 07:03:47 +1200

On 24/07/2015 05:12, Roland Bless wrote:
> DSCP and gain nothing. 

Actually, we don't burn anything. With 8 exceptions, all DSCP
"standards" are only RECOMMENDED [RFC2119]. Any operator is free
to use the recommended values, or not. The same goes for any inter-
operator agreement at a domain boundary (and where there is no
agreement, bleaching will occur, so it doesn't matter anyway).

The 8 exceptions are CS0..CS7, which were explicitly preserved to
be compatible with IPv4 TOS.

It is very unfortunate that CS1, which is a MUST code point
in RFC 2474 section 4.2.2.1, was suggested for LE by RFC 3662
and later effectively promoted to a recommendation. That is
a clear and simple violation of RFC 2474. Mea culpa, I missed
that back in 2003 (and so did various other people).

> I don't think so, because we at least

Exactly.

> So with a new DSCP outcome d.) will disappear, which IMHO is

And, to repeat, we haven't really wasted a precious resource.
Running out of DSCPs is simply not a thing, in any realistic
deployment. (IMNSHO, any deployment that tries to use more
than three or four DSCPs at the same time is pretty much doomed
anyway. KISS applies.)

Rgds
   Brian

---

From: <[email-masked]>
Date: Fri, 24 Jul 2015 10:27:43 +0200

Roland,

the discussion may miss a pre-requisite. There are two options at domain boundaries:

- sender negotiates QoS with receiver. In that case expected 
  DSCPs and treatment of unexpected DSCPs and all PHBs should 
  be defined.

- sender does not negotiate QoS with receiver. My impression 
  is that below you and also Bob say in that case CS1 means 
  scavenger. To the receiver it is just an unknown DSCP and the 
  expected PHB is undefined. Existing standards 
  recommend Best Effort forwarding in that case. And they 
  allow for remarking.

To me, we need to settle the above issue, before we start to discuss something else.

Regards, Ruediger

-----Ursprüngliche Nachricht-----
Von: tsvwg [mailto:[email-masked]] Im Auftrag von Roland Bless
Gesendet: Donnerstag, 23. Juli 2015 19:13
An: tsvwg
Betreff: [tsvwg] Why a new DSCP can help with Lower Effort deployment

Hi,

Bob Briscoe commented (to the proposal of using 000010 as new DSCP for LE) that we may simply burn another DSCP and gain nothing. I don't think so, because we at least get rid of the ambiguity DSCP CS1 => CS PHB (RFC 2474) or DSCP CS1 => LE PDB (RFC 3662). This would be at least a step forward.

So let's assume an application wants to use Lower Effort as defined in RFC 3662. The following cases may occur:
1.) Marked as DSCP CS1
   a.) handled as LE [good]
   b.) bleached => handled as BE [maybe bad (I)]
   c.) dropped [app must be prepared for this (II)]
   d.) handled as in RFC2474 => priority inversion [bad]

So with a new DSCP outcome d.) will disappear, which IMHO is a good thing.

Regards,
 Roland

---

From: Brian E Carpenter <[email-masked]>
Date: Fri, 24 Jul 2015 20:55:49 +1200

Hi,

On 24/07/2015 20:27, [email-masked] wrote:
> - sender negotiates QoS with receiver. 

Do you mean negotiated by humans and placed in an SLA, or
dynamically negotiated by machines?

>   In that case expected

Yes.

>   recommend Best Effort forwarding in that case. And they 

Alternatively, it is a known RFC 2474 DSCP called "Class Selector 1",
in which case the traffic will get precedence over Best Effort.
That is not a desirable result.

   Brian

---

From: Roland Bless <[email-masked]>
Date: Fri, 24 Jul 2015 10:57:51 +0200

Hi Ruediger,

>   DSCPs and treatment of unexpected DSCPs and all PHBs should 

by "receiver" I guess you actually mean the DiffServ (DS) domain that
receives a packet and not the other end-system?! There also may
be different DS domains that need to be traversed along the path.
For every "elevated QoS" negotiation should be the case, e.g., EF
usually doesn't work as intended if neither admission control nor
policing at the domain boundaries is properly done. However, for lower
effort, there is no need to "negotiate". The only problem is the
expectation that lower effort is supported within the domain.
If it is not supported, it will usually be remarked to Best Effort,
see below.

>   scavenger. To the receiver it is just an unknown DSCP and the 

This is basically the problem of using DSCPs as indication
of QoS behavior expectation. A new codepoint for LE
would make the intent of the application at least unambiguous
and that's IMHO the progress that we can achieve.

>   recommend Best Effort forwarding in that case. And they 

In some cases this is no problem, in other cases, the application
may want to back-off if LE is not supported. Applications may detect
whether bleaching happened if they get feedback about this.
For instance, if remarked to BE they may use a LEDBAT like congestion
control at least.

> To me, we need to settle the above issue, before we start to discuss something else.

I don't see a problem here or I didn't get your point.

Regards,
 Roland

---

From: <[email-masked]>
Date: Fri, 24 Jul 2015 11:45:21 +0200

Hi Roland,

my point is that a sender/receiver has no notion of which PHB a DSCP identifies, when 

- the receiver doesn't inform others, that it supports a PHB (here a   
  published statement that scavenger is supported by DSCP xyz on all
  interconnection and access interfaces).
- the receiver is not informed by the sender about the PHB a sender 
  links to a DSCP (here CS1 is scavenger). 

You and Bob assume CS1 marked traffic can only identify PHB/PDB scavenger, if sent. My view: this doesn't hold. A DSCP could mean anything, unless one of both parties defines how the DSCP is interpreted.

Regards,

Ruediger

-----Ursprüngliche Nachricht-----
Von: Roland Bless [mailto:[email-masked]] 
Gesendet: Freitag, 24. Juli 2015 10:58
An: Geib, Rüdiger
Cc: [email-masked]
Betreff: Re: [tsvwg] Why a new DSCP can help with Lower Effort deployment

Hi Ruediger,

>   DSCPs and treatment of unexpected DSCPs and all PHBs should 

by "receiver" I guess you actually mean the DiffServ (DS) domain that receives a packet and not the other end-system?! There also may be different DS domains that need to be traversed along the path.
For every "elevated QoS" negotiation should be the case, e.g., EF usually doesn't work as intended if neither admission control nor policing at the domain boundaries is properly done. However, for lower effort, there is no need to "negotiate". The only problem is the expectation that lower effort is supported within the domain.
If it is not supported, it will usually be remarked to Best Effort, see below.

>   scavenger. To the receiver it is just an unknown DSCP and the

This is basically the problem of using DSCPs as indication of QoS behavior expectation. A new codepoint for LE would make the intent of the application at least unambiguous and that's IMHO the progress that we can achieve.

>   recommend Best Effort forwarding in that case. And they 

In some cases this is no problem, in other cases, the application may want to back-off if LE is not supported. Applications may detect whether bleaching happened if they get feedback about this.
For instance, if remarked to BE they may use a LEDBAT like congestion control at least.

Regards,
 Roland

---

From: Roland Bless <[email-masked]>
Date: Fri, 24 Jul 2015 12:24:06 +0200

Hi Ruediger,

>   interconnection and access interfaces).

That's a property of the DiffServ Architecture's flexibility, RFC 2474
requires a flexible DSCP -> PHB mapping. However, standardized
codepoints are intended to help here.

>   links to a DSCP (here CS1 is scavenger). 

Signaling a DSCP to PHB-ID mapping would be the correct
solution, but since we don't have that deployed, we need to rely
on standard DSCP to PHB mappings.

> You and Bob assume CS1 marked traffic can only identify PHB/PDB
> scavenger, if sent. My view: this doesn't hold. A DSCP could mean

No, I'm not assuming that CS1 always means LE. That's why I want
a separate DSCP for LE.

> anything, unless one of both parties defines how the DSCP is
> interpreted.

Yes, but without SLA negotation or explicit signaling, you cannot
solve this. Even if standard DSCP to PHB mapping is used, you
don't know whether the PHB is supported or the DSCP is mapped
to another DSCP and/or PHB.

Regards,
 Roland

---

From: Brian E Carpenter <[email-masked]>
Date: Fri, 24 Jul 2015 22:27:52 +1200

> You and Bob assume CS1 marked traffic can only identify PHB/PDB scavenger, if sent. My view: this doesn't hold. A DSCP could mean anything, unless one of both parties defines how the DSCP is interp…

Quite correct. That is not a matter of opinion. It's a matter of definition,
as explained in RFC 2474 and 2475. (It's also why we invented PHBIDs, RFC3140,
but unfortunately nobody seems to use them.)

   Brian