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

[Gorry Fairhurst <[e-mail]>]

Thanks very much, and please see below:

On 15/06/2021 07:51, [e-mail] wrote:
>
> 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).
>
I think the expectations are reasonable.

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

> ----------------------
>
> 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.
>
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.
>
> ---------------------
>
> 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 
> <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.

> Regards,
>
> Ruediger
>
Gorry
>
> *Von:*tsvwg <[e-mail]> *Im Auftrag von *Gorry Fairhurst
> *Gesendet:* Montag, 14. Juni 2021 15:22
> *An:* [e-mail]
> *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: *
>
> 	
>
> [e-mail] <mailto:[e-mail]>
>
> *To: *
>
> 	
>
> Ana Custura <[e-mail]> <mailto:[e-mail]>, Godred 
> Fairhurst <[e-mail]> <mailto:[e-mail]>, Gorry 
> Fairhurst <[e-mail]> <mailto:[e-mail]>, 
> Raffaello Secchi <[e-mail]> <mailto:[e-mail]>
>
>
>
>
> 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 
> <https://www.ietf.org/archive/id/draft-custura-tsvwg-dscp-considerations-02.txt>
> Status: 
> https://datatracker.ietf.org/doc/draft-custura-tsvwg-dscp-considerations/ 
> <https://datatracker.ietf.org/doc/draft-custura-tsvwg-dscp-considerations/>
> Htmlized: 
> https://datatracker.ietf.org/doc/html/draft-custura-tsvwg-dscp-considerations 
> <https://datatracker.ietf.org/doc/html/draft-custura-tsvwg-dscp-considerations>
> Diff: 
> https://www.ietf.org/rfcdiff?url2=draft-custura-tsvwg-dscp-considerations-02 
> <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
>