Re: [AVTCORE] Comments ondraft-ietf-avtcore-feedback-supression-rtp-06.txt

Qin Wu <bill.wu@huawei.com> Mon, 19 September 2011 08:32 UTC

Return-Path: <bill.wu@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 34B5E21F8AB0 for <avt@ietfa.amsl.com>; Mon, 19 Sep 2011 01:32:19 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -5.337
X-Spam-Level:
X-Spam-Status: No, score=-5.337 tagged_above=-999 required=5 tests=[AWL=1.262, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id uKqLmMdvAfyh for <avt@ietfa.amsl.com>; Mon, 19 Sep 2011 01:32:18 -0700 (PDT)
Received: from szxga01-in.huawei.com (szxga01-in.huawei.com [119.145.14.64]) by ietfa.amsl.com (Postfix) with ESMTP id 62E2421F8A95 for <avt@ietf.org>; Mon, 19 Sep 2011 01:32:18 -0700 (PDT)
Received: from huawei.com (szxga05-in [172.24.2.49]) by szxga05-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0LRR00JI2H5Q65@szxga05-in.huawei.com> for avt@ietf.org; Mon, 19 Sep 2011 16:34:38 +0800 (CST)
Received: from szxrg02-dlp.huawei.com ([172.24.2.119]) by szxga05-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0LRR003P3H55GP@szxga05-in.huawei.com> for avt@ietf.org; Mon, 19 Sep 2011 16:34:38 +0800 (CST)
Received: from szxeml203-edg.china.huawei.com ([172.24.2.119]) by szxrg02-dlp.huawei.com (MOS 4.1.9-GA) with ESMTP id ADT67019; Mon, 19 Sep 2011 16:34:36 +0800
Received: from SZXEML405-HUB.china.huawei.com (10.82.67.60) by szxeml203-edg.china.huawei.com (172.24.2.55) with Microsoft SMTP Server (TLS) id 14.1.270.1; Mon, 19 Sep 2011 16:34:34 +0800
Received: from w53375q (10.138.41.130) by szxeml405-hub.china.huawei.com (10.82.67.60) with Microsoft SMTP Server (TLS) id 14.1.270.1; Mon, 19 Sep 2011 16:34:33 +0800
Date: Mon, 19 Sep 2011 16:34:29 +0800
From: Qin Wu <bill.wu@huawei.com>
X-Originating-IP: [10.138.41.130]
To: "Van Caenegem, Tom (Tom)" <tom.van_caenegem@alcatel-lucent.com>, Magnus Westerlund <magnus.westerlund@ericsson.com>
Message-id: <5DE91CAB60B24F48B87C9533EBF1E919@china.huawei.com>
MIME-version: 1.0
X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2900.6109
X-Mailer: Microsoft Outlook Express 6.00.2900.5931
Content-type: text/plain; charset="iso-8859-1"
Content-transfer-encoding: 7bit
X-Priority: 3
X-MSMail-priority: Normal
X-CFilter-Loop: Reflected
References: <20110831070359.24630.22446.idtracker@ietfa.amsl.com> <4E5F9C23.8050702@ericsson.com> <4E69F7AE.3040601@ericsson.com> <8CD73AC40EDC452A80EE42BBF82E7DE8@china.huawei.com> <4E6E1A90.7050805@ericsson.com> <EC3FD58E75D43A4F8807FDE0749175461918135D@FRMRSSXCHMBSB1.dc-m.alcatel-lucent.com> <7C1EF2A3109E4EAB8AD991160AF71AF6@china.huawei.com> <EC3FD58E75D43A4F8807FDE074917546191E6834@FRMRSSXCHMBSB1.dc-m.alcatel-lucent.com>
Cc: avt@ietf.org, draft-ietf-avtcore-feedback-supression-rtp@tools.ietf.org
Subject: Re: [AVTCORE] Comments ondraft-ietf-avtcore-feedback-supression-rtp-06.txt
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: Mon, 19 Sep 2011 08:32:19 -0000

Hi,
----- Original Message ----- 
From: "Van Caenegem, Tom (Tom)" <tom.van_caenegem@alcatel-lucent.com>
To: "Qin Wu" <bill.wu@huawei.com>; "Magnus Westerlund" <magnus.westerlund@ericsson.com>
Cc: <avt@ietf.org>; <draft-ietf-avtcore-feedback-supression-rtp@tools.ietf.org>
Sent: Friday, September 16, 2011 7:00 PM
Subject: RE: [AVTCORE] Comments ondraft-ietf-avtcore-feedback-supression-rtp-06.txt



Qin,


The BRS sends a NACK or TPLR message to the DS, where the SSRC in this NACK or TPLR message is the one of the BRS. The DS forwards/reflects this message down on the primary SSM. This procedure will allow isolated feedback suppression, when RTP receivers only trigger FB suppression when recognising the SSRC as belonging to the BRS to which they report.

[Qin]: What do you mean about isolated feedback suppression, do you mean DS control which BRS it will redistribute Feedback suppression message from BRS or just flood the message to all the BRSes.

Tom: no. As explained above a BRS that wants FB suppression will send NACK or TPLM to the DS, which then re-distributes to ALL RTP receivers via the SSM. Only receivers that report to the BRS that sent the TPL or NACK message to the DS, will suppress feedback. Other receivers will ignore this NACK/TPL message. Whether the feedback suppression is activated or not, is hence determined by the SSRC identifier value (the one of the BRS) in the TPLM or NACK that is received by the RTP receiver. See the draft document.

[Qin]: It is not clear to me how this is different from FB suppression rule defined in RFC4585.
it looks to me the receiver behavior for FB suppression in your draft document is not compliant with what it described in RFC4585,
Fist of all,  ome receivers doesn't follow FB suppression rule defined in RFC4585 when they receive NACK or TPL with unkonw SSRC value.

However according to RFC4585, if NACK or TPLM is allowed to send to all the receivers, all the receivers should react to the receiving NACK or TPLM following rule defined in RFC4585
rather than ignore  or discard it when SSRC in NACK or TPLM is unknow.

Secondly If one receiver didn't report the loss to the BRS, however the DS may still send NACK or TPLM to this receiver. In your undersanding, this receiver should not activate feedback suppression.
However according to RFC4585, the receiver receiving NACK or TPLM should suppress FB message if it see the same loss.

So in my understanding, additional rule you proposed is like conditional FB suppression for receivers, in other words, the receiver selectively does FB suppression based on the SSRC delcared. My question is does it conflict with RFC4585? Is it optional choice or 
mandatory choice for FB suppression? e.g., only the number of receivers exceeds the threshold, then conditional FB suppression applies.


Regards=