Re: [AVTCORE] Comments on draft-ietf-avtcore-clksrc-03

Kevin Gross <kevin.gross@avanw.com> Sun, 05 May 2013 03:29 UTC

Return-Path: <kevin.gross@avanw.com>
X-Original-To: avt@ietfa.amsl.com
Delivered-To: avt@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 04EA921F96C3 for <avt@ietfa.amsl.com>; Sat, 4 May 2013 20:29:10 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: 0.542
X-Spam-Level:
X-Spam-Status: No, score=0.542 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FH_RELAY_NODNS=1.451, FM_FORGED_GMAIL=0.622, HELO_MISMATCH_NET=0.611, HTML_MESSAGE=0.001, RDNS_NONE=0.1, SARE_SUB_6CONS_WORD=0.356]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id pQg8Zw4euaJ0 for <avt@ietfa.amsl.com>; Sat, 4 May 2013 20:29:05 -0700 (PDT)
Received: from qmta01.emeryville.ca.mail.comcast.net (qmta01.emeryville.ca.mail.comcast.net [IPv6:2001:558:fe2d:43:76:96:30:16]) by ietfa.amsl.com (Postfix) with ESMTP id C65D421F96C0 for <avt@ietf.org>; Sat, 4 May 2013 20:29:05 -0700 (PDT)
Received: from omta23.emeryville.ca.mail.comcast.net ([76.96.30.90]) by qmta01.emeryville.ca.mail.comcast.net with comcast id Y3FR1l00C1wfjNsA13V5JF; Sun, 05 May 2013 03:29:05 +0000
Received: from mail-ie0-x229.google.com ([IPv6:2607:f8b0:4001:c03::229]) by omta23.emeryville.ca.mail.comcast.net with comcast id Y3V41l00F4jVWYZ8j3V4V2; Sun, 05 May 2013 03:29:04 +0000
Received: by mail-ie0-f169.google.com with SMTP id u16so1748724iet.0 for <avt@ietf.org>; Sat, 04 May 2013 20:29:04 -0700 (PDT)
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:x-received:in-reply-to:references:date:message-id :subject:from:to:cc:content-type; bh=Snw44jjDDJydZFFRQC/FiVo85iE+a2KDWniZQYlZIT4=; b=VSMQBHTx5HbuMIx7pz+T02aGVYQBeESFxlCq2clWqh4r5uILiuaPJIHwwo7yymXAe1 4NBip1k2xQIBpO+lY5PbSct7HgxXQDuCuZA/BTc6wEQhVksTEbb6Oq0E5fVPL2nRseDP KqpccLMTrWthlR0ttPOydN9HkwbaPvr1D995Tox5OX+foxBE8iu9TwlPYq0lP2TF9ZkS p8Rk0BcV9Wr5S3UMQ0L9SYc6zUP83ommoiVpmDOrXEDVxkNv+7QTZifPeqkp+/u2p2XY ARJMNjrlCoALqCcrhX+hg+H+NF/yvh8gMwIXQWvbkj4BuBb8BBQlCctL1SCkSRAAzkKY a3iw==
MIME-Version: 1.0
X-Received: by 10.50.92.69 with SMTP id ck5mr1127699igb.107.1367724544190; Sat, 04 May 2013 20:29:04 -0700 (PDT)
Received: by 10.50.180.201 with HTTP; Sat, 4 May 2013 20:29:03 -0700 (PDT)
In-Reply-To: <517636E0.2020607@ericsson.com>
References: <5163DF09.7050606@ericsson.com> <CALw1_Q08JKDV9W8yCiTa_+thX1NodzUojbrPjTzt4vAR9wKLrw@mail.gmail.com> <517636E0.2020607@ericsson.com>
Date: Sat, 04 May 2013 21:29:03 -0600
Message-ID: <CALw1_Q3cAy3-9xHGQ0xOoig3ZCiP_O-4rDf0_nndCY2pMwxXrA@mail.gmail.com>
From: Kevin Gross <kevin.gross@avanw.com>
To: Magnus Westerlund <magnus.westerlund@ericsson.com>
Content-Type: multipart/alternative; boundary="047d7b10d03d9b744c04dbf02f15"
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=comcast.net; s=q20121106; t=1367724545; bh=Snw44jjDDJydZFFRQC/FiVo85iE+a2KDWniZQYlZIT4=; h=Received:Received:Received:MIME-Version:Received:Date:Message-ID: Subject:From:To:Content-Type; b=YGvyWXEbZUkqkADv1HkVnvfc6i5sG0cGJatQVvNq2ixalcH9ppUw6cbTuFj/YahL/ BYJVTbvgoqzg28POXEe1uizzGBJfL6YJIDks9OG05Dv8ss0XUtVVe8Dwut/jvaSSKg tVfOq/tcgVIZ2E0RcYNH9aTUewKKxshb6+HUsLo6WnuPkTxk3PfoD7wCXIjK19kNEl h+iuFGppftz4mS9JzCe8EFBpVaZTSaYLwDKI4E28xr+48uT7/hIRXCyqpQeWVAdr5Z HFoKYqS/Y3jzxFAj2g9YvvrFXkX/2s2BVXe5RHSX9AX5y87TKytmxOVmCJ61E9FbCi 2e4O4RnFhqZDQ==
Cc: IETF AVTCore WG <avt@ietf.org>
Subject: Re: [AVTCORE] Comments on draft-ietf-avtcore-clksrc-03
X-BeenThere: avt@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Audio/Video Transport Core Maintenance <avt.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/avt>, <mailto:avt-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/avt>
List-Post: <mailto:avt@ietf.org>
List-Help: <mailto:avt-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/avt>, <mailto:avt-request@ietf.org?subject=subscribe>
X-List-Received-Date: Sun, 05 May 2013 03:29:10 -0000

