Re: [ippm] draft-mirsky-ippm-asymmetrical-pkts-02 Comments and Questions

["Footer Foote (Nokia)" <[e-mail]>]

Hi Greg,

Looking forward to the update and your consideration of my comments.

Thanks,
Footer

From: Greg Mirsky <[e-mail]>
Sent: Monday, January 15, 2024 9:22 AM
To: Footer Foote (Nokia) <[e-mail]>
Cc: [e-mail]; [e-mail]
Subject: Re: draft-mirsky-ippm-asymmetrical-pkts-02 Comments and Questions


CAUTION: This is an external email. Please be very careful when clicking links or opening attachments. See the URL nok.it/ext for additional information.


Hi Footer,
many thanks for your detailed comments and suggestions. All are a great help in improving the document. I will work on updating the draft and will share the new version by the end of the month.

Regards,
Greg


On Fri, Jan 12, 2024 at 10:19 AM Footer Foote (Nokia) <[e-mail]<mailto:[e-mail]>> wrote:
Thank you to the authors for submitting the work describe in https://datatracker.ietf.org/doc/draft-mirsky-ippm-asymmetrical-pkts/.

The work is very promising and well structured.  I have a few comments, and questions on initial review, for their consideration.

Section 1, Introduction - Would there be value in slightly restructuring the first paragraph of the Introduction to consolidate the references RFC7497.  I have included something for your consideration.

"Simple Two-way Active Measurement Protocol (STAMP) [RFC8762] defined the STAMP base functionalities.  STAMP Protocol Optional Extensions [RFC8972] introduces a TLV structure that allows the Session-Sender to include optional instructions for Session-Reflector.   New STAMP TLVs can be defined to support the scenarios in [RFC7497] which discusses the coordination of messaging between the source and destination to help deliver a key tent of IPPM minimizing the test traffic effect on user traffics.  In some scenarios, e.g., rate measurements discussed in [RFC7497], it is beneficial not only to use a variable size of the test packets transmitted downstream while controlling length, number, and interpacket interval for reflected test packets."

Section 2.  Problem Statement - if the above is judged to be good for inclusion then possibly remove this reference to RFC7497 from this section, "[RFC7497] analyses rate measurement scenarios where it is beneficial to enable control of the responding node reflecting the received test packet with a different length and, in some cases, with a series of equally timed test packets." and focus on STAMP."

Section 3 Reflected Test Packet Control TLV
1: "Type is a fourteen-bit field".  Should be "four-bit field" to match the format of the PDU?
2: Interval Between the Reflected Packets is a 32-bit field indicated in nanoseconds.  In the third paragraph following rules the unit is described as milliseconds?
3: Could there be issues with Interval Between the Reflected Packets or possibly other fields on the Session-Reflector in response to Session-Sender requests, where the Session-Reflector cannot meet the Session-Sender Request.  Should the behavior of a Session-Reflector be described that includes what happens when the Session-Sender makes a request in the control TLV with values that the Session-Reflector cannot accommodate, either at that instance in time or at all.  Maybe we could use the U flag to indicate something was unrecognized or not supported in a well-structured TLV?
4: The way I read the Number of Reflected Packets and Interval Between Reflected Packets, when the Session-Reflector receives a STAMP PDU with the Control TLV it will respond to the STAMP test PDU from the Session-Sender with those number of packets at that interval specified in the PDU.
- Should a statement be added where, the Session-Sender should consider the combination of these two values so it does not generate test packets that will arrive on the Session-Reflector the schedule on the Session-Reflector had completed, which was triggered by the previous packet from the Session-Sender.
5: A couple of questions on the packet structure;
- Do the Number of the Reflected Packets and Interval Between the Reflected Packets require 32 bit fields?
6: The fourth paragraph under rules indicates local policy decides how to deal with Number of reflected Packets is equal to 0.  What are some examples of this policy?  Would this include local storage of results, maybe something else?  If local storage of results is the local policy, should the STAMP YANG model consider statistics on the reflector for this possible one-way measurement.

Section 3.1.2 Layer 3 Address Group Sub-TLV - The Sub-TLV Format tags the IP address field IP Network Prefix.  The Prefix Length Description below refers to this field as "the IP Network filed".  Should those two elements be aligned?

General - Should a consideration be given to a first bit and last bit when the Number of Reflected Packets  equals zero.  It may be of value if there is a requirement to create sample windows on the Session-Reflector, if one large collection of statistics is not the desired result.
General - Is there a change that needs to be described for the computation of loss in the where multiple responses are generated by the Session-Reflector triggered by a single Session-Sender STAMP test PDU.  Does the simple 1:1 STAMP 32 sequence number math change in this case?

Hopefully, some of these comments are helpful.

Thank you for submitting this work.

Footer