[ippm] Re: I-D Action: draft-ietf-ippm-asymmetrical-pkts-02.txt

[[e-mail]]

Hi Greg,

thanks for your fast reaction. I’d like to confirm a subset of changes and ask for some more time to think about open issues. I agree with the changes you propose for the sections left in this message below.

Regards,

Ruediger

Von: Greg Mirsky <[e-mail]>
Gesendet: Dienstag, 5. November 2024 11:04
An: Geib, Rüdiger <[e-mail]>
Cc: [e-mail]
Betreff: Re: [ippm] Re: I-D Action: draft-ietf-ippm-asymmetrical-pkts-02.txt

Hi Ruediger,
many thanks for your comments and thoughtful suggestions; much appreciated. Please find my notes below tagged by GIM>>. Attached, please find the diff highlighting all the updates applied in the working version, including those discussed below.

Regards,
Greg
<snip>
Performance Measurement with Asymmetrical Packets in STAMP
[RG]: If I understand the draft text correctly, a single test packet may be “reflected” by multiple packets and the latter may be of a length diverging from that of the received packet.
[RG]: If that is correct, I’d suggest to change the document name to
Performance Measurement with Asymmetrical Traffic in STAMP
GIM>> Makes sense to me. What if we twist title a bit more:
Performance Measurement with Asymmetrical Traffic Using STAMP
And making the short title as follows:
Asymmetrical Traffic Using STAMP
What are your thoughts?


[RG]: The abstract should clarify, that by this doc:

  *   Any reflected packet may have a length differing from that of the received packet
  *   Any single received packet may be reflected by multiple packets

Abstract
“This document describes an ..extension .... that enables the use of STAMP test and reflected packets of variable length during a single STAMP test session.”
[RG]: In addition, this document allows for reflection of a number > 1 packet per received packet, if I fetch the following specification correctly (a [single?] received STAMP test packet is is feflected by a number of reflected packets):
GIM>> Your understanding is absolutely correct. Propose the follwoing update:
OLD TEXT:
   This document describes an optional extension to a Simple Two-way
   Active Measurement Protocol (STAMP) that enables the use of STAMP
   test and reflected packets of variable length during a single STAMP
   test session.
NEW TEXT:
   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.

“Number of the Reflected Packets is a four-octet field. The value is an unsigned integer that is the number of reflected test packets the Session-Reflector is requested to transmit in response to receiving a STAMP test packet with the Reflected Test Packet Control TLV.”
[RG]: If I misunderstood that, I’d appreciate text stating that “Number of Reflected Packets” identifies the number of STAMP packets to be received and then reflected by a single test packet each of a specified length.
GIM>> Perhaps current wording is not clear. The intention is for the value of the Number of the Reflected Packets field to instruct the Session-Reflctor about the number of reflected packets the Session-Reflector is commanded to generate for each received STAMP test packet that includes the Reflected Test Packet Control TLV. Thus, an operator can variate the number, rate of reflected packets in response for each STAMP test packet in the STAMP test session.


2. Reflected Test Packet Control TLV

“Length is a two-octet field. The value is variable, not smaller than 12 octets.” <<<<< [RG]: The value is an unsigned integer indicating the length of the Reflected Test Packet Control TLV in octets.... (or the like) ?
“Length of the Reflected Packet is a four-octet field. The value is an unsigned integer that is the requested length of a reflected test packet in octets.”

“... length of the Session-Reflector packet in the mode matching mode of the received STAMP test packet...”
[RG]:         ...mode matching the mode...?
GIM>> Thank you for pointing that ambiguity to me, Ruediger. We refer to unauthenticated and authenticated modes. Would the following update make it clearer:
OLD TEXT:
      The length of the reflected test packet MUST be the largest of the
      length of the Session-Reflector packet in the mode matching mode
      of the received STAMP test packet, as defined in Section 4.3 of
      [RFC8762] with all the present in the received STAMP test packet
      STAMP extension TLVs [RFC8972] ...
NEW TEXT:
      The length of the reflected test packet MUST be the largest of the
      length of the Session-Reflector packet in the mode matching mode
      (unauthenticated or authenticated) of the received STAMP test
      packet, as defined in Section 4.3 of [RFC8762] with all the
      present in the received STAMP test packet STAMP extension TLVs
      [RFC8972] ...


2.1.2. Layer 3 Address Group Sub-TLV
“The value of the Length field MUST be equal to 8 or 20.”
[RG]: This is ambiguous. Something like the following? The value of the Length field MUST be equal to 8, if Address Family is set to IPv4.  The value of the Length field MUST be equal to 20, if Address Family is set to IPv6.
GIM>> Thank you for the suggestion that helps an implementer.
NEW TEXT:
   The value of the
   Length field MUST be equal to 8 if the value of the Address Family
   family is set to IPv4.  The value of the Length field MUST be equal
   to 20 if the value of the Address Family field is set to IPv6.


3.1. Rate Measurement
“The Reflected Test Packet Control TLV, defined in Section 2<https://www.ietf.org/archive/id/draft-ietf-ippm-asymmetrical-pkts-02.html#reflected-cntrl-tlv>, conforms to the requirements for measuring access rate by providing optional controls of the number of reflected test packets, the size of the reflected packet(s), and the time interval, i.e., rate, in transmitting the sequence of the reflected test packets.”

[RG]: I’d appreciate a reference to UDP Speed Test / RFC 9097 (or ITU-T Y.1540 or the BBF standard – I’ll have to find it) and draft-ietf-ippm-capacity-protocol-10 <https://datatracker.ietf.org/doc/draft-ietf-ippm-capacity-protocol/>  . UDPST allows for measuring access rate and is used to that purpose. I’m not opposed to a competing standard, but some discussion comparing UDPST and “STAMP Asymmetrical” for the purpose of access bandwidth measurement may be useful. Please note, that a flow control and some kind of congestion avoidance was required by IETF, when UDPST was standardized.
GIM>> I've added the reference to the IETF draft as informational with the following text appended to the quote:
NEW TEXT:
   The UDP Speed Test
   ([RFC9097] and [I-D.ietf-ippm-capacity-protocol]) also allows for the
   measurement of access bandwidth.

</snip>