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

[Qin Wu <[e-mail]>]

Hi,Magnus:
Sorry for late feedback, please see my reply below.
----- Original Message ----- 
From: "Magnus Westerlund" <[e-mail]>
To: "Qin Wu" <[e-mail]>
Cc: <[e-mail]>; <[e-mail]>
Sent: Monday, September 12, 2011 10:22 PM
Subject: Re: Comments on draft-ietf-avtcore-feedback-supression-rtp-06.txt


> Hi,
> 
> Removed the issues where I have no more comments.
> 
> See inline
> 
> On 2011-09-07 05:28, Qin Wu wrote:
>> Hi,Magnus:
>> Please see my replies below. Hope it address your remaining comments.
>> ----- Original Message -----
>> From: "Magnus Westerlund" <[e-mail]
>> <mailto:[e-mail]>>
>> To: "Qin Wu" <[e-mail] <mailto:[e-mail]>>
>> Cc: <[e-mail] <mailto:[e-mail]>>;
>> <[e-mail]
>> <mailto:[e-mail]>>
>> Sent: Tuesday, September 06, 2011 3:58 PM
>> Subject: Re: Comments on draft-ietf-avtcore-feedback-supression-rtp-06.txt
>> 
>> 
>> On 2011-09-05 06:06, Qin Wu wrote:
>>> Hi, Magnus:
>>> Thank for your valuable review. please see my replies below.
>>>
>>>> ----- Original Message -----
>>>> From: "Magnus Westerlund" <[e-mail]
>> <mailto:[e-mail]>>
>>>> To: <[e-mail] <mailto:[e-mail]>>;
>> <[e-mail]
>> <mailto:[e-mail]>>
>>>> Sent: Thursday, September 01, 2011 10:52 PM
>>>> Subject: Comments on draft-ietf-avtcore-feedback-supression-rtp-06.txt
>> 
> 
>> 
>>>
>>>> 5. Section 3, fourth paragraph:
>>>> I am trying to get my head around the implications of not being explicit
>>>> about the time feedback suppression lasts. And I don't quite get how it
>>>> works from either side.
>>>
>>>> As the sender of of Third party loss report, the first message is pretty
>>>> straight forward. It suppresses all receiver that get it for one of
>>>> their Retransmission timeout intervals. As a sender I have no idea how
>>>> long that interval are in the various receivers implementations. It is
>>>> likely a RTT + some fudge time for the source being reported. The issue
>>>> is that the RTT to the orignal source, rather than the third party
>>>> reporting the loss is quite different, thus not reflecting the interval
>>>> before the Third party expects to get the packet for forwarding.
>>>
>>> [Qin]: Firstly, the normal behavior of TPLR sender is the same as for
>> sending a NACK and not
>>> receiving a repair. I think that the paragraph was about the case when the
>>> downstream receiver received a suppression message but expected to get a
>>> repair packet w=even though it did not sent a NACK.
>>>
>>> Secondly, it is true that the interval to get TPLR varies from
>> different receivers implementation.
>>> However the senders of TPLR does not need to know how long it take for
>> receiver to get TPLR
>>> message, instead the receiver should more concerns the interval to
>> recieve TPLR from the sender
>>> of TPLR. In other words, upon being told about the packet loss, TPLR
>> senders should immediately
>>> create, send TPLR to the recievers. The other intermediary between
>> sender and receiver just simply
>>> forward TPLR message to the recievers.
>>>
>>> For reciever who concerns the interval, they should know how to choose
>> appropirate interval for timer.
>>> one way is to choose the longest time to receive TPLR, i.e., one RTT
>> to recieve TPLR from source since
>>>  the media source also can be the sender of TPLR. Does this
>> clarification make sense to you?
>> 
>> Well, but if you are a Intermediary that forwards upstream RTP packets
>> onto a multicast segment and at the same time buffers them for
>> retransmission. Then when that Intermediary detects a loss upstream of
>> itself it might want to send a TPLR as soon as it is pretty certain of
>> that loss downstream to avoid the receivers sending NACK on something it
>> can't repair. And in that case, it is difficult to determine how often
>> it should be repeated while it is still not received or repaired.
>> 
>> [Qin]: I get your point. As I said, the behavior of intermediary for
>> sending TPLR could be the same as one for sending a NACK.
>> 
>> In case of the loss of TPLR, the intermediary may send another TPLR for
>> the same packet loss event.
>> 
>> Before sending the another TPLR, the intermediary may rely on a timer to
>> ensure that the attempt to send first TPLR for suppression
>> 
>> has failed and so avoid unnecessary resending new TPLR for the same
>> packet loss.
>> 
>> The timer can be based on observed round-trip time measured from
>> intermediary to the receiver. The estimate of the round-trip time
>> 
>> (RTT) to the receiver can be calculated based on past observations, RTCP
>> report round-trip time. Does this address your comment?
>> 
> 
> I think using observed RTTs is a good thing. However, one needs to
> answer the question of who's RTT are one using. A SSM receiver has no
> RTT measurements performed, as they are sending no SRs. So unless the
> summary Report is provided the receiver have no knowledge of any RTTs in
> the system.
> 
> This is likely true also for intermediaries unless they send data using
> their own SSRC, like unicast RTX.
> 
> Thus, it becomes difficult to know how the entities will behave with
> these retransmission timers.


