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

[Greg Mirsky <[e-mail]>]

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:

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