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

[Greg Mirsky <[e-mail]>]

Thank you for catching these nits, Will! I fixed both and will upload the
new version shortly.

Regards,
Greg

On Fri, May 2, 2025 at 2:35 PM Will Hawkins <[e-mail]> wrote:

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