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

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. Thepoint I'm trying to convey is that the jitter is real but must beaccounted not as part of propagation delay but as residence time. HopeI'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 <rjsparks(_at_)nostrum(_dot_)com<mailto:rjsparks(_at_)nostrum(_dot_)com>> 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
    <rjsparks(_at_)nostrum(_dot_)com <mailto:rjsparks(_at_)nostrum(_dot_)com>> 
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
        <rjsparks(_at_)nostrum(_dot_)com 
<mailto:rjsparks(_at_)nostrum(_dot_)com>> 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".)