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

[Robert Sparks <[e-mail]>]

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
>     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.
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 <[e-mail] 
> <mailto:[e-mail]>> wrote:
>
>
>
>     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
>>         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?
>     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
>>     <[e-mail] <mailto:[e-mail]>> wrote:
>>
>>         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
>>         <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".)
>>
>>
>
>