Re: [mpls] Review of draft-ietf-mpls-residence-time-13
Greg Mirsky <gregimirsky@gmail.com> Wed, 22 February 2017 14:22 UTC
Return-Path: <gregimirsky@gmail.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 D997B129986; Wed, 22 Feb 2017 06:22:51 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.699
X-Spam-Level:
X-Spam-Status: No, score=-2.699 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com
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 xCYO-71jBVXs; Wed, 22 Feb 2017 06:22:49 -0800 (PST)
Received: from mail-oi0-x235.google.com (mail-oi0-x235.google.com [IPv6:2607:f8b0:4003:c06::235]) (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 5959F12997F; Wed, 22 Feb 2017 06:22:49 -0800 (PST)
Received: by mail-oi0-x235.google.com with SMTP id s205so2135208oif.3; Wed, 22 Feb 2017 06:22:49 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=XIgIgtg1qtkUPB8TWXfevsexZSXdwxv+QPqALa22ZRg=; b=eUy4JN3IxHRuelgIFTxIzJzyaNAkOrUwfCe15sY0VLrSmgpt7Z+OD/iEakyuVfbzyY GMXGw+U7saDsFmLsbC79pFRRXlBQBEfDvtX5UErsVwcjIOacmN2r1tOQbH1xniyjFWxH ZcelRg6/09GfUxgf25zgIVK72LHGHPjino2FdZpuUbn/TlU0/fwC95pOLjI2J3Vmgl7T nDDI+Hx1uwIDlMl+5yj0WDIj0HiDcl9L8e2HBXBh+DOxbrDJ6xyPBrhPrfFLGd9rexXk Huf74rw8KMMm4TlMNNNCSabfNdGWIvFnNXggzbUWg5uGDdyBqIIFx/jCEvpgbgz5YpJg cTKg==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=XIgIgtg1qtkUPB8TWXfevsexZSXdwxv+QPqALa22ZRg=; b=r+LYy1CggyaM+G+TZ036N38AEpVcM5Ql5QBq7ldVHTXjRbe1Y36CacxBpDn2tUumY2 7i/coWwO6etH8k9DzLlUSg6hQ3bw3D/f0KTyyjawxRiadVMEnNNcuArAGs2aNuWx/ZIs cPotmM6j+ZdE37IAox6VRN5gOD6Qs/TCf75oVqkV0JtTFHKicnlvavVH5CYnHLu10XxL X2O9R55epHdpaV6zdDPyjZersW+UQyuUa64kT/bEOgzrG8nOO/HfED7JXtHoNj4opMI6 KcpUzTrgU1SjSgXuDXIKRzrfuzh8YzjFWJRBk/KNTz0eTSHnMHPSmzIY0ych/i5y7e+2 7sVg==
X-Gm-Message-State: AMke39lnd+Pr2gg7apyjvGBRy7BVDKb570RHYKWfFRWIwDSsZl/vV+7eAKycZ94WmklQIe5an1SdQ4pOhZvfNA==
X-Received: by 10.202.239.2 with SMTP id n2mr18668278oih.157.1487773368653; Wed, 22 Feb 2017 06:22:48 -0800 (PST)
MIME-Version: 1.0
Received: by 10.157.38.211 with HTTP; Wed, 22 Feb 2017 06:22:48 -0800 (PST)
In-Reply-To: <ca75efb7-d1ba-c9c7-593b-486dd41a7171@nostrum.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> <ca75efb7-d1ba-c9c7-593b-486dd41a7171@nostrum.com>
From: Greg Mirsky <gregimirsky@gmail.com>
Date: Wed, 22 Feb 2017 06:22:48 -0800
Message-ID: <CA+RyBmV=fCrv7NfbAXZ7VPj2ngX0h-6eO6EwY7h4CiWV8PgrAQ@mail.gmail.com>
To: Robert Sparks <rjsparks@nostrum.com>
Content-Type: multipart/alternative; boundary="94eb2c0931da251a7b05491f3b6d"
Archived-At: <https://mailarchive.ietf.org/arch/msg/mpls/DffJlaOI-Ri_nDOHjGkjvJFr1yQ>
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 14:22:52 -0000
Hi Robert, agreed. Thank you for your thorough review and the most helpful comments. I'll upload the update shortly. Regards, Greg On Wed, Feb 22, 2017 at 1:09 AM, Robert Sparks <rjsparks@nostrum.com> wrote: > 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> > 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> >> 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> >>> 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>. >>>> >>>> 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".) >>>> >>>> >>> >>> >> >> > >
- [mpls] Review of draft-ietf-mpls-residence-time-13 Robert Sparks
- Re: [mpls] Review of draft-ietf-mpls-residence-ti… Greg Mirsky
- Re: [mpls] Review of draft-ietf-mpls-residence-ti… Greg Mirsky
- Re: [mpls] Review of draft-ietf-mpls-residence-ti… Robert Sparks
- Re: [mpls] Review of draft-ietf-mpls-residence-ti… Greg Mirsky
- Re: [mpls] Review of draft-ietf-mpls-residence-ti… Robert Sparks
- Re: [mpls] Review of draft-ietf-mpls-residence-ti… Greg Mirsky
- Re: [mpls] Review of draft-ietf-mpls-residence-ti… Robert Sparks
- Re: [mpls] Review of draft-ietf-mpls-residence-ti… Greg Mirsky
- Re: [mpls] Review of draft-ietf-mpls-residence-ti… Alexander Vainshtein