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

Qin Wu <sunseawq@huawei.com> Fri, 06 May 2011 08:23 UTC

Return-Path: <sunseawq@huawei.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 AA830E06C8 for <avt@ietfa.amsl.com>; Fri, 6 May 2011 01:23:37 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.887
X-Spam-Level:
X-Spam-Status: No, score=-4.887 tagged_above=-999 required=5 tests=[AWL=1.712, BAYES_00=-2.599, 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 n3NM67-L8GiX for <avt@ietfa.amsl.com>; Fri, 6 May 2011 01:23:36 -0700 (PDT)
Received: from szxga03-in.huawei.com (szxga03-in.huawei.com [119.145.14.66]) by ietfa.amsl.com (Postfix) with ESMTP id A463BE0663 for <avt@ietf.org>; Fri, 6 May 2011 01:23:36 -0700 (PDT)
Received: from huawei.com (szxga03-in [172.24.2.9]) by szxga03-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0LKR00MFELYMLB@szxga03-in.huawei.com> for avt@ietf.org; Fri, 06 May 2011 16:23:10 +0800 (CST)
Received: from huawei.com ([172.24.2.119]) by szxga03-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0LKR003VTLYMGL@szxga03-in.huawei.com> for avt@ietf.org; Fri, 06 May 2011 16:23:10 +0800 (CST)
Received: from w53375 ([10.138.41.70]) by szxml04-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTPA id <0LKR00EJJLYMOB@szxml04-in.huawei.com> for avt@ietf.org; Fri, 06 May 2011 16:23:10 +0800 (CST)
Date: Fri, 06 May 2011 16:26:42 +0800
From: Qin Wu <sunseawq@huawei.com>
To: Colin Perkins <csp@csperkins.org>
Message-id: <039c01cc0bc7$54926720$46298a0a@china.huawei.com>
MIME-version: 1.0
X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2900.3664
X-Mailer: Microsoft Outlook Express 6.00.2900.3664
Content-type: text/plain; charset="iso-8859-1"
Content-transfer-encoding: 7bit
X-Priority: 3
X-MSMail-priority: Normal
References: <03fa01cbfb54$b52f1f20$46298a0a@china.huawei.com> <CD3C736F-0E35-43E3-BDEC-F18BD4D5623F@csperkins.org> <038a01cc0bc4$870fffd0$46298a0a@china.huawei.com> <054B1A63-8659-4190-8C13-C9357128C6A8@csperkins.org>
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:23:37 -0000

> 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=

[Qin]: But NACK also can be used for retransmission. Retransmission is one kind of packet loss repairement mechanism. And there was consensus that how to repair the packet loss should be beyond scope of this document. 
If I am wrong, please correct me.