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

Thanks Greg for the text. It looks good to me.

Regards,
Rakesh

On Tue, Feb 20, 2024 at 3:22 PM Greg Mirsky <gregimirsky@gmail.com> 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 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
>>>
>>