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

[Greg Mirsky <[e-mail]>]

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

On Wed, Oct 30, 2024 at 5:01 AM <[e-mail]> wrote:

> Hi Greg,
>
>
>
> after giving the document some more attention, I’m having some more
> comments. These are ordered by appearance in text, not by severity
> (major/minor/nits).
>
>
>
> Regards,
>
>
>
> Ruediger
>
>
>
>
>
>
>
>
>
> 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.


>
>
> 3.2. Active Performance Measurement in Multicast Environment
>
> “The Session-Reflector MUST use the source IP address of the received
> STAMP test packet as the destination IP address of the reflected test
> packet, and MUST use one of the IP addresses associated with the node as
> the source IP address for that packet.”
>
> [RG] please clarify text:  ..... associated with the node hosting the
> Session-Reflector as the source IP address for that packet.
>
>
>
> [RG]: If I understand the text correctly, a single Session-Sender packet
> is intended to be sent to an Mcast tree. Are all receivers expected to be
> STAMP aware? If not, please discuss operation. I also think, that some of
> the discussion of this section should be repeated within or copied to the
> security section.
>
GIM>> I think that the expectation of STAMP capability on the remote
endpoint of the STAMP test is the same in p2mp as in p2p case. As such, the
system that hosts the STAMP Session-Sender might have information about the
STAMP-capable leaves of the multicast tree or it may not. I think that that
is outside of the scope of STAMP operation.

>
>
> 4. Security Considerations
>
> [RG]: This section requires more discussion, I think. Security references
> point down to https://www.rfc-editor.org/rfc/rfc4656.html#page-38 – a
> document which didn’t plan a “Reflector” to be the true sender controlled
> by a remote system (and foresaw a control channel between sender and
> receiver). To me, the chain of security references doesn’t apply here any
> more.
>
GIM>> I got confused, as the Security Considerations section has no
reference to RFC 4656. Could you kindly clarify where do you see the
connection in that section?

> One important aspect to me seems to be operation of this STAMP extension
> within a single operational domain. Please add text, if this is expected or
> required.
>
GIM>> The proposed STAMP extension inherits all the security considerations
defined for the base STAMP specification, and the document that defined the
STAMP extension mechanism. Neither of these documents have any special
consideration for administrative domains. Furthermore, STAMP may be used in
unauthenticated or authenticated mode to mitigate any security concerns.
Also, STAMP extensions can be secured using HMAC TLV.

> I personally still feel more comfortable, if operational guidance and
> authentication is implemented for a remote controlled load generator as
> specified by this draft ( n = 2^32 packets of a size up to 2^32 Byte
> length).
>
GIM>> The use of HMAC TLV is RECOMMENDED if the STAMP is in the
unauthenticated mode. Furthermore, in the last update we expanded Security
Considerations with the following text:
   But even with the
   HMAC TLV, the Reflected Test Packet Control TLV could be exploited
   for the replay attack.  To mitigate that risk, a STAMP Session-
   Reflector SHOULD use the value of Sequence Number field [RFC8762] of
   the received STAMP test packet.  If that value compared to the
   received in the previous test packet of the same STAMP test session
   is not increasing, then the Session-Reflector MUST respond with a
   single reflected packet, setting the U flag to 1 [RFC8972].
That is in addition to the existing provision in Section 2 for the
Session-Reflector that allows for it to reject the requested parameters for
the reflected packets:
If a Session-Reflector that recognizes the Reflected Test Control TLV
cannot sustain the transmission of reflected test packets at the interval
requested in the Interval Between the Reflected Packets field on the
received TLV, the Session-Reflector MUST set the U flag [RFC8972] to 1, and
MUST transmit a single reflected packet.

