Subject: [ippm] section 10 of draft-ietf-ippm-initial-registry-06

From: Yaakov Stein <[email-masked]>
Date: Tue, 20 Mar 2018 20:43:46 +0000

Al,

I didn't know what I was getting myself into when I volunteered to look over even a small portion of this document.
93 pages ????

So, here are some preliminary remarks, mostly limited to the first half of section 10
(although some of what I have to say applies to other portions of the document).

RTDelay ... The Observation Point [RFC7011] is assumed to be in the network at a remote point from the end hosts.
->
While TCP runs end-to-end between two hosts, here we consider the measurement of RTDelay based on a single Observation Point located somewhere in the network.

and similarly:
RTLoss ... The Observation Point [RFC7011] is assumed to be in the network at a remote point from the end hosts.
->
We consider the measurement of the RTLoss based on a single Observation Point located somewhere in the network.

Cleaner wording:
Although there is no RFC that describes passive measurement of Round-Trip Delay, the parallel definition for Active measurement is given in RFC 2681 [RFC2681].
(and I saw many more examples of this verbose referencing)

With the Observation Point [RFC7011] (OP) located between the hosts    participating in the TCP connection, the Round-trip Delay metric    requires two individual measurements between the OP and each host,    such that the Spatial Composition [RFC6049] of the measurements yields    a Round-trip Delay singleton.
   Well, actually 7011 never explicitly discusses composition of Round-trip metrics, only one-way ones. I would simply say
It is evident that the Round-trip Delay singleton is obtained by adding
the two measurements. (and that would save some text later on how to perform the composition)

The direction of SYN transfer is the Forward direction of transmission,
->
The direction of SYN transfer is considered the Forward direction of transmission,

Examples may be found in the TCP timestamp fields.
  Unclear to me.
  In fact, the insistence on using the timestamp field is not clear to me.
  Although the timestamp option is often used, it IS only an option.
  Since you are working from a single OP, you can get away without the timestamp.
  Yes, I saw the comment on packets on only one side of the OP, and am not convinced that there aren't enough of the contrary case.

Note that when OP is located at host A or host B, one of the terms   composing RTDelay will be zero or negligible.
Since you state that the OP is "in the network" (and explicitly add that it is remote to the hosts),
I guess this is limited to the case where a router itself is the TCP end-point. Is that what is meant?
In any case, you should either remove this remark, or the statement that the OP is remote from the end-point.

TCP segments are normally monotonically increasing.
  I think this should be
TCP segments are transmitted with monotonically increasing sequence numbers, but may these segments may be received out of order.
Also, "reordered packets" should be "misordered packets" or "out of order packets". Reordering is what the host does.

Packet Losses can be inferred from: ... Duplicate segments:
  Not only - duplication can occur due to malfunctioning network elements too.

Why the requirement for DSCP to be set to zero? Perhaps I am interested in the RTT for a given DSCP value.
(I saw this over and over in the doc)

I am not sure why you specify that the TCP checksum must be calculated.
That is standard TCP, and does not have to be specified here!
If you do want to, then please specify the IP checksum, the TTL, etc.

Once again, I am not sure why you insist on the timestamp option.

The principal source of RTDelay error is the host processing time
Another possibility to combat this is minimum gating (like in NTP).

Nits:

Examinating -> examining

Why Corresponding Packets (capital P) but Qualified packets (small p) ?

The Strowes reference is:
Strowes, S., "Passively Measuring TCP Round Trip Times", Communications of the ACM, Vol. 56 No. 10, Pages 57-64.

Y(J)S