Re: [ippm] IPPM adoption call for draft-mirsky-ippm-asymmetrical-pkts

Greg Mirsky <gregimirsky@gmail.com> Tue, 23 April 2024 14:18 UTC

Return-Path: <gregimirsky@gmail.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 9DB9DC14F6B4 for <ippm@ietfa.amsl.com>; Tue, 23 Apr 2024 07:18:12 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -7.094
X-Spam-Level:
X-Spam-Status: No, score=-7.094 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_HI=-5, 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
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com
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 imwK0C0l6S-G for <ippm@ietfa.amsl.com>; Tue, 23 Apr 2024 07:18:08 -0700 (PDT)
Received: from mail-yw1-x1133.google.com (mail-yw1-x1133.google.com [IPv6:2607:f8b0:4864:20::1133]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits) key-exchange X25519 server-signature RSA-PSS (2048 bits) server-digest SHA256) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 21EB1C14E515 for <ippm@ietf.org>; Tue, 23 Apr 2024 07:18:08 -0700 (PDT)
Received: by mail-yw1-x1133.google.com with SMTP id 00721157ae682-6181d032bf9so54488067b3.3 for <ippm@ietf.org>; Tue, 23 Apr 2024 07:18:08 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1713881887; x=1714486687; 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=78S7Z7gFCi45/NHGt9Jn77OWEsjzbOspN0kdg1beoAc=; b=NVVtTD3W2BnfY0tXiIo6zfLwC86PQWe9WfU3UNPDMurDta6jefQWiqRFrpchDcsjJl I3M8e1a/fpEj+2akKu8ewyRxTv8SvEa6GaAFi8sUFI3lVwSZt9EBJre+v2YLBVf2a7Q9 G24MALkcmeEtBLTBJtfKTji2x9x7BIqGyfegiKhAgzY9/CVXoU46IIlpKTU2GKUqlcjI vND9AAhVw3xcNeNc2gaPY1dH0xKRpotbJylsk51XM5LKiRDfvTXknfyA4yR6Oy9aGeKU mDdZv3oLHiuDefwat/QjclFXepi/Gp3yXhyPDFyvQ9XVYlUUiyjvHGjc46o13q0CNr0D CEDg==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1713881887; x=1714486687; 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=78S7Z7gFCi45/NHGt9Jn77OWEsjzbOspN0kdg1beoAc=; b=T1QKkmFxHo85d4QYudw6fDlooAgeD5It0u/3ToSEsaXWYTaIBuMYhlHFGlsm2zXHjN jhl8bAyMI13HZqqPQIzQ8uqUhL4HfxVetgZjRWiWynq3AM2ehPxlZTCn7iY8WEAb9ksE ni+EuUtKvXYEXKrsUscho/lSi1Vxl+1Y71SjdTC14oUWpb4znfFot8orDqDIXfRM92J7 AMJ2V7He2Ut3sPmn/OEmcc6a38wVfUD7HIKu3O/7OmkcuQCkt6aZ8ncFUHtqPN+oo1GB zlIghQcoof8WHm8BwEbrQA2ztrPZCWpv2Reg2aXHdY/9pHf4GgJdWcOVOxTzLEpyO68C qEjA==
X-Forwarded-Encrypted: i=1; AJvYcCWmx/CY9rGtCb53ma7q9fwqGx7uwuhayz36p+3X4z9a+FIAg5ZFnGTJtl497AdqQUn/wh2uRmwxN4vGlTjn
X-Gm-Message-State: AOJu0Yw0uftwrbKe1rVdhHxmqsT0BEgdLhRiRv2ZZmoem8M99bEzZOwH 8rY0vdA9BcjLj7/G+jX7nWRk0hyhEyrpxuFUljuuKzVzxF+I/xCXVIXP1coyp0BtIZtx+nlPZEo 92diVDLe+vUm0N0pSgP1obmXpVbs=
X-Google-Smtp-Source: AGHT+IHwcF/CVTMjT0FbTtI4fc4/Zwqei6TWhsXNiCJkakAYo+Peg5ZRGduAPeQojo5Xt2DG8mqpYEaPzfuxZ0awFGg=
X-Received: by 2002:a05:690c:94:b0:61a:f1fc:eb14 with SMTP id be20-20020a05690c009400b0061af1fceb14mr15457619ywb.18.1713881886573; Tue, 23 Apr 2024 07:18:06 -0700 (PDT)
MIME-Version: 1.0
References: <EB9C8A72-2118-4D5F-8A49-BB6CC327297F@apple.com> <BEUP281MB37572304A4EF68F3C8714E479C112@BEUP281MB3757.DEUP281.PROD.OUTLOOK.COM>
In-Reply-To: <BEUP281MB37572304A4EF68F3C8714E479C112@BEUP281MB3757.DEUP281.PROD.OUTLOOK.COM>
From: Greg Mirsky <gregimirsky@gmail.com>
Date: Tue, 23 Apr 2024 16:17:56 +0200
Message-ID: <CA+RyBmUD1PqufW7SWXWnyPW757WjCrvguB4__z=zFMUJPLnzhw@mail.gmail.com>
To: Ruediger.Geib@telekom.de
Cc: tpauly=40apple.com@dmarc.ietf.org, ippm@ietf.org
Content-Type: multipart/alternative; boundary="0000000000000952750616c43979"
Archived-At: <https://mailarchive.ietf.org/arch/msg/ippm/n_kDp-6ZVd_xoSQB1rBIX5x3xC4>
Subject: Re: [ippm] IPPM adoption call for draft-mirsky-ippm-asymmetrical-pkts
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: Tue, 23 Apr 2024 14:18:12 -0000

