[AVT] Review of draft-brandenburg-avt-rtcp-for-idms-02

"Ali C. Begen (abegen)" <abegen@cisco.com> Wed, 24 November 2010 18:59 UTC

Return-Path: <abegen@cisco.com>
X-Original-To: avt@core3.amsl.com
Delivered-To: avt@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id E76E03A6996 for <avt@core3.amsl.com>; Wed, 24 Nov 2010 10:59:10 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -10.597
X-Spam-Level:
X-Spam-Status: No, score=-10.597 tagged_above=-999 required=5 tests=[AWL=0.002, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id y756mcNhvYmf for <avt@core3.amsl.com>; Wed, 24 Nov 2010 10:59:09 -0800 (PST)
Received: from sj-iport-5.cisco.com (sj-iport-5.cisco.com [171.68.10.87]) by core3.amsl.com (Postfix) with ESMTP id 0F2D23A6998 for <avt@ietf.org>; Wed, 24 Nov 2010 10:59:08 -0800 (PST)
Authentication-Results: sj-iport-5.cisco.com; dkim=neutral (message not signed) header.i=none
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: AlsFAH7v7EyrR7Ht/2dsb2JhbACUfo4GcaNem0CFRwSEW4ka
X-IronPort-AV: E=Sophos;i="4.59,249,1288569600"; d="scan'208";a="291978461"
Received: from sj-core-1.cisco.com ([171.71.177.237]) by sj-iport-5.cisco.com with ESMTP; 24 Nov 2010 19:00:07 +0000
Received: from xbh-sjc-221.amer.cisco.com (xbh-sjc-221.cisco.com [128.107.191.63]) by sj-core-1.cisco.com (8.13.8/8.14.3) with ESMTP id oAOJ0ANh028971; Wed, 24 Nov 2010 19:00:10 GMT
Received: from xmb-sjc-215.amer.cisco.com ([171.70.151.169]) by xbh-sjc-221.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.4675); Wed, 24 Nov 2010 11:00:06 -0800
X-MimeOLE: Produced By Microsoft Exchange V6.5
Content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
Date: Wed, 24 Nov 2010 11:00:05 -0800
Message-ID: <04CAD96D4C5A3D48B1919248A8FE0D540DBBA920@xmb-sjc-215.amer.cisco.com>
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
Thread-Topic: Review of draft-brandenburg-avt-rtcp-for-idms-02
Thread-Index: AcuMAnQnWqEiqys8TQGThffTPwQOjA==
From: "Ali C. Begen (abegen)" <abegen@cisco.com>
To: draft-brandenburg-avt-rtcp-for-idms@tools.ietf.org
X-OriginalArrivalTime: 24 Nov 2010 19:00:06.0761 (UTC) FILETIME=[CF1D9D90:01CB8C09]
Cc: avt@ietf.org
Subject: [AVT] Review of draft-brandenburg-avt-rtcp-for-idms-02
X-BeenThere: avt@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: Audio/Video Transport Working Group <avt.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/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: Wed, 24 Nov 2010 18:59:11 -0000

I have several editorial and architectural comments.

Abstract: "watching apart together" . Is this a common term?

Section 1.2: 
First para.: RTCP is supposed to be used whenever RTP is used. So saying they are typically used in conjunction is misleading.

Third para.: Put "respectively" after [RFC3550].

Section 1.3:
Put  a reference for RFC 4566.

Section 4:
First para.: The reference for "Feedback Target" should be 5760 not 3550.

The "shall" requirement in Block Type and Reserved Bits should be "SHALL".

Page 7 (top): The reference for RTP/RTCP is 3550 not 3611.

Payload Type field is said to use the types from 3551. And you assume each type has a certain clock rate. But most applications use dynamic payload types and for them you need to get the clock rate from the SDP itself.

Packet Presented NTP timestamp: I really don't know how you could know this information. In the RTP plane, you can only know when you delivered the packet to higher layer. But that has nothing to do with when it will be decoded/displayed/played/etc. Even if we try to synch the times that a packet is delivered to the higher layer, shall we assume everybody runs the same hardware with the same configuration so that the chances of having all the viewers seeing the same content are somewhat >0?

Beyond that, another question I have is that what happens when a viewer detects that it is running ahead of other viewers. What does he do? Slow down, stop for a while? Similarly, if one is lagging behind, how we do make him go faster to catch up with others (more accurately to the reference point determined by the MSAS)?

Even if we make this work, there could be very funny attacks that even friends can run against each other. In Section 6, you mention a threshold of 10 seconds, but to me even that is very high for most apps.

Finally, when there are multiple temporally correlated streams (audio + video) that are transmitted in separate RTP streams, I guess you run this stuff only for one of them. Correct? 

-acbegen