Magnus,

I believe what we have defined in the draft is the declarative model you
have minimally requested. I believe this gives more functionality than
you're assuming it does. When used on an engineered network, there will
generally be a well-known time source and as such, offers will be
compatible with answers. When used on less constrained networks, devices
may use a "traceable" clock where the specifics of the exact source of the
clock do not need to be exactly matched to make a successful connection.

You appear to be proposing that we invent our own multiple-choice
negotiation scheme. In writing the offer-answer description I assumed that
it would be preferable to use an existing and general scheme for this than
new attribute-specific SDP syntax and semantics. Is there something I am
missing? I appreciate that we can't assume all user agents will implement
RFC 5939 but 5939 is backwards compatible with a declarative fallback mode
for those agents.

RFC 5939 allows you to specify potential configurations as a collected set
of alternate attributes in the pcfg statements (section 3.5.1). The pcfg
syntax is rich enough to express potential interdependency
between reference and media clock attributes.

Kevin Gross
+1-303-447-0517
Media Network Consultant
AVA Networks - www.AVAnw.com <http://www.avanw.com/>, www.X192.org


On Tue, Apr 23, 2013 at 1:23 AM, Magnus Westerlund <
magnus.westerlund@ericsson.com> wrote:

> On 2013-04-18 00:41, Kevin Gross wrote:
> > Magnus,
> >
> > Thanks for looking at this and sorry for the delay responding.
> >
> > I agree that mediaclk-ext is too restrictive. Your suggestion is
> > very accommodating  Something a bit more structured such as 'token "="
> > byte-string' might be more appropriate. I will check with my co authors
> > on this.
>
> Sure.
>
> >
> > As there is great precedent for it in SDP, we have implemented a simple
> > offer-answer model. I would propose that systems should use the
> > mechanisms defined in RFC 5939 if negotiation of clock configurations is
> > necessary. Perhaps adding some discussion and a reference to this RFC
> > would help.
>
> Yes, there are precedence for simple models. However, I think yours are
> over simplified and has unclear goals. Can you please comment on which
> of the goals I discuss below that you see needs to be meet? I think a
> purely declarative model would be better than what you have now, that
> would at least allow the answer to say, I use X when X is different from
> what is in the offer.
>
> When it comes to CAPNEG that is clearly a possible road, but likely will
> result that almost no one can actually determine your capability for
> clock sources. Instead they will be stuck with the your current proposal.
>
> I think even going to the model that the answer picks one for both out
> of the offerers capabilities would be better. That would at least enable
> the highest likelihood that both would use the same clocks.
>
> >
> > I don't think that independently negotiating reference and media clocks
> > as you have suggested will be adequate. Under some implementations,
> > while multiple clocks are supported, certain combinations of media and
> > reference clocks may not be allowed.
>
> Okay, that is an additional requirement. Which, might not even work well
> with CAPNEG. You will have two independent attributes that actually have
> dependencies. What you say, you appear to indicate that from each side
> you can have restrictions like this: This media-ref clock can only be
> used given that your wall clock source is either of these.
>
> Cheers
>
> Magnus
>
>