Hi Ruediger,
thank you for your kind words and supporting this work; much appreciated.
Please find my notes below tagged GIM>>.

Regards,
Greg


On Tue, Apr 23, 2024 at 4:05 PM <Ruediger.Geib@telekom.de> wrote:

> Hi Tommy,
>
>
>
> I’ve read the document and support adoption.
>
>
>
> Comments:
>
>    - The security issue has been raised by others already. I’d appreciate
>    reliable safeguards as part of the specification to avoid misuse.
>
> GIM>> We'll work on improving the issues related to the security that have
been noted in the course of the WG AP.

>
>    - If relevant to the authors, DiffServ related topics may be added,
>    i.e. setting a DSCP and / or some ECN Bit Combinations on the return path.
>    I think the latter feature might be of interest, as L4S introduction may
>    benefit from section-wise testing facilities along an end to end path to
>    ensure transparent ECN bit transport (and locate nodes which reset ECN
>    bits). I just note, that reporting the ECN Bits received by the reflector
>    may be of interest too (but that’s a different story then, I guess).
>
> GIM>> A very interesting angle, thank you. We will look and invite you and
others to investigate the applicability of Class of Service TLV
(defined in Section
4.4 of RFC 8972
<https://datatracker.ietf.org/doc/html/rfc8972#name-class-of-service-tlv>)
in combination with this and, possibly, other STAMP extensions. It seems
like Clss of Service TLV provide the control that can be used in the
scenario you describe.

>
>
> Regards,
>
>
>
> Ruediger
>
>
>
> *Von:* ippm <ippm-bounces@ietf.org> *Im Auftrag von * Tommy Pauly
> *Gesendet:* Dienstag, 9. April 2024 18:28
> *An:* IETF IPPM WG (ippm@ietf.org) <ippm@ietf.org>
> *Betreff:* [ippm] IPPM adoption call for
> draft-mirsky-ippm-asymmetrical-pkts
>
>
>
> Hello IPPM,
>
>
>
> This email starts an adoption call
> for draft-mirsky-ippm-asymmetrical-pkts. This is a document we’ve discussed
> several times, and is a normative dependency for another document we
> discussed adopting at IETF 119, draft-gandhi-ippm-stamp-ext-hdr.
>
>
>
> You can find the draft here:
>
> https://datatracker.ietf.org/doc/draft-mirsky-ippm-asymmetrical-pkts/
>
>
> https://www.ietf.org/archive/id/draft-mirsky-ippm-asymmetrical-pkts-04.html#name-reflected-test-packet-control
>
>
>
> Please review the draft and respond to this email to indicate if you think
> IPPM should adopt this document as a working group item.
>
>
>
> This call will last for 3 weeks. Please reply by *Tuesday, April 30*.
>
>
>
> Best,
>
> Tommy & Marcus
> _______________________________________________
> ippm mailing list
> ippm@ietf.org
> https://www.ietf.org/mailman/listinfo/ippm
>