Re: [Gen-art] Review of draft-ietf-mpls-residence-time-13
Robert Sparks <rjsparks@nostrum.com> Wed, 15 February 2017 19:15 UTC
Return-Path: <rjsparks@nostrum.com>
X-Original-To: gen-art@ietfa.amsl.com
Delivered-To: gen-art@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2C2841293E0; Wed, 15 Feb 2017 11:15:34 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.899
X-Spam-Level:
X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RP_MATCHES_RCVD=-0.001, URIBL_BLOCKED=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 oQibP_bl5vs5; Wed, 15 Feb 2017 11:15:30 -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 9F9581296F2; Wed, 15 Feb 2017 11:15:30 -0800 (PST)
Received: from unescapeable.local ([47.186.26.91]) (authenticated bits=0) by nostrum.com (8.15.2/8.15.2) with ESMTPSA id v1FJFSuQ072323 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128 verify=NO); Wed, 15 Feb 2017 13:15:29 -0600 (CST) (envelope-from rjsparks@nostrum.com)
X-Authentication-Warning: raven.nostrum.com: Host [47.186.26.91] 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>
From: Robert Sparks <rjsparks@nostrum.com>
Message-ID: <e28d238c-f27f-6dd9-41a9-b0ff6e2fe272@nostrum.com>
Date: Wed, 15 Feb 2017 13:15:28 -0600
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+RyBmW8NcThCJt4WscccfTMr29JWa-7oPVaptvOdT1dgi+Q_A@mail.gmail.com>
Content-Type: multipart/alternative; boundary="------------8EF8ACD6F400BCC5968C8777"
Archived-At: <https://mailarchive.ietf.org/arch/msg/gen-art/hV2GviZqBz6wbHVIcwHqMV4t80E>
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: [Gen-art] Review of draft-ietf-mpls-residence-time-13
X-BeenThere: gen-art@ietf.org
X-Mailman-Version: 2.1.17
Precedence: list
List-Id: "GEN-ART: General Area Review Team" <gen-art.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/gen-art>, <mailto:gen-art-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/gen-art/>
List-Post: <mailto:gen-art@ietf.org>
List-Help: <mailto:gen-art-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/gen-art>, <mailto:gen-art-request@ietf.org?subject=subscribe>
X-List-Received-Date: Wed, 15 Feb 2017 19:15:34 -0000
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".) >> >> > >
- [Gen-art] Review of draft-ietf-mpls-residence-tim… Robert Sparks
- Re: [Gen-art] Review of draft-ietf-mpls-residence… Greg Mirsky
- Re: [Gen-art] Review of draft-ietf-mpls-residence… Greg Mirsky
- Re: [Gen-art] Review of draft-ietf-mpls-residence… Robert Sparks
- Re: [Gen-art] Review of draft-ietf-mpls-residence… Greg Mirsky
- Re: [Gen-art] Review of draft-ietf-mpls-residence… Robert Sparks
- Re: [Gen-art] Review of draft-ietf-mpls-residence… Greg Mirsky
- Re: [Gen-art] Review of draft-ietf-mpls-residence… Robert Sparks
- Re: [Gen-art] Review of draft-ietf-mpls-residence… Greg Mirsky
- Re: [Gen-art] Review of draft-ietf-mpls-residence… Alexander Vainshtein