Subject: [tsvwg] draft-custura-tsvwg-dscp-considerations-02.txt

From: Gorry Fairhurst <[email-masked]>
Date: Mon, 14 Jun 2021 14:21:31 +0100

Chaies, WG,

The authors have updloaded a new revsion of 
draft-custura-tsvwg-dscp-considerations and would like to request 
adoption by tsvwg,

best wishes,

Gorry, Ana and Raffaello

-------- Forwarded Message --------
Subject: 	New Version Notification for 
draft-custura-tsvwg-dscp-considerations-02.txt
Date: 	Mon, 14 Jun 2021 06:17:40 -0700
From: 	[email-masked]
To: 	Ana Custura <[email-masked]>, Godred Fairhurst 
<[email-masked]>, Gorry Fairhurst <[email-masked]>, 
Raffaello Secchi <[email-masked]>

A new version of I-D, draft-custura-tsvwg-dscp-considerations-02.txt
has been successfully submitted by Godred Fairhurst and posted to the
IETF repository.

Name: draft-custura-tsvwg-dscp-considerations
Revision: 02
Title: Considerations for Assigning a new Recommended DiffServ Codepoint 
(DSCP)
Document date: 2021-06-14
Group: Individual Submission
Pages: 19
URL: 
https://www.ietf.org/archive/id/draft-custura-tsvwg-dscp-considerations-02.txt
Status: 
https://datatracker.ietf.org/doc/draft-custura-tsvwg-dscp-considerations/
Htmlized: 
https://datatracker.ietf.org/doc/html/draft-custura-tsvwg-dscp-considerations
Diff: 
https://www.ietf.org/rfcdiff?url2=draft-custura-tsvwg-dscp-considerations-02

Abstract:
This document discusses considerations for assigning a new
recommended DiffServ Code Point (DSCP). It considers the common
remarking behaviours that the Diffserv field might be subjected to
along an Internet path. It also notes some implications of using a
specific DSCP.

This individual draft aims to seek comments and contributions from
the TSVWG working group.

The IETF Secretariat

---

From: <[email-masked]>
Date: Tue, 15 Jun 2021 06:51:21 +0000

Gorry,

Thanks for your draft. Some comments:

It might be worth to differentiate expectations of traffic sources and sinks and DSCP setting behavior.

  1.  Is the setting behaviour intended to enable a local or sectional differential treatment, without expecting end-to-end service differentiation?
Example: Sender domain sets DSCPs to influence stream playout priorities in receiver browsers, or any/many unknown intentions when setting DSCPs.
  2.  Is the setting behaviour intended to enable end-to-end service differentiation with an expectation of interconnection agreements in place?
Example: Provider interconnection agreements, e.g. for public telephony service.
  3.  Is the setting behaviour intended to enable end-to-end service differentiation without an expectation of interconnection agreements in place?
Example: NQB (as far as I understood it).

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

Section 5.2.1.  Mappings Specified for MPLS Short Pipe

The table is a copy and paste error from GSMA IR.34. RFC8100 uses different class names and wouldn’t support DSCPs AF31, AF32, AF21 and AF11 in a single class.  If there’s a need for 4 DSCPs at interconnection, e.g. CS3, AF31, AF32 and AF33 is conforming to the intent of RFC8100.

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

Adding a reference to https://www.rfc-editor.org/rfc/rfc3270.txt might be fair.

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

My impression is, that this draft, as many others, ignores operational practice and operator requirements.

  *   As RFC5127 correctly states, backbone networks are often overprovisioned under stable operating conditions. Operating and maintaining a plethora of differentiated, DSCP based service differentiations is a nightmare. My op-staff wouldn’t be happy if they were to reconfigure all or a majority of the backbone routers by a bi-annual DSCP-to-PHB mapping table configuration adaptation. Simple to configure, smooth to operate, comprehensible with limited expertise for monitoring and debugging, and adding value, that’s what’s expected.
  *   The issue of reasonable traffic treatment if a provider receives an unknown DSCP at an edge isn’t explained to the extent I feel to be reasonable.

To add to the latter: Say my domain applies the GSMA IR.34 table. What is the recommended treatment of unused DSCPs AF42, AF43…..AF12, AF13 received by a GSMA IR.34 domain, if that same domain receives these combined with AF41, AF31… at an interconnection without any DiffServ SLA? RFC2597 seems to say remark to one of the unused AF DSCPs of the same ordered aggregate. I’m not sure to which extent a sender using https://www.rfc-editor.org/rfc/rfc8837.txt would be, receiving AF22 and AF12 traffic which was remarked from the AFx1 DSCPs as my domain supports IR.34.

The IETF statement “If packets are received that are marked with an unknown or an unexpected DSCP, RFC2474 [RFC2474] recommends forwarding the packet using a default (best effort) treatment, but without changing the DSCP.” Is just covering one operational scenario, but not all. There’s a gap to that within the IETF DiffServ specifications. I don’t blame you for that, but drafts handling remarking might add a statement why to expect remarking. That gap is one reason (MPLS short pipe & IPv4 is another). So adding a statement mentioning this gap in standards at section “4.  Remarking the DSCP” in your draft and if desired, adding the example given above, may help to explain why there is a bleaching behaviour at network boundaries.

