Re: [ippm] Jim Guichard's Discuss on draft-ietf-ippm-explicit-flow-measurements-03: (with DISCUSS)

Giuseppe Fioccola <giuseppe.fioccola@huawei.com> Wed, 03 May 2023 09:07 UTC

Return-Path: <giuseppe.fioccola@huawei.com>
X-Original-To: ippm@ietfa.amsl.com
Delivered-To: ippm@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 59182C14CF15; Wed, 3 May 2023 02:07:11 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.896
X-Spam-Level:
X-Spam-Status: No, score=-1.896 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_BLOCKED=0.001, RCVD_IN_MSPIKE_H2=-0.001, RCVD_IN_ZEN_BLOCKED_OPENDNS=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001, URIBL_DBL_BLOCKED_OPENDNS=0.001, URIBL_ZEN_BLOCKED_OPENDNS=0.001] autolearn=ham autolearn_force=no
Received: from mail.ietf.org ([50.223.129.194]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id RJjLnrhI7fh8; Wed, 3 May 2023 02:07:07 -0700 (PDT)
Received: from frasgout.his.huawei.com (frasgout.his.huawei.com [185.176.79.56]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 545B6C14CF09; Wed, 3 May 2023 02:07:07 -0700 (PDT)
Received: from frapeml500006.china.huawei.com (unknown [172.18.147.200]) by frasgout.his.huawei.com (SkyGuard) with ESMTP id 4QB9ym0BgKz67Xxc; Wed, 3 May 2023 17:05:36 +0800 (CST)
Received: from frapeml500006.china.huawei.com (7.182.85.219) by frapeml500006.china.huawei.com (7.182.85.219) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id 15.1.2507.23; Wed, 3 May 2023 11:07:03 +0200
Received: from frapeml500006.china.huawei.com ([7.182.85.219]) by frapeml500006.china.huawei.com ([7.182.85.219]) with mapi id 15.01.2507.023; Wed, 3 May 2023 11:07:03 +0200
From: Giuseppe Fioccola <giuseppe.fioccola@huawei.com>
To: Jim Guichard <james.n.guichard@futurewei.com>, The IESG <iesg@ietf.org>
CC: "draft-ietf-ippm-explicit-flow-measurements@ietf.org" <draft-ietf-ippm-explicit-flow-measurements@ietf.org>, "ippm-chairs@ietf.org" <ippm-chairs@ietf.org>, "ippm@ietf.org" <ippm@ietf.org>, "marcus.ihlar@ericsson.com" <marcus.ihlar@ericsson.com>
Thread-Topic: Jim Guichard's Discuss on draft-ietf-ippm-explicit-flow-measurements-03: (with DISCUSS)
Thread-Index: AQHZfDgSuNuFMiHpW0Oo1J9psuvJQK9INWeA
Date: Wed, 03 May 2023 09:07:03 +0000
Message-ID: <2a8f03570158437d96b669384886f1c4@huawei.com>
References: <168295080384.49928.5675199861192112944@ietfa.amsl.com>
In-Reply-To: <168295080384.49928.5675199861192112944@ietfa.amsl.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
x-originating-ip: [10.203.246.60]
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: base64
MIME-Version: 1.0
X-CFilter-Loop: Reflected
Archived-At: <https://mailarchive.ietf.org/arch/msg/ippm/Ywg7GYhRaOe0PFEGIoqz299RE44>
Subject: Re: [ippm] Jim Guichard's Discuss on draft-ietf-ippm-explicit-flow-measurements-03: (with DISCUSS)
X-BeenThere: ippm@ietf.org
X-Mailman-Version: 2.1.39
Precedence: list
List-Id: IETF IP Performance Metrics Working Group <ippm.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/ippm>, <mailto:ippm-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/ippm/>
List-Post: <mailto:ippm@ietf.org>
List-Help: <mailto:ippm-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/ippm>, <mailto:ippm-request@ietf.org?subject=subscribe>
X-List-Received-Date: Wed, 03 May 2023 09:07:11 -0000

Hi Jim,
Thank you for your review.
This is an informational document since we initially followed the approach of RFC 8321 and RFC 8889, which were elevated to standards track when the methods were considered more mature (i.e. RFC 9341 and RFC 9342). The bits used in both QUIC and TCP headers are just examples of experimentation. Indeed, this draft aims to define transport agnostic methodologies that can be theoretically applicable to any transport-layer protocols between client and server. Different techniques are included in this document, while the assumption is that the different standards track documents, which apply these methods to a specific protocol (e.g. QUIC, TCP, CoAP,…), will consolidate the design into fewer bits according to the application scenarios. A first example is https://datatracker.ietf.org/doc/draft-ietf-core-coap-pm/.
I agree with you that a standards track document would avoid any possible objection about the DOWNREF of future documents, but I do not know if there is the consensus of the WG to change the intended status to standards track. Maybe this could be verified with a poll. Moreover, it is also worth highlighting that some of the methods described in this draft are already proposed standards: Q bit is described in RFC 9341 while S bit is introduced as an optional feature in RFC 9000.

Regards,

Giuseppe

-----Original Message-----
From: Jim Guichard via Datatracker <noreply@ietf.org> 
Sent: Monday, May 1, 2023 4:20 PM
To: The IESG <iesg@ietf.org>
Cc: draft-ietf-ippm-explicit-flow-measurements@ietf.org; ippm-chairs@ietf.org; ippm@ietf.org; marcus.ihlar@ericsson.com; marcus.ihlar@ericsson.com
Subject: Jim Guichard's Discuss on draft-ietf-ippm-explicit-flow-measurements-03: (with DISCUSS)

Jim Guichard has entered the following ballot position for
draft-ietf-ippm-explicit-flow-measurements-03: Discuss

When responding, please keep the subject line intact and reply to all email addresses included in the To and CC lines. (Feel free to cut this introductory paragraph, however.)


Please refer to https://www.ietf.org/about/groups/iesg/statements/handling-ballot-positions/
for more information about how to handle DISCUSS and COMMENT positions.


The document, along with other ballot positions, can be found here:
https://datatracker.ietf.org/doc/draft-ietf-ippm-explicit-flow-measurements/



----------------------------------------------------------------------
DISCUSS:
----------------------------------------------------------------------

I am wondering why this is an informational document when it uses reserved bits
from both QUIC and TCP headers (?). If those reserved bits are used by the
mechanisms described in this document but there is no "official" allocation of
the bits then future documents that wish to use these bits will be limited
and/or clash with an Informational RFC. Adding a DISCUSS as although this is
not a technical area of expertise for me, it seems unusual and I would like to
better understand the document track selection.

I also do not see a transport area directorate review and in fact the document
shepherd highlights that the document could benefit from such a review. Given
that the bits introduced in the document are suggested to be carried in the
QUIC and TCP headers using their reserved bits, then a review by the area
responsible for those transport protocols seems mandatory.