Subject: [tsvwg] IP-Precedence (was: DSCP for NQB - Gorry's slides )

From: <[email-masked]>
Date: Thu, 24 Mar 2022 08:47:23 +0000

Hi Gorry,

One remark. I found this line in the slides:

DSCP 45 might be treated
with higher IP precedence

As you also chair the TSV WG (but don't speak as a chairman here, I assume), I'd like to suggest this WG to start a discussion:

- accept the state of the art - some backbones aggregate DiffServ classes and aggregating on "IP precedence" is a fair concept.
- or of course stick to the idea that "IP precedence was deprecated" (and note that contributors otherwise active as chairs use the no-longer-existing-since-decades precedence in their presentations)
- and may be say yep, deprecated IP-Prec as was used prior to DiffServ but now accept practice and think that aggregation of traffic on e.g. the first three bits of the dscp is a valuable practice in those parts of the network, where traffic is aggregated.

I don't say or demand MUST aggregate on IP Prec. I just state it's there and it won't go away. 

Regards,

Ruediger

-----Ursprüngliche Nachricht-----
Von: tsvwg <[email-masked]> Im Auftrag von Gorry Fairhurst
Gesendet: Mittwoch, 23. März 2022 16:21
An: [email-masked] <[email-masked]>
Betreff: [tsvwg] DSCP for NQB - Gorry's slides

David (and Wes),

Ana has made slides - uploaded.

I made new slides for the DSCP related to the NQB topic, I don't know whether this is a useful slide deck or not? Or whether we should use it to talk to Greg after the meeting? Could even be at the meeting? Taking lkater is OK.

It identifies options:

1. Only use DSCP 45 - which was eliminated because some percentage of paths remarked.

2. MUST NOT use DSCP 45 over transit, is only avoided by requiring remarking and carried as 5

3. SHOULD NOT use DSCP 45 over transit, but some will.

4. DSCP 5 defined as an aggregate, either can be used - with slightly different semantics.

Thoughts?

Gorry

---

From: Gorry Fairhurst <[email-masked]>
Date: Thu, 24 Mar 2022 10:41:00 +0100

> I don't say or demand MUST aggregate on IP Prec. I just state it's there and it won't go away.

Ruediger,

Yes (as an individual) to the benefits of that discsussion. This would 
be welcome by me and I would hope we can understand what might be 
current practice - and what is prevalent. And hence, what impact that 
has on the RFCs the IETF might plan to write. Thoughts very welcome.

Gorry

---

From: <[email-masked]>
Date: Thu, 24 Mar 2022 15:24:59 +0000

Hi Gorry,

To pick that up a little, some examples. I think, a draft was useful. RFC8100 contains some arguments already.

As a starting remark, the philosophy which I follow when DSCP based PHBs are aggregated: there is one class which is overbooked, Best Effort / default. All others are overprovisioned. And I like to quote from RFC5127:

“In the core of a high capacity network, it is common for the network

   to be engineered in such a way that a major link, switch, or router

   can fail, and the result will be a routed network that still meets

   ambient Service Level Agreements (SLAs).“

Within a backbone, that often holds for default forwarding too.

A point which hasn’t been in scope of RFC8100: the operational edge routers I am aware of all support re-classification on egress, meaning per DSCP values and classification may change. Further, products offering different per DSCP QoS properties on the access are operational. Aggregation of DSCP based PHBs is performed, where it is useful. I note that there may be an issue with edge routers based on VoQ. The latter may benefit from some limited complexity standard QoS configuration to scale better. I admit not to be chartered with designing carrier grade router edge QoS policies based on VoQ, however. But I configure VoQ schemes on some core routers, so I’m having an idea what I talk about.

A rough example on simplification of configuration:

RFC5127, DSCP style (published):

    -------------------------------------------

   |Treatment || MPLS ||  DSCP   |   DSCP      |

   |Aggregate || EXP  ||  name   |   value     |

   |==========++======++=========|=============|

   | Network  || 110  ||  CS6    |   110000    |

   | Control  ||      ||         |             |

   |==========++======++=========|=============|

   | Real-    || 100  ||  EF     |   101110    |

   | Time     ||      ||---------|-------------|

   |          ||      ||  CS5    |   101000    |

   |          ||      ||---------|-------------|

   |          ||      ||AF41,AF42|100010,100100|

   |          ||      ||  AF43   |   100110    |

   |          ||      ||---------|-------------|

   |          ||      ||  CS4    |   100000    |

   |          ||      ||---------|-------------|

   |          ||      ||  CS3    |   011000    |

   |==========++======++=========|=============|

   | Assured  || 010* ||  CS2    |   010000    |

   | Elastic  ||      ||  AF31   |   011010    |

   |          ||      ||  AF21   |   010010    |

   |          ||      ||  AF11   |   001010    |

   |          ||------||---------|-------------|

   |          || 011* ||  AF32   |   011100    |

   |          ||      ||  AF22   |   010100    |

   |          ||      ||  AF12   |   001100    |

   |          ||      ||  AF33   |   011110    |

   |          ||      ||  AF23   |   010110    |

   |          ||      ||  AF13   |   001110    |

   |==========++======++=========|=============|

   | Elastic  || 000* || Default |   000000    |

   |          ||      || (CS0)   |             |

   |          ||------||---------|-------------|

   |          || 001* ||  CS1    |   001000    |

    -------------------------------------------

Similar, precedence style (some conflicts, might be resolvable):

    -----------------------------

   |Treatment || MPLS ||  Prec   |

   |Aggregate || EXP  ||  name   |

   |==========++======++=========|

   | Network  || 110  ||  110    |

   | Control  ||      ||         |

   |==========++======++=========|

   | Real-    || 100  ||  101    |

   | Time     ||      ||---------|

   |          ||      ||  100    |

   |==========++======++=========|

   | Assured  || 010* ||  011    |

   | Elastic  ||------||---------|

   |          || 011* ||  010    |

   |==========++======++=========|

   | Elastic  || 000  ||  000    | I’d suggest to call and operate IP-Prec 000 as “default” in general and distinguish by DSCPs only at the edge.

    -----------------------------

I moved CS3, 011000 to Assured Elastic. I changed drop level definitions in Assured Elastic (I’m not aware of interconnections requesting a PHB with different drop levels, be it DSCP or IP-Prec based). I removed Prec 1 completely, as many DSCPs are available in the above table already.

Notes: The precedence based classification is shorter and allows peers to pick from range of DSCPs without requiring a change of configuration. Also the original table allows to pick from a range, but would require adoption per peer and config get’s longer, if all values are picked.

From personal experience I can tell that we’ve once tried to configure precedence based classification and rewrite based on DSCPs only with a set of 48 DSCPs. We decided not to go to the lab with the result, because we couldn’t imagine how operational staff would debug and maintain it during emergencies without prefering to remove the entire QoS configuration.

Regards,

Ruediger

-----Ursprüngliche Nachricht-----
Von: Gorry Fairhurst <[email-masked]>
Gesendet: Donnerstag, 24. März 2022 10:41
An: Geib, Rüdiger <[email-masked]>
Cc: [email-masked]
Betreff: Re: IP-Precedence (was: [tsvwg] DSCP for NQB - Gorry's slides )

> - or of course stick to the idea that "IP precedence was deprecated"

> (and note that contributors otherwise active as chairs use the

> no-longer-existing-since-decades precedence in their presentations)

Ruediger,

Yes (as an individual) to the benefits of that discsussion. This would be welcome by me and I would hope we can understand what might be current practice - and what is prevalent. And hence, what impact that has on the RFCs the IETF might plan to write. Thoughts very welcome.

Gorry

> Von: tsvwg <[email-masked]<mailto:[email-masked]>> Im Auftrag von Gorry Fairhurst

> An: [email-masked]<mailto:[email-masked]> <[email-masked]<mailto:[email-masked]>>

> 2. MUST NOT use DSCP 45 over transit, is only avoided by requiring

> remarking and carried as 5

---

From: Brian E Carpenter <[email-masked]>
Date: Fri, 25 Mar 2022 08:37:49 +1300

Excuse front posting, but it seems to me that this whole topic is complicated by the fundamental rule that DSCPs are locally defined and all the "standards" are in fact recommendations. I'm not raising this for "religious" reasons but as a practical matter. It means that to respect that rule, everything has to be subject to an agreement between carriers to use the recommended DSCPs at the border, because that is the only way that respecting the precedence bits can work.

Is it time to challenge that rule? It exists because the major ISPs 20+ years ago wanted it. Otherwise diffserv would not have been defined as a limited domain protocol.

Regards
    Brian Carpenter

On 25-Mar-22 04:24, [email-masked] wrote:
>     | Network  || 110  ||  110    
|
>  From personal experience I can tell that we’ve once tried to configure precedence based classification and rewrite based on DSCPs only with a set of 48 DSCPs. We decided not to go to the lab with the result, because we couldn’t imagine how operational staff would debug and 
maintain it during emergencies without prefering to remove the entire QoS 
configuration.
> On 24/03/2022 09:47, [email-masked] <mailto:[email-masked]> wrote:
> 
>  > Hi Gorry,
> 
>  >
> 
>  > - and may be say yep, deprecated IP-Prec as was used prior to DiffServ but now accept practice and think that aggregation of traffic on e.g. the first three bits of the dscp is a valuable practice in those parts of 
the network, where traffic is aggregated.
> Yes (as an individual) to the benefits of that discsussion. This would be welcome by me and I would hope we can understand what might be current 
practice - and what is prevalent. And hence, what impact that has on the RFCs the IETF might plan to write. Thoughts very welcome.
>  > Von: tsvwg <[email-masked] <mailto:[email-masked]>> Im Auftrag von Gorry Fairhurst
> 
>  > An: [email-masked] <mailto:[email-masked]> <[email-masked] <mailto:[email-masked]>>
> 
>  > I made new slides for the DSCP related to the NQB topic, I don't know whether this is a useful slide deck or not? Or whether we should use it 
to talk to Greg after the meeting? Could even be at the meeting? Taking lkater is OK.

---

From: Gorry Fairhurst <[email-masked]>
Date: Thu, 24 Mar 2022 22:17:31 +0100

On 24/03/2022 20:37, Brian E Carpenter wrote:
> Excuse front posting, but it seems to me that this whole topic is 
> complicated by the fundamental rule that DSCPs are locally defined and 
> all the "standards" are in fact recommendations. I'm not raising this 
> for "religious" reasons but as a practical matter. It means that to 
> respect that rule, everything has to be subject to an agreement 
> between carriers to use the recommended DSCPs at the border, because 
> that is the only way that respecting the precedence bits can work.
>
> Is it time to challenge that rule? It exists because the major ISPs 
> 20+ years ago wanted it. Otherwise diffserv would not have been 
> defined as a limited domain protocol.
>
> Regards
>    Brian Carpenter

Yes, I think this is a great summary of the topic.

I see the issues we are facing appear to arise from a desire to allow 
end-to-end marking - and measurement shows that this is oftem possible. 
At the same time as far as I see it, it's also totally allowed for an 
operator to manage their use of DSCPs in a consistent way to realise 
useful services.

However, we will shortly run out of usable DSCPs to register if the 
practice of bleaching the top 3 bits of the DSCP in some neteworks 
persists. That might be what people think is good, that might not, but 
we do need to be aware of the situation and its implications.

But also continuing below., on the other topic..

>> As a starting remark, the philosophy which I follow when DSCP based 
>> PHBs are aggregated: there is one class which is overbooked, Best 
>> Effort / default. All others are overprovisioned. And I like to quote 
>> from RFC5127:
>>
>> A point which hasn’t been in scope of RFC8100: the operational edge 
>> routers I am aware of all support re-classification on egress, 
>> meaning per DSCP values and classification may change. Further, 
>> products offering different per DSCP QoS properties on the access are 
>> operational. Aggregation of DSCP based PHBs is performed, where it is 
>> useful. I note that there may be an issue with edge routers based on 
>> VoQ. The latter may benefit from some limited complexity standard QoS 
>> configuration to scale better. I admit not to be chartered with 
>> designing carrier grade router edge QoS policies based on VoQ, 
>> however. But I configure VoQ schemes on some core routers, so I’m 
>> having an idea what I talk about.
>>
>>     | Elastic  || 000  ||  000    | I’d suggest to call and operate 
>> IP-Prec 000 as “default” in general and distinguish by DSCPs only at 
>> the edge.
>>
>> I moved CS3, 011000 to Assured Elastic. I changed drop level 
>> definitions in Assured Elastic (I’m not aware of interconnections 
>> requesting a PHB with different drop levels, be it DSCP or IP-Prec 
>> based). I removed Prec 1 completely, as many DSCPs are available in 
>> the above table already.
>>
>> Notes: The precedence based classification is shorter and allows 
>> peers to pick from range of DSCPs without requiring a change of 
>> configuration. Also the original table allows to pick from a range, 
>> but would require adoption per peer and config get’s longer, if all 
>> values are picked.
>>
>>  From personal experience I can tell that we’ve once tried to 
>> configure precedence based classification and rewrite based on DSCPs 
>> only with a set of 48 DSCPs. We decided not to go to the lab with the 
>> result, because we couldn’t imagine how operational staff would debug 
>> and 
> maintain it during emergencies without prefering to remove the entire 
> QoS configuration.
>>
>> Regards,
>>
>> Ruediger

Thanks Ruediger, that also explains things well. There are several 
pieces here, and it is clear that it is important to consider operators 
who manage the DSCP markings of the traffic that traverse their network.

I suspect this might be an important, but different piece of the puzzle 
compared  to the deterministic remarking. The details help to understand 
this.

Somehow we need to capture this in the ID!

Gorry

>>  > Hi Gorry,
>>  >
>>  > One remark. I found this line in the slides:
>>
>>  >
>>
>>  > DSCP 45 might be treated
>>
>>  > with higher IP precedence
>>
>>  >
>>
>>  > As you also chair the TSV WG (but don't speak as a chairman here, 
>> I assume), I'd like to suggest this WG to start a discussion:
>>
>>  >
>>
>>  > - accept the state of the art - some backbones aggregate DiffServ 
>> classes and aggregating on "IP precedence" is a fair concept.
>>
>>  > - or of course stick to the idea that "IP precedence was deprecated"
>>
>>  > (and note that contributors otherwise active as chairs use the
>>
>>  > no-longer-existing-since-decades precedence in their presentations)
>>
>>  > - and may be say yep, deprecated IP-Prec as was used prior to 
>> DiffServ but now accept practice and think that aggregation of 
>> traffic on e.g. the first three bits of the dscp is a valuable 
>> practice in those parts of 
>>  >
>>  > I don't say or demand MUST aggregate on IP Prec. I just state it's 
>> there and it won't go away.
>>
>>  >
>>
>>  > Regards,
>>
>>  >
>>
>>  > Ruediger
>>
>> Ruediger,
>>
>> Yes (as an individual) to the benefits of that discsussion. This 
>> would be welcome by me and I would hope we can understand what might 
>> be current 
> practice - and what is prevalent. And hence, what impact that has on 
> the RFCs the IETF might plan to write. Thoughts very welcome.
>>
>> Gorry
>>
>>  >
>>
>>  > -----Ursprüngliche Nachricht-----
>>
>>  > Von: tsvwg <[email-masked] 
>> <mailto:[email-masked]>> Im Auftrag von Gorry Fairhurst
>>
>>  > Gesendet: Mittwoch, 23. März 2022 16:21
>>
>>  > An: [email-masked] <mailto:[email-masked]> 
>> <[email-masked] <mailto:[email-masked]>>
>>
>>  > Betreff: [tsvwg] DSCP for NQB - Gorry's slides
>>
>>  >
>>
>>  > David (and Wes),
>>
>>  >
>>
>>  > Ana has made slides - uploaded.
>>
>>  >
>>
>>  > I made new slides for the DSCP related to the NQB topic, I don't 
>> know whether this is a useful slide deck or not? Or whether we should 
>> use it 
>>  >
>>  > It identifies options:
>>  >
>>  > 1. Only use DSCP 45 - which was eliminated because some percentage 
>> of paths remarked.
>>
>>  >
>>
>>  > 2. MUST NOT use DSCP 45 over transit, is only avoided by requiring
>>
>>  > remarking and carried as 5
>>
>>  >
>>
>>  > 3. SHOULD NOT use DSCP 45 over transit, but some will.
>>
>>  >
>>
>>  > 4. DSCP 5 defined as an aggregate, either can be used - with 
>> slightly different semantics.
>>
>>  >
>>
>>  > Thoughts?
>>
>>  >
>>
>>  > Gorry
>>

---

From: <[email-masked]>
Date: Fri, 25 Mar 2022 08:03:27 +0000

Brian,

With regard sending DSCP marked traffic without an agreement my philosophy is "be liberal in what you accept and conservative in what you send", and I'd appreciate peers were acting similar.

I'd be happy to reserve IP-Prec / DSCP range 000 xxx for new standard (default in the backbone) PHBs, allowing to cross inter domain boundaries without agreements. My notion here is: the access and the WiFi AP most often are the bottlenecks. Any solutions sharing bandwidth reasonable and fair between competing flows which result in an improved Quality of Experience for those who offer and consume services is desirable. My expectation is, there's (standard) Diffserv on the access and default transport elsewhere. This may result in a situation, where traffic marked ddd xxx at interconnections without an agreement, and ddd ne 000, is remarked for default or Lower Effort PHB, to disambiguate this kind of traffic from standard conforming default traffic carrying a 000 xxx DSCP at interconnection. This may be reasonable. 

Some experience with unexpected DSCPs:  we've had a case where a default scheduler was foreseeing default and network management traffic for an access only. We received arbitrarily marked traffic for that access, which we only figured out, once it was congested. The router classified the traffic for a DiffServ PHB at the backbone interface, which wasn't configured at the access. That traffic then got entirely dropped on the access. We changed the access configuration to stop that, but the point is: marking traffic with arbitrary codepoints results in a risk of misclassification and undesired service impact along an end-to-end path.

To finalise, let me describe the other situation: A certain PHB is desired end-to-end within our domain. From my experience, Moore's law applies: unless one carefully designs QoS production end-to-end, something goes wrong. There's a number of examples proving this, which I can't describe in detail here, but the worst one ended with application self-dDoSing. My point here is the requirement for a careful and well defined end-to-end design, if DiffServ is supposed to work. It is not sufficient to set a DSCP at source and transmit.

All that may be looked at as reasons, why I prefer to remark to a DSCP/Prec codepoint reliably causing no harm at network boundaries. If TSV WG revises the DiffServ standards based on operational experience gathered, this hopefully is another useful input (apart from my desired standards support for aggregation on IP-Prec in the backbone and on interconnection). 
I'd also appreciate if those arbitrarily setting DSCPs, or forwarding them at peering interfaces without agreement share their operational deliberations and experience, to hear also that party. 

Regards,

Ruediger

-----Ursprüngliche Nachricht-----
Von: Brian E Carpenter <[email-masked]> 
Gesendet: Donnerstag, 24. März 2022 20:38
An: Geib, Rüdiger <[email-masked]>; [email-masked]
Cc: [email-masked]
Betreff: Re: [tsvwg] IP-Precedence (was: DSCP for NQB - Gorry's slides )

Regards
    Brian Carpenter

|

---

From: Brian E Carpenter <[email-masked]>
Date: Sat, 26 Mar 2022 08:55:55 +1300

> we do need to be aware of the situation and its implications.

Reading that and Rüdiger's reply, it occurs to me that it might finally
be time to consider an update to RFC 2474 (almost an Applicability
Statement) that says that at domain boundaries, operators MUST conform
to [TBD].

    Brian

>>>      to be engineered in such a way that a major link, 
switch,
>> or router