Regards,

Ruediger

Von: tsvwg <[email-masked]> Im Auftrag von Gorry Fairhurst
Gesendet: Montag, 14. Juni 2021 15:22
An: [email-masked]
Betreff: [tsvwg] draft-custura-tsvwg-dscp-considerations-02.txt

Chaies, WG,

The authors have updloaded a new revsion of draft-custura-tsvwg-dscp-considerations and would like to request adoption by tsvwg,

best wishes,

Gorry, Ana and Raffaello

-------- Forwarded Message --------
Subject:
New Version Notification for draft-custura-tsvwg-dscp-considerations-02.txt
Date:
Mon, 14 Jun 2021 06:17:40 -0700
From:
[email-masked]<mailto:[email-masked]>
To:
Ana Custura <[email-masked]><mailto:[email-masked]>, Godred Fairhurst <[email-masked]><mailto:[email-masked]>, Gorry Fairhurst <[email-masked]><mailto:[email-masked]>, Raffaello Secchi <[email-masked]><mailto:[email-masked]>

Name: draft-custura-tsvwg-dscp-considerations
Revision: 02
Title: Considerations for Assigning a new Recommended DiffServ Codepoint (DSCP)
Document date: 2021-06-14
Group: Individual Submission
Pages: 19
URL: https://www.ietf.org/archive/id/draft-custura-tsvwg-dscp-considerations-02.txt
Status: https://datatracker.ietf.org/doc/draft-custura-tsvwg-dscp-considerations/
Htmlized: https://datatracker.ietf.org/doc/html/draft-custura-tsvwg-dscp-considerations
Diff: https://www.ietf.org/rfcdiff?url2=draft-custura-tsvwg-dscp-considerations-02

Abstract:

The IETF Secretariat

---

From: Gorry Fairhurst <[email-masked]>
Date: Tue, 15 Jun 2021 12:48:08 +0100

Thanks very much, and please see below:

On 15/06/2021 07:51, [email-masked] wrote:
>  1. Is the setting behaviour intended to enable a local or sectional
>     differential treatment, without expecting end-to-end service
>     differentiation?
>     Example: Sender domain sets DSCPs to influence stream playout
>     priorities in receiver browsers, or any/many unknown intentions
>     when setting DSCPs.
>  2. Is the setting behaviour intended to enable end-to-end service
>     differentiation with an expectation of interconnection agreements
>     in place?
>  3. Is the setting behaviour intended to enable end-to-end service
>     differentiation without an expectation of interconnection
>     agreements in place?
I think the expectations are reasonable.

We would like to use this to expand a little the section at the end.

> The table is a copy and paste error from GSMA IR.34. RFC8100 uses 
> different class names and wouldn’t support DSCPs AF31, AF32, AF21 and 
> AF11 in a single class.  If there’s a need for 4 DSCPs at 
> interconnection, e.g. CS3, AF31, AF32 and AF33 is conforming to the 
> intent of RFC8100.
>
Sorry, mea culpa. We will will remove that table and will fix.
>
> ---------------------
>
> Adding a reference to https://www.rfc-editor.org/rfc/rfc3270.txt 
> <https://www.rfc-editor.org/rfc/rfc3270.txt> might be fair.
>
Yes, we will add.
>   * As RFC5127 correctly states, backbone networks are often
>     overprovisioned under stable operating conditions. Operating and
>     maintaining a plethora of differentiated, DSCP based service
>     differentiations is a nightmare. My op-staff wouldn’t be happy if
>     they were to reconfigure all or a majority of the backbone routers
>     by a bi-annual DSCP-to-PHB mapping table configuration adaptation.
>     Simple to configure, smooth to operate, comprehensible with
>     limited expertise for monitoring and debugging, and adding value,
>     that’s what’s expected.
>   * The issue of reasonable traffic treatment if a provider receives
>     an unknown DSCP at an edge isn’t explained to the extent I feel to
>     be reasonable.
>
> To add to the latter: Say my domain applies the GSMA IR.34 table. What 
> is the recommended treatment of unused DSCPs AF42, AF43…..AF12, AF13 
> received by a GSMA IR.34 domain, if that same domain receives these 
> combined with AF41, AF31… at an interconnection without any DiffServ 
> SLA? RFC2597 seems to say remark to one of the unused AF DSCPs of the 
> same ordered aggregate. I’m not sure to which extent a sender using 
> https://www.rfc-editor.org/rfc/rfc8837.txt 
> <https://www.rfc-editor.org/rfc/rfc8837.txt> would be, receiving AF22 
> and AF12 traffic which was remarked from the AFx1 DSCPs as my domain 
> supports IR.34.
>
> The IETF statement “If packets are received that are marked with an 
> unknown or an unexpected DSCP, RFC2474 [RFC2474] recommends forwarding 
> the packet using a default (best effort) treatment, but without 
> changing the DSCP.” Is just covering one operational scenario, but not 
> all. There’s a gap to that within the IETF DiffServ specifications. I 
> don’t blame you for that, but drafts handling remarking might add a 
> statement why to expect remarking. That gap is one reason (MPLS short 
> pipe & IPv4 is another). So adding a statement mentioning this gap in 
> standards at section “4.  Remarking the DSCP” in your draft and if 
> desired, adding the example given above, may help to explain why there 
> is a bleaching behaviour at network boundaries.
>
I think it would be really useful to add this as an example of how 
operational practice can change the marking.

