Performance Measurement with Asymmetrical Traffic Using Simple Two-Way Active Measurement Protocol (STAMP)
draft-ietf-ippm-asymmetrical-pkts-14

From Chris Inacio:  
Asymmetric having two different meanings in the document is unfortunate; maybe when defining to two different meanings up front, give them two word names "asymmetric size" and "asymmetric count" and don't use just asymmetric in the document again.  (I think others folks have commented on this.)


* In section 2 this sentence references Section 3 of [RFC8972] for rules, but there are no relevant rules in that reference for this (at least not that I can tell).

  In a case where the length of the reflected packet calculated by this
   rule is longer than the length of the reflected packet calculated by
   the rules in Section 3 of [RFC8972], the Session-Reflector MUST use
   the Extra Padding TLV (Section 4.1 of [RFC8972]) to increase the
   length of the reflected test packet.


* Overriding the MUST in the first sentence in the next sentence with a MAY seems like poor form:

By default,
   the Session-Reflector MUST discard the received STAMP test packet.  A
   local policy MAY override this default behavior and specify
   alternative handling.
[Deb addition:  This might be a good place for a SHOULD vice MUST.]

Thanks for the work done in this document. The -13 revision, which actually addresses my concerns per
https://mailarchive.ietf.org/arch/msg/ippm/qkgQb-sA-gqwQu6b5tC_wlFcoFU/

Nevertheless, this revision has also introduced two non-blocking issues:

- SHOULD (in section 3.1) without the required guidance per https://datatracker.ietf.org/doc/statement-iesg-statement-on-clarifying-the-use-of-bcp-14-key-words/
- The "MAC" expansion includes "address" in section 2.1 😉

I am trusting the authors and the responsible AD to address the first issue at least.

-éric

# Thanks to Lars Eggert for his TSVART review and to the editors for an update to address these comments.

Thank you for preparing this document.

Thank you for the work that has been put into this document and the new test added to rev -13, especially text on protecting the path from excessive congestion.

# COMMENTS (non-blocking).

## Section 3.1.1
This does not presently note the impact on the SLA. IAnote  be helpful to call this out in section 3.1.1 : e.g. (from [I-D.ietf-ippm-capacity-protocol]):
"Service subscribers with limited data volumes who conduct
       extensive capacity testing might experience the effects of
       Service Provider controls on their service.  Testing with the
       Service Provider's measurement hosts SHOULD be limited in
       frequency and/or overall volume"
- This could be a particularly important consideration when performing the tests described in this document.

Gorry Fairhurst

# 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.
"

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

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)?

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.
"

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. 

204	   Also, a new STAMP TLV flag [RFC8972], Conformant Reflected Packet is

GV> s/a new STAMP/an additional STAMP/


Many thanks for this document,

Kind Regards,
Gunter Van de Velde

Section 2.1.1, paragraph 5
>       EUI-48 Address Group: A six-octet field that represents the group
>       that this TLV is addressed to.  If the Session-Reflector applies
>       the EUI-48 Address Group Mask to its MAC address and the result is
>       equal to the EUI-48 Address Group, then the Session-Reflector MUST
>       stop processing the Layer 2 Address Group sub-TLV and continue
>       processing the received test packet.  If no matches are found, the
>       Session-Reflector MUST stop processing the received packet.

There is a bit of asymmetric text here in the description of L2 address
and in L2 Mask. It says here "its MAC address" while the Mask
description says "all MAC addresses". To make it consistent with L3,
it might be better to just say "all MAC addresses".

-------------------------------------------------------------------------------
NIT
-------------------------------------------------------------------------------

All comments below are about very minor potential issues that you may choose to
address in some way - or ignore - as you see fit. Some were flagged by
automated tools (via https://github.com/larseggert/ietf-reviewtool), so there
will likely be some false positives. There is no need to let me know what you
did with these suggestions.

Section 1.1, paragraph 1
>    The document uses terms defined in [RFC8762], especially Session-
>    Sender, Session-Reflector and Symmetrical Packets.
> 
>    The document uses terms defined in [RFC8972], especially STAMP
>    Session Identifier (SSID), STAMP TLV Flags and Sub-TLVs.

Do not know why these are two different sentences/paragraphs. Can they be combined?

Section 2, paragraph 18
>    If the "Number of Reflected Packets" field is set to zero, the
>    Session-Reflector MUST NOT send any reflected packets.  By default,
>    the Session-Reflector MUST discard the received STAMP test packet.  A
>    local policy MAY override this default behavior and specify
>    alternative handling.  Note that this behavior of the Session-
>    Reflector is demonstrated when the Control Code Flags field of the
>    Return Path Control Code sub-TLV (Section 4.1.1 of [RFC9503]) is set
>    to No Reply Requested.  If this the intended behavior, use of the
>    Return Path TLV is preferable.

s/If this the intended/If this is the intended/

These URLs in the document did not return content:

 * https://www.juniper.net/do

Section 1, paragraph 2
> at operators experience monitoring in a unicast network. This document analy
>                                       ^
Use "an" instead of "a" if the following word starts with a vowel sound, e.g.
"an article", "an hour".

Section 2, paragraph 18
> ]) is set to No Reply Requested. If this the intended behavior, use of the Re
>                                     ^^^^
A verb may be missing.

# IESG review of draft-ietf-ippm-asymmetrical-pkts-11

CC @MikeBishop

## Nits

All comments below are about very minor potential issues that you may choose to
address in some way - or ignore - as you see fit. Some were flagged by
automated tools (via https://github.com/larseggert/ietf-reviewtool), so there
will likely be some false positives. There is no need to let me know what you
did with these suggestions.

### Typos

### Paragraph 0
```
  Network Working Group                                          G. Mirsky
```
Shouldn't this be IPPM?

### Grammar/style

#### Asymmetrical vs. Asymmetric

A quick search suggests these are equivalent words. Unless you have a precise rule
for when you're using one versus the other, consider picking one and using it
consistently. (I think "asymmetric" sounds better in context, FWIW.)

Also, an "asymmetrical packet" sounds like the packet itself is lopsided; consider
using this term primarily to describe the traffic pattern, since the effect you're
describing is that there's more traffic from one party than the other.

#### Section 2, paragraph 18
```
]) is set to No Reply Requested. If this the intended behavior, use of the Re
                                    ^^^^
```
A verb may be missing.

Thank you to Christer Holmberg for the GENART review.