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

[Qin Wu <[e-mail]>]

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.  



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.



>>  
>> 
>> 3. Section 3:
>>   "To increase the robustness to the loss of a TPLR or of a transmission
>>    packet, a receiver is allowed to receive additional TPLR for the same
>>    packet.  In the case the first TPLR is lost and the additional TPLR
>>    arrives at the receiver, the receiver should immediately refresh the
>>    timer."
>> 
>> In the second sentence I don't see how the receiver can know that it is
>> a retransmission. It is simply a TPLR from its perspective if that is lost.
>> 
>> Robustness reasons is only one reason for repeating them the other is
>> clearly to renew the timer. Thus I think the formulation should be more
>> generic to make it clear that all receivers should upon reception of a
>> TPLR refresh the timer for the packets indicated.
>> 
>>  
>> 
>> [Qin]: If the receiver does not keep state for the times the TPLR is
>> 
>>  retransmitted, we can add repetition count field in each FCI entry
>> 
>>  of TPLR feedback message to indicate the times TPLR is retransmitted.
>> 
>>  Particularly in PSLEI Feedback Message, we can reuse seq nr. Field to
>> 
>>  indicate if additional TPLR is retransmitted, which one you think better?
>> 
>> 
> 
> How, can the receiver keep state for something it has not seen due to
> the initial packet not having been received?
> 
> I don't think we need new packet extensions, just clarified rules that
> correctly describe what the RTP end-point should do when it sees the
> TPLR message.

[Qin]; Okay, I Agree with that, see below.

> 
>> 
>> 7. Section 4.2:
>>    Seq nr:8bits  Command sequence number.  It is used by the Command
>>       receiver to check if the Command is repeated.  The sequence number
>>       space is unique for each pairing of the SSRC of command sender and
>>       the SSRC of the command receiver.  The sequence number SHALL
>>       increase by 1 modulo 256 for each new Command.  A repetition SHALL
>>       NOT increase the sequence number.  The initial value is arbitrary.
>> 
>> Based on that it is defined that upon receiving one of the PSLEI
>> request, one shouldn't send a FIR or PLI message for a time interval
>> equal to the RTT between the receiver and the sender of the PSLEI
>> message does the sequence number field have any meaning? From my
>> perspective it doesn't matter if it is a new request or not. You are
>> suppressed from the reception of the message, nothing else.
>> 
>> [Qin]: I think we can use seq nr field to indicate the times the TPLR is
>> retransmitted, e.g.,
>> 
>> If the additional TPLR with the same SSRC and different Seq Number is
>> received, the
>> 
>> receiver knows that it is a retransmission if the receiver keeps state
>> for the previous
>> 
>> TPLR with the same SSRC.
>> 
>> Also we can replace seq nr. Field with Repetition count field to
>> indicate how many time
>> 
>> the TPLR is retransmitted.
>> 
>> 
> 
> That is possible, but is the repetition count really providing anything?
> What is the simplest most straight forward that can work? I think that
> is that one simple suppress the source for X time after having receives
> a TPLR message indicate that source. So, as long as you get repeat
> messages more often than X you continue to be suppressed. Will the
> receiver work better to know that it is now suppressed for Y times in a
> go because of the same event?

[Qin]: I agree that adding new field is a little overdesign and does not too much value.

 Your proposal is more straightforward and looks good to me. I will make it clear in the text.


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