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

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

> -----Original Message-----
> From: ippm <ippm-bounces@ietf.org> On Behalf Of Éric Vyncke via Datatracker
> Sent: Thursday, June 3, 2021 7:39 AM
> To: The IESG <iesg@ietf.org>
> Cc: ippm-chairs@ietf.org; draft-ietf-ippm-capacity-metric-method@ietf.org;
> ippm@ietf.org
> 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
> 
...
> ----------------------------------------------------------------------
> COMMENT:
> ----------------------------------------------------------------------
> 
> 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.
[acm] 

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 ?
[acm] 
This important aspect of IPPM testing is discussed in an update to our measurement
Framework (RFC 2330), in RFC 7312: https://datatracker.ietf.org/doc/html/rfc7312#section-3.1.2

   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/
[acm]
ok

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

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]
      guidelines.
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
> RFC
> 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 https://datatracker.ietf.org/doc/html/rfc8468#section-5

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?"
[acm]
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
advice:

   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 ?

[acm] 
(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
> ippm@ietf.org
> https://urldefense.com/v3/__https://www.ietf.org/mailman/listinfo/ippm__;!!Bhd
> T!zqf-cZZb_zNzvDdwXfO1sq0Mw_SEkhmaDj26jDYUgCEqD76tci1IvLP05gKs$