Re: Review of draft-ietf-mpls-residence-time-13
Robert Sparks <rjsparks@nostrum.com> Wed, 15 February 2017 15:49 UTC
Return-Path: <rjsparks@nostrum.com>
X-Original-To: ietf@ietfa.amsl.com
Delivered-To: ietf@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EB4AE1294FA; Wed, 15 Feb 2017 07:49:42 -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=unavailable 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 d8tZ9jlIxlgO; Wed, 15 Feb 2017 07:49:41 -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 A27F5129630; Wed, 15 Feb 2017 07:43:02 -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 v1FFh0Sd047339 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128 verify=NO); Wed, 15 Feb 2017 09:43:01 -0600 (CST) (envelope-from rjsparks@nostrum.com)
X-Authentication-Warning: raven.nostrum.com: Host [47.186.26.91] claimed to be unescapeable.local
Subject: Re: Review of draft-ietf-mpls-residence-time-13
To: Greg Mirsky <gregimirsky@gmail.com>
References: <148702270016.25055.10297552659599192833.idtracker@ietfa.amsl.com> <CA+RyBmWaTBNzycSyEu8BLCZA3jF2t-_vy3chosvrmurkamNEfQ@mail.gmail.com>
From: Robert Sparks <rjsparks@nostrum.com>
Message-ID: <a812b604-89b0-b741-4ea8-e518259dbb17@nostrum.com>
Date: Wed, 15 Feb 2017 09:43:00 -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+RyBmWaTBNzycSyEu8BLCZA3jF2t-_vy3chosvrmurkamNEfQ@mail.gmail.com>
Content-Type: multipart/alternative; boundary="------------8A6A2E153845792501B20E33"
Archived-At: <https://mailarchive.ietf.org/arch/msg/ietf/IUh5cyjsWspT5l2or-Wzw_23jwI>
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>
X-BeenThere: ietf@ietf.org
X-Mailman-Version: 2.1.17
Precedence: list
List-Id: IETF-Discussion <ietf.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/ietf>, <mailto:ietf-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/ietf/>
List-Post: <mailto:ietf@ietf.org>
List-Help: <mailto:ietf-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/ietf>, <mailto:ietf-request@ietf.org?subject=subscribe>
X-List-Received-Date: Wed, 15 Feb 2017 15:49:43 -0000
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".) > >
- Review of draft-ietf-mpls-residence-time-13 Robert Sparks
- Re: Review of draft-ietf-mpls-residence-time-13 Greg Mirsky
- Re: Review of draft-ietf-mpls-residence-time-13 Greg Mirsky
- Re: Review of draft-ietf-mpls-residence-time-13 Robert Sparks
- Re: Review of draft-ietf-mpls-residence-time-13 Greg Mirsky
- Re: Review of draft-ietf-mpls-residence-time-13 Robert Sparks
- Re: Review of draft-ietf-mpls-residence-time-13 Greg Mirsky
- Re: Review of draft-ietf-mpls-residence-time-13 Robert Sparks
- Re: Review of draft-ietf-mpls-residence-time-13 Greg Mirsky