> Ruediger
Gorry
>
> *Von:*tsvwg <[email-masked]> *Im Auftrag von *Gorry Fairhurst
> *Gesendet:* Montag, 14. Juni 2021 15:22
> *An:* [email-masked]
> *Betreff:* [tsvwg] draft-custura-tsvwg-dscp-considerations-02.txt
>
> Chaies, WG,
>
> *Subject: *
> New Version Notification for 
> *Date: *
> *From: *
> [email-masked] <mailto:[email-masked]>
>
> *To: *
>
> 	
>
> Ana Custura <[email-masked]> <mailto:[email-masked]>, Godred 
> Fairhurst <[email-masked]> <mailto:[email-masked]>, Gorry 
> Fairhurst <[email-masked]> <mailto:[email-masked]>, 
> Raffaello Secchi <[email-masked]> <mailto:[email-masked]>
>
>
>
>
> <https://www.ietf.org/archive/id/draft-custura-tsvwg-dscp-considerations-02.txt>
> Status: 
> <https://datatracker.ietf.org/doc/draft-custura-tsvwg-dscp-considerations/>
> Htmlized: 
> <https://datatracker.ietf.org/doc/html/draft-custura-tsvwg-dscp-considerations>
> Diff: 
> <https://www.ietf.org/rfcdiff?url2=draft-custura-tsvwg-dscp-considerations-02>
>
> Abstract:

---

From: Martin Duke <[email-masked]>
Date: Mon, 21 Jun 2021 09:50:47 -0700

As an individual, I strongly support adoption of a draft along these lines.

On Tue, Jun 15, 2021 at 4:48 AM Gorry Fairhurst <[email-masked]>
wrote:

>    priorities in receiver browsers, or any/many unknown intentions when
>    setting DSCPs.
>    differentiation with an expectation of interconnection agreements in place?
>    differentiation without an expectation of interconnection agreements in
>    place?
> different class names and wouldn’t support DSCPs AF31, AF32, AF21 and AF11
> in a single class.  If there’s a need for 4 DSCPs at interconnection, e.g.
> CS3, AF31, AF32 and AF33 is conforming to the intent of RFC8100.
>
>
>
>    - As RFC5127 correctly states, backbone networks are often
>    differentiations is a nightmare. My op-staff wouldn’t be happy if they were
>    to reconfigure all or a majority of the backbone routers by a bi-annual
>    DSCP-to-PHB mapping table configuration adaptation. Simple to configure,
>    smooth to operate, comprehensible with limited expertise for monitoring and
>    debugging, and adding value, that’s what’s expected.
>    - The issue of reasonable traffic treatment if a provider receives an
>    unknown DSCP at an edge isn’t explained to the extent I feel to be
>    reasonable.
>
>
>
> To add to the latter: Say my domain applies the GSMA IR.34 table. What is
> the recommended treatment of unused DSCPs AF42, AF43…..AF12, AF13 received
> by a GSMA IR.34 domain, if that same domain receives these combined with
> AF41, AF31… at an interconnection without any DiffServ SLA? RFC2597 seems
> to say remark to one of the unused AF DSCPs of the same ordered aggregate.
> I’m not sure to which extent a sender using
> https://www.rfc-editor.org/rfc/rfc8837.txt would be, receiving AF22 and
> AF12 traffic which was remarked from the AFx1 DSCPs as my domain supports
> IR.34.
>
>
>
> unknown or an unexpected DSCP, RFC2474 [RFC2474] recommends forwarding the
> packet using a default (best effort) treatment, but without changing the
> DSCP.” Is just covering one operational scenario, but not all. There’s a
> gap to that within the IETF DiffServ specifications. I don’t blame you for
> that, but drafts handling remarking might add a statement why to expect
> remarking. That gap is one reason (MPLS short pipe & IPv4 is another). So
> adding a statement mentioning this gap in standards at section “4.
> Remarking the DSCP” in your draft and if desired, adding the example given
> above, may help to explain why there is a bleaching behaviour at network
> boundaries.
>
>
>
> *Von:* tsvwg <[email-masked]> <[email-masked]> *Im
> Auftrag von *Gorry Fairhurst
> draft-custura-tsvwg-dscp-considerations and would like to request adoption
> by tsvwg,
>
> best wishes,
>
> Gorry, Ana and Raffaello
>
>
> [email-masked]
> Ana Custura <[email-masked]> <[email-masked]>, Godred Fairhurst
> <[email-masked]> <[email-masked]>, Gorry Fairhurst
> <[email-masked]> <[email-masked]>, Raffaello Secchi
> <[email-masked]> <[email-masked]>
>
>
>
>