Subject: [tsvwg] I-D Action: draft-ietf-tsvwg-dscp-considerations-01.txt

From: [email-masked]
Date: Mon, 24 Jan 2022 07:11:43 -0800

A New Internet-Draft is available from the on-line Internet-Drafts directories.
This draft is a work item of the Transport Area Working Group WG of the IETF.

        Title           : Considerations for Assigning a new Recommended DiffServ Codepoint (DSCP)
        Authors         : Ana Custura
                          Godred Fairhurst
                          Raffaello Secchi
	Filename        : draft-ietf-tsvwg-dscp-considerations-01.txt
	Pages           : 22
	Date            : 2022-01-24

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.

The IETF datatracker status page for this draft is:
https://datatracker.ietf.org/doc/draft-ietf-tsvwg-dscp-considerations/

There is also an htmlized version available at:
https://datatracker.ietf.org/doc/html/draft-ietf-tsvwg-dscp-considerations-01

A diff from the previous version is available at:
https://www.ietf.org/rfcdiff?url2=draft-ietf-tsvwg-dscp-considerations-01

Internet-Drafts are also available by rsync at rsync.ietf.org::internet-drafts

---

From: Brian E Carpenter <[email-masked]>
Date: Tue, 25 Jan 2022 11:58:31 +1300

Hi,

I think that this draft should refer somehow to RFC3086. Does it contradict any of the considerations in that RFC, or does it support them?

RFC3086 was written without any significant deployment experience to draw on, and if it's wrong or misleading, the present draft would be a good place to say so. The notion of formally specified Per Domain Behaviors never really took off, but the present draft brushes against it, especially in the bullet:

"* How is the proposed service class characterised? - What are the characteristics of the traffic to be carried? What are the expectations for treatment?"

Regards
    Brian Carpenter

On 25-Jan-22 04:11, [email-masked] wrote:
> _______________________________________________
> I-D-Announce mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/i-d-announce
> Internet-Draft directories: http://www.ietf.org/shadow.html
> or ftp://ftp.ietf.org/ietf/1shadow-sites.txt
>

---

From: <[email-masked]>
Date: Tue, 25 Jan 2022 09:21:31 +0000

Hi Ana,

Thanks for your and your co-authors work. Some comments and questions:

Draft text:

   DSCP CS2 is recommended for the OAM (Operations, Administration, and
   Maintenance) service class (see [RFC4594], Section 3.3).

   The DSCP CS6 is recommended for local network control traffic.  This
   includes routing protocols and OAM traffic that are essential to
   network operation administration, control and management.
   Section 3.2 of RFC4594 [RFC4594] recommends that "CS6 marked packet
   flows from untrusted sources (for example, end user devices) SHOULD
   be dropped or remarked at ingress to the DiffServ network".

   DSCP CS7 is reserved for future use by network control traffic.  "CS7
   marked packets SHOULD NOT be sent across peering points" [RFC4594].

[RG] I'd suggest to add a statement expressing whether all that has been verified with or 
confirmed by operators. I readily agree that traffic marked CS6 is deployed for network 
management traffic and I'm optimistic, that you'll find more than one operator 
supporting that.

[RG] All this is internal traffic and multiple network elements may have to be protected from 
misuse. Any set of rules protecting nodes from unwanted traffic in general
- may have to be deployed and maintained at hundreds or thousands of nodes and operate smooth and reliably in all of them.
- may be restricted in the number of filter rules/terms by that single node operating or providing memory for the smallest number of terms
- may in consequence have to be simple and generic

[RG] As many in the community know, I'd personally rather deploy DSCPs 101 000/001/002 or so 
if I were interested in several DSCPs for management purposes, but a fair question to me also is, 
why deploy more than one DSCP for domain internal management traffic? 

#####

4.  Remarking the DSCP

   It is a feature of the DiffServ architecture that the Diffserv field
   of packets can be remarked at domain boundaries (see section 2.3.4.2
   of RFC2475 [RFC2475]).  A DSCP can be remarked at the ingress of a
   DiffServ domain.  This can be with or without restoring the initial
   DSCP marking at the egress of the same domain.  The Diffserv field
   can also be re-marked based upon common semantics and agreements
   between providers at an exchange point.

   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.  This seeks to support incremental DiffServ deployment in
   existing networks as well as preserving DSCP markings by routers that
   have not been configured to support DiffServ.  (See also
   Section 4.3).

