Re: [AVTCORE] Gen-ART review of draft-ietf-avtcore-idms-09

Kevin Gross <> Mon, 10 June 2013 14:26 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 0CBFD21F93E5 for <>; Mon, 10 Jun 2013 07:26:16 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: 0.186
X-Spam-Status: No, score=0.186 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]
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id GWaeGs0YUnRE for <>; Mon, 10 Jun 2013 07:26:12 -0700 (PDT)
Received: from ( [IPv6:2001:558:fe2d:44:76:96:27:212]) by (Postfix) with ESMTP id 94C0321F93FB for <>; Mon, 10 Jun 2013 07:26:07 -0700 (PDT)
Received: from ([]) by with comcast id meFG1l00617UAYkAEeS6pT; Mon, 10 Jun 2013 14:26:06 +0000
Received: from ([IPv6:2607:f8b0:4001:c03::22f]) by with comcast id meS41l00x5FJP4R8ZeS5Cc; Mon, 10 Jun 2013 14:26:06 +0000
Received: by with SMTP id a13so3505636iee.20 for <multiple recipients>; Mon, 10 Jun 2013 07:26:04 -0700 (PDT)
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=JxSUwGNAiNQ+YkSrt0Qdt6RNZ1iHRyTYpqS/VnTwvsk=; b=ZjdxUDkSKhOAuU4HegUwFttzMflHo9wBF38LEkma/YyjoSU/Q2Afd1HU1GZ9g+jhDf D4OBSCtTVKs++k/XNMfzj1AbLSdttnKC2goneIp6pEW5Jsh+kWATrkRopo+T8FLHNv5h GRXLhycYFQniMHtzzyyGl0bw9gpSgcuCS7JAmzuLk1A12ET8i+UdR864VBj3bXBpJjSY Zq0eifmE5YLKa32OgZhEhVWOM6gIAk4sFlglPtZHOTXKiQZ0i7pBy4Z20k2OEsQbaNt8 V7lQAnzcTsKbCd1/Lg3XzAocSwKfBSXhvEAQspDRkAQMyxlH//9ebDKnUH/p/1KoGE2x kGKA==
MIME-Version: 1.0
X-Received: by with SMTP id ou4mr3868419icb.53.1370874364796; Mon, 10 Jun 2013 07:26:04 -0700 (PDT)
Received: by with HTTP; Mon, 10 Jun 2013 07:26:04 -0700 (PDT)
In-Reply-To: <>
References: <> <>
Date: Mon, 10 Jun 2013 08:26:04 -0600
Message-ID: <>
From: Kevin Gross <>
To: "Brandenburg, R. (Ray) van" <>
Content-Type: multipart/alternative; boundary="bcaec50dc32c8bcb4004decd8f9c"
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=q20121106; t=1370874366; bh=JxSUwGNAiNQ+YkSrt0Qdt6RNZ1iHRyTYpqS/VnTwvsk=; h=Received:Received:Received:MIME-Version:Received:Date:Message-ID: Subject:From:To:Content-Type; b=rNJ02E3PeQ/O/3Nx5cILUjm+6BESWPgy+EEa90QsSTR5YLus0/uJqz9IymmWe78e0 tTx/0fbXUXcxgALvvJpQAtSMBxsYUoD6a+5PFfoVc5G6yhOIHHNeYzLS+Qce0gqwHm jiImP4EhQLQR/6eMYf8x5Cs3t1eRebnPzZ9c5xd88zriKLIeUv8Yu9zBCNObqbmrIv aLajIkEP5HVWEgD6moYSwohS0w3FVg0IWTNHaDFdFPvN7JVKQ7PK/Ciq2Cjgl8QR19 HzyS0gU2evuxpW+AW8t+AjgsDdCPQ4niDWwye816LKX4/x5mzjo6d4aaRIqr5mY/NI FzKKox37UnJzQ==
Cc: "Romascanu, Dan (Dan)" <>, General Area Review Team <>, "" <>, "" <>
Subject: Re: [AVTCORE] Gen-ART review of draft-ietf-avtcore-idms-09
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Audio/Video Transport Core Maintenance <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Mon, 10 Jun 2013 14:26:16 -0000

Dan, thanks for looking at this.

As a co-author, I'll weigh in on a couple of things that Ray did not

Kevin Gross
Media Network Consultant
AVA Networks - <>,

On Mon, Jun 10, 2013 at 2:33 AM, Brandenburg, R. (Ray) van <> wrote:

> -----Original Message-----
> From: Romascanu, Dan (Dan) []
> Sent: zondag 9 juni 2013 9:53
> To: General Area Review Team
> Cc:
> Subject: Gen-ART review of draft-ietf-avtcore-idms-09
> (resending, I mis-spelled .all address at the first try)
> I am the assigned Gen-ART reviewer for this draft. For background on
> Gen-ART, please see the FAQ at
> <>.
> Please resolve these comments along with any other Last Call comments you
> may receive.
> Document: draft-ietf-avtcore-idms-09
> Reviewer: Dan Romascanu
> Review Date: 6/6/13
> IETF LC End Date: 6/11/13
> IESG Telechat date:
> Summary:
> Not Ready
> Major issues:
> 5. In Section 8:
>    Because RTP
>    timestamps do wrap around, the sender of this packet SHOULD use
>    recent values, i.e. choose NTP timestamps that reflect current time
>    and not too far in the future or in the past.
> Why a SHOULD here and not a MUST? If there are any cases of exception they
> need to be detailed.
> [Ray: I will check with my co-authors]

[Kevin] Devices that receive these reports need to deal with rollover
conditions both for the RTP timestamp (which can rollover a couple times a
day) and the NTP timestamp (which will have its first rollover in 2036). I
believe these requirements are already stated in RFC3550 and RFC5905
respectively. The suggestion to use recent timestamps in reporting reduces
statistical chance that a receiving device will need to do extra
computation required to handle an RTP rollover. There's no way to eliminate
this possibility altogether and the requirement is stated in a qualitative
way and so could not be enforced as a MUST.

> 6. In Section 8:
>    This SHOULD relate to the first
>    arriving RTP packet containing this particular RTP timestamp, in case
>    multiple RTP packets contain the same RTP timestamp.
> Why a SHOULD here and not a MUST? If there are any cases of exception they
> need to be detailed.
> [Ray: I will check with my co-authors]

[Kevin] This is an issue that the authors discussed at length and for which
we do not believe there is an optimal solution and so we were reluctant to
require our recommendation. Ideally we want an NTP timestamp indicating
when all data required to render the specified RTP timestamp has arrived.
For this we'd really like to know when the last packet for an RTP timestamp
arrived. In the presence packet loss and reordering, it is not possible to
reliably record the last packet. It is possible to record the first packet
and so this is our recommendation. The accuracy of arrival times is not so
critical in IDMS as arrival time allows a less precise synchronization than
presentation times.