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

[Greg Mirsky <[e-mail]>]

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