Subject: [ippm] Benjamin Kaduk's No Objection on draft-ietf-ippm-route-09: (with COMMENT)

From: Benjamin Kaduk via Datatracker <[email-masked]>
Date: Fri, 07 Aug 2020 17:21:15 -0700

Benjamin Kaduk has entered the following ballot position for
draft-ietf-ippm-route-09: No Objection

When responding, please keep the subject line intact and reply to all
email addresses included in the To and CC lines. (Feel free to cut this
introductory paragraph, however.)

Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html
for more information about IESG DISCUSS and COMMENT positions.

The document, along with other ballot positions, can be found here:
https://datatracker.ietf.org/doc/draft-ietf-ippm-route/

----------------------------------------------------------------------
COMMENT:
----------------------------------------------------------------------

Section 1

   test.  However, metrics for assessment of path components and related
   performance aspects had not been attempted in IPPM when the [RFC2330]
   framework was written.

nit(?): this seems to be the only place in the document that uses the
phrase "path component", and it was a bit confusing to me.  That is, I'm
used to seeing "path component" being (e.g.) one hop or link in a
multi-link path from source to destination, but the context here
suggests that it might be referring to something more like a single
route within a route ensemble.  I don't have a specific proposed change;
I just wanted to mention that I puzzled over this wording for a bit.

Section 2

   Also, to specify a framework for active methods of measurement which
   use the techniques described in [PT] at a minimum, and a framework
   for hybrid active-passive methods of measurement, such as the Hybrid
   Type I method [RFC7799] described in
   [I-D.ietf-ippm-ioam-data](intended only for single administrative
   domains), which do not rely on ICMP and provide a protocol for
   explicit interrogation of nodes on a path.  [...]

nit: could you remind us that the "Also" refers to the scope of this
work (the previous paragraph started with "The scope is" but there was a
fair bit of intervening stuff between there and here).

   Hop  A Hop MUST contain a Node Identity, and MAY contain arrival and/
      or departure interface identification, round trip delay, and an
      arrival timestamp.

In my head a "hop" is the operation of going from node A to node B,
i.e., the journey and not the destination.  So if we're associating a
node identity with the hop, would we need to say if that's the source or
destination node of the "hop" (or am I just misunderstanding things)?

Section 3.3

   Nmax, the largest value of i needed for a packet to be received at
   Dst (sent between T0 and Tf).  Nmax may be equal to N.

I'm not really sure I understand how Nmax works.  That is, for any given
packet, it has a value for 'i', and that packet may or may not be
delivered.  But with 'i' defined as the limit on the number of hops for
"a specific packet may visit", I don't see how we get to do multiple
tries for the same packet with different 'i', as we would need to do in
order to determine the "largest value of i *needed*" (emphasis mine).
That is, we can set 'i' unreasonably large and that would result in
delivery, but that does not (as I understand it) meet the definition for
Nmax -- Nmax is supposed to be a boundary value for some condition.  I'm
just not entirely clear on exactly what that boundary is, since we're
talking about a specific packet, and my understanding is that we only
get one crack at a specific packet.

   o  t(i,j) Arrival Timestamp (where t(i,j) is ideally supplied by the
      Hop, or approximated from the sending time of the packet that
      revealed the Hop)

I'm getting a bit of deja vu as I write this, but it seems risky to
propose using the term "arrival timestamp" both for something generated
at the Hop and something generated by the sender of the packet, since
that loses information about the accuracy of the value for a given use
case.  Perhaps it's best to reserve the term for the ideal quantity and
leave approximations for the processing pipeline (as opposed to the
measurement pipeline).

Section 3.4

   RTL(i,j,T) is defined as a singleton of the [RFC6673] Round-trip Loss
   between the Node with address = Src and the Node at Hop h(i,j) at
   time T.

Just to check my understanding: does the "singleton" and "at time T"
force us into a logical (boolean) loss metric for this case, as opposed
to a sample-ratio-type loss metric?

Section 3.6

   identities at a minimum.  The models need to be expanded to include
   these features, as well as Arrival Interface ID, Departure Interface
   ID, and Arrival Timestamp, when available.  [...]

Is this expected to occur as future work?  (Is there an I-D worth
referencing?)

Section 4.1

   Internet routing is complex because it depends on the policies of
   thousands of Autonomous Systems (AS).  While most of the routers
   perform load balancing on flows using Equal Cost Multiple Path
   (ECMP), a few still divide the workload through packet-based
   techniques.  The former scenario is defined according to [RFC2991],
   while the latter generates a round-robin scheme to deliver every new
   outgoing packet.  [...]

I was surprised to see "packet-based techniques" refer to a round-robin
scheme for queuing outgoing packets across interfaces, but assume this
just means I need to do more background reading.  Any tips for where to
start?

   Formally, to maintain the same flow in the measurements to a
   particular hop, the Type-P-Route-Ensemble-Method-Variant packets
   should be[PT]:

