[AVTCORE] ***SPAM*** 7.478 (5) Comments on draft-stokking-avtcore-idms-for-iptv-00

Kevin Gross <kevin.gross@avanw.com> Fri, 19 December 2014 18:40 UTC

Return-Path: <kevin.gross@avanw.com>
X-Original-To: avt@ietfa.amsl.com
Delivered-To: avt@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com []) by ietfa.amsl.com (Postfix) with ESMTP id 33D291A89B9 for <avt@ietfa.amsl.com>; Fri, 19 Dec 2014 10:40:19 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: YES
X-Spam-Score: 7.478
X-Spam-Level: *******
X-Spam-Status: Yes, score=7.478 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FM_FORGED_GMAIL=0.622, FRT_STOCK1=3.988, FRT_STOCK2=3.988, HTML_MESSAGE=0.001, SPF_NEUTRAL=0.779] autolearn=no
Received: from mail.ietf.org ([]) by localhost (ietfa.amsl.com []) (amavisd-new, port 10024) with ESMTP id tdujPNecJGQp for <avt@ietfa.amsl.com>; Fri, 19 Dec 2014 10:40:17 -0800 (PST)
Received: from resqmta-po-09v.sys.comcast.net (resqmta-po-09v.sys.comcast.net [IPv6:2001:558:fe16:19:96:114:154:168]) (using TLSv1.2 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id DBF7B1A1BE4 for <avt@ietf.org>; Fri, 19 Dec 2014 10:40:17 -0800 (PST)
Received: from resomta-po-07v.sys.comcast.net ([]) by resqmta-po-09v.sys.comcast.net with comcast id VWg81p00B4zp9eg01WgHeE; Fri, 19 Dec 2014 18:40:17 +0000
Received: from mail-yh0-f54.google.com ([]) by resomta-po-07v.sys.comcast.net with comcast id VWeG1p00G1Az1tM01WeHWv; Fri, 19 Dec 2014 18:38:17 +0000
Received: by mail-yh0-f54.google.com with SMTP id 29so708629yhl.27 for <avt@ietf.org>; Fri, 19 Dec 2014 10:38:17 -0800 (PST)
MIME-Version: 1.0
X-Received: by with SMTP id s24mr7783732yhs.138.1419014297096; Fri, 19 Dec 2014 10:38:17 -0800 (PST)
Received: by with HTTP; Fri, 19 Dec 2014 10:38:17 -0800 (PST)
Date: Fri, 19 Dec 2014 11:38:17 -0700
Message-ID: <CALw1_Q3NW68hf5Pr=1Za=ef0qw+sxBEaK+dk3W2_ss4jVJdLNw@mail.gmail.com>
From: Kevin Gross <kevin.gross@avanw.com>
To: "avt@ietf.org" <avt@ietf.org>, Hans Stokking <hans.stokking@tno.nl>
Content-Type: multipart/alternative; boundary="e89a8f646d931c18e0050a960310"
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=comcast.net; s=q20140121; t=1419014417; bh=zvgx/7R1Qr1HJC3Nzw1mAcA4YiyjiVsEnfPsKS/q2Ag=; h=Received:Received:Received:MIME-Version:Received:Date:Message-ID: Subject:From:To:Content-Type; b=Cb4k4HnHONLdeauWUBuH0IjQRgxsyW7ThFuf0qYMBQz4abVB99GZImVWM6M86ahvt 5obwx+XYOiSUXWSXk1x3UPbOW5j90taqBeII4F0H+Y+EkgR1BlPFXj50U05qfIvAYA fbL6zF00H2SqbHqOPPwumW8ZZ+pK2YsW7pjI6AZq+b12uB4wAO00funT0IIFH0SSSg 82OeX8YmPiVY+2SU4JhntkG6bMrRCnhuxGKFS8cnxM6pbZltOgtyAsgSkkngNG/0MM DFO2y8MwlxulwipPNq3r3kEqwfFwclvgXJC/gpWh1wVaPHh6CngJg2weW6/3HNjEgU AAekoDdsQiNIg==
Archived-At: http://mailarchive.ietf.org/arch/msg/avt/xuNtXbOCmPy01S7LCeCaIdkz63s
X-Mailman-Approved-At: Sat, 20 Dec 2014 11:39:09 -0800
Subject: [AVTCORE] ***SPAM*** 7.478 (5) Comments on draft-stokking-avtcore-idms-for-iptv-00
X-BeenThere: avt@ietf.org
X-Mailman-Version: 2.1.15
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: Fri, 19 Dec 2014 18:40:19 -0000

Sorry I have gotten behind following AVT. I will try to catch up. Hans
asked me to have a look at his draft and so here are my comments:

I would avoid using the "SSM" acronym. It is most commonly used for
Source-Specific Multicast. Although RFC 5760 talks about Single-Source
Multicast, it uses "SSM" to refer to Source-Specific Multicast

It took me a while to appreciate the scaling problem you're trying to solve
here. It seems unlikely and undesirable to synchronize all viewers of an
IPTV stream. As per the use cases described in RFC 7272, we're talking
about potentially numerous but small groups. Most viewers will watch in
isolation and don't need synchronization. Can you include some details for
use case where IDMS scalability is an issue. Streams with millions of
receivers doesn't necessarily stress IDMS, what are these receivers trying
to do?

At the top of page 5, maybe you mean RTP timestamp, not NTP timestamp in
two places. Unless you're using RFC 6051, there is no NTP timestamp in the
RTP packet. But further down in the paragraph it appears that RTP
timestamps are different, "various RTP/NTP relationships." I'm confused.

I think Figure 1 and Figure 2 are sort of swapped. In RFC 7272 the
presentation timestamps are 64 bits and the receive timestamps are 32 bits.
You're showing the opposite here.

In section 3, I'm not sure I appreciate why multicast IDMS settings packets
is not considered scalable. This information does not need to be
transmitted frequently. It doesn't look like parsing a large list of
synchronization groups is an unreasonable task in the context of all the
other RTCP traffic a receiver will be fielding in such a widely-received

Kevin Gross - AVA Networks