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

[[e-mail]]

Hi Greg, Will,

Thanks for the productive discussion on my comment.
I believe your suggested updates address my comment perfectly.
The more explicit clarifications proposed by Will make sense to me and benefit the reader.

Cheers,
Xiao Min


Original


From: WillHawkins <[e-mail]>
To: Greg Mirsky <[e-mail]>;
Cc: 肖敏10093570;[e-mail] <[e-mail]>;[e-mail] <[e-mail]>;
Date: 2025年05月02日 05:52
Subject: Re: [ippm] Re: Fwd: New Version Notification for draft-ietf-ippm-asymmetrical-pkts-06.txt


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
 
 
>       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.
 
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!
 
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]