Subject: [mpls] Review of draft-ietf-mpls-residence-time-13

From: Robert Sparks <[email-masked]>
Date: Mon, 13 Feb 2017 13:51:40 -0800

Reviewer: Robert Sparks
Review result: Ready

I am the assigned Gen-ART reviewer for this draft. The General Area
Review Team (Gen-ART) reviews all IETF documents being processed
by the IESG for the IETF Chair. Please wait for direction from your
document shepherd or AD before posting a new version of the draft.

For more information, please see the FAQ at

<https://trac.ietf.org/trac/gen/wiki/GenArtfaq>.

Document: draft-ietf-mpls-residence-time-13
Reviewer: Robert Sparks
Review Date: 2017-02-13
IETF LC End Date: 2017-01-17
IESG Telechat date: 2017-03-02

Summary: Ready for publication as PS

Thanks for addressing my comments.
(I still think some discussion about taking arrival and departure time
measurements would be helpful, even if it only said "do it
consistently so you don't indicate jitter that's not really there".)

---

From: Greg Mirsky <[email-masked]>
Date: Mon, 13 Feb 2017 17:02:44 -0800

Hi Robert,
thank you for your review and patience as we've been working on the
document. The text you've proposed is indeed useful to implementer and I'll
add it with the next update.

Regards,
Greg

---

From: Greg Mirsky <[email-masked]>
Date: Tue, 14 Feb 2017 20:06:36 -0800

Hi Robert,
Section 5 Data Plane Theory of Operation has the following recommendation
on reading time value at ingress and egress:

   Each RTM-capable
   node on the explicit path receives an RTM packet and records the time
   at which it receives that packet at its ingress interface as well as
   the time at which it transmits that packet from its egress interface;
   this should be done as close to the physical layer as possible to
   ensure precise accuracy in time determination.

Do you find the text sufficient in providing guidance to an implementer of RTM?

Regards,

Greg

---

From: Robert Sparks <[email-masked]>
Date: Wed, 15 Feb 2017 09:43:00 -0600

On 2/14/17 10:06 PM, Greg Mirsky wrote:
> Hi Robert,
> Section 5 Data Plane Theory of Operation has the following 
> recommendation on reading time value at ingress and egress:
>     Each RTM-capable
Well, no - that was point in the text from my review of -12 that caused 
me to make comment in the first place.

What does "precise accuracy" even _MEAN_? You're waving your hands with 
words that don't help the reader guess what you mean at the moment. The 
subsequent email exchange said the important part was that you measure 
_precisely_ (in that the measurements are always taken the same way), 
but accuracy isn't that important (you've (and here by "you" I mean the 
set of people that have responded to the review") told me it's not 
important whether the reading is taken at the beginning of the 
bit-stream, the end, or several 1000 nanoseconds after the last bit came 
off the physical media as long as it's done the same way for each 
packet). The fact that you're carrying a measurement that can talk about 
times smaller than the interarrival time for individual bits for some 
real world line speeds says that different implementations taking the 
measurement different ways is going to result in different residence 
time measurements, even if the residence time was really identical. 
You've told me that's not important to the protocol using the 
measurement as long as the an individual implementation doesn't 
introduce something that will look to the using protocol like jitter 
that's not really there.

The text does not say that to an implementer right now.

To restate that long paragraph with maybe a longer one,  assume a 
simplified world where everything is perfectly constant. Packets are all 
flowing at the same size and same rate. For reference, I assert that the 
time between the first bit of a packet entering the system taking the 
measurement and the first bit of that packet leaving the system is 
exactly T (every time). You are telling me that if the system returns cT 
for some constant T other than 1 (and not necessarily  close to 1), 
everything is fine. You're also telling me that if you replace the 
system with another that preserves T, but measures differently so that 
it returns c'T where c' != c, everything is fine. The important part to 
you is that c and c' don't change for their respective systems. (That 
surprises me, I can see how the way the clocks are going to use this 
will do the right thing, but I can't help but think someone later will 
look at the difference between the two systems and say something is 
wrong with one of them). What you've told me is not fine is that if you 
drop i a third system that also preserves T but reports aT where a 
_varies_ over some range.

Have I heard you correctly?
> Regards,
> Greg
>
> On Mon, Feb 13, 2017 at 1:51 PM, Robert Sparks <[email-masked] 
> <mailto:[email-masked]>> wrote:
>
>     Reviewer: Robert Sparks
>     Review result: Ready
>
>     <https://trac.ietf.org/trac/gen/wiki/GenArtfaq
>     <https://trac.ietf.org/trac/gen/wiki/GenArtfaq>>.
>

---

From: Greg Mirsky <[email-masked]>
Date: Wed, 15 Feb 2017 09:20:55 -0800

Hi Robert,
yes, you've absolutely correct in your example. The importance of RTM is to
exclude and quantify, as much as possible, jitter from propagation delay.
I've updated the wording to reflect that. Below is new text I propose,
please let me know if it makes it clearer.

   Each RTM-capable
   node on the explicit path receives an RTM packet and records the time
   at which it receives that packet at its ingress interface as well as
   the time at which it transmits that packet from its egress interface.
   These actions should be done as close to the physical layer as
   possible at the same point of packet processing striving to avoid
   introduction of jitter in propogation delay to ensure precise
   accuracy in time determination.

Regards,

Greg

On Wed, Feb 15, 2017 at 7:43 AM, Robert Sparks <[email-masked]> wrote:

> Well, no - that was point in the text from my review of -12 that caused me
> to make comment in the first place.
>
> _precisely_ (in that the measurements are always taken the same way), but
> accuracy isn't that important (you've (and here by "you" I mean the set of
> people that have responded to the review") told me it's not important
> whether the reading is taken at the beginning of the bit-stream, the end,
> or several 1000 nanoseconds after the last bit came off the physical media
> as long as it's done the same way for each packet). The fact that you're
> carrying a measurement that can talk about times smaller than the
> interarrival time for individual bits for some real world line speeds says
> that different implementations taking the measurement different ways is
> going to result in different residence time measurements, even if the
> residence time was really identical. You've told me that's not important to
> the protocol using the measurement as long as the an individual
> implementation doesn't introduce something that will look to the using
> protocol like jitter that's not really there.
>
> measurement and the first bit of that packet leaving the system is exactly
> T (every time). You are telling me that if the system returns cT for some
> constant T other than 1 (and not necessarily  close to 1), everything is
> fine. You're also telling me that if you replace the system with another
> that preserves T, but measures differently so that it returns c'T where c'
> != c, everything is fine. The important part to you is that c and c' don't
> change for their respective systems. (That surprises me, I can see how the
> way the clocks are going to use this will do the right thing, but I can't
> help but think someone later will look at the difference between the two
> systems and say something is wrong with one of them). What you've told me
> is not fine is that if you drop i a third system that also preserves T but
> reports aT where a _varies_ over some range.
>

---

From: Robert Sparks <[email-masked]>
Date: Wed, 15 Feb 2017 13:15:28 -0600

On 2/15/17 11:20 AM, Greg Mirsky wrote:
> Hi Robert,
> yes, you've absolutely correct in your example. The importance of RTM 
> is to exclude and quantify, as much as possible, jitter from 
> propagation delay. I've updated the wording to reflect that. Below is 
> new text I propose, please let me know if it makes it clearer.
>     Each RTM-capable
perhaps change "avoid introduction of jitter" to "avoid introducing the 
appearance of jitter that's not really there"?

(I'm about to board a plane, so further responses will be very delayed).
> Regards,
> Greg
>
> On Wed, Feb 15, 2017 at 7:43 AM, Robert Sparks <[email-masked] 
>     Well, no - that was point in the text from my review of -12 that
>     caused me to make comment in the first place.
>
>     What does "precise accuracy" even _MEAN_? You're waving your hands
>     with words that don't help the reader guess what you mean at the
>     moment. The subsequent email exchange said the important part was
>     that you measure _precisely_ (in that the measurements are always
>     taken the same way), but accuracy isn't that important (you've
>     (and here by "you" I mean the set of people that have responded to
>     the review") told me it's not important whether the reading is
>     taken at the beginning of the bit-stream, the end, or several 1000
>     nanoseconds after the last bit came off the physical media as long
>     as it's done the same way for each packet). The fact that you're
>     interarrival time for individual bits for some real world line
>     speeds says that different implementations taking the measurement
>     different ways is going to result in different residence time
>     measurements, even if the residence time was really identical.
>     introduce something that will look to the using protocol like
>     jitter that's not really there.
>
>     simplified world where everything is perfectly constant. Packets
>     are all flowing at the same size and same rate. For reference, I
>     assert that the time between the first bit of a packet entering
>     the system taking the measurement and the first bit of that packet
>     leaving the system is exactly T (every time). You are telling me
>     that if the system returns cT for some constant T other than 1
>     (and not necessarily  close to 1), everything is fine. You're also
>     telling me that if you replace the system with another that
>     preserves T, but measures differently so that it returns c'T where
>     c' != c, everything is fine. The important part to you is that c
>     and c' don't change for their respective systems. (That surprises
>     me, I can see how the way the clocks are going to use this will do
>     the right thing, but I can't help but think someone later will
>     look at the difference between the two systems and say something
>     is wrong with one of them). What you've told me is not fine is
>     that if you drop i a third system that also preserves T but
>>     On Mon, Feb 13, 2017 at 1:51 PM, Robert Sparks
>>     <[email-masked] <mailto:[email-masked]>> wrote:
>>
>>         Reviewer: Robert Sparks
>>         Review result: Ready
>>

---

From: Greg Mirsky <[email-masked]>
Date: Wed, 15 Feb 2017 12:40:28 -0800

Hi Robert,
safe travel and here's another version for your consideration. The point
I'm trying to convey is that the jitter is real but must be accounted not
as part of propagation delay but as residence time. Hope I'm getting close.

   Each RTM-capable
   node on the explicit path receives an RTM packet and records the time
   at which it receives that packet at its ingress interface as well as
   the time at which it transmits that packet from its egress interface.
   To ensure precise accuracy in time determination these actions should
   be done as close to the physical layer as possible at the same point
   of packet processing striving to avoid introducing the appearance of
   jitter in propogation delay whereas it should be accounted as
   residence time.

Regards,

Greg

On Wed, Feb 15, 2017 at 11:15 AM, Robert Sparks <[email-masked]>
wrote:

> yes, you've absolutely correct in your example. The importance of RTM is
> to exclude and quantify, as much as possible, jitter from propagation
> delay. I've updated the wording to reflect that. Below is new text I
> propose, please let me know if it makes it clearer.
>
>    Each RTM-capable

---

From: Robert Sparks <[email-masked]>
Date: Wed, 22 Feb 2017 10:09:01 +0100

I would simply delete "To ensure precise accuracy in time determination" 
and start the sentence at "These actions"

RjS

On 2/15/17 9:40 PM, Greg Mirsky wrote:
> Hi Robert,
> safe travel and here's another version for your consideration. The 
> point I'm trying to convey is that the jitter is real but must be 
> accounted not as part of propagation delay but as residence time. Hope 
> I'm getting close.
>     Each RTM-capable
> On Wed, Feb 15, 2017 at 11:15 AM, Robert Sparks <[email-masked] 
>>     yes, you've absolutely correct in your example. The importance of
>>     RTM is to exclude and quantify, as much as possible, jitter from
>>     propagation delay. I've updated the wording to reflect that.
>>     Below is new text I propose, please let me know if it makes it
>>     clearer.
>>         Each RTM-capable
>     perhaps change "avoid introduction of jitter" to "avoid
>     introducing the appearance of jitter that's not really there"?
>
>>     On Wed, Feb 15, 2017 at 7:43 AM, Robert Sparks
>>         Well, no - that was point in the text from my review of -12
>>         that caused me to make comment in the first place.
>>
>>         What does "precise accuracy" even _MEAN_? You're waving your
>>         hands with words that don't help the reader guess what you
>>         mean at the moment. The subsequent email exchange said the
>>         important part was that you measure _precisely_ (in that the
>>         measurements are always taken the same way), but accuracy
>>         isn't that important (you've (and here by "you" I mean the
>>         set of people that have responded to the review") told me
>>         it's not important whether the reading is taken at the
>>         beginning of the bit-stream, the end, or several 1000
>>         nanoseconds after the last bit came off the physical media as
>>         long as it's done the same way for each packet). The fact
>>         that you're carrying a measurement that can talk about times
>>         smaller than the interarrival time for individual bits for
>>         some real world line speeds says that different
>>         implementations taking the measurement different ways is
>>         going to result in different residence time measurements,
>>         even if the residence time was really identical. You've told
>>         me that's not important to the protocol using the measurement
>>         as long as the an individual implementation doesn't introduce
>>         something that will look to the using protocol like jitter
>>         that's not really there.
>>
>>         To restate that long paragraph with maybe a longer one, 
>>         assume a simplified world where everything is perfectly
>>         constant. Packets are all flowing at the same size and same
>>         rate. For reference, I assert that the time between the first
>>         bit of a packet entering the system taking the measurement
>>         and the first bit of that packet leaving the system is
>>         exactly T (every time). You are telling me that if the system
>>         returns cT for some constant T other than 1 (and not
>>         necessarily  close to 1), everything is fine. You're also
>>         preserves T, but measures differently so that it returns c'T
>>         where c' != c, everything is fine. The important part to you
>>         is that c and c' don't change for their respective systems.
>>         (That surprises me, I can see how the way the clocks are
>>         going to use this will do the right thing, but I can't help
>>         but think someone later will look at the difference between
>>         the two systems and say something is wrong with one of them).
>>         What you've told me is not fine is that if you drop i a third
>>         system that also preserves T but reports aT where a _varies_
>>         over some range.
>>

---

From: Greg Mirsky <[email-masked]>
Date: Wed, 22 Feb 2017 06:22:48 -0800

Hi Robert,
agreed. Thank you for your thorough review and the most helpful comments.
I'll upload the update shortly.

Regards,
Greg

---

From: Alexander Vainshtein <[email-masked]>
Date: Wed, 22 Feb 2017 16:29:02 +0200

My thanks as well - to Robert for a most careful review and to Greg for
handling the draft for all these years.

Regards,
Sasha

On Feb 22, 2017 16:22, "Greg Mirsky" <[email-masked]> wrote:

>>> yes, you've absolutely correct in your example
>>>
>>>