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

[Will Hawkins <[e-mail]>]

On Fri, May 2, 2025 at 4:47 PM Greg Mirsky <[e-mail]> wrote:
>
> Hi Will,
> great suggestions. Please find my notes below tagged GIM2>>. I attached the diff that highlights all applied updates.
>
> Regards,
> Greg
>
> On Thu, May 1, 2025 at 2:51 PM Will Hawkins <[e-mail]> wrote:
>>
>> On Thu, May 1, 2025 at 2:38 PM Greg Mirsky <[e-mail]> wrote:
>> >
>> > Hi Xiao Min,
>> > thank you for catching this. Would the following update suggested by Will address your concern:
>> > OLD TEXT:
>> >       If a test packet is received that
>> >       would generate traffic that exceeds either of these limits, the
>> >       Session-Reflector MUST set the U flag [RFC8972] to 1, and MUST
>> >       transmit a single reflected packet.  Otherwise, the Session-
>> >       Reflector MUST set the U flag to 0 in each reflected test packet.
>> > NEW TEXT:
>> >       If a test packet is received that
>> >       would generate traffic that exceeds either of these limits, the
>> >       Session-Reflector MUST set the C flag Section 7.2 to 1, and MUST
>>
>> Seems like we might want parenthesis around the reference to Section 7.2:
>> Session-Reflector MUST set the C flag (Section 7.2) to 1, and MUST
>
> GIM>> Done
>>
>>
>>
>> >       transmit a single reflected packet.  Otherwise, the Session-
>> >       Reflector MUST set the C flag to 0 in each reflected test packet.
>>
>> I think that the updated text matches my intention with respect to the rate.
>>
>> However, I think that it might make sense to also amend
>>
>> Session-Reflector MUST set the C (Conformant Reflected Packet) STAMP
>> TLV flag Section 7.2 to 1, and MUST transmit a single reflected
>> packet.
>>
>> to
>>
>> Session-Reflector MUST set the C (Conformant Reflected Packet) STAMP
>> TLV flag Section 7.2 to 1, and MUST transmit a single reflected packet
>> with a length that matches the MTU.
>
> GIM>> I agree. Done.
>>
>>
>> just to be extra explicit.
>>
>> While we are there, I was wondering if it might make sense to add some
>> exposition to highlight the way that an implementation can tell the
>> difference between the two cases where the C flag is set. Although a
>> careful reader would be able to see the difference, I know that I
>> could easily read past it.
>>
>> Something as simple as
>>
>> The Session Sender can detect that the Session Reflector was not able
>> to reflect a packet with the requested length when it receives a
>> reflected packet with the C flag set and a length that does not match
>> the one requested in the initial test packet.
>>
>> could be added to the end of
>> https://www.ietf.org/archive/id/draft-ietf-ippm-asymmetrical-pkts-06.html#section-2-9
>>
>> and
>>
>> The Session Sender can detect that the Session Reflector was not able
>> to generate reflected packets with the requested rate when it receives
>> a reflected packet with the C flag set and a length that matches the
>> one requested in the initial test packet.
>>
>> at the end of https://www.ietf.org/archive/id/draft-ietf-ippm-asymmetrical-pkts-06.html#section-2-10.2
>>
>> Those are just suggestions. I hope that they help! Thank you, Greg and Xiao!
>
> GIM>> Great suggestions, thank you! I combined your text to add the following:
> NEW TEXT:
>

Absolutely fantastic (no surprise, of course) with two small nits ...


>    As defined above, there are two cases when a Session-Reflector will
>    set the C flag in the reflected packet.  To disambiguate the case led

... set the C flag in the reflected packet.  To disambiguate which case led

>    to the C flag being set to 1, an implementation of Session-Sender can
>    use the following:
>
>       The requested length exceeds the MTU of the egress interface of
>       the Session-Reflector if the length of the received reflected
>       STAMP packet is less than the value of the Length of the Reflected
>       Packet field.
>
>       The requested data rate and/or the data volume exceed the imits

... The requested data rate and/or the data volume exceed the limits

Thank you, as always!
Will


>       set at the Session-Reflector if the length of the received
>       reflected STAMP packet equals the value of the Length of the
>       Reflected Packet field.
>
> What are your thoughts?
>>
>>
>> Will
>>
>>
>> >
>> > Regards,
>> > Greg
>> >
>> >
>> > On Wed, Apr 30, 2025 at 3:15 PM <[e-mail]> wrote:
>> >>
>> >> Hi Greg,
>> >>
>> >>
>> >> It seems you missed my comments on this document. Link as below.
>> >>
>> >> https://mailarchive.ietf.org/arch/msg/ippm/OEalOX_icvyPEas6j-P-Mrok7bk/
>> >>
>> >>
>> >> Cheers,
>> >>
>> >> Xiao Min
>> >>
>> >> Original
>> >> From: GregMirsky <[e-mail]>
>> >> To: IETF IPPM WG <[e-mail]>;IPPM Chairs <[e-mail]>;
>> >> Date: 2025年05月01日 03:43
>> >> Subject: [ippm] Fwd: New Version Notification for draft-ietf-ippm-asymmetrical-pkts-06.txt
>> >> _______________________________________________
>> >> ippm mailing list -- [e-mail]
>> >> To unsubscribe send an email to [e-mail]
>> >>
>> >> Dear All,
>> >> This version includes updates resulting from Greg White, Ruediger, Rakesh, and Giuseppe's many great comments. We also added an Implementation Consideration section reflecting Will Hawkins's Teaparty work.
>> >>
>> >> Regards,
>> >> Greg
>> >> ---------- Forwarded message ---------
>> >> From: <[e-mail]>
>> >> Date: Wed, Apr 30, 2025 at 12:37 PM
>> >> Subject: New Version Notification for draft-ietf-ippm-asymmetrical-pkts-06.txt
>> >> To: Ernesto Ruffini <[e-mail]>, Greg Mirsky <[e-mail]>, Henrik Nydell <[e-mail]>, Richard Foote <[e-mail]>, Will Hawkins <[e-mail]>
>> >>
>> >>
>> >> A new version of Internet-Draft draft-ietf-ippm-asymmetrical-pkts-06.txt has
>> >> been successfully submitted by Greg Mirsky and posted to the
>> >> IETF repository.
>> >>
>> >> Name:     draft-ietf-ippm-asymmetrical-pkts
>> >> Revision: 06
>> >> Title:    Performance Measurement with Asymmetrical Traffic Using STAMP
>> >> Date:     2025-04-30
>> >> Group:    ippm
>> >> Pages:    16
>> >> URL:      https://www.ietf.org/archive/id/draft-ietf-ippm-asymmetrical-pkts-06.txt
>> >> Status:   https://datatracker.ietf.org/doc/draft-ietf-ippm-asymmetrical-pkts/
>> >> HTML:     https://www.ietf.org/archive/id/draft-ietf-ippm-asymmetrical-pkts-06.html
>> >> HTMLized: https://datatracker.ietf.org/doc/html/draft-ietf-ippm-asymmetrical-pkts
>> >> Diff:     https://author-tools.ietf.org/iddiff?url2=draft-ietf-ippm-asymmetrical-pkts-06
>> >>
>> >> Abstract:
>> >>
>> >>    This document describes an optional extension to a Simple Two-way
>> >>    Active Measurement Protocol (STAMP) that enables control of the
>> >>    length and/or number of reflected packets 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 -- [e-mail]
>> > To unsubscribe send an email to [e-mail]