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 >> >
- [ippm] Fwd: New Version Notification for draft-mi… Greg Mirsky
- Re: [ippm] Fwd: New Version Notification for draf… Rakesh Gandhi
- Re: [ippm] Fwd: New Version Notification for draf… Greg Mirsky
- Re: [ippm] Fwd: New Version Notification for draf… Greg Mirsky
- Re: [ippm] Fwd: New Version Notification for draf… Rakesh Gandhi