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

Qin Wu <sunseawq@huawei.com> Fri, 06 May 2011 08:03 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 28E91E068C for <avt@ietfa.amsl.com>; Fri, 6 May 2011 01:03:46 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.374
X-Spam-Level:
X-Spam-Status: No, score=-4.374 tagged_above=-999 required=5 tests=[AWL=1.340, BAYES_00=-2.599, HTML_FONT_FACE_BAD=0.884, HTML_MESSAGE=0.001, 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 m0ZOV1puLzNj for <avt@ietfa.amsl.com>; Fri, 6 May 2011 01:03:45 -0700 (PDT)
Received: from szxga03-in.huawei.com (szxga03-in.huawei.com [119.145.14.66]) by ietfa.amsl.com (Postfix) with ESMTP id B2D5AE0663 for <avt@ietf.org>; Fri, 6 May 2011 01:03:44 -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 <0LKR00MMJL16LB@szxga03-in.huawei.com> for avt@ietf.org; Fri, 06 May 2011 16:03:07 +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 <0LKR007A7L16VJ@szxga03-in.huawei.com> for avt@ietf.org; Fri, 06 May 2011 16:03:06 +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 <0LKR00E44L16OB@szxml04-in.huawei.com> for avt@ietf.org; Fri, 06 May 2011 16:03:06 +0800 (CST)
Date: Fri, 06 May 2011 16:06:38 +0800
From: Qin Wu <sunseawq@huawei.com>
To: Colin Perkins <csp@csperkins.org>
Message-id: <038a01cc0bc4$870fffd0$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: multipart/alternative; boundary="Boundary_(ID_DlOaV9uUCajbSntCL5v6Vg)"
X-Priority: 3
X-MSMail-priority: Normal
References: <03fa01cbfb54$b52f1f20$46298a0a@china.huawei.com> <CD3C736F-0E35-43E3-BDEC-F18BD4D5623F@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:03:46 -0000

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.


  3) The 6th paragraph of Section 3 also confuses this when it states "replace it with a Third Party Loss Report message that reflects the loss pattern they have themselves seen": if they have seen the loss, then a NACK is appropriate. If they've been told about the loss, then a third party loss report is needed.

  [Qin]: Okay.


  4) Section 6.1, 2nd paragraph has a similar problem. Upstream loss will cause an SSM Distribution Source to generate a NACK, which it sends upstream and downstream. The third party loss report is used when one downstream receiver reports loss, leaving the Distribution Source with the responsibility of telling the other downstream receivers. Section 6.1.1 gets this correct.

  [Qin]: Okay.


  5) Section 6.1.2, 2nd paragraph: same problem. This section also needs to talk about the need to generate and send downstream third party loss reports in response to NACKs received from downstream.

  [Qin]: Okay.


  6) Section 6.2: why does a BRS that detects loss send a third-party report, rather than a NACK? The third-party report would be sent in response to downstream receivers sending NACKs, to inform other receivers, no?

  [Qin]: Okay, how about rephrase 
  "
  a BRS that detects loss
  "
  as
  "
  a BRS that receives downstream loss report
  "
  In this case, BRS need to send handle third-party report rather than NACK..



  -- 
  Colin Perkins
  http://csperkins.org/