Re: [ippm] Fwd: New Version Notification for draft-mirsky-ippm-asymmetrical-pkts-03.txt

Greg Mirsky <gregimirsky@gmail.com> Tue, 20 February 2024 20:22 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 7DF91C180B6E; Tue, 20 Feb 2024 12:22:40 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.105
X-Spam-Level:
X-Spam-Status: No, score=-2.105 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, RCVD_IN_ZEN_BLOCKED_OPENDNS=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, T_SCC_BODY_TEXT_LINE=-0.01, 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 gaybCBoDz_ai; Tue, 20 Feb 2024 12:22:36 -0800 (PST)
Received: from mail-yb1-xb36.google.com (mail-yb1-xb36.google.com [IPv6:2607:f8b0:4864:20::b36]) (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 9930AC180B69; Tue, 20 Feb 2024 12:22:36 -0800 (PST)
Received: by mail-yb1-xb36.google.com with SMTP id 3f1490d57ef6-dcc86086c9fso5840721276.3; Tue, 20 Feb 2024 12:22:36 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1708460556; x=1709065356; 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=18aI2ByID1tG5mxxhxsBTJFpmLI01jWyVBIpGKTtK/M=; b=DoEU5hellxQe1aPtEMxwRTGoawJQZWr4sZJ3wqxCYDoYx0themmYoCYy5e5IQstPtd bVlq4wNYqPjHY6a3qxUSB+BE/tiGTVMjr5p4XJftvXSepp7wFlUUjY6AYG6oJSCnXNxt wrohsPKVVzK2HqvPrMlpgIytVUWyN3niQlRUgV4ODXjj0Ew8ZxnV9MfZrpSfbGnJFlbE U/dgBVHXF6DUXKnqkWH5xHd0CIMvtR54L8X4bjePeVNVVG6VpVrAbrOC1ZZNW581JWFq 5B8vhj6kcaxwx+RLUVWRohTAYQAN2Jzv+XaBiXxaKI8++waOGXza5upCIAW80EGHw/OE jduw==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1708460556; x=1709065356; 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=18aI2ByID1tG5mxxhxsBTJFpmLI01jWyVBIpGKTtK/M=; b=YdhTlyRgXg6oaBgGkVLoUh3YhLKUOSqwzIMWnDhahfzelcWQ0GzClqO+CY2lZ0e/Dt kMhHZMguI8u6fnmqb1dF1e3PrevAd0xoZSid5TMUpsbhbL6yPo7Yr6Gw2U0Pcf5zummv Kzi4pU26vj2dpgufYVcZPtC6f9kyd+cwizDx/9XmQtX3AAirp8t4rerrJLntyIstg77/ SRShTwBtMSyKpG+/e/LwxIXGAe0O0AUGv0vhpAMdktyWD+AyvNLp85Tkz2mHJh5XOXck 1nzO6cIgt9IhEz1NtYFAlZtcvS+mvPMWngSuKpjjlssCU/A9vtPESR8HDP9SkTdUSS32 +ccA==
X-Forwarded-Encrypted: i=1; AJvYcCXqR8TQNMkIh7Jth3PztLzzAH+DF72x8jPj840ZFLUxAKty+dyJyTtJx1C5998IOYe3aObfPAHETiOldklycqENvqIPag==
X-Gm-Message-State: AOJu0YyuR5hwTwOzl4WA2vYKxY0dcik1mb+hgDkX5VJo9eQ2WZ/XVlGw I73RFxI8dXyhFdEAc0rIjR6WPPDDck9Eo9XdhWE9CZsr0fnN5pqi2SQQRj4ReMvJjSkHcS8ICLY JiaxiNpAAj0wRJ6JgI6TcxjP8Itobj+N4CAA=
X-Google-Smtp-Source: AGHT+IFCcXTxn93q8dFppTBCAbk5mGJFmUrzGePLaSNdYFDNApeGIBEvxEy4UFA+kBbGKhbPfB4NjPSVQ2YoloQ3nc4=
X-Received: by 2002:a5b:f03:0:b0:dcd:72f7:15b8 with SMTP id x3-20020a5b0f03000000b00dcd72f715b8mr16676547ybr.11.1708460555184; Tue, 20 Feb 2024 12:22:35 -0800 (PST)
MIME-Version: 1.0
References: <170723405726.18854.13431250923273901282@ietfa.amsl.com> <CA+RyBmXBHD9O6deWO=9F7u=VgmboWYG1Sr1N4D1Ug8Bx_A74Kw@mail.gmail.com> <CAMZsk6fbBkkuph12FXGvxu6J5kw2u-8Op_NcpBD5vEZoUb-zRg@mail.gmail.com>
In-Reply-To: <CAMZsk6fbBkkuph12FXGvxu6J5kw2u-8Op_NcpBD5vEZoUb-zRg@mail.gmail.com>
From: Greg Mirsky <gregimirsky@gmail.com>
Date: Tue, 20 Feb 2024 12:22:23 -0800
Message-ID: <CA+RyBmUwsjc1KSpZGdLEXQ38FWhUPTobXQxy=me_EWxYqz0q7w@mail.gmail.com>
To: Rakesh Gandhi <rgandhi.ietf@gmail.com>
Cc: IETF IPPM WG <ippm@ietf.org>, IPPM Chairs <ippm-chairs@ietf.org>
Content-Type: multipart/alternative; boundary="000000000000812d910611d5f8f1"
Archived-At: <https://mailarchive.ietf.org/arch/msg/ippm/CJtXT7wXjt6GhvOfwQebZL75J94>
Subject: Re: [ippm] Fwd: New Version Notification for draft-mirsky-ippm-asymmetrical-pkts-03.txt
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, 20 Feb 2024 20:22:40 -0000

Hi Rakesh,
thank you for bringing this scenario to the discussion. The authors
discussed it and we updated the draft to address your concern. Below is the
new section that combines text from earlier version with the most recent
update as the second paragraph:
3.3.  Using Reflected Test Packet Control TLV in Combination with Other
      TLVs

   [RFC9503] defines the Return Path TLV that, when used in the
   combination with the Return Address Sub-TLV, allows a Session-Sender
   to request the reflected packet be sent to a different address from
   the Session-Sender one.  These STAMP extensions could be used in
   combination with the Reflected Packet Control TLV, defined in this
   document, to direct the reflected STAMP test packets to a collector
   of measurement data (according to the [RFC7594]) for further
   processong and network analytics.  An example of the use case could
   be used in the multicast scenario when, for example, the Session-
   Sender is close to the actual multicast frames generator (for
   example, a camera transmitting live video) so that the test packets
   follow the same path as the video stream packets in one direction.
   The data center where the test data are analyzed could be far away,
   and it would be better to have reflected packets return there.

   For compatibility with [RFC9503], a Session-Sender MUST NOT include a
   Return Path Control Code Sub-TLV with the Control Code flag set to No
   Reply Requested in the same test packet as the Reflected Test Packet
   Control TLV is non-zero.  A Session-Reflector that supports both TLVs
   MUST set the U flag in Return Path and Reflected Test Packet Control
   TLVs in the reflected STAMP packet.  Furthermore, the Session-
   Reflector SHOULD log a notification to inform an operator about the
   misconstructed STAMP packet.

Your comments, questions, and suggestions are always welcome and greatly
appreciated.

Regards,
Greg

On Wed, Feb 7, 2024 at 5:15 AM Rakesh Gandhi <rgandhi.ietf@gmail.com> wrote:

> Hi Greg,
>
> Thanks for sharing the updates.
> RFC 9503 (previously draft-ietf-ippm-stamp-srpm) defines control code with
> - No Reply Requested. It may intersect with the following text in this
> draft in Section 2:
>
> If the value of the Number of the Reflected Packets equals zero, then the
> Session-Reflector MUST NOT send a reflected packet. Processing of the
> received STAMP test packet with the Reflected Test Packet Control TLV, in
> which the value of the Number of the Reflected Packets equals zero, is
> according to the local nodal policy. The received STAMP test packet is
> discarded if no policy to handle these cases is configured on the node.
>
> Maybe the draft can clarify the expected behavior e.g. number of reflected
> packets is non-zero but control code requests do not reply. Maybe control
> code takes precedence??
>
> Thanks,
> Rakesh
>
>
>
> On Tue, Feb 6, 2024 at 10:57 AM Greg Mirsky <gregimirsky@gmail.com> wrote:
>
>> Dear All,
>> we've updated our proposal for the STAMP extension, Reflected Test Packet
>> Control TLV, and its applicability for rate measurement as well as
>> performance measurements in the multicast network. The authors always
>> welcome your questions, comments, and suggestions. Looking forward to
>> presenting and discussing this work at the IPPM session in Brisbane.
>>
>> Regards,
>> Greg (on behalf of the authors)
>>
>> ---------- Forwarded message ---------
>> From: <internet-drafts@ietf.org>
>> Date: Tue, Feb 6, 2024 at 7:40 AM
>> Subject: New Version Notification for
>> draft-mirsky-ippm-asymmetrical-pkts-03.txt
>> To: Ernesto Ruffini <eruffini@outsys.org>, Greg Mirsky <
>> gregimirsky@gmail.com>, Henrik Nydell <hnydell@cisco.com>, Richard Foote
>> <footer.foote@nokia.com>
>>
>>
>> A new version of Internet-Draft
>> draft-mirsky-ippm-asymmetrical-pkts-03.txt has
>> been successfully submitted by Greg Mirsky and posted to the
>> IETF repository.
>>
>> Name:     draft-mirsky-ippm-asymmetrical-pkts
>> Revision: 03
>> Title:    Performance Measurement with Asymmetrical Packets in STAMP
>> Date:     2024-02-06
>> Group:    Individual Submission
>> Pages:    11
>> URL:
>> https://www.ietf.org/archive/id/draft-mirsky-ippm-asymmetrical-pkts-03.txt
>> Status:
>> https://datatracker.ietf.org/doc/draft-mirsky-ippm-asymmetrical-pkts/
>> HTML:
>> https://www.ietf.org/archive/id/draft-mirsky-ippm-asymmetrical-pkts-03.html
>> HTMLized:
>> https://datatracker.ietf.org/doc/html/draft-mirsky-ippm-asymmetrical-pkts
>> Diff:
>> https://author-tools.ietf.org/iddiff?url2=draft-mirsky-ippm-asymmetrical-pkts-03
>>
>> Abstract:
>>
>>    This document describes an optional extension to a Simple Two-way
>>    Active Measurement Protocol (STAMP) that enables the use of STAMP
>>    test and reflected packets of variable length during a single STAMP
>>    test session.  In some use cases, the use of asymmetrical test
>>    packets allow for the creation of more realistic flows of test
>>    packets and, thus, a closer approximation between active performance
>>    measurements and conditions experienced by the monitored application.
>>
>>    Also, the document includes an analysis of challenges related to
>>    performance monitoring in a multicast network.  It defines procedures
>>    and STAMP extensions to achieve more efficient measurements with a
>>    lesser impact on a network.
>>
>>
>>
>> The IETF Secretariat
>>
>>
>> _______________________________________________
>> ippm mailing list
>> ippm@ietf.org
>> https://www.ietf.org/mailman/listinfo/ippm
>>
>