ietf
[Top] [All Lists]

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

2017-02-15 13:15:56


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".)