[ippm] Re: Gunter Van de Velde's No Objection on draft-ietf-ippm-asymmetrical-pkts-11: (with COMMENT)

[Greg Mirsky <[e-mail]>]

Hi Gunter,
Thank you for your comments and helpful suggestions. We prepared updates
addressing all DISCUSSES and COMMENTS received from the IESG reviewers.
Please find my notes below, tagged GIM>>. I attached the TXT copy of the
working text and the diff, highlighting all the updates applied in the
working version.

Regards,
Greg

On Fri, Feb 27, 2026 at 7:58 AM Gunter Van de Velde via Datatracker <
[e-mail]> wrote:

> Gunter Van de Velde has entered the following ballot position for
> draft-ietf-ippm-asymmetrical-pkts-11: No Objection
>
> When responding, please keep the subject line intact and reply to all
> email addresses included in the To and CC lines. (Feel free to cut this
> introductory paragraph, however.)
>
>
> Please refer to
> https://www.ietf.org/about/groups/iesg/statements/handling-ballot-positions/
> for more information about how to handle DISCUSS and COMMENT positions.
>
>
> The document, along with other ballot positions, can be found here:
> https://datatracker.ietf.org/doc/draft-ietf-ippm-asymmetrical-pkts/
>
>
>
> ----------------------------------------------------------------------
> COMMENT:
> ----------------------------------------------------------------------
>
> # Gunter Van de Velde, RTG AD, comments for
> draft-ietf-ippm-asymmetrical-pkts-11
>
> # The line numbers used are rendered from IETF idnits tool:
>
> https://author-tools.ietf.org/api/idnits?url=https://www.ietf.org/archive/id/draft-ietf-ippm-asymmetrical-pkts-11.txt
>
> # Thanks for the writeup and to think about TWAMP for multicast.
>
> # COMMENTS
> # ========
>
> 20         This document defines an optional STAMP extension that allows a
> 21         Session-Reflector to send packets whose length or quantity
> differs
> 22         from those sent by the Session-Sender.  While standard STAMP
> 23         exchanges packets symmetrically, some measurement scenarios
> benefit
> 24         from asymmetric response packets to better reflect real
> application
> 25         conditions.  This extension enables the Session-Reflector to
> send
> 26         packets of different sizes and/or additional packets not tied
> one-
> 27         for-one to incoming test packets.  The document also analyzes
> 28         challenges in multicast performance monitoring and specifies
> STAMP
> 29         procedures to improve measurement efficiency and reduce network
> 30         impact.
>
> GV> What about the following alternative abstract
>
> "
>    This document defines an optional extension to the Simple Two-Way
>    Active Measurement Protocol (STAMP) that enables a Session-Reflector
>    to send asymmetrical packets, that is, response packets whose size
>    or quantity differs from those sent by the Session-Sender.  While
>    standard STAMP exchanges are symmetrical, certain measurement
>    scenarios benefit from reflected packets of different lengths or
>    additional responses to better approximate application traffic
>    conditions.  The extension specifies the Reflected Test Packet
>    Control TLV and associated procedures, analyzes challenges in active
>    performance measurement (including in multicast environments), and
>    describes STAMP behaviors to improve measurement efficiency and
>    reduce network impact.
> "
>
GIM>> Thank you for the proposed text, we took it all in.

>
> 110        in [RFC7497], it would be beneficial for a Session-Reflector to
> 111        respond with Asymmetrical Test packets: packets whose length is
> not
>
> GV> is there a reason why Asymmetrical Test packets is written written with
> first letter in capitals? It seems to happen in more places where capitals
> are
> used for unknown to me reason
>
GIM>> I changed all occurrences to lowercase. I hope I have not missed any.

>
> 136        In this document, "Asymmetrical Packets" has two meanings,
> depending
> 137        on the context.  First, an Asymmetrical Packet means a packet
> sent by
> 138        a Session-Reflector with a size different from the packet sent
> by the
> 139        Session-Sender.  The second, third, fourth, etc. packets sent
> by the
> 140        Session-Reflector in response to a single test packet received
> from a
> 141        Session-Sender are also referred to as Asymmetrical Packets.
>
> GV> The text speaks about two meanings, but then goes into first, second,
> third, fourth. I think i understand the intent of this, but i think the two
> meanings can be more explicit explained. Is this intent to say that (1)
> Asymmetry in packet size and (2) Asymmetry in packet count (multiple
> replies
> per one request)?
>
GIM>> Thank you for pointing out this ambiguity. We updated the text in the
Terminology section as follows:
NEW TEXT:
   In this document, "asymmetrical packets" has two meanings, depending
   on the context.  The first aspect is asymmetry in packet size between
   a packet sent by a Session-Reflector and the packet it received from
   the Session-Sender.  The second aspect is asymmetry in the number of
   packets the Session-Reflector transmits in response to receiving a
   single STAMP test packet.

And we worked on making it clearer in the second paragraph of the
Introduction:
NEW TEXT:
   By default, a STAMP Session-Sender and a Session-Reflector exchange
   packets symmetrically: the number of packets sent by the Session-
   Reflector and the Session-Sender are the same and the length of the
   packets sent by the Session-Reflector and the Session-Sender are the
   same.  However, in some scenarios, e.g., rate measurements discussed
   in [RFC7497], it would be beneficial for a Session-Reflector to
   respond with asymmetrical test packets: packets whose length is not
   symmetrical to the test packet sent by the Session-Sender and/or
   packets that are not sent in direct response to a packet received
   from a Session-Sender.  The optional extension defined in this
   document gives operators the tools to create such asymmetrical
   packets between a Session-Sender and a Session-Reflector.
>
>
> 143        In this document, a Multicast Network means a network that
> sends data
> 144        from a single source to multiple destinations by transmitting a
> 145        single packet to a single, specially designated address.
>
> GV> What about he following to be more accurate:
>
> "
> A communication network model where a sender transmits a single packet
> addressed to a multicast group, and the network delivers copies of that
> packet
> to multiple receivers that have joined the group. "
>
GIM>> Thank you for the proposed text. We used it as follows:
NEW TEXT:
   In this document, a multicast network means a communication network
   model where a sender transmits a single packet addressed to a
   multicast group, and the network delivers copies of that packet to
   multiple receivers that have joined the group.

>
> 161          0                   1                   2                   3
> 162          0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0
> 1
> 163
>  +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
> 164         |STAMP TLV Flags|      Type     |           Length
>   |
> 165
>  +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
> 166         |Length of the Reflected Packet |Number of the Reflected
> Packets|
> 167
>  +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
> 168         |             Interval Between the Reflected Packets
>   |
> 169
>  +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
> 170         ~                            Sub-TLVs
>  ~
> 171
>  +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
>
> GV> Can the names of the fields be more shorter field names. The current
> documented proposal seems to have used the long description as field names.
>
GIM>> We discussed your question. It seems like using longer names makes
references to them in the text more readable and easier to understand.

>
> 204        Also, a new STAMP TLV flag [RFC8972], Conformant Reflected
> Packet is
>
> GV> s/a new STAMP/an additional STAMP/
>
GIM>> Thank you for the suggestion, done.

>
> Many thanks for this document,
>
> Kind Regards,
> Gunter Van de Velde
>
>
>
>