Re: [ippm] Éric Vyncke's No Objection on draft-ietf-ippm-capacity-metric-method-11: (with COMMENT)

"MORTON JR., AL" <> Fri, 04 June 2021 05:01 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 902AB3A28CB; Thu, 3 Jun 2021 22:01:08 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -1.896
X-Spam-Status: No, score=-1.896 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_BLOCKED=0.001, RCVD_IN_MSPIKE_H3=0.001, RCVD_IN_MSPIKE_WL=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id WkqqoubzWuwU; Thu, 3 Jun 2021 22:01:03 -0700 (PDT)
Received: from ( []) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 190603A28CA; Thu, 3 Jun 2021 22:01:02 -0700 (PDT)
Received: from pps.filterd ( []) by ( with SMTP id 1544rrbD048481; Fri, 4 Jun 2021 01:01:00 -0400
Received: from ( []) by with ESMTP id 38y1uvmd67-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Fri, 04 Jun 2021 01:00:59 -0400
Received: from (localhost []) by (8.14.5/8.14.5) with ESMTP id 15450w1g030644; Fri, 4 Jun 2021 01:00:59 -0400
Received: from ( []) by (8.14.5/8.14.5) with ESMTP id 15450u8K030457 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Fri, 4 Jun 2021 01:00:56 -0400
Received: from ( []) by (Service) with ESMTP id 49A724005C1C; Fri, 4 Jun 2021 05:00:56 +0000 (GMT)
Received: from (unknown []) by (Service) with ESMTP id F0DE34005C1B; Fri, 4 Jun 2021 05:00:55 +0000 (GMT)
Received: from ( by ( with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id 15.1.2242.10; Fri, 4 Jun 2021 01:00:55 -0400
Received: from ([]) by ([]) with mapi id 15.01.2242.010; Fri, 4 Jun 2021 01:00:48 -0400
From: "MORTON JR., AL" <>
To: =?iso-8859-1?Q?=C9ric_Vyncke?= <>, The IESG <>
CC: "" <>, "" <>, "" <>
Thread-Topic: =?iso-8859-1?Q?[ippm]_=C9ric_Vyncke's_No_Objection_on_draft-ietf-ippm-cap?= =?iso-8859-1?Q?acity-metric-method-11:_(with_COMMENT)?=
Thread-Index: AQHXWG0iAkhDlzVRsUOjhKQze+6pEKsCVC/g
Date: Fri, 4 Jun 2021 05:00:48 +0000
Message-ID: <>
References: <>
In-Reply-To: <>
Accept-Language: en-US
Content-Language: en-US
x-originating-ip: []
x-tm-snts-smtp: 64FCB6B87163A21BD003E96F846B685A89AA94BA377D65793BB368242C5490E72
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
X-Proofpoint-GUID: zahqnqudPYwmLOceNzd3bFDADU7BdvPg
X-Proofpoint-ORIG-GUID: zahqnqudPYwmLOceNzd3bFDADU7BdvPg
X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10434:6.0.391, 18.0.761 definitions=2021-06-04_01:2021-06-04, 2021-06-04 signatures=0
X-Proofpoint-Spam-Details: rule=outbound_policy_notspam policy=outbound_policy score=0 phishscore=0 priorityscore=1501 mlxscore=0 lowpriorityscore=0 spamscore=0 impostorscore=0 clxscore=1011 malwarescore=0 mlxlogscore=999 bulkscore=0 suspectscore=0 adultscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.12.0-2104190000 definitions=main-2106040038
Archived-At: <>
Subject: Re: [ippm] =?iso-8859-1?q?=C9ric_Vyncke=27s_No_Objection_on_draft-ie?= =?iso-8859-1?q?tf-ippm-capacity-metric-method-11=3A_=28with_COMMENT=29?=
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: IETF IP Performance Metrics Working Group <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Fri, 04 Jun 2021 05:01:10 -0000

Hi Eric, Thanks for your review -
please see replies [acm] below,

> -----Original Message-----
> From: ippm <> On Behalf Of Éric Vyncke via Datatracker
> Sent: Thursday, June 3, 2021 7:39 AM
> To: The IESG <>
> Cc:;;
> Subject: [ippm] Éric Vyncke's No Objection on draft-ietf-ippm-capacity-metric-
> method-11: (with COMMENT)
> Éric Vyncke has entered the following ballot position for
> draft-ietf-ippm-capacity-metric-method-11: No Objection
> ----------------------------------------------------------------------
> ----------------------------------------------------------------------
> Thank you for the work put into this document.
> Please find below some non-blocking COMMENT points (but replies would be
> appreciated).
> I hope that this helps to improve the document,
> Regards,
> -éric
> == COMMENTS ==
> Generic comment about the 1 Mbps granularity, this may of course be well suited
> for many connection but not really for constrained networks where the
> measurement techniques of this I-D could be applied.

We don't mandate the starting rate or the table step-size:

   ...It is
   RECOMMENDED that rates begin with 0.5 Mbps at index zero, use 1 Mbps
   at index one, and then continue in 1 Mbps increments to 1 Gbps.

The lowest capacity we have tried to test was 1.5 Mbps, so
we didn't make an informed recommendation for low-rate/constrained networks.
The problem we are trying to solve is in a much higher rate range.

Perhaps we can add:

The sending rate table SHOULD include the maximum capacity where it will 
make measurements, including constrained rates less than 500kbps if applicable. 

> Should the payload content random content to avoid some compression techniques
> on the path ?
This important aspect of IPPM testing is discussed in an update to our measurement
Framework (RFC 2330), in RFC 7312:

   Some packet payloads are more susceptible to compression than others,
   but optimizers in the measurement path can be out ruled by using
   incompressible packet payload.  This payload content could be
   supplied by a pseudo-random sequence generator or by using part of a
   compressed file (e.g., a part of a ZIP compressed archive).

We can add "Payload Content" as a metric parameter in section 4.

   Payload Content   This IPPM-conforming measurement adds packet payload content as a
   Type-P parameter, which can help to improve measurement determinism.
   To remove a possible advantage due to compression, payload content SHOULD be
   supplied by a pseudo-random sequence generator, by using part of a
   compressed file, or by other means. See Section 3.1.2 of RFC7312.

> -- Section 4 --
> s/the address of a host/one of the IP addresses of a host/

> Should there be a SHOULD rather than a MAY in "The IPv6 flow label MAY be
> included" ?

So, this would be recommending the v6 flow label be part of the 
flow definition under certain circumstances with tunnels and ECMP or LAG:

      ... Note: The IPv6 flow label MAY be included in the
      flow definition when routers have complied with [RFC6438]
s/MAY/SHOULD/ sounds reasonable.

> -- Section 5.3 --
> "   o  n0 is the total number of IP-Layer header and payload bits that
>       can be transmitted in standard-formed packets [RFC8468] from the
>       Src host and correctly received by the Dst host during one
>       contiguous sub-interval, dt in length, during the interval [T,
>       T+I],"
> If we want to split hairs, in the case of IP fragmentation or NAT64, the
> received bits will be different than the one sent ;-) I had no time to read
> 8468 (day job...), but, does the above remark fall in the same category as
> "Some compression affects on measurement are discussed in Section 6 of
> [RFC8468]."

According to

A packet is standard-formed if ....

     +  It is not an IP fragment.

So, fragmentation is off the table.

However, tests of a transition mechanism might well be the intended subject
of a capacity test. As long as the IPv4 and IPv6 packets sent/received are
both standard-formed, this should be allowed (and the change in header
size easily accounted for on a per-packet basis).

> -- Section 8.3 --
> "  The number of concurrent, independent tests between
>    the same Source and Destination SHALL be limited to one."
> Is it between hosts or between network? I.e.n "same source and destination
> networks?"
I'm not sure that adding "networks" makes the requirement more clear.
The Source and Destination networks could be multi-homed, a situation 
where single flows are assigned to one of the parallel links. We allow
multiple flows to comprise a test and produce a measurement of
aggregate capacity. 

But adding "host" isn't the obvious clarification, either. Previously we said:

... Although the default is a single flow (F=1)
   for testing, use of multiple flows may be advantageous for the
   following reasons:

   1.  the test host may be able to create higher load than with a
       single flow, or parallel test hosts may be used to generate 1
       flow each.

Since is one of the last requirements we have added (this week), 
and only to prohibit what seems (to the authors) to be an obvious 
mistake in judgement (neither of two independent tests conducted 
concurrently will be able to correctly measure the maximum capacity), 
then we should also consider removing the requirement sentence, leaving the

   It is obviously counter-productive to run more than one independent
   test (regardless of the number of flows in the test stream)
   attempting to measure the *maximum* capacity between the same Source
   and Destination.

(and add "concurrent" somewhere above).


> -- Section 8.4 --
> "supports IPv4 and IPv6 address families." does it support a NAT64 function on
> the path ?

(this is about the running code)
I'm fairly sure we did not test with any v4-v6 transition function on 
the path, but the possibility exists for surprises - it might work 
under some circumstances...

> _______________________________________________
> ippm mailing list
> T!zqf-cZZb_zNzvDdwXfO1sq0Mw_SEkhmaDj26jDYUgCEqD76tci1IvLP05gKs$