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

[[e-mail]]

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