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

[Magnus Westerlund <[e-mail]>]

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.

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.

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.

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

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

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

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