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

[Robert Sparks <[e-mail]>]

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