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