[RG] This is one part of the DSCP treatment recommendations given by RFC 2474. 
RFC 2474 states:

   Operators may choose to use
   different codepoints for a PHB, either in addition to or in place of
   the recommended default.  Note that if operators do so choose, re-
   marking of DS fields may be necessary at administrative boundaries
   even if the same PHBs are implemented on both sides of the boundary.

   Packets received with an unrecognized codepoint SHOULD be forwarded
   as if they were marked for the Default behavior (see Sec. 4), and
   their codepoints should not be changed.  Such packets MUST NOT cause
   the network node to malfunction.

[RG] Further, there's a MUST and NOT REQUIRED statement in
https://www.rfc-editor.org/rfc/rfc2474#section-7.1
Please add proper text and a reference to the sections so far missing in your text
 (as you offer for the current text of your draft). 
All that is useful to avoid the impression that your draft is about "green-field" DSCP 
marking. DiffServ is operational in many networks since more than a decade. 

"Not required"....I will not push load on internal node managers to maintain and deploy lists of 
DSCPs which are currently unused in the direction of traffic at their network section and may 
locally receive default treatment without being changed. Stable and reliable operation under 
normal conditions, fast restoration of stable operation once things go wrong. 
That's also to say, there may be little time to investigate how the traffic with that 
"interesting" DSCP reached the point, where it just causes trouble. I've been involved in, say, 
"agile" deployments DoSing off their own service by setting the wrong DSCPs. I'm not interested in
having that on a large scale (and customer complaints combined with management 
targets, while the those solving the issues aren't those who caused them).
That's a vote for well specified end-to-end QoS, including DSCPs (I appreciate your work to that), 
forwarding and transport specifications, and SLAs, if these are necessary (and I hope,
 they aren't necessary in all cases).

#####

5.2.  Mappings Specified for MPLS

[RG] Resulting DiffServ behaviour of the MPLS pipe models differ, especially for 
Short-Pipe carrying IPv4 traffic. See
 https://www.rfc-editor.org/rfc/rfc8100#appendix-A
The text tries to explain consequences of Short-Pipe. 

#####

5.3.  Mapping Specified for Mobile Networks

[RG] You may consider adding a statement that GSMA IR.34 is not binding, but saw 
deployment. I'd suggest to further add text stating that 3GPP QCI and 5CI only
 specify wireless network properties of traffic. There's no obligation to support 
any specific QCI, there's no obligation to map any service or application traffic 
to a specific QCI. There are recommendations to that, but deployments depend 
on local operator preferences.
To the extent I'm aware of mobile network operation, service classification 
doesn't depend on DSCPs at least in some networks. DSCPs and differentiated IP 
forwarding are deployed by at least some mobile operators.

#####

6.4.  Impact on deployed infrastructure

........In other domains, policing can ensure
   that only traffic that matches a policy is permitted to use a
   specific DSCP (e.g., as in MPLS TC).

[RG] suggest:
In other domains, classification at network boundaries can ensure
   that only traffic that matches a policy is permitted to use a
   specific DSCP (e.g., as in MPLS TC).

#####

[RG] There are two generic classes of PHBs or Domain Behaviours - QoS resulting from node forwarding features - to me, 
- those which are overbooked (less resources than demand at a bottleneck), transport has mechanisms to detect congestion and reduce traffic once it is noticed and 
- those which are overprovisioned (more resources than demand), transport or network has mechanisms to avoid or detect pending congestion and limit or reduce traffic before congestion results in significant queuing, jitter or drops.

Regards,

Ruediger

-----Ursprüngliche Nachricht-----
Von: tsvwg <[email-masked]> Im Auftrag von [email-masked]
Gesendet: Montag, 24. Januar 2022 16:12
An: [email-masked]
Cc: [email-masked]
Betreff: [tsvwg] I-D Action: draft-ietf-tsvwg-dscp-considerations-01.txt

Abstract: