From rgandhi.ietf@gmail.com Wed Feb 21 14:08:00 2024 Return-Path: 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 7D096C15171B; Wed, 21 Feb 2024 14:08:00 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -7.105 X-Spam-Level: X-Spam-Status: No, score=-7.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_HI=-5, 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 fLNbHIjIoBAR; Wed, 21 Feb 2024 14:07:56 -0800 (PST) Received: from mail-qv1-xf2e.google.com (mail-qv1-xf2e.google.com [IPv6:2607:f8b0:4864:20::f2e]) (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 EFF99C14CE25; Wed, 21 Feb 2024 14:07:55 -0800 (PST) Received: by mail-qv1-xf2e.google.com with SMTP id 6a1803df08f44-68ef590377aso21270006d6.1; Wed, 21 Feb 2024 14:07:55 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1708553275; x=1709158075; 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=04ptrPUKkLpLBOHUBwz4I9yq5s9qVLGH+3ZGsFHRtak=; b=m6GUAkxpYS5+hyU1vko2ARmBySZbXtWr7r1fNxxiYP+ngmZncGfh88XrXkKAg6cNjo D2y8+IWieGnZewQ8kuP7tUG5cRxKKkMZmdRVeU9k0aRmyN+UhqAUisMWHjlh55MoGDa/ ocouZfsO/qH9cA0MTIwIeW9G17/28UiLon/YlV6c7G5YGSTXLER1ze5jNjFGJAIDOJCf bRPjYhdDSITLNEsEItY0HmoZxWJ+Qdg/CT8KvsfffuMrCaLqHYJe+92sEwxkjgKSPWSY YdvXYBbc5VXErYDAoNVmbmzRGrT+iQ0VFI4qad0z/dVB/u3F2HnuCpsTprlWFM5a0+C1 vu1A== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1708553275; x=1709158075; 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=04ptrPUKkLpLBOHUBwz4I9yq5s9qVLGH+3ZGsFHRtak=; b=jzd+3mPi+go2oLDAyEoD6Njtfyx62Bi58mqN9UgWGz9oTFDFRLEqceKHK608nfWvo5 HkVaUcp7VLlhATBwdhXwGmA6m7ddw/LtEX3+FufXXZZbdqNv7ASeD0AYRA0jHADjsCua LHdyF5eBu0ZgdAIvGlJxMLjS7TbyZBom5+PXbmYpOTF4+fN4OH8s3w5GZaN6zgz+AIYo ywJTx2ZNUYc9ZMZMNyvDwheae/Tbvtp0mH5w5GxscTkHntuKEY/5jOTy/sOZVMebx+fW nhx458YEM3WrrGlKn/3Jn5qQoveBazheitRcI8IaqUXgWJNyKcc/olc2NxVgfi48xe/r ibYg== X-Forwarded-Encrypted: i=1; AJvYcCUse+TTpT82V5NWD8+jvPi0yQCdUWbOLSKJcgubKQNdhOrCk++Wp6m0iFfhR57UzGsapO+s8bfLfilyREzx9QLiL9wf4w== X-Gm-Message-State: AOJu0YzL27JsJTOvUk4AYqOxpVLcxSkMf102q5KlMLW3B7unx5nOWxjk V5p6+FBs7xgH07+ul8Sn9qOEZYJ1G5XMhCIi1nWM8oK6qHqC2O8PyAnlA1wLUZPHD5aIfnrjicU SrVP83yiqgOn+j0ezTfd1hVTubfPX1VGahg== X-Google-Smtp-Source: AGHT+IHUWLlQhasCOugWkd9OgNdhEtBUbzSj7hXhshwh0QD319WH1dKn+wLH9cuTY5hR21TfYZV70hScFBqNTpTGqm8= X-Received: by 2002:a0c:aa5c:0:b0:68f:a78f:bf1d with SMTP id e28-20020a0caa5c000000b0068fa78fbf1dmr2407971qvb.39.1708553274628; Wed, 21 Feb 2024 14:07:54 -0800 (PST) MIME-Version: 1.0 References: <170723405726.18854.13431250923273901282@ietfa.amsl.com> In-Reply-To: From: Rakesh Gandhi Date: Wed, 21 Feb 2024 17:07:42 -0500 Message-ID: To: Greg Mirsky Cc: IETF IPPM WG , IPPM Chairs Content-Type: multipart/alternative; boundary="00000000000003a3c10611eb8f73" Archived-At: 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 21 Feb 2024 22:08:00 -0000 --00000000000003a3c10611eb8f73 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Thanks Greg for the text. It looks good to me. Regards, Rakesh On Tue, Feb 20, 2024 at 3:22=E2=80=AFPM Greg Mirsky = wrote: > 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 t= he > 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=E2=80=AFAM Rakesh Gandhi > 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 t= his >> draft in Section 2: >> >> If the value of the Number of the Reflected Packets equals zero, then th= e >> Session-Reflector MUST NOT send a reflected packet. Processing of the >> received STAMP test packet with the Reflected Test Packet Control TLV, i= n >> 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. Ma= ybe >> control code takes precedence?? >> >> Thanks, >> Rakesh >> >> >> >> On Tue, Feb 6, 2024 at 10:57=E2=80=AFAM Greg Mirsky >> 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: >>> Date: Tue, Feb 6, 2024 at 7:40=E2=80=AFAM >>> Subject: New Version Notification for >>> draft-mirsky-ippm-asymmetrical-pkts-03.txt >>> To: Ernesto Ruffini , Greg Mirsky < >>> gregimirsky@gmail.com>, Henrik Nydell , Richard >>> Foote >>> >>> >>> 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-pk= ts >>> Diff: >>> https://author-tools.ietf.org/iddiff?url2=3Ddraft-mirsky-ippm-asymmetri= cal-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 procedure= s >>> 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 >>> >> --00000000000003a3c10611eb8f73 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Thanks Greg for the text. It looks good to me.
<= div>
Regards,
Rakesh


<= /div>

On Tue, Feb 20, 2024 at 3:22=E2=80=AFPM Greg Mirsky <gregimirsky@gmail.com> wrote:
Hi Rakesh,
thank you for bringing this scenario to the discu= ssion. The authors discussed it and we updated the draft to address your co= ncern. Below is the new section that combines text from earlier version wit= h the most recent update as the second paragraph:
3.3.=C2=A0= Using Reflected Test Packet Control TLV in Combination with Other
=C2=A0 =C2=A0 =C2=A0 TLVs

=C2=A0 =C2=A0[RFC9503]= defines the Return Path TLV that, when used in the
=C2=A0 =C2=A0= combination with the Return Address Sub-TLV, allows a Session-Sender
<= div>=C2=A0 =C2=A0to request the reflected packet be sent to a different add= ress from
=C2=A0 =C2=A0the Session-Sender one.=C2=A0 These STAMP = extensions could be used in
=C2=A0 =C2=A0combination with the Ref= lected Packet Control TLV, defined in this
=C2=A0 =C2=A0document,= to direct the reflected STAMP test packets to a collector
=C2=A0= =C2=A0of measurement data (according to the [RFC7594]) for further
=C2=A0 =C2=A0processong and network analytics.=C2=A0 An example of the u= se case could
=C2=A0 =C2=A0be used in the multicast scenario when= , for example, the Session-
=C2=A0 =C2=A0Sender is close to the a= ctual multicast frames generator (for
=C2=A0 =C2=A0example, a cam= era transmitting live video) so that the test packets
=C2=A0 =C2= =A0follow the same path as the video stream packets in one direction.
=
=C2=A0 =C2=A0The data center where the test data are analyzed could be= far away,
=C2=A0 =C2=A0and it would be better to have reflected = packets return there.

=C2=A0 =C2=A0For compatibili= ty with [RFC9503], a Session-Sender MUST NOT include a
=C2=A0 =C2= =A0Return Path Control Code Sub-TLV with the Control Code flag set to No
=C2=A0 =C2=A0Reply Requested in the same test packet as the Reflect= ed Test Packet
=C2=A0 =C2=A0Control TLV is non-zero.=C2=A0 A Sess= ion-Reflector that supports both TLVs
=C2=A0 =C2=A0MUST set the U= flag in Return Path and Reflected Test Packet Control
=C2=A0 =C2= =A0TLVs in the reflected STAMP packet.=C2=A0 Furthermore, the Session-
=C2=A0 =C2=A0Reflector SHOULD log a notification to inform an operato= r about the
=C2=A0 =C2=A0misconstructed STAMP packet.
=

Your comments, questions, and suggestions are always we= lcome and greatly appreciated.

Regards,
= Greg

On Wed, Feb 7, 2024 at 5:15=E2=80=AFAM Rakesh Gandhi <rgandhi.ietf@gmai= l.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 t= he 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 Pack= et 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 req= uests do not reply. Maybe control code takes precedence??
Thanks,
Rakesh



On = Tue, Feb 6, 2024 at 10:57=E2=80=AFAM Greg Mirsky <gregimirsky@gmail.com> wrote:
= Dear All,
we've updated our proposal for the STAMP extension, Refle= cted Test Packet Control TLV, and its applicability for rate measurement as= well as performance measurements in the=C2=A0multicast network. The author= s 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=E2=80=AFAM
Subject= : New Version Notification for draft-mirsky-ippm-asymmetrical-pkts-03.txtTo: Ernesto Ruffini <eruffini@outsys.org>, Greg Mirsky <gregimirsky@gmail.com>, Henrik = Nydell <hnydell@c= isco.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:=C2=A0 =C2=A0 =C2=A0draft-mirsky-ippm-asymmetrical-pkts
Revision: 03
Title:=C2=A0 =C2=A0 Performance Measurement with Asymmetrical Packets in ST= AMP
Date:=C2=A0 =C2=A0 =C2=A02024-02-06
Group:=C2=A0 =C2=A0 Individual Submission
Pages:=C2=A0 =C2=A0 11
URL:=C2=A0 =C2=A0 =C2=A0 h= ttps://www.ietf.org/archive/id/draft-mirsky-ippm-asymmetrical-pkts-03.txt
Status:=C2=A0 =C2=A0https://dat= atracker.ietf.org/doc/draft-mirsky-ippm-asymmetrical-pkts/
HTML:=C2=A0 =C2=A0 =C2=A0= https://www.ietf.org/archive/id/draft-mirsky-ippm-asymmetrical-pkts-03.html=
HTMLized: https://datatrack= er.ietf.org/doc/html/draft-mirsky-ippm-asymmetrical-pkts
Diff:=C2=A0 =C2=A0 =C2=A0https://author-tools.ietf.org/iddiff?url2=3Ddraft-mirsky-ippm-asymme= trical-pkts-03

Abstract:

=C2=A0 =C2=A0This document describes an optional extension to a Simple Two-= way
=C2=A0 =C2=A0Active Measurement Protocol (STAMP) that enables the use of ST= AMP
=C2=A0 =C2=A0test and reflected packets of variable length during a single = STAMP
=C2=A0 =C2=A0test session.=C2=A0 In some use cases, the use of asymmetrical= test
=C2=A0 =C2=A0packets allow for the creation of more realistic flows of test=
=C2=A0 =C2=A0packets and, thus, a closer approximation between active perfo= rmance
=C2=A0 =C2=A0measurements and conditions experienced by the monitored appli= cation.

=C2=A0 =C2=A0Also, the document includes an analysis of challenges related = to
=C2=A0 =C2=A0performance monitoring in a multicast network.=C2=A0 It define= s procedures
=C2=A0 =C2=A0and STAMP extensions to achieve more efficient measurements wi= th a
=C2=A0 =C2=A0lesser impact on a network.



The IETF Secretariat


_______________________________________________
ippm mailing list
ippm@ietf.org
https://www.ietf.org/mailman/listinfo/ippm
--00000000000003a3c10611eb8f73--