Re: [ippm] AD Review #2 of RFC8889bis

[Giuseppe Fioccola <[e-mail]>]

Hi Martin,
Thanks for your review.
I can update RFC8889bis as well in the next few days.

Please find my answers inline tagged as [GF]

Regards,

Giuseppe


From: Martin Duke <[e-mail]>
Sent: Wednesday, February 16, 2022 1:10 AM
To: [e-mail]; IETF IPPM WG <[e-mail]>
Subject: AD Review #2 of RFC8889bis

Giuseppe,

Only two new issues with this one:

1) The formula for L in section 7 is not exactly wrong, but it is very oddly expressed.

(a) In 8321 you introduce the value A, which is the maximum clock skew between the two nodes. Together with the path delay, this provides the lower bound for L.

In 8889, you introduce m as the maximum divergence between marking nodes, but the text says this is not clock skew but a result of the nodes being "overloaded". I don't know if overloading is a concern or not, but if it is, clearly it is an issue in the point-to-point case as well!

It would be better if all skew issues -- both clock and overloading -- were brought into a single quantity A. I don't see any reason that marking nodes would have different properties than counting nodes[1], so why not use the same value?

IIUC, 8321 and 8889 should have the same constraints on L -- the worst-case for clock skew is the same for both.

[GF]: Yes, we can keep it simple and use the same constraints on L. I agree that the additional mismatch between the marking nodes can simply be incorporated into A. I will revise the text accordingly.

(b) A question I don't know the answer to: is 3 standard deviations really enough in the multipoint case? If there are thousands of possible paths and a few of them are quite a bit longer, won't that introduce many errors? This isn't a single entity you're sampling, but a heterogenous set of paths. Is there a reason to think this is a normal distribution?

[GF]: We can assume that the multiple paths behaviors can still be represented by distinct normal distributions. In this case, the combination of normal distributions can result in a new normal distribution. So, we can say that the range of 3 standard deviations is still valid under this assumption.

(2) The delay measurement section is vague about one-way vs. two-way delay. Is two-way delay meaningful in a multipath environment?

[GF]: Yes I can add more considerations in section 8. In case of delay measurements on the basis of multipoint paths, the one-way delay value is representative of an entire multipoint path and you can calculate the two-way delay by summing the one-way delays of the two directions, as we do for RFC8321. While, in case of delay measurements on a single-packet basis (e.g. double marking or hashing), it is always possible but it is not immediate since you have to couple the measurement on each single path with the opposite direction. In this case the NMS can do the calculation.

****

These seem like the sort of questions that would be answered by implementation and deployment experience. How do we set L? What times of delay measurement are viable? If 8889 doesn't have enough deployment to answer these questions, maybe it's not ready for PS?

[GF]: RFC8889 has enough implementation and deployment experience as RFC8321. So it is ready for PS since it is the natural extension of RFC8321 for multipoint scenarios. If you find it useful, I can add a section about the "Results of the Multipoint Alternate Marking Experiment", similarly to RFC8321.

Martin

[1] In the multipoint case, the distinction between marking nodes and egress nodes seems artificial -- the diagrams seem to envision traffic going from left to right, but of course it should be traveling in all directions!

[GF]: To simplify the explanation, we considered one way but, of course, it is always two way. I can highlight this point in the next version.