Subject: [ippm] Comments on draft-ietf-ippm-initial-registry-05.txt

From: "Huangyihong (Rachel)" <[email-masked]>
Date: Tue, 7 Nov 2017 08:18:29 +0000

Hi,

I did a review on this draft and think this is very useful, especially section 10 on passive TCP RTT metrics. I have a few comments for discussion. As I didn't follow this work before, please forgive me if I raise something already discussed.

1.       Section 10 defines the metrics "RTDelay", and it is calculated by "RTDelay = RTD_fwd + RTD_rev". I'm wondering if RTD_fwd and RTD_rev can also be used as the standard metrics? Because in some scenarios, people may need to report RTD_fwd and RTD_rev to do some network diagnoses. In such a case, RTDelay may not be enough.

2.       Same question to out-of-order segments and duplicate segments.

3.       The definition of our-of-order segments, maybe should consider the case where the ECMP exists? This means that packet losses should be differentiated from the real out-of-order packets.

4.       What's the plan for section 12? Is there any requirement for RTP layered metrics?

BR,
Rachel

---

From: "MORTON, ALFRED C (AL)" <[email-masked]>
Date: Sat, 11 Nov 2017 03:47:15 +0000

Hi Rachel,
Thanks for your review and comments!
Please see replies in-line below, [ACM],
Al

From: ippm [mailto:[email-masked]] On Behalf Of Huangyihong (Rachel)
Sent: Tuesday, November 07, 2017 3:18 AM
To: [email-masked]
Subject: [ippm] Comments on draft-ietf-ippm-initial-registry-05.txt

Hi,

I did a review on this draft and think this is very useful, especially section 10 on passive TCP RTT metrics. I have a few comments for discussion. As I didn't follow this work before, please forgive me if I raise something already discussed.
[ACM]
Section 10 is completely new, so there's no risk of
repeating past discussion (repeats are probably
safer when asked on the list, if they happen at all,
and newer folks are always entitled to a few basic
questions, IMO).

1.       Section 10 defines the metrics "RTDelay", and it is calculated by "RTDelay = RTD_fwd + RTD_rev". I'm wondering if RTD_fwd and RTD_rev can also be used as the standard metrics? Because in some scenarios, people may need to report RTD_fwd and RTD_rev to do some network diagnoses. In such a case, RTDelay may not be enough.
[ACM]
It would be possible. For example, I think that the
RTD of the 3-way Handshake should be treated as a separate
singleton of RTD for each connection measured, and added
to the results reported (RTDelay-SA). So, think about
what statistics of RTD_fwd and RTD_rev would help with
network diagnosis.

2.       Same question to out-of-order segments and duplicate segments.
[ACM]
Also possible, but we should also be aware that the
Performance Metric entries were mostly intended for
comparison between different networks measured exactly
the same way (with less focus on troubleshooting).

3.       The definition of our-of-order segments, maybe should consider the case where the ECMP exists? This means that packet losses should be differentiated from the real out-of-order packets.
[ACM]
You mean distinguishing out-of-order due to loss or true re-ordering?
I think this is where Brian's heuristic of evaluation
in RTT intervals will help: We will probably see
re-ordered packets filling a sequence number gap
during the *same* RTT interval as the out-of-order
packets that created the gap. (I'm using the RFC4737
definition of Re-ordered packets here, they arrive "late".)

@@@@ This additional heuristic needs to appear
in the draft, if we agree on how it works.

Also, keep in mind that ECMP usually comes with some form
of flow-hashing to keep all packets of a flow on a single
ECMP subpath. Recognizing this network behavior and
measuring it are the goals of Paris Traceroute and
the Route Ensemble metric draft. Have a look:
https://tools.ietf.org/html/draft-amf-ippm-route-01

4.       What's the plan for section 12? Is there any requirement for RTP layered metrics?
[ACM]
That's a great Question!  Section 12 contains an example
of an earlier version of the Registry Format applied to
RTCP-XR Burst/Gap Metric. I wrote this entry to prove
that the format proposed at that time was needed and useful
for RTCP metrics, so *not* just for IPPM metrics (which was
the criticism at the moment).

It was a lot of work to put this entry together, so I've
been reluctant to delete this section. I suppose
it could be revised to fit the current Registry Format.
But, is there a particular RTCP metric that folks want to
see registered?  Worth discussing a bit further...

-=-=-=-=-=-=-=-

BR,
Rachel

---

From: "Huangyihong (Rachel)" <[email-masked]>
Date: Mon, 20 Nov 2017 09:46:18 +0000

Hi Al,

Sorry for the late reply. I finally got time to deal with these technical discussion emails^^. Please see inline marked with [Rachel].

BR,
Rachel

From: MORTON, ALFRED C (AL) [mailto:[email-masked]]
Sent: Saturday, November 11, 2017 11:47 AM
To: Huangyihong (Rachel); [email-masked]
Subject: RE: Comments on draft-ietf-ippm-initial-registry-05.txt

Hi Rachel,

From: ippm [mailto:[email-masked]] On Behalf Of Huangyihong (Rachel)
Sent: Tuesday, November 07, 2017 3:18 AM
To: [email-masked]<mailto:[email-masked]>
Subject: [ippm] Comments on draft-ietf-ippm-initial-registry-05.txt

Hi,

[Rachel]: A use case we are using these metrics is that to help with locating the home network wifi problems. Since wifi has some channel contention, queuing delay, and mac layer retransmission, the delay will be significant if the wifi network is not good enough. So some operators is trying to figure out what the problem is when its end user is using internet service and complain about the it. So one simple way is to compare the RTD_rev  and the normal threshold to see if the delay is too high. If it is, it may mean that the wifi network of this user is too bad.

[Rachel]: It is helpful to identify, for example, interdomain troubleshooting, to see if the problem is happening inside or outside of the area. I think performance metrics can also be used for troubleshooting, which is the common case in the real world, no?

[Rachel]: Yes, this is exactly what I mean. I agree it should be in the draft.

[Rachel]: Thanks. I'll have a look.

[Rachel]: In the past, when we were developing xrblock RFCs, it was required that we should follow the template from RFC 6390 to define the metrics. I didn't follow the history of this registry draft. How is it related to RFC6390?

>From my point of view, registering some of the metrics, e.g., delay, loss, are useful. For example, if a middlebox is able to read the RTP header, maybe it's required to collect some of the xrblock metrics, and doesn't have to use RTCP XR protocol to report it.

-=-=-=-=-=-=-=-

BR,
Rachel