[AVTCORE] Comments on draft-ietf-avtcore-feedback-supression-rtp-04

"Van Caenegem, Tom (Tom)" <tom.van_caenegem@alcatel-lucent.com> Tue, 21 June 2011 09:30 UTC

Return-Path: <tom.van_caenegem@alcatel-lucent.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 6C14821F850B for <avt@ietfa.amsl.com>; Tue, 21 Jun 2011 02:30:18 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.099
X-Spam-Level:
X-Spam-Status: No, score=-6.099 tagged_above=-999 required=5 tests=[AWL=0.150, BAYES_00=-2.599, HELO_EQ_FR=0.35, RCVD_IN_DNSWL_MED=-4]
Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 3eAc6Rla9DAm for <avt@ietfa.amsl.com>; Tue, 21 Jun 2011 02:30:17 -0700 (PDT)
Received: from smail2.alcatel.fr (smail2.alcatel.fr [64.208.49.57]) by ietfa.amsl.com (Postfix) with ESMTP id 7207321F84D2 for <avt@ietf.org>; Tue, 21 Jun 2011 02:30:17 -0700 (PDT)
Received: from FRMRSSXCHHUB04.dc-m.alcatel-lucent.com (FRMRSSXCHHUB04.dc-m.alcatel-lucent.com [135.120.45.64]) by smail2.alcatel.fr (8.14.3/8.14.3/ICT) with ESMTP id p5L9Sfq7001909 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NOT); Tue, 21 Jun 2011 11:30:10 +0200
Received: from FRMRSSXCHMBSB1.dc-m.alcatel-lucent.com ([135.120.45.39]) by FRMRSSXCHHUB04.dc-m.alcatel-lucent.com ([135.120.45.64]) with mapi; Tue, 21 Jun 2011 11:29:55 +0200
From: "Van Caenegem, Tom (Tom)" <tom.van_caenegem@alcatel-lucent.com>
To: Qin Wu <sunseawq@huawei.com>, 'IETF AVTCore WG' <avt@ietf.org>, Roni Even <Even.roni@huawei.com>
Date: Tue, 21 Jun 2011 11:29:53 +0200
Thread-Topic: Comments on draft-ietf-avtcore-feedback-supression-rtp-04
Thread-Index: Acwv9cbj3rppvW+LTjeQyurT6E3Z7w==
Message-ID: <EC3FD58E75D43A4F8807FDE0749175461827F981@FRMRSSXCHMBSB1.dc-m.alcatel-lucent.com>
Accept-Language: nl-NL, en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
acceptlanguage: nl-NL, en-US
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
X-Scanned-By: MIMEDefang 2.64 on 155.132.188.80
Subject: [AVTCORE] Comments on draft-ietf-avtcore-feedback-supression-rtp-04
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: Tue, 21 Jun 2011 09:30:18 -0000

Hi,

as promised, these are comments I have on the draft " RTCP Extension for Third-party Loss Report"
 
-IMO the draft does not provide a good rationale on the use case for sending this new report. The section 3 (protocol overview) says:
 
"If an intermediary receives a NACK from another system, it should redistribute that NACK to all other systems that would not otherwise receive it.  An example of this is RTCP-SSM in simple feedback model [RFC5760], where the distribution source reflects NACKs to other systems.   
If an intermediary receives a NACK from another system, but, for some reason, cannot redistribute that NACK, then it may send a third-party loss report to the systems that were unable to receive the NACK, and won't receive the NACK via other means. An example would be a distribution source using RTCP-SSM in Distribution Source Feedback Summary model [RFC5760]."

My questions: 

-why would the intermediary not be able or capable to send the received NACK to the "systems" that were unable to receive the NACK, whereas it would be able or capable to send the 3rd party loss report to those same "systems"? 

-The DS in RTCP-SSM operating in FB summary mode is mentioned as an example for a case where a NACK cannnot be forwarded. Why is this?  RFC5760 does not prevent a DS to foward the NACK (see the RFC 5760 and my quote from that RFC in "draft-vancaenegem-avtcore-retransmission-for-ssm-00"

-This section 3 makes a distinction between an intermediate that does check the RTP stream for missing packets itself, and an intermediate that does not, but still the behaviour in terms of FW-ing the NACKs received from other "systems" is exactly the same. Why make this distinction then?

I still have an outstanding comment which has not been resolved yet. The section 6.1. and 6.1.1. take RFC 5760 as use case architectures, but section 6.1.1. talks about two distribution sources, whereas RFC 5760 only defined ONE SINGLE DS. Please clarify this.

Regards
Tom