Re: [AVTCORE] Comments on draft-ietf-avtcore-feedback-supression-rtp-07

Qin Wu <bill.wu@huawei.com> Fri, 04 November 2011 03:46 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 71B5911E8147 for <avt@ietfa.amsl.com>; Thu, 3 Nov 2011 20:46:29 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.338
X-Spam-Level:
X-Spam-Status: No, score=-4.338 tagged_above=-999 required=5 tests=[AWL=0.508, BAYES_00=-2.599, MIME_BASE64_TEXT=1.753, 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 THvKlMnfGPq4 for <avt@ietfa.amsl.com>; Thu, 3 Nov 2011 20:46:28 -0700 (PDT)
Received: from szxga04-in.huawei.com (szxga04-in.huawei.com [119.145.14.67]) by ietfa.amsl.com (Postfix) with ESMTP id 2120211E8146 for <avt@ietf.org>; Thu, 3 Nov 2011 20:46:28 -0700 (PDT)
Received: from huawei.com (szxga04-in [172.24.2.12]) by szxga04-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0LU4008S5AH9JL@szxga04-in.huawei.com> for avt@ietf.org; Fri, 04 Nov 2011 11:46:21 +0800 (CST)
Received: from szxrg02-dlp.huawei.com ([172.24.2.119]) by szxga04-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0LU400LPEAGNSA@szxga04-in.huawei.com> for avt@ietf.org; Fri, 04 Nov 2011 11:46:21 +0800 (CST)
Received: from szxeml202-edg.china.huawei.com ([172.24.2.119]) by szxrg02-dlp.huawei.com (MOS 4.1.9-GA) with ESMTP id AET32016; Fri, 04 Nov 2011 11:46:20 +0800
Received: from SZXEML412-HUB.china.huawei.com (10.82.67.91) by szxeml202-edg.china.huawei.com (172.24.2.42) with Microsoft SMTP Server (TLS) id 14.1.270.1; Fri, 04 Nov 2011 11:46:08 +0800
Received: from w53375q (10.138.41.130) by szxeml412-hub.china.huawei.com (10.82.67.91) with Microsoft SMTP Server (TLS) id 14.1.270.1; Fri, 04 Nov 2011 11:46:12 +0800
Date: Fri, 04 Nov 2011 11:46:11 +0800
From: Qin Wu <bill.wu@huawei.com>
X-Originating-IP: [10.138.41.130]
To: Magnus Westerlund <magnus.westerlund@ericsson.com>
Message-id: <85A232BE2B3647CB98401741A6DD9D91@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=windows-1252
Content-transfer-encoding: base64
X-Priority: 3
X-MSMail-priority: Normal
X-CFilter-Loop: Reflected
References: <4E8D76C1.5080508@ericsson.com> <BAC40485A1FA456CA771192D4F750C77@china.huawei.com> <4E9E93A0.10701@ericsson.com> <06E9C1CF3B7D47B5A8FC8540EABA2FAF@china.huawei.com> <4EB2986F.2000301@ericsson.com>
Cc: IETF AVTCore WG <avt@ietf.org>, draft-ietf-avtcore-feedback-supression-rtp@tools.ietf.org
Subject: Re: [AVTCORE] Comments on draft-ietf-avtcore-feedback-supression-rtp-07
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, 04 Nov 2011 03:46:29 -0000

----- Original Message ----- 
From: "Magnus Westerlund" <magnus.westerlund@ericsson.com>
To: "Qin Wu" <bill.wu@huawei.com>
Cc: "IETF AVTCore WG" <avt@ietf.org>rg>; <draft-ietf-avtcore-feedback-supression-rtp@tools.ietf.org>
Sent: Thursday, November 03, 2011 9:34 PM
Subject: Re: [AVTCORE] Comments on draft-ietf-avtcore-feedback-supression-rtp-07


On 2011-10-20 11:27, Qin Wu wrote:
> Hi, Magnus:
> Thank for your replies. please see inline.
> ----- Original Message ----- 
> From: "Magnus Westerlund" <magnus.westerlund@ericsson.com>
> To: "Qin Wu" <bill.wu@huawei.com>
> Cc: "IETF AVTCore WG" <avt@ietf.org>rg>; <draft-ietf-avtcore-feedback-supression-rtp@tools.ietf.org>
> Sent: Wednesday, October 19, 2011 5:08 PM
> Subject: Re: [AVTCORE] Comments on draft-ietf-avtcore-feedback-supression-rtp-07
> 
> 
>> Hi,
>>
>> Sorry for the delay in following up.
>>
>> I have removed the issues which don't need further discussion.
>>
>>
>> On 2011-10-11 03:40, Qin Wu wrote:
>>> Hi, Magnus,
>>> Thank for your valuable review, please see my replies belows.
>>> ----- Original Message -----
>>> From: "Magnus Westerlund" <magnus.westerlund@ericsson.com
>>
>>> 2. Section 3.
>>>   "The timer value shall be
>>>    based on the observed round-trip time.  A receiver should compute an
>>>    estimate of the round-trip time (RTT) to the sender of TPLR from RTCP
>>>    report round-trip time if available, or its reception time of the
>>>    reflected RTCP FB message (e.g.,NACK), or any other means."
>>>
>>> We hade the discussion before but now that you clarified which RTT to be
>>> used, I think it is worth having a discussion if that RTT is the right
>>> one. So you suggest that the RTT between the sender of the TPLR and the
>>> receiver of the message is the most appropriate to use when suppressing
>>> the message. I am not certain that is the case.
>>>
>>> Lets consider the use cases. In the case of an intermediary in a
>>> distribution tree sending the TPLR and at the same time sending a NACK
>>> upstream. Then the time until the retransmission reaches the suppressed
>>> receiver is the time from the sending of the NACK up to the
>>> retransmitting entity and all the way down past the TPLR sender to the
>>> suppressed receiver. The receiver may not have a true RTT to the
>>> original media sender as that source appears to live at the TPLR sender,
>>> not further upstream.
>>>
>>> Yes, the sender of the TPLR and the receiver might at least have mutual
>>> knowledge of each other, thus the TPLR sender is able to determine the
>>> lowest RTT in the set of receviers thus determining how often to repeat
>>> it to cover additional time requried for the upstream part of the
>>> request. But I do note that these times aren't matching what appear to
>>> be the delays in the systems.
>>>
>>> Can we find a better solution?
>>>  
>>>
>>> [Qin]: It looks to me the round trip time between media source and
>>>
>>>  intermediary is trivial if we assume the intermediary is much
>>>
>>> closer to the source, that is why I put the last paragraph in the
>>>
>>> section 3 as follows:
>>>
>>> “
>>>
>>> In order not to incur a lot of NACK requests due to additional TPLR
>>>
>>> described above, it is recommended that the RTP system sending
>>>
>>> TPLR should be implemented more closer to the source. Also when
>>>
>>>  the loss was detected and repair initiated much closer to the source,
>>>
>>> the delay for the receiver to recover from packet loss can be reduced
>>>
>>> through the combination of intermediary feedback to the source and
>>>
>>> Third Party Loss Report downstream.
>>>
>>> ”
>>>
>>>  
>>>
>>> If we look for a better solution, I think we have two possible ways:
>>>
>>> The first way is to rely on sender report from media sender to
>>>
>>> calculate the more approximate RTT from media sender to the receiver.
>>>
>>> RTT measurement method follows the same way described in the
>>>
>>> figure 2 of RFC3550.
>>>
>>>  
>>>
>>> The second way is to we can allow the intermediary tell the receiver the
>>>
>>> RTT from media source to intermediary itself by sending a new message
>>>
>>> since the intermediary can measure such RTT based on past observation
>>>
>>> and estimation. However for the second way we need to define new
>>>
>>> message or extend TPLR message to carry such RTT.
>>>
>>>  
>>>
>>> What do you think?
>>>
>>
>> From follow up email:
>>> Hi,Magnus: As regarding if there is better solution, I have some
>>> corrections and additional thoughts.
>>> I think If the media source is the repair server, the receiver should
>>> set timer to T1=max(the RTT from media source to middlebox sending
>>> TPLR, 1/2 of RTT from middlebox to receiver) when the receiver
>>> receives first TPLR. When the receiver receive addtional TPLR within
>>> T1, the receiver should reset the timer to the RTT from media source
>>> to middlebox sending TPLR.
>>>
>>> If the middlebox is the repair server, the receiver should set the
>>> timer to T2=1/2 of RTT from middlebox to receiver when the receiver
>>> receives first TPLR. When the receiver receive addtional TPLR within
>>> T2, the receiver should reset the timer to the T2.
>>>
>>
>> Can you express these rules for the receiver as something that is based
>> on what is observable from the RTP and RTCP traffic? Is when media
>> server being repair server equal to TPLR sender SSRC = Media SSRC the
>> TPLR applies on? And if they are not the same it is the second case?
>>
> 
> 
> [Qin]: Okay, I think the media source will not be the TPLR sender. 
> 
>  
> 
> The receiver should set the timer for the retransmitted data packet when it receive the first TPLR.
> 
> 
> 
> 
> If the sender of Retransmitted data packet is the media source, the timer value shall be
> 
> based on the observed time difference between the round-trip time from the receiver to 
> 
> the original media source and the round-trip time from the receiver to the sender of the TPLR.  

How does the receiver of a TPLR know that the sender of the
retransmitted data packet will be the media stream source?

And if this if statement is not true, what should the timer value be?

[Qin]: Isn't by the SDES packet. According to RFC4588, section 5.2, the media source MUST
use the same CNAME for an original stream and its associated retransmission stream.

> 
> 
> 
> A receiver should compute an estimate of the round-trip time (RTT) to the original media source 
> 
> from Sender Report (SR) packets for the original stream, or any other means. The round-trip time 
> 
> from the receiver to the sender of the TPLR can be calculated from RTCP report round-trip time 
> 
> if available, or any other means.
> 

I think this needs to be more explicit on how that estimate actually can
be done and what precision we expect in it.

[Qin]: Agree.

Cheers

Magnus Westerlund

----------------------------------------------------------------------
Multimedia Technologies, Ericsson Research EAB/TVM
----------------------------------------------------------------------
Ericsson AB                | Phone  +46 10 7148287
Färögatan 6                | Mobile +46 73 0949079
SE-164 80 Stockholm, Sweden| mailto: magnus.westerlund@ericsson.com
----------------------------------------------------------------------