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

[Greg Mirsky <[e-mail]>]

Hi Ruediger,
I hope that your travel from IETF home was light. What are your thoughts
about the rest of the proposed updates? Do you find them addressing
your concerns?

Best regards,
Greg

On Tue, Nov 5, 2024 at 12:01 PM <[e-mail]> wrote:

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