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

[Martin Duke <[e-mail]>]

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

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

> 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 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 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]> <[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]
>
> *To: *
>
> Ana Custura <[e-mail]> <[e-mail]>, Godred Fairhurst
> <[e-mail]> <[e-mail]>, Gorry Fairhurst
> <[e-mail]> <[e-mail]>, Raffaello Secchi
> <[e-mail]> <[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
> 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
>
>
>