>
>
> “Also, STAMP authentication mode [RFC8762
> <https://www.ietf.org/archive/id/draft-ietf-ippm-asymmetrical-pkts-02.html#RFC8762>]
> or HMAC TLV [RFC8972
> <https://www.ietf.org/archive/id/draft-ietf-ippm-asymmetrical-pkts-02.html#RFC8972>]
> could be used for a STAMP test session containing the Reflected Test Packet
> Control TLV.”
> [RG]: To me, authentication is a SHOULD as a minimum, if Reflected Test
> Packet Control TLV is present and Number of the Reflected Packets > 1.
>
GIM>> Indeed, that is consistant with Security Considerations section:
Considering the potential number of reflected packets that can be generated
by a single test packet sent to a multicast address, a Session-Sender
SHOULD sign packets using the HMAC TLV when sending such messages. I
propose changing to:
NEW TEXT:
   Also, either STAMP authentication
   mode [RFC8762] or HMAC TLV [RFC8972] SHOULD be used for a STAMP test
   session containing the Reflected Test Packet Control TLV.

>
> [RG]: A MUST seems more appropriate, if destination address is MCAST and
> Number of the Reflected Packets > 1.  In the unicast case, I’d favour some
> kind of limit for Number of the Reflected Packets when a SHOULD turns MUST
> for AUTH, e.g. if more than an “initial window” number of packets is
> demanded. UDPST allows for requestor and reflector to be in different
> operational domains. If you are interested, please read
> https://www.rfc-editor.org/rfc/rfc9097.html#name-security-considerations
> for UDPST security requirements and recommendations.
>
>
>
> “A Session-Sender SHOULD NOT send the next STAMP test packet with the
> Reflected Test Packet Control TLV before the Session-Reflector is expected
> to complete transmitting all reflected packets in response to the Reflected
> Test Packet Control TLV in the previous test packet.”
>
> [RG]: This needs to be enhanced. Please specify the behaviour of the
>  Session-Reflector, if it receives a Reflected Test Packet Control TLV from
> a Session-Sender before having transmitted Number of the Reflected Packets
> to that Session-Sender. Silent drop? Further, this seems to be operational
> point, where some flow control may be specified. I don’t think it’s a good
> idea to have a Session-Sender continually request large batches of test
> traffic, if that Session-Sender receives packets from the Session-Reflector
> with a high packet loss.
>
GIM>> I agree that this is covered in the text quoted above:
If a Session-Reflector that recognizes the Reflected Test Control TLV
cannot sustain the transmission of reflected test packets at the interval
requested in the Interval Between the Reflected Packets field on the
received TLV, the Session-Reflector MUST set the U flag [RFC8972] to 1, and
MUST transmit a single reflected packet.

>
>
>
>
>
>
>
>
>
>
> *Von:* Greg Mirsky <[e-mail]>
> *Gesendet:* Mittwoch, 23. Oktober 2024 16:54
> *An:* zhangli (CE) <zhangli344=[e-mail]>
> *Cc:* [e-mail]; [e-mail]
> *Betreff:* [ippm] Re: I-D Action: draft-ietf-ippm-asymmetrical-pkts-02.txt
>
>
>
> Hi Li,
>
> many thanks for your suggestion; much appreciated! I've prepared the
> update as follows:
>
>
>
> 6.2.  Layer 2 and Layer 3 Address Group Sub-TLV Types
>
>
>
>    The IANA is requested to assign new values for the Layer 2 and Layer
>
>    3 Address Group sub-TLV Types from the STAMP Sub-TLV Types registry
>
>    according to Table 2.
>
>
>
> Best regards,
>
> Greg
>
>
>
> On Wed, Oct 23, 2024 at 1:28 AM zhangli (CE) <zhangli344=
> [e-mail]> wrote:
>
> Hi Authors,
>
> I just read this draft and find that there is a mistake in the name of
> section 6.1 and section 6.2, they are both " Reflected Test Packet Control
> TLV Type ". Based on my understanding, the name of section 6.2 maybe "Layer
> 2 & Layer 3 Address Group sub-TLV Type" or " Reflected Test Packet Control
> sub-TLV Type ".
>
> Best regards
> Li
>
> -----邮件原件-----
> 发件人: [e-mail] <[e-mail]>
> 发送时间: 2024年10月16日 5:42
> 收件人: [e-mail]
> 抄送: [e-mail]
> 主题: [ippm] I-D Action: draft-ietf-ippm-asymmetrical-pkts-02.txt
>
> Internet-Draft draft-ietf-ippm-asymmetrical-pkts-02.txt is now available.
> It is a work item of the IP Performance Measurement (IPPM) WG of the IETF.
>
>    Title:   Performance Measurement with Asymmetrical Packets in STAMP
>    Authors: Greg Mirsky
>             Ernesto Ruffini
>             Henrik Nydell
>             Richard Foote
>    Name:    draft-ietf-ippm-asymmetrical-pkts-02.txt
>    Pages:   11
>    Dates:   2024-10-15
>
> Abstract:
>
>    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.  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 datatracker status page for this Internet-Draft is:
> https://datatracker.ietf.org/doc/draft-ietf-ippm-asymmetrical-pkts/
>
> There is also an HTML version available at:
> https://www.ietf.org/archive/id/draft-ietf-ippm-asymmetrical-pkts-02.html
>
> A diff from the previous version is available at:
>
> https://author-tools.ietf.org/iddiff?url2=draft-ietf-ippm-asymmetrical-pkts-02
>
> Internet-Drafts are also available by rsync at:
> rsync.ietf.org::internet-drafts
>
>
> _______________________________________________
> ippm mailing list -- [e-mail]
> To unsubscribe send an email to [e-mail]
>
>