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

[[e-mail]]

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


[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):

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


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


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.


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.

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.

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

“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.
[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.





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]<mailto:[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]<mailto:[e-mail]> <[e-mail]<mailto:[e-mail]>>
发送时间: 2024年10月16日 5:42
收件人: [e-mail]<mailto:[e-mail]>
抄送: [e-mail]<mailto:[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]<mailto:[e-mail]>
To unsubscribe send an email to [e-mail]<mailto:[e-mail]>