[Qin]: This is not true. Look at the section 7.1.6 of RFC5760, in SSM summary feedback case, the distribution source can use Round-Trip time sub-report block defined in section 7.1.6 to tell the receiver about the round-trip time from the distribution source to the receivers. This round-trip time can be calculated based on the SR from media source, RR from receiver and the current time according to the section 7.1.6. So this round-trip time calculation also applies to the other use cases.




> In addition as the receiver reaction to additional TPLRs aren't
> documented it becomes difficult to determine how big impact spurious
> TPLRs have on the system.


[Qin]: Agree. I think we may follow the similar rules made for multiple retransmission described in the section 6.3 of RFC4588 if we document additional TPLRs.


> But lets assume that a TPLR simply resets the timer each time it is a
> received. Then it makes sense for an intermediary that are awaiting
> retransmission upstream to send TPLR periodically on an interval that is
> guaranteed to be shorter than any participants retransmission timer
> until it receives the retransmission request. Yes, sending one and if
> the receiver populations timer is as long or longer than the
> intermeediary's timer to the media source, then that is more optimal.
> But if that results in a lot of NACK requests, then I would claim it
> might be less efficient from a network resource perspective.
> 
> Thus different implementation choices exist. And with the current lack
> of clarity I guess different implementation choices will be made and
> with poor performance as result.

[Qin]: We don't need to support various implementation choices.

Assume the intermediary sits between media source and receiver, we can ask intermediary to measure the round trip time between media source and intermediary, the round trip time between intermediary and receiver to make sure the media source is more near to the intermediary than the receiver.

Therefore we can guarantee that the receiver populations timer to intermediary is set as long or longer than the intermediary's timer to the media source. 

In this case, we will not introduce a lot of NACK when additional TPLR is used.

Does this make sense to you?



>>  
>> 
>> Another case in my mind is how often to send a TPLR for different packet
>> loss in case there is no loss of TPLR or of retransmission packet.
>> 
>> In this case, the intermediary can follow the same timing rule of
>> sending NACK defined in RFC4585. i.e., The TPLR message may be sent
>> 
>> in a regular full compound RTCP packet or in an early RTCP packet, as
>> per AVPF.
>> 
> 
> Yes, I think the normal rules fro sending AVPF packets should be
> followed. I don't think you need to have the "full" rule for something
> that is in fact a new Feedback event. Just use the rules for sending
> feedback events.

[Qin]: Okay.

>> 
>>>
>>>> The next question is if and in that case when the node should send an
>>>> additional TPLR message. Should it wait for receiving a first NACK and
>>>> expect a storm of others before the suppression has reached the others.
>>>> Should it try to estimate the lowest suppression time to any of the down
>>>> stream receivers?
>>>
>>> [Qin]:
>>>  In most case, the node in the middle does not need to send additional
>>> TPLR if upstream node has been told about all the packet loss event.
>>>  Unless the upsteam node miss one or more than one packet loss, the
>>>  node in the middle between upstream node and the receive may send
>>> additional TPLR. However same as the upstream node sending TPLR,
>>>  the node in the middle does not need to wait for a certain time to send
>>> TPLR. upon been told about the loss and make sure the loss is not
>> reported
>>> by upstream node, the node should create and send additional TPLR
>> immediately.
>>> Does it make sense?
>> 
>> I still don't know how often I need to send them to ensure that I don't
>> get NACKs from my receivers.
>>  
>> [Qin] See above.
>> 
>>>
>>>> As a receiver, when I receive an additional TPLR message, do I
>>>> immediately restart the timer, or do I wait until the timer expires and
>>>> then refreshes it for one new interval?
>>>
>>> [Qin]: First, I think the reciever behavior follows the feedback
>> suppression
>>>  rule defined in RFC4585. secondly, I think the timer is restarted per
>> each new loss, if the
>>>  reciever receive additinal TPLR message, which report the different
>> loss, the
>>>  reciever should restart the timer immediately. However if additinal
>> TPLR report
>>> the same loss as the previous TPLR, the receiver should wait untile
>> the timer expires
>>> and then refreshes it for one new interval.
>> 
>> I personally think refreshing the timer immediately in both cases might
>> be both simpler and work better. Especially as the sender of an update
>> then knows that it is one interval from the reception of the new TPLR,
>> and not two intervals since the first one. As the length of the interval
>> is not known it is difficult to know when receivers will approximately
>> resume sending NACKs.
>>  
>> [Qin]: I agree with you. In the case the first TPLR is lost and the
>> second TPLR arrives
>> at the receiver, the receiver should immediately refresh the timer. In
>> the case the first
>> TPLR is not lost and the second TPLR for different packet loss event
>> arrives at the receiver,
>> the receiver should immediately start a new timer for the second TPLR.
>> The length of the interval
>> can be estimated based on past observation or RTCP report round-trip
>> time or other means.
>> Does it make sense to you?
> 
> I am fine with individual timers for each TPLR report.

[Qin]:Okay.

> As before, I think how a receiver truly can estimate a reasonable timer
> needs discussion.

[Qin]:See above.

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