Re: [TICTOC] Enterprise profile update

Kevin Gross <kevin.gross@avanw.com> Mon, 07 April 2014 06:01 UTC

Return-Path: <kevin.gross@avanw.com>
X-Original-To: tictoc@ietfa.amsl.com
Delivered-To: tictoc@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 338581A0376 for <tictoc@ietfa.amsl.com>; Sun, 6 Apr 2014 23:01:31 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: 1.401
X-Spam-Level: *
X-Spam-Status: No, score=1.401 tagged_above=-999 required=5 tests=[BAYES_20=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, SPF_NEUTRAL=0.779] autolearn=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 iUWY7J_g5MJi for <tictoc@ietfa.amsl.com>; Sun, 6 Apr 2014 23:01:27 -0700 (PDT)
Received: from qmta07.emeryville.ca.mail.comcast.net (qmta07.emeryville.ca.mail.comcast.net [IPv6:2001:558:fe2d:43:76:96:30:64]) by ietfa.amsl.com (Postfix) with ESMTP id 41CF11A0229 for <tictoc@ietf.org>; Sun, 6 Apr 2014 23:01:27 -0700 (PDT)
Received: from omta07.emeryville.ca.mail.comcast.net ([76.96.30.59]) by qmta07.emeryville.ca.mail.comcast.net with comcast id mu1B1n0051GXsucA7u1NUC; Mon, 07 Apr 2014 06:01:22 +0000
Received: from mail-yh0-f42.google.com ([209.85.213.42]) by omta07.emeryville.ca.mail.comcast.net with comcast id mtzM1n0050vSxq98UtzNWc; Mon, 07 Apr 2014 05:59:22 +0000
Received: by mail-yh0-f42.google.com with SMTP id t59so5469295yho.1 for <tictoc@ietf.org>; Sun, 06 Apr 2014 22:59:21 -0700 (PDT)
MIME-Version: 1.0
X-Received: by 10.236.76.105 with SMTP id a69mr10280317yhe.8.1396850361549; Sun, 06 Apr 2014 22:59:21 -0700 (PDT)
Received: by 10.170.216.213 with HTTP; Sun, 6 Apr 2014 22:59:21 -0700 (PDT)
In-Reply-To: <20140405133748.GB4566@netboy>
References: <CACQYgzE106JaKArgc=3HKkKcrdvSy5PmK-A0=_ZMdfrFUJbrtQ@mail.gmail.com> <20140405112034.GM22106@netboy> <20140405133748.GB4566@netboy>
Date: Sun, 06 Apr 2014 23:59:21 -0600
Message-ID: <CALw1_Q3hNRNpHzQ=1z0XRTqvcvm2W7=Gm_ZWa2UJT-BqYTvmZw@mail.gmail.com>
From: Kevin Gross <kevin.gross@avanw.com>
To: Richard Cochran <richardcochran@gmail.com>
Content-Type: multipart/alternative; boundary="20cf303ea7129ac94c04f66d9114"
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=comcast.net; s=q20140121; t=1396850482; bh=1E0IsVuurn3CGlO+OSEGyHn7NGTlcdYdfyBn5OBAtkM=; h=Received:Received:Received:MIME-Version:Received:Date:Message-ID: Subject:From:To:Content-Type; b=O7qVC1T5siSq1UKhzFdGv8qdqocUG0DfpOeKOECVP+z5eQXFYy6V7aCa5lPp8rcNt ExNMIP4wB6AWHKPTHA8BUU43yaYfRkSp2HZXvE1fmlQgiOHc1V7AjPkW/HdFCsfITs ZRhOqOiOVc94l1yY4xByqlZhXTEG58NuSs0mCauWv476SemSGZPy1cx/uZSZLIqc7s LVex3hG01oQbZsXiVawNwLRUm5Lsg7bnst4STXo0GyB9Y0kReEpBoG2CLqyn81Hqn6 +OPRH688VuMHIr1uKSbDHROVmtMtIiMhPagWYLR7XPVs9wLSpQElUCIMjnyw0kWkcO AS6oOL+s7dPJw==
Archived-At: http://mailarchive.ietf.org/arch/msg/tictoc/FZaPLyPL8jq36X7YnFvg2DYplAQ
Cc: "tictoc@ietf.org" <tictoc@ietf.org>
Subject: Re: [TICTOC] Enterprise profile update
X-BeenThere: tictoc@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: Timing over IP Connection and Transfer of Clock BOF <tictoc.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/tictoc>, <mailto:tictoc-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/tictoc/>
List-Post: <mailto:tictoc@ietf.org>
List-Help: <mailto:tictoc-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/tictoc>, <mailto:tictoc-request@ietf.org?subject=subscribe>
X-List-Received-Date: Mon, 07 Apr 2014 06:01:31 -0000

I can't remember if this was discussed in TICTOCK yet. Apologies if I'm
bringing up a settled point.

I appreciate the scalability of unicast delay request/response but I want
to make sure everyone is aware of a hazard with hybrid mode. On some
networks, unicasts and multicasts are delivered through separate network
paths. On these networks, half the round trip delay of a delay
request/response unicast exchange will not be a good estimate of sync
multicast propagation time.

It may be best to leave a multicast delay request/response option for
devices that need higher accuracy or want to have the option to compare
unicast and multicast delay request/response performance to determine
whether hybrid mode is viable on the network they are connected through.

Kevin Gross - AVA Networks


On Sat, Apr 5, 2014 at 7:37 AM, Richard Cochran <richardcochran@gmail.com>wrote:

> On Sat, Apr 05, 2014 at 01:20:35PM +0200, Richard Cochran wrote:
> > Doug,
> >
> > On Wed, Mar 12, 2014 at 12:41:33PM -0700, Douglas Arnold wrote:
> >
> > > 1. Elimination of the Unicast only and Multicast only modes of
> operation.
> > >  The only mode of operation is the hybrid multicast/unicast mode.  In
> this
> > > mode the master sends sync and announce as multicast, and it responds
> to
> > > delay request messages "in kind".  In other words a delay response is
> > > unicast if the delay requests is unicast, and multicast if the delay
> > > requests is multicast.
> >
> > Nice. This idea makes way more sense than the unicast option in 1588,
> > IMHO.
>
> On second thought, why doesn't this profile simply say that slaves may
> use 1588 section 16.1 to negotiate unicast Delay_Resp messages?
>
> As is, this profile mandates behavior WRT unicast that isn't really
> allowed by 1588, unless you say that it falls under the very vague and
> open ended 7.3.1 clause.
>
> I would prefer the common sense unicast handling in your profile, but
> unfortunately 1588 already specifies something else.
>
> Thanks
> Richard
>
> _______________________________________________
> TICTOC mailing list
> TICTOC@ietf.org
> https://www.ietf.org/mailman/listinfo/tictoc
>