It's not entirely clear that we need a reference for these attributes;
they seem to be fairly easy to verify independently, IIUC.

   o  TCP case: For IPv4, the fields Src, Dst, port-Src, port_Dst,
      sequence number, and Diffserv Field SHOULD be the same.  For IPv6,
      the field FlowLabel, Src and Dst SHOULD be the same.

Are we happy to pair "to maintain the same flow" (previous paragraph)
with "SHOULD be the same" (here, and subsequent bullet points)?

Section 4.1

   1.  SHOULD occasionally check path portions which have exhibited
       stable results over time, particularly ingress and egress
       portions of the path.

Do we want to give any (e.g., order of magnitude) guidance for
"occasionally"?

Section 4.2

   In addition to node identity, nodes may also identify the ingress and
   egress interfaces utilized by the tracing packet, the time of day
   when the packet was processed, and other generic data (as described

nit: I'd consider "absolute time" over "time of day", since the latter
may have connotations of implying that there is 24-hour-periodic
behavior.  (It may also be subject to local time zone on the node
inserting the value.)

Section 4.3

   1.  Nodes at the ingress to the domain SHOULD be both Discoverable
       and Cooperating, and SHOULD reveal the same Node Identity in
       response to both active and hybrid methods.

The second clause here seems redundant with point (2) that follows.
(Similarly for point (3)'s similar clause.)  That is, the recommendation
to use the same identity for both methods can only ever apply when the
node in question is both Discoverable and Cooperating -- if it's only
one, then there will only be one identity available, and no need for
consistency across methods.

   When Nodes follow these requirements, it becomes a simple matter to

Perhaps a philosophical question, but are "SHOULD"-level directives more
of "requirements" or "guidelines"?

Section 5

   traffic load is not stationary.  Nonetheless, as the first approach,
   a link seems to be congested if, after sending several traceroute
   probes, it is possible to detect congestion observing different
   statistics parameters (e.g., see [IDCong]).  Finally, to recognize

nit: please check the wording of this sentence; I think there may be a
missing word or similar.

Section 6

   every hop.  This procedure could be done for a single Member Route
   flow, with parameter E set as False, or for every detected Route
   Ensemble flow (E=True).

nit: I don't think we define 'E' until the full procedure, a few
paragraphs below.

   made.  Line 8 and 13 set a timer for each cycle of measurements.  A
   cycle comprises the traceroutes packets, considering every possible
   Hop and the alternatives paths in the Alt variable (ensured in lines
   9-12).  [...]

I recognize that this is pseudocode, but "what if the
advanced-traceroute() operation takes longer than the i_t time?"

Section 7

We could consider some bland statement about the measurement
technologies (e.g., ICMP) not providing cryptographic protection for the
requested/returned data, and the risks of processing untrusted data in
general.  This is particularly true for reverse DNS data, used in
determining whether node identities represent the same node or not,
since DNSSEC deployment remains inconsistent (especially for the reverse
zone).

   The security considerations that apply to any active measurement of
   live paths are relevant here as well.  See [RFC4656] and [RFC5357].

(The security considerations of 5357 don't seem to be adding much
discussion, here, though I don't object to referencing it.)

Section 9

Should we intuitively know who the "original 3 authors" are?

Section 11.1

I was surprised to see draft-ietf-ippm-ioam-data in the normative
references section, as all the previous discussion was consistent with
merely an informative reference.

Similarly, RFCs 5388, 5835, 6437, and 7312 do not seem to be referenced
in a fashion that requires a normative reference.

---

From: "MORTON, ALFRED C (AL)" <[email-masked]>
Date: Sat, 8 Aug 2020 18:09:53 +0000

Thanks for your review and Comments, Ben.
Please see replies [acm] below,
Al

> -----Original Message-----
> From: Benjamin Kaduk via Datatracker [mailto:[email-masked]]
> Sent: Friday, August 7, 2020 8:21 PM
> To: The IESG <[email-masked]>
> Cc: [email-masked]; [email-masked]; [email-masked];
> Brian Trammell <[email-masked]>; [email-masked]
> Subject: Benjamin Kaduk's No Objection on draft-ietf-ippm-route-09: (with
> COMMENT)
> 
...
[acm] 
I see your point, I changed 
s/ path components/ paths/

so the sentence now reads (in the working version of -10):
However, metrics for assessment of paths and related performance aspects had not been attempted in IPPM when the RFC 2330 framework was written.

> fair bit of intervening stuff between there and here).
[acm] 
Sure:
Also, the Scope includes specifying a framework...

> destination node of the "hop" (or am I just misunderstanding things)?
[acm] 
I think it has been very common to refer to "Hop" as a noun, such as when IPv6 refers to Hop Count. IPPM had an extended discussion of Hop and Node definitions, and this is where we ended-up (with everyone happy!).

> order to determine the "largest value of i *needed*" (emphasis mine).
[acm] 
You're right, we don't conduct multiple tries with the same packet, but we can increase i and send another packet with the characteristics that result in the new packet traversing the same path.
We also iterate through values of i on packets testing other paths.

> Nmax -- Nmax is supposed to be a boundary value for some condition.
[acm] 
Among the values of N determined for different paths, one path could be larger than all the others; it involves the most Hops from Src to Dst. Nmax!

>  I'm
[acm] 
Most tools send more than one packet traversing the same path with a single value of i, to measure round trip time (RTT) and the RTT variation. Multiple packets provide some robustness from loss due to link performance and queue drops.

> leave approximations for the processing pipeline (as opposed to the
[acm] 
OK, let's refactor as a definition and a Note.

o  t(i,j) Arrival Timestamp, where t(i,j) is ideally supplied by the Hop. (Note that t(i,j) might be approximated from the sending time of the packet that revealed the Hop, e.g., when the round trip response time is available and divided by 2.)

> to a sample-ratio-type loss metric?
[acm] 
Yes, that's correct.  In the RFC 2330 framework, we have singleton, sample (or stream of singletons), and statistic (calculated on the sample, in this case the set of Boolean values for loss) and this last step is where loss ratio appears.

> Is this expected to occur as future work?  (Is there an I-D worth
[acm] 
No I-D yet.  Maybe when IOAM sees more deployment and interest, there are IOAM data I-D implementations available now.

> just means I need to do more background reading.  Any tips for where to
[acm] 
The early versions of Juniper M160 had four M40 routers combined and treated incoming packets this way, and they caused a lot of packet reordering as you might expect.
https://www.juniper.net/documentation/en_US/release-independent/junos/topics/concept/m160-overview-nog.html

> they seem to be fairly easy to verify independently, IIUC.
[acm] 
I think the reference is to indicate implementation in the Paris Traceroute method/tool, at least.
 
> with "SHOULD be the same" (here, and subsequent bullet points)?
[acm] 
There are ways to conduct valid measurements with SHOULD, IMO, but I see how MUST results in simplification.  Let's see what others say about this; no change proposed yet.

> Do we want to give any (e.g., order of magnitude) guidance for
[acm] 
OK, I'll suggest "daily".

> behavior.  (It may also be subject to local time zone on the node
[acm] 
I'm ok with changing to "absolute time", let's see if anyone has heartburn.

> consistency across methods.
[acm] 
I see that now, department of redundancy department missed that one, I'll fix it.
thanks!
 
> of "requirements" or "guidelines"?
[acm] 
SHOULD is a strong recommendation, and implementers are often asked to explain why they didn't follow that recommendation. All the RFC 2119 terms are listed in the section titled "Requirements Language".
I think we're ok with this wording.

> nit: please check the wording of this sentence; I think there may be a
[acm] I agree:

Nonetheless, as the first approach, a link seems to be congested if observing different/varying statistical results after sending several traceroute probes (e.g., see [IDCong]).  

> nit: I don't think we define 'E' until the full procedure, a few
[acm] 
Right, I have defined and clued-in the reader as a forward reference.

This procedure could be done for a single Member Route flow, an non-exhaustive search with parameter E (defined below) set as False, or for every detected Route Ensemble flow (E=True).
 
>    Hop and the alternatives paths in the Alt variable (ensured in lines
[acm] 
Bad things happen. I'll add a caution about setting the i_t time long enough to avoid this.

> since DNSSEC deployment remains inconsistent (especially for the reverse
[acm] 
Ok, I'll do that in one sentence:

Some of the protocols used (e.g., ICMP) do not provide cryptographic protection for the requested/returned data, and there are risks of processing untrusted data in general, but these are  limitations of the existing protocols where we are applying new methods.

> discussion, here, though I don't object to referencing it.)
[acm] 
Ok

> Should we intuitively know who the "original 3 authors" are?
[acm] 
No, I'll name them.
> merely an informative reference.
[acm] 
I don't think we have a basis for a Hybrid method with Cooperation Nodes without citing IOAM.

> in a fashion that requires a normative reference.
[acm] Checking these citations:

I agree that 5388, 5835, 6437 and 7312 citations are Informative.

Thanks for sending your extensive review early in the week, Ben! You may save some time for others.
Al

---

From: Benjamin Kaduk <[email-masked]>
Date: Mon, 10 Aug 2020 17:22:19 -0700

Hi Al,

> Please see replies [acm] below,

Thanks for the updates and the illuminative replies.  I don't have any
further comments, so trimming the quoted text.

-Ben