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

[Magnus Westerlund <[e-mail]>]

On 2011-10-20 11:27, Qin Wu wrote:
> Hi, Magnus:
> Thank for your replies. please see inline.
> ----- Original Message ----- 
> From: "Magnus Westerlund" <[e-mail]>
> To: "Qin Wu" <[e-mail]>
> Cc: "IETF AVTCore WG" <[e-mail]>; <[e-mail]>
> 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" <[e-mail]
>>
>>> 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?

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

Cheers

Magnus Westerlund

----------------------------------------------------------------------
Multimedia Technologies, Ericsson Research EAB/TVM
----------------------------------------------------------------------
Ericsson AB                | Phone  [phone]
Färögatan 6                | Mobile [phone]
SE-164 80 Stockholm, Sweden| mailto: [e-mail]
----------------------------------------------------------------------