[tsvwg] Opsdir last call review of draft-ietf-tsvwg-dscp-considerations-13

Qin Wu via Datatracker <noreply@ietf.org> Sun, 14 May 2023 22:36 UTC

Return-Path: <noreply@ietf.org>
X-Original-To: tsvwg@ietf.org
Delivered-To: tsvwg@ietfa.amsl.com
Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 13C2BC15153F; Sun, 14 May 2023 15:36:30 -0700 (PDT)
MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: 8bit
From: Qin Wu via Datatracker <noreply@ietf.org>
To: ops-dir@ietf.org
Cc: draft-ietf-tsvwg-dscp-considerations.all@ietf.org, last-call@ietf.org, tsvwg@ietf.org
X-Test-IDTracker: no
X-IETF-IDTracker: 10.3.0
Auto-Submitted: auto-generated
Precedence: bulk
Message-ID: <168410379006.53335.8820785229217684593@ietfa.amsl.com>
Reply-To: Qin Wu <bill.wu@huawei.com>
Date: Sun, 14 May 2023 15:36:30 -0700
Archived-At: <https://mailarchive.ietf.org/arch/msg/tsvwg/TMS268G5fDiYTdutv1oE8rTXYzo>
Subject: [tsvwg] Opsdir last call review of draft-ietf-tsvwg-dscp-considerations-13
X-BeenThere: tsvwg@ietf.org
X-Mailman-Version: 2.1.39
List-Id: Transport Area Working Group <tsvwg.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/tsvwg>, <mailto:tsvwg-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/tsvwg/>
List-Post: <mailto:tsvwg@ietf.org>
List-Help: <mailto:tsvwg-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/tsvwg>, <mailto:tsvwg-request@ietf.org?subject=subscribe>
X-List-Received-Date: Sun, 14 May 2023 22:36:30 -0000

Reviewer: Qin Wu
Review result: Has Issues

I have reviewed this document as part of the Ops area directorate's ongoing
effort to review all IETF documents being processed by the IESG.  These
comments were written primarily for the benefit of the Ops area
directors.Document editors and WG chairs should treat these comments just like
any other last-call comments.

Thanks for writing this draft, this is a very interesting document. This
document extends DSCP usage from the limited domain to end to end manner. One
of interesting use case is to map 3GPP QCI/5QI to DSCP and support consistent
end to end QoS.

Here are a few comments I made for this latest version.
1.Section 1
My general question is support end to end QoS across multiple domains, why RSVP
or Interserv is not sufficient? How does we use diffserv to provide consistent
QoS requirements?

2.Section 3.1 DSCP Pool 3 description said:
Pool 3 codepoints are now "utilized for standards assignments and are no
longer available for assignment to experimental or local use" [RFC8436]. “

Really, this seems not what RFC8436 said, RFC8436 add one constraint which is
only when Pool 1 is ever exhausted, do we intend to update RFC8436 to further
relax constraint? If that is the case, how do we provide back compatibility to
RFC what RFC8436 stipulated?

3.Section 3.1 said:
  Table showing the summary of the DSCP abbreviations used in published

Just want to confirm what table shows is DSCP abbreviations or PHB abbreviation?

4. Section 3.2 said:
The traffic consists of the network control service class and the OAM service
class. “ Is there any possibility DSCP CS2 used for OAM service class is
overridden by some other data traffic? If that is the case, how do you detect
some conflict? What is the impact on other data traffic? How such conflict can
be resolved?

5. Section 4 said:
“The DiffServ field
   can also be re-marked based on common semantics and agreements
   between providers at an exchange point. ”
Common semantics and agreement usually is reached in the provider to provider
interconnection domain or inter-domain or inter-provider use case?

6. Section 4 said:
“If packets are received that are
   marked with an unknown or an unexpected DSCP by a DiffServ domain
   interior node, [RFC2474] recommends forwarding the packet using a
   default (best effort) treatment, but without changing the DSCP”

Isn’t DSCP value unique and has ,consistent meaning in each domain?I want to
see the text be specific about the reasons why DSCP is unknown or unexpected?
E.g., some border router doesn’t support new DSCP value? Some of DSCP bits are
set to zero? I see the big challenges when DSCP is remarked in each domain and
match different local policy, in that sense, it seems hard to provide
consistent end to end QoS? No?

7.Section 5.1.1 said:
This aligned with the now deprecated use of CS1 as the codepoint for the lower
effort service, as previously specified in [RFC4594]. ” This alignment is
referred to PCP1 or PCP0? My impression is PCP1, no?

8.Section 5.1, table:
The table provided here is not completely consistent with figure 7 in RFC7222,
e.g., in figure 7 of RFC7222, PHB assigned to background is BE while in this
draft, PHB assigned to background is CS0. Please make them consistent ”