Re: [AVTCORE] Fw: New Version Notification for draft-ietf-avtcore-feedback-supression-rtp-01

Colin Perkins <csp@csperkins.org> Fri, 06 May 2011 08:12 UTC

Return-Path: <csp@csperkins.org>
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 D71D0E068C for <avt@ietfa.amsl.com>; Fri, 6 May 2011 01:12:00 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -103.599
X-Spam-Level:
X-Spam-Status: No, score=-103.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100]
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 mt11Q2xgDCpB for <avt@ietfa.amsl.com>; Fri, 6 May 2011 01:12:00 -0700 (PDT)
Received: from anchor-msapost-1.mail.demon.net (anchor-msapost-1.mail.demon.net [195.173.77.164]) by ietfa.amsl.com (Postfix) with ESMTP id 0B94FE067C for <avt@ietf.org>; Fri, 6 May 2011 01:12:00 -0700 (PDT)
Received: from starkperkins.demon.co.uk ([80.176.158.71] helo=[192.168.0.5]) by anchor-post-1.mail.demon.net with esmtpsa (AUTH csperkins-dwh) (TLSv1:AES128-SHA:128) (Exim 4.69) id 1QIG8j-0000ZR-ia; Fri, 06 May 2011 08:11:58 +0000
Mime-Version: 1.0 (Apple Message framework v1084)
Content-Type: text/plain; charset="us-ascii"
From: Colin Perkins <csp@csperkins.org>
X-Priority: 3
In-Reply-To: <038a01cc0bc4$870fffd0$46298a0a@china.huawei.com>
Date: Fri, 06 May 2011 09:11:53 +0100
Content-Transfer-Encoding: quoted-printable
Message-Id: <054B1A63-8659-4190-8C13-C9357128C6A8@csperkins.org>
References: <03fa01cbfb54$b52f1f20$46298a0a@china.huawei.com> <CD3C736F-0E35-43E3-BDEC-F18BD4D5623F@csperkins.org> <038a01cc0bc4$870fffd0$46298a0a@china.huawei.com>
To: Qin Wu <sunseawq@huawei.com>
X-Mailer: Apple Mail (2.1084)
Cc: magnus.westerlund@ericsson.com, avt@ietf.org
Subject: Re: [AVTCORE] Fw: New Version Notification for draft-ietf-avtcore-feedback-supression-rtp-01
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: Fri, 06 May 2011 08:12:01 -0000

On 6 May 2011, at 09:06, Qin Wu wrote:
> Thanks for your valuable comments, please see below.
> ----- Original Message -----
> From: Colin Perkins
> To: Qin Wu
> Cc: avt@ietf.org ; magnus.westerlund@ericsson.com
> Sent: Friday, May 06, 2011 12:30 AM
> Subject: Re: [AVTCORE] Fw: New Version Notification for draft-ietf-avtcore-feedback-supression-rtp-01
> 
> On 15 Apr 2011, at 11:05, Qin Wu wrote:
>> Hi,folks:
>> We have updated draft-ietf-avtcore-feedback-suppression-rtp to version 01 to address the comments from Prague meeting and on the list.
>> The new version is available at:
>> http://datatracker.ietf.org/doc/draft-ietf-avtcore-feedback-supression-rtp/
>> the diff from 00 is
>> http://tools.ietf.org/rfcdiff?url2=draft-ietf-avtcore-feedback-supression-rtp-01
>>  
>> Also I recall in the meeting there was a comment about use case and we have four use cases in the current draft and I would ask WG do people think these use cases are clear and what use cases are missing and do people think that use cases are needed.
> 
> I have several comments on this draft that relate to the use cases, both as written in Section 6, and elsewhere. The draft seems to be written as if it were still generating a feedback suppression packet, rather than a third-party loss report packet that happens to suppress feedback.
> 
> 1) The title and abstract were appropriate when the draft was solely aimed at feedback suppression, but should be updated now the focus is on third-party loss reports. 
>  
> [Qin]: Good point, will reflect this update in the new version.
> 
> 2) The protocol overview in Section 3, in particular the 2nd to 5th paragraphs, seems to have the use case for this third party report backwards. If there is packet loss upstream of a middlebox, that middlebox should send a NACK packet both upstream and downstream, to indicate that it has noticed the loss, and to suppress feedback from other downstream receivers. The third-party loss report is sent downstream by the middlebox when downstream loss is reported to the middlebox in a way that other downstream receivers are not aware of the loss reports, to inform those receivers of the loss and suppress their feedback.
>  
> [Qin]: Okay, you mention the middlebox send NACK upstream, it is about packet loss recovery. I would like to leave this beyond scope of this document.

The NACK is a notification of loss: it's independent of the packet loss recovery mechanism used. I do not believe this is out of scope of this document.

Colin