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

From: Marcus Ihlar <[email-masked]>
Date: Mon, 6 Dec 2021 15:52:36 +0000

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

---

From: <[email-masked]>
Date: Tue, 7 Dec 2021 08:00:34 +0000

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 <[email-masked]> Im Auftrag von Marcus Ihlar
Gesendet: Montag, 6. Dezember 2021 16:53
An: [email-masked]
Betreff: [ippm] draft-morton-ippm-capacity-metric-protocol

Hi IPPM,

BR,
Marcus

---

From: Lincoln Lavoie <[email-masked]>
Date: Thu, 9 Dec 2021 13:41:44 -0500

Hello Marcus & All,

First, I am completely in support of moving forward with the draft. Thank
you to Al and team for all of their hard work in developing these materials.

I've reviewed the 02 version and don't have any additional comments at this
time.

Cheers,
Lincoln

On Mon, Dec 6, 2021 at 10:52 AM Marcus Ihlar <marcus.ihlar=
[email-masked]> wrote:

> 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/).
>
>
>
>
> 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
>
>
> _______________________________________________
> ippm mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/ippm
>

-- 
*Lincoln Lavoie*
Principal Engineer, Broadband Technologies
21 Madbury Rd., Ste. 100, Durham, NH 03824
[email-masked]
https://www.iol.unh.edu
+1-603-674-2755 (m)
<https://www.iol.unh.edu>

---

From: Greg Mirsky <[email-masked]>
Date: Thu, 9 Dec 2021 16:25:04 -0800

Hi Marcus,
I support the adoption of this draft by the IPPM WG.
This is an essential part of the work on the IP network capacity
measurement.

Regards,
Greg

---

From: can desem <[email-masked]>
Date: Wed, 15 Dec 2021 14:41:27 +1100

Hi Marcus and all,

I would like to express my support for the adoption of this protocol. I
believe that this will be a really useful standards based tool for IP
capacity measurement, especially at gigabit speeds and expect to see it
widely adopted in the industry.

Regards,
Can Desem