Re: [AVTCORE] I-D Action:draft-ietf-avtcore-feedback-supression-rtp-07.txt

[Qin Wu <[e-mail]>]

Sorry for late reply. please see inline.
----- Original Message ----- 
From: "Colin Perkins" <[e-mail]>
To: "Qin Wu" <[e-mail]>
Cc: <[e-mail]>
Sent: Tuesday, October 11, 2011 10:13 PM
Subject: Re: [AVTCORE] I-D Action:draft-ietf-avtcore-feedback-supression-rtp-07.txt


Qin,

On 11 Oct 2011, at 09:11, Qin Wu wrote:
> Hi, Colin:
> Thank for your careful review, please see my replies belows.
> 
> Regards!
> -Qin
> ----- Original Message ----- 
> From: "Colin Perkins" <[e-mail]>
> To: <[e-mail]>
> Sent: Tuesday, October 11, 2011 5:46 AM
> Subject: Re: [AVTCORE] I-D Action:draft-ietf-avtcore-feedback-supression-rtp-07.txt
> 
> 
>> On 26 Sep 2011, at 09:17, [e-mail] wrote:
>>> A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Audio/Video Transport Core Maintenance Working Group of the IETF.
>>> 
>>> Title           : RTCP Extension for Third-party Loss Report
>>> Author(s)       : Qin Wu
>>>                         Frank Xia
>>>                         Roni Even
>>> Filename        : draft-ietf-avtcore-feedback-supression-rtp-07.txt
>>> Pages           : 16
>>> Date            : 2011-09-26
>>> 
>>>  In a large RTP session using the RTCP feedback mechanism defined in
>>>  RFC 4585, a feedback target may experience transient overload if some
>>>  event causes a large number of receivers to send feedback at once.
>>>  This overload is usually avoided by ensuring that feedback reports
>>>  are forwarded to all receivers, allowing them to avoid sending
>>>  duplicate feedback reports.  However, there are cases where it is not
>>>  recommended to forward feedback reports, and this may allow feedback
>>>  implosion.  This memo discusses these cases and defines a new RTCP
>>>  third-party loss report that can be used to inform receivers that the
>>>  network is aware of some loss event, allowing them to suppress
>>>  feedback.  Associated SDP signalling is also defined.
>>> 
>>> 
>>> A URL for this Internet-Draft is:
>>> http://www.ietf.org/internet-drafts/draft-ietf-avtcore-feedback-supression-rtp-07.txt
>> 
>> 
>> I have read this draft, and have some comments:
>> 
>> - Section 1, 1st paragraph: "(e.g, implementing the RFC 4585" - should this be "(e.g., not implementing the RFC 4585"?
> 
> [Qin]:It is a typo and my mistake. Thank for catching it.
> 
> 
>> - Section 3, 3rd paragraph, says the "timer value shall be based on the observed round-trip time", but it's not clear that this means. By based on, do you mean equal to the RTT, or some other function derived from it? Which RTT? The suppression, ideally, wants to be for long enough for the sender of the TPLR to somehow repair the loss at all of its downstream receivers, so none of them need to resend a NACK. This might imply the RTT from the receiver to the original media source and/or repair server be used, which is different from the RTT specified. I think some more thought is needed here.
>> 
> 
> [Qin]: See my discussion with Magnus in the previous email on this thread. But that need some corrections. I think you are right, If the middlbox is repair server, more approximate RTT is the RTT from the receiver and repair server. If the original media is repair server, more approximate RTT should be 1/2 of RTT between the middlebox and receiver plus RTT from middlebox to media source. But if the middlebox sending TPLR is more close to media source, one RTT from middlebox to media source can be omitted.

How does the receiver of the TPLR know the RTT value to use? It doesn't seem to have the information it needs to calculate this.

[Qin]: yes, the receiver doesn't have enough information to calculate more precise RTT unless unless the middlebox tell the receiver the RTT from original source to the middlebox.

 But the receiver can calculate one coarse RTT from receiver to the original media source or repair server and use this RTT as one approximate RTT since we assume the middlebox is near to the original media source.



>> - Section 3, 4th paragraph: "In the case the first TPLR is lost and the additional TPLR arrives at the receiver, the receiver should immediately refresh the timer" - sure, but what else would it do? This makes it seem that something different is done in this case, but the behaviour looks to be the same whether or not a TPLR is lost.
> 
> [Qin]: Assume the middlebox sending NACK upstream and TPLR downstream at the same time,refresh timer means waiting for one RTT from media source to get the retransmitted RTP data packet after getting that additional TPLR, however if the middlebox itself is repair server, the timer should be same irrespectively a TPLR is lost, i.e., 1/2 RTT from middlebox to the receiver.

I don't understand. The receiver of a TPLR cannot know if a previous TPLR has been lost, therefore it will behave the same in both cases.


[Qin]: your understanding, but if we want the receiver of TPLR know if a previous TPLR is lost, we can add repetition count field. This field can be used to specify the number

 of times the TPLR with the same SSRC has been retransmitted.

Do we allow such extension?

>> - Section 6.3: if a monitor co-located with a translator detects a loss, why does that monitor not send a NACK? Not clear what's the reason for using a TPLR here.
> 
> [Qin]:That's becos translator has a monitor, which told translator to send TPLR, if translator has no monitor and receives NACK from a receiver, this receiver should forward NACK directly. Does this clarify?

No, since an RTCP translator can't send a TPLR as it doesn't have an SSRC. The monitor has its own SSRC, and so can send RTCP reports, and should send a NACK packet since it is the monitor that detects the loss.

[Qin]: I believe you are right. How about say "RTCP translator acting as monitoring send NACK while translator without monitoring functionality just forward TPLR from its upstream to the downstream session participant
in the same way as forwarding other RTCP traffic.

>> - Section 6.5: the behaviour described makes sense for an RTP-terminating mixer, but an RFC 3550 mixer could just forward the FIR or PLI messages without using the TPLR, no?
> 
> [Qin]: According to Section 7.3 of RFC 3550, a mixer must not forward RTCP unaltered between
>   the two domains, also according to section 3.4 of RFC5117, In some cases, the reception
>   of a codec-control message may result in the generation and
>   transmission of RTCP feedback messages by the Mixer to the
>   participants in the other domain.  
>  So I think this is not a issue.

I disagree. There are two valid ways to process RTCP FIR or PLI messages in a mixer: either do as you describe and send a TPLR message, or forward the FIR/PLI to all participants. Both are valid behaviours, yet your draft only mentions one of them. It should mention both.

[Qin] Okay, I agree both approaches are possible. I will make this clear in the relevant text.


-- 
Colin Perkins
http://csperkins.org/