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

Robert Sparks <rjsparks@nostrum.com> Wed, 22 February 2017 09:09 UTC

Return-Path: <rjsparks@nostrum.com>
X-Original-To: mpls@ietfa.amsl.com
Delivered-To: mpls@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6C362129457; Wed, 22 Feb 2017 01:09:15 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.9
X-Spam-Level:
X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RP_MATCHES_RCVD=-0.001] autolearn=ham autolearn_force=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 7xibN_aVW40m; Wed, 22 Feb 2017 01:09:13 -0800 (PST)
Received: from nostrum.com (raven-v6.nostrum.com [IPv6:2001:470:d:1130::1]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id F2C231293DF; Wed, 22 Feb 2017 01:09:12 -0800 (PST)
Received: from unescapeable.local (2.204-14-84.ripe.coltfrance.com [84.14.204.2]) (authenticated bits=0) by nostrum.com (8.15.2/8.15.2) with ESMTPSA id v1M997Y9022800 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128 verify=NO); Wed, 22 Feb 2017 03:09:09 -0600 (CST) (envelope-from rjsparks@nostrum.com)
X-Authentication-Warning: raven.nostrum.com: Host 2.204-14-84.ripe.coltfrance.com [84.14.204.2] claimed to be unescapeable.local
To: Greg Mirsky <gregimirsky@gmail.com>
References: <148702270016.25055.10297552659599192833.idtracker@ietfa.amsl.com> <CA+RyBmWaTBNzycSyEu8BLCZA3jF2t-_vy3chosvrmurkamNEfQ@mail.gmail.com> <a812b604-89b0-b741-4ea8-e518259dbb17@nostrum.com> <CA+RyBmW8NcThCJt4WscccfTMr29JWa-7oPVaptvOdT1dgi+Q_A@mail.gmail.com> <e28d238c-f27f-6dd9-41a9-b0ff6e2fe272@nostrum.com> <CA+RyBmUzP9rDdq9un08GnY0Dzcq+0w-ty1_Fg=kGGHZ3af8JJQ@mail.gmail.com>
From: Robert Sparks <rjsparks@nostrum.com>
Message-ID: <ca75efb7-d1ba-c9c7-593b-486dd41a7171@nostrum.com>
Date: Wed, 22 Feb 2017 10:09:01 +0100
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.12; rv:45.0) Gecko/20100101 Thunderbird/45.7.1
MIME-Version: 1.0
In-Reply-To: <CA+RyBmUzP9rDdq9un08GnY0Dzcq+0w-ty1_Fg=kGGHZ3af8JJQ@mail.gmail.com>
Content-Type: multipart/alternative; boundary="------------4BA9FE9488D2E8686F0044F9"
Archived-At: <https://mailarchive.ietf.org/arch/msg/mpls/XRFGvhz6Lvkj8MkTzwXrvwjW3AM>
Cc: "mpls@ietf.org" <mpls@ietf.org>, "gen-art@ietf.org" <gen-art@ietf.org>, draft-ietf-mpls-residence-time.all@ietf.org, "ietf@ietf.org" <ietf@ietf.org>
Subject: Re: [mpls] Review of draft-ietf-mpls-residence-time-13
X-BeenThere: mpls@ietf.org
X-Mailman-Version: 2.1.17
Precedence: list
List-Id: Multi-Protocol Label Switching WG <mpls.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/mpls>, <mailto:mpls-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/mpls/>
List-Post: <mailto:mpls@ietf.org>
List-Help: <mailto:mpls-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/mpls>, <mailto:mpls-request@ietf.org?subject=subscribe>
X-List-Received-Date: Wed, 22 Feb 2017 09:09:15 -0000

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 <rjsparks@nostrum.com 
> <mailto:rjsparks@nostrum.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@nostrum.com <mailto:rjsparks@nostrum.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@nostrum.com <mailto:rjsparks@nostrum.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".)
>>>
>>>
>>
>>
>
>