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

From: "MORTON, ALFRED C (AL)" <[email-masked]>
Date: Fri, 22 Jun 2018 19:22:09 +0000

Hi Yaakov,

A belated thank you for your review.

I copied your March 20 message into a text file
to be sure I could work on the reply & edits
on the flight home, then forgot to send the 
reply in the few hours before my next flight out
(and the that meeting spawned a memory wipe).
Mea culpa.

Almost every issue you noted has been fixed
(can't do much about that 93 page thing).
There is still some time for further edits if
wanted. 

@IPPM:
I'm also looking for comments on the DNS section 6.
Ignacio Alvarez-Hamelin has exchanged some mail with me
on this section (thanks), resulting in some clarifications.

We still seek to close this open issue for DNS:

@@@@ <Loss> would require support of ID generation 
and population in the Message.  An alternative would be 
to use a random Source port on the Query Message, 
but we would choose ONE method before proceeding. @@@@

regards, and hope to see you in Montreal,
Al

> From: Yaakov Stein [mailto:[email-masked]]
> Sent: Tuesday, March 20, 2018 4:44 PM
> To: MORTON, ALFRED C (AL) <[email-masked]>; [email-masked]
> Subject: section 10 of draft-ietf-ippm-initial-registry-06
> 
> 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 ????

We have actually removed tons of redundancy, but the agreement was to
prepare a full-combinatorial registry, with much specificity.

> 
> 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.
> 
Done for Loss and Delay.

> 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)
> 
That's because there is a requirement for this section to include
a full bibliographic reference to an immutable doc.

> 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)
That's correct about RFC7011, because it is RFC6049 on Spatial Composition
that deals with combining two delay singletons or statistics. 
Added:
   (we are extending the composition of one-way subpath delays to subpath 
   round-trip delay).
> 
> The direction of SYN transfer is the Forward direction of transmission,
> ->
> The direction of SYN transfer is considered the Forward direction of
> transmission,

OK

> 
> 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.

We are willing to use any fields that help to establish correspondence.
the previous sentence says:
   In the definitions below, Corresponding Packets are transferred in 
   different directions and convey a common value in a TCP header field 
   that establishes correspondence (to the extent possible).

> 
> 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.
> 
Ok, let's be more inclusive, in connection with the word remote
(but a search today failed to find the word remote in the text ??)
s/located/typically located/
where applicable.

> 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.
Ok

> Also, "reordered packets" should be "misordered packets" or "out of order
> packets". Reordering is what the host does.
Sorry, but we re-used Paxson's terminology in RFC4337, and here.

> 
> Packet Losses can be inferred from: ... Duplicate segments:
>   Not only - duplication can occur due to malfunctioning network elements
> too.
Yes, bizarre network behavior breaks many inferences, let's just accept that.

> 
> 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)
We made DSCP a *Fixed* Parameter in these registered metrics, set at BE,
so that it corresponds to the most common case.  This does not preclude
tests with other DSCP, where YMMV (w.r.t. performance).
 
> 
> 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!
Removed (this may be a holdover from previous UDP entries)

> If you do want to, then please specify the IP checksum, the TTL, etc.
TTL or Hop Limit are now mentioned in the Run-time Parameters section.
> 
> Once again, I am not sure why you insist on the timestamp option.
If available, it makes correlation much easier.

> 
> The principal source of RTDelay error is the host processing time
> Another possibility to combat this is minimum gating (like in NTP).
> 
Yes, We mention that under Delay Heuristics.

> Nits:
> Examinating -> examining
thx
> 
> Why Corresponding Packets (capital P) but Qualified packets (small p) ?
> 
now cap-P 

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

> Y(J)S