- In the Introduction, it is mentioned that this new protocol supports
measurement features which were not available by standard measurement
protocols, such as OWAMP, TWAMP, STAMP etc. For sake of clarity, it would be
good to clarify the motivation and explain why you chose to design a new
protocol instead of extending existing tools to implement the capacity
measurement.
[Authors] ADD:... bulk measurement load is unidirectional. The above IPPM standards did support creation of unsymmetric traffic in combination with some two-way communication, as supported by TWAMP and STAMP, when work on UDPST started. Further, two-way communication of TWAMP and STAMP are limited to reflection or unidirectional load creation, but lack support for closed loop feedback operation. The latter enables limiting congestion of a bottleneck, whose capacity is measured, to a short time range. Support of such a control loop is the main feature of the UDPST Protocol.
--------------
- In section 2, I think it is necessary to specify better the applicability. I
guess the method can be applied in different scenarios, e.g. controlled domain
or connection over the internet. I would highlight the different aspects,
especially in terms of security, based on the application.
[Authors] ADD a paragraph at the end of Section 2:
UDPSTP is a client based protocol. It may be applied by consumers to measure their own access bandwidth. Consumers may prefer an cross-domain measurement architecture for this purpose. UDPSTP may be deployed in Large-Scale Measurement of Broadband Performance environments (LMAP, see [RFC7497]), another cross-domain deployment. A network operator may support operation and maintenance by UDPST, a typical intra domain deployment. All these deployments require or benefit from trust into the results, which are ensured by authenticated communication. As an option enabling measurements controlled by very low-end devices in a lab or limited domain [RFC8799], unauthenticated operation may be implemented (but may be operated only in exactly that case).
--------------
- Section 4.2 and section 2 could be related. If section 2 will be improved by
adding the possible applicability scenarios, the different security mode
operations of section 4.2 can be linked to those scenarios.
[Authors] ADD at numbered list of section 4.2, final statement:
1. ...(see section 2)
2. ... This mode may be preferred to perform infrequent reliable measurements, typically initiated by consumers or for operator OAM purposes (see section 2).
3. ... This mode may be preferred to perform infrequent reliable measurements, typically initiated by consumers or for operator OAM purposes (see section 2).
4.... Encryption preserves privacy, and may be of interest for Large-Scale Measurement of Broadband Performance environments (LMAP, see section 2).
--------------
- In section 6.2.1, it is mentioned that the server has the option to modify
the request made by the client. If I have understood correctly looking at
section 6.3, when the client receives the response it can only accept the test
parameters modified by the server and the negotiation ends, right? I suggest to
make it clearer.
[Authors] ADD at the end of 6.3, 6th paragraph:
.....modified by the server. If the setup parameters coerced by the server are not acceptable to the client, it ends the test.
CHANGE start of 7th paragraph:
To finalize an accepted test activation, the client SHALL...
---------------
- Since section 9 is quite short, I would suggest to incorporate its content
elsewhere in the document, maybe in section 2. Therefore, section 9.1 can
become section 9 or moved too.
[Authors] Section 9 text was copied from RFC 9097. We prefer to keep it and expand it for RFC9097 operational aspects:
The nominal duration of a measurement interval at the Destination, parameter testIntTime, MUST be constrained in a production network, since this is an active test method and it will likely cause congestion on the Src to Dst host path during a test.
It is RECOMMENDED to locate test endpoints as close to the intended measured link(s) as practical. The testing operator MUST set a value for the MaxHops Parameter, based on the expected path length. This Parameter can keep measurement traffic from straying too far beyond the intended path.
It is obviously counterproductive to run more than one independent and concurrent test (regardless of the number of flows in the test stream) attempting to measure the maximum capacity on a single path. The number of concurrent, independent tests of a path SHALL be limited to one.
See section 8 of [RFC9097] for a discussion of the method of measurement beyond purely operational aspects.
--------- End ---------------
--
last-call mailing list -- last-call@xxxxxxxx
To unsubscribe send an email to last-call-leave@xxxxxxxx
