[ippm] Re: draft-mirsky-ippm-stamp-cos-ext

Greg Mirsky <gregimirsky@gmail.com> Fri, 23 May 2025 23:06 UTC

Return-Path: <gregimirsky@gmail.com>
X-Original-To: ippm@mail2.ietf.org
Delivered-To: ippm@mail2.ietf.org
Received: from localhost (localhost [127.0.0.1]) by mail2.ietf.org (Postfix) with ESMTP id E46652C7BAB7 for <ippm@mail2.ietf.org>; Fri, 23 May 2025 16:06:12 -0700 (PDT)
X-Virus-Scanned: amavisd-new at ietf.org
X-Spam-Flag: NO
X-Spam-Score: -2.098
X-Spam-Level:
X-Spam-Status: No, score=-2.098 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: mail2.ietf.org (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com
Received: from mail2.ietf.org ([166.84.6.31]) by localhost (mail2.ietf.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Q3tXTTC_rwMu for <ippm@mail2.ietf.org>; Fri, 23 May 2025 16:06:12 -0700 (PDT)
Received: from mail-pj1-x1033.google.com (mail-pj1-x1033.google.com [IPv6:2607:f8b0:4864:20::1033]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits) key-exchange X25519 server-signature ECDSA (P-256) server-digest SHA256) (No client certificate requested) by mail2.ietf.org (Postfix) with ESMTPS id 8430F2C7BAB0 for <ippm@ietf.org>; Fri, 23 May 2025 16:06:12 -0700 (PDT)
Received: by mail-pj1-x1033.google.com with SMTP id 98e67ed59e1d1-310ce23a660so307084a91.1 for <ippm@ietf.org>; Fri, 23 May 2025 16:06:12 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1748041571; x=1748646371; darn=ietf.org; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:from:to:cc:subject:date:message-id:reply-to; bh=Im77AjGyALd4PWOxApX8hHXMZ+kMUwXxs700h8Wrd0w=; b=XndqwiaHkqu7Fnj8JgOLxBhLQ+6a0bMfGXgEa8JrmauqRfwAIv7Z++oUED5Hhjv2fT BQEWIMvQA62eGQp8TNoKppcoeKpz19y7K/8ZULyiDDNJu2PcnpiZdl8+gHkyn1pT2fKr CH+7M9fuM66silyB73iXSVZ6t7hrnHyd3rup/AHYQqEazlXCHI4l3KHqCEw/VG/WnlSi RD8uch7Cqao13mjpmnvhQMciDA4DaShT8X5w08gmoTFRFBFQLkCsgxJ+2XH06yGDEklG CqEHyhycWBKPZE2hokP/6DJrFbahH90VFzSQ7dZK6Ic9FwXnAstK1fxaC5u3ZCRCps7r iE+A==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1748041571; x=1748646371; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:x-gm-message-state:from:to:cc:subject:date:message-id :reply-to; bh=Im77AjGyALd4PWOxApX8hHXMZ+kMUwXxs700h8Wrd0w=; b=pSJzMWUHG/uomhC/7kDCaaECwRJH2EoXTABo6y20lxmOicoLXBitrvWGZnU2R8IzJi 3MhRaWbnUpHsDSHXUkO4bPTIjAhEvza/bxHV5bCH2djiGDKaudgGQq5igV0XQv8l4gxH SnQQTGJtdqKlpm7/ggjXdlIqc06o6R+mEDhFsQ+6OCXzLGW0hJ4bvhkzJ/uoJ/Jl4Y2+ MwsG2uywkkBLoQw23gnVuSTANeKXzWuKSi7ekulsBwv4EfqSDZgY/k0He7fRkUlOblt8 +yNS/E7SSKSeohigywDvQLNZRrF2jpT5uPWeFEywIQwUDbDTkjeYWLGN6GZezocF9IJr ng/g==
X-Gm-Message-State: AOJu0YzMkY70uHlADJv3ACtzlR9nNpYn1Gz9kTZbzJgyW1JL1hHWj0hv AwzRamf8WEExezkfAuqSR96nczZij6KRk0xONL3R1ZPlyXDjf+ZUiOYCTbk9H/NKHKoKc9nit0v RVEOwZpvnesBFy1qtSbxtczfnCe/hzG3ofS1F
X-Gm-Gg: ASbGncv4N3iHX17XjKwj4LIMPpMI8jxCTSojYVfy/l7K2G53fKKp9CcC0S8FoPKQQRR HRr/+h8OgeWnD5PfwEdjLxVEf/5r/VsXL2b5m+ImiP9+L4ljR+EzmzhXTEKrM3nAwE/RZBL0G4N wvyj+pfD1jejQyCj7Q5f/HC4cvrQ5x8W5jx/+6LZU4PdKXjEelpjuhDkvfoEvBhml5NCkxaH5xb XZD
X-Google-Smtp-Source: AGHT+IERJu9cS2ZrckZaIWOF7at8XCXDrOKBCCXgtjtZ7eB5wk9lOVAy2265e3sZAXNOjvDMcKaalqxBzDn+CD78eb0=
X-Received: by 2002:a17:90b:358c:b0:30a:4c29:4c9c with SMTP id 98e67ed59e1d1-3110f0c9deemr1035084a91.6.1748041571481; Fri, 23 May 2025 16:06:11 -0700 (PDT)
MIME-Version: 1.0
References: <2025040910454420474DCzi1rrqdme3uhV5xxD@zte.com.cn>
In-Reply-To: <2025040910454420474DCzi1rrqdme3uhV5xxD@zte.com.cn>
From: Greg Mirsky <gregimirsky@gmail.com>
Date: Fri, 23 May 2025 16:05:58 -0700
X-Gm-Features: AX0GCFsPY74c5hDWOZe04EEyDGXbqa1oyetPIDnI7cN_Oo5DH6uFeELOQgF21n8
Message-ID: <CA+RyBmWvCRottk4kF2bukX+4saxdmR4z+NMkxpv+E5QtPPMP0Q@mail.gmail.com>
To: xiao.min2@zte.com.cn
Content-Type: multipart/alternative; boundary="000000000000ebbddf0635d5a487"
Message-ID-Hash: S467JUB46HOPWVZG4A4QTNLUXPRRKDTK
X-Message-ID-Hash: S467JUB46HOPWVZG4A4QTNLUXPRRKDTK
X-MailFrom: gregimirsky@gmail.com
X-Mailman-Rule-Misses: dmarc-mitigation; no-senders; approved; emergency; loop; banned-address; member-moderation; header-match-ippm.ietf.org-0; nonmember-moderation; administrivia; implicit-dest; max-recipients; max-size; news-moderation; no-subject; digests; suspicious-header
CC: ippm@ietf.org
X-Mailman-Version: 3.3.9rc6
Precedence: list
Subject: [ippm] Re: draft-mirsky-ippm-stamp-cos-ext
List-Id: IETF IP Performance Metrics Working Group <ippm.ietf.org>
Archived-At: <https://mailarchive.ietf.org/arch/msg/ippm/uwBswxZ7_U3w1ibRZfFIIPvNPGY>
List-Archive: <https://mailarchive.ietf.org/arch/browse/ippm>
List-Help: <mailto:ippm-request@ietf.org?subject=help>
List-Owner: <mailto:ippm-owner@ietf.org>
List-Post: <mailto:ippm@ietf.org>
List-Subscribe: <mailto:ippm-join@ietf.org>
List-Unsubscribe: <mailto:ippm-leave@ietf.org>

Hi Xiao Min,
apologies for the delay to respond and thank you for your comments. I agree
that explanation of interworking between CoS TLV as defined in Section 4.4
of RFC 8792 and the extended CoS is helpful. I propose adding a new section:
NEW TEXT:
3.1.  Interoperability with RFC 8972

   Consider two scenarios of interoperability between an implementation
   that supports the CoS TLV as defined in Section 4.4 of [RFC8972]
   (referred to as A) and the implementation that supports it as defined
   in this specification (referred to as B):

   *  A Session-Sender uses A and Session-Reflector - B.

   *  A Session-Sender uses B and Session-Reflector - A.

   In the former case, if A includes CoS TLV in the STAMP test packet,
   it zeroes the Reserved field.  When B receives the packet with CoS
   TLV, it uses the value of the REC field, which is 0b00, to set the
   ECN value in the IP header of the reflected STAMP test packet.

   In the latter case, regardless of the value set by B in the STAMP
   test packet, A, acting as Session-Reflector, will interpret it as
   part of the Reserved field and ignore the value according to
   Section 4.4 of [RFC8972].  Thus, A will set ECN in the IP header of
   the reflected STAMP test packet to 0b00.

What are your thoughts about the new section?

Regards,
Greg

On Tue, Apr 8, 2025 at 7:45 PM <xiao.min2@zte.com.cn> wrote:

> Hi Greg,
>
>
> Thank you for the concise and well-written draft.
>
> I like the idea of making the new CoS TLV backward compatible with the
> existing CoS TLV defined in Section 4.4 of RFC 8972.
>
> While reading the substantial part on the new definition of existing RP
> field and the new added REC field, I believe it's helpful to explain the
> existing definition of RP field here, in addition to the new definition.
> Furthermore, a new section explaining the backward compatibility, like
> Section 4.6 of RFC 8762, may make the advantages of this kind design more
> clear.
>
>
> Best Regards,
>
> Xiao Min
>