Re: [ippm] draft-morton-ippm-capacity-metric-protocol

[[e-mail]]

Hi Marcus,

I support adoption.

Regards, Ruediger


Some comments:

Section  3.  Protocol Overview

   The client requires configuration of a test direction parameter
   (upstream or downstream test) as well as the hostname or IP address
   of the server in order to begin the setup and configuration exchanges
   with the server.

RG: The draft also mentions a sender and a receiver. Both, client and server
may act as sender and receiver. This depends on the test direction,
upstream or downstream.
Words to that appear in "9.  Method of Measurement", at the end of the doc.


4.  Stopping the Test: The server initiates the phase to stop the
       test by setting the STOP1 indication in load PDUs or sstatus
       feedback messages.                                                      ( ^^^^)

RG: Would it be worth a thought to enable the client to terminate a test?

##########

5.  Setup Request and Response Exchange

The message format isn't "TLV". Is the protocol extensible (e.g. could security be adapted to future needs)?

##########

6.2.  Test Activation Request - server response

.....The remaining 28 octets of the Test Activation Request (normally read

RG: A bit worrying, seems to be set by the sender in the reply to a request only. See editorials...

##########

7.1.  Test Packet PDU and Roles

.... On the other hand, the test configuration MAY use a fixed sending
   rate requested by the client,

RG: contains descriptive text about the method (e.g. decision on the sending rate). The text
there certainly is correct. I wonder, whether a reference replacing the text would be sufficient?

RG:  Does the MAY here introduce a new method? If it does, would that require to update the
RFC specifying the method?

###########

10.  Security Considerations

RG: would a receiver (client and host) require an "Emergency Stop" message? If yes, should it require authentication in order to avoid an attacker from unwanted test termination?

Would a three-way-handshake make sense to activate testing? (noting that the sender in that case also must be protected against opening of unbounded numbers of tests). A three way handshake protects against forged test set up messages.

What else could be forged? Do these require authentication or at least a discussion?

  *   Response message feedback (indicating ramp-up/no drop where there's congestion or the other way around, congestion where there is none).
  *   Stop messages (unwanted termination)
  *   Could a host or a client be tricked into persistently acting as a sender?
########


Editorials

6.2.  Test Activation Request - server response

...   When the server sends the Test Activation response back, it SHALL set
   the cmd Response field to:

RG: Server Test Activation Reply (or Response - please apply stringently through the text)
When the server responds by a Test Activation Reply, it...

----

   The server SHALL include all the test parameters again to make the
   client aware of any changes.

RG: The server SHALL repeat all test parameters to indicate changes to the client.

----

8.  Stopping the Test

   When the test duration timer on the server expires, it SHALL set the
   connection test action to STOP and also starts marking all outgoing
   load or status PDUs with a test action of STOP1.

RG: ...and mark all outgoing load...

----

10.  Security Considerations

A. Unathenticated mode (for all phases)

Unauthenticated
    ^^^^

Von: ippm <[e-mail]> Im Auftrag von Marcus Ihlar
Gesendet: Montag, 6. Dezember 2021 16:53
An: [e-mail]
Betreff: [ippm] draft-morton-ippm-capacity-metric-protocol

Hi IPPM,

This email starts an adoption call for draft-morton-ippm-capacity-metric-protocol, " Test Protocol for One-way IP Capacity Measurement".  This document is intended for Standards Track and defines a protocol for measuring Network Capacity metrics defined in RFC 9097 (https://datatracker.ietf.org/doc/rfc9097/)

https://datatracker.ietf.org/doc/draft-morton-ippm-capacity-metric-protocol/
https://datatracker.ietf.org/doc/html/draft-morton-ippm-capacity-metric-protocol-02

This adoption call will last until Monday, December 20. Please review the document, and reply to this email thread to indicate if you think IPPM should adopt this document.

BR,
Marcus