Re: [AVTCORE] comments on "draft-ietf-avtcore-feedback-supression-rtp-06"

On 6 Sep 2011, at 10:02, Qin Wu wrote:
> Hi,Tom
> Thank for your early feedback to this new version and please see my replies below.
> ----- Original Message -----
> From: Van Caenegem, Tom (Tom)
> To: 'IETF AVTCore WG'
> Cc: Qin Wu
> Sent: Monday, September 05, 2011 11:30 PM
> Subject: comments on "draft-ietf-avtcore-feedback-supression-rtp-06"
> 
> >Hi Qin
> >these are my comments on "draft-ietf-avtcore-feedback-supression-rtp-06"
> >Regards
>  
> >1)Abstract:
> >'This memo discusses these cases and defines a new RTCP third-party loss report that can be used to inform receivers that a feedback target is aware of some loss event."
> 
> >Comment:  "feedback target" is only defined in RFC 5760. Please use terminology that does not limit to RFC 5760 architectures (unless this is what this ID is after?)
> 
> [Qin]: Okay, how about say “the network” instead of saying “Feedback target”.
> 
> 2)Intro, first paragraph:
> 
> >"One common cause of such a feedback storm is receivers utilizing RTP retransmission [RFC4588] as a packet loss recovery technique based, sending feedback using RTCP NACK messages
> 
> >[RFC4585] without proper dithering of the retransmission requests."
> 
> >Comment: what is meant with "without proper dithering"?  Is this about RTP Rx not behaving according to RFC 4585 when sending RTCP FB messages?  Please clarify.
> 
> [Qin]: No, it is in accordance with RFC4585. Dithering means wait for random time to send NACK. However in some cases, multiple recievers may wait for almost the same time without seeing a corresponding FB message from any other receiver reporting the same event  and then send its own NACK. After they sent out NACK, these receivers then recieved the late NACK from each other reporting the same event.
> 

While you're not guaranteed that only one NACK is sent, I don't think that will cause a NACK storm, provided the RFC 4585 dithering rules are correctly implemented. The main reasons I see that can cause a NACK storm are 1) not implementing the RFC 4585 dithering rules; or 2) sending NACKs to a middlebox that doesn't redistribute them to other receivers (e.g., a RTCP SSM box using summary feedback) and hence preventing the dithering rules from working. 

> Another rationale is multiple receivers May still send NACK to the same source to ask for the lost packet besides Sending NACK to the other recivers in the same group,
> Therefore sending NACK to the other recievers in the same group is not enough to prevent NACK is recieved by the same source that posses the lost packet. Hope this clarifies.
> 
> >To elaborate further here: what I (still!) miss in this section is a clear description of  the rationale why this ID defines a new RTCP message. IMO the baseline should be as follows for this section:
> 
> >-RFC 4585 does include feedback suppression
> 
> >-For some RTP topologies and/or policies, RFC 4585-based suppression (based on a receiver receiving a FB message from another receiver) may not be adequate or not possible. Provide examples for >such RTP topologies/policies.
> 
> [Qin]: See above.
> 
> >Maybe another reason could be that there is a timing aspect that is different from RFC 4585 (I concur with Magnus that the timing aspect is indeed something that must be >addressed)
> 
> [Qin]: The timing rule of sending new message could be same as the timing rule of sending NACK.
> 
> I am afraid additional timing rule is not needed.
> 
> >IMO, the above rationale is the one reason to define a new message.Your text suggests that one reason for defining this TPL message is that receiving a NACK for an RTP receiver (and which enables >suppression, the feature this ID is about) is confusing towards that receiver. How can this be, if it is part of RFC 4585? 
> 
> [Qin]: How the sender of TPLR message is told about packet loss is not focus of this document. Receiving NACK
> 
>  from a receiver that detects pakcet loss is just one way or example. There may be other ways,e.g., receiving receive report that convey packet loss event.
> 
> >3)Protocol overview, 2nd paragraph
> 
> >"When a receiver gets a Third Party Loss Report message, it should refrain from sending a feedback request (e.g., NACK or FIR) for the missing packets reported in the message for a certain period of >time.'
> 
> >Comment: why don't you mandate (...MUST refrain from sending..) the suppression (in the same way it is mandated by RFC 4585?)
> 
> [Qin]: Okay, I think it makes sense.
> 
> >4)Protocol overview, 3rd paragraph
> 
> >'Systems that receive a Third Party Loss Report SHOULD NOT initiate their own additional Third Party Loss Report messages for the same packet sequence numbers. They may either simply forward >the Third Party Loss Report message, or they may generate their own Third Party Loss Report that reports a set of the losses they see, which are different from ones reported in the Third Party Loss >report they received."
> 
> >Comment: "systems" (these are entities, right?) that observe packet losses themselves , can only issue/source NACKs, not TPL reports
> 
> [Qin]:Your are right, but this is irrevelant to this paragraph. This paragraph focuses on how to deal with recieved TPL report.
> Systems could be any RTP Systems or RTP node. It doesn’t matter.
> 
> >5)Protocol overview, 4th paragraph
> 
> >I really do not understand this paragraph.. are you describing a situation where an intermediate should not send a TPL report?
> 
> [Qin]: This paragraph explaines TPL report usage should not conflict with packet loss repair mechanism and gives a example explain this. The example mostly focuses on how receiver deals with second loss (i.e., retransmission packet loss when TPLR is used) raised by Janathan.
> 
> >6)Protocol overview, general comment:
> 
> >What I miss in this section is some text/clarification in which RTP session, using which SSRC, this TPL message is transmitted. E.g. in case of a DS in summary feedback model which gets a nack from >one or more receivers, and this DS decides to send a TPL message. It will do so using its  own SSRC and I guess it will send it inside the SSM. . but what about other topologies like RAMS.. see my >note number 10.
> 
> [Qin]: Section 3 is about the semantic of TPLR and how to deal with TPLR by sender, middlebox and receiver and is not specific to any case. As regarding how SSRC is chosen has been clarified in the section 6 (use case section) and section 4 (message format section).
> 
> >7) section 6.1. first paragraph
> 
> >"Note that each receiver sending multicast NACK to its group may still need to send unicast NACK addressed to the media source or distribution source for lost packets, this may lead to a NACK >storm if feedback suppression is not performed and if the RTCP bandwidth limit is misconfigured."
> 
> >Comment: are you suggesting that TPL reports are a way to deal with the lack of FB suppression at Rx or with misconfigured limits? If not, please delete this sentence.
> 
> [Qin]: Yes, TPL report is necessary when multiple receivers still send NACK to the source to ask for lost packet at the same time, in this case, FB suppression at Rx to suppress other receiver sending NACk is not adequate.
> 
> >8) section 6.1. general
> 
> >The main message in this section is that SSM in summary feedback model may generate TPL reports and when operating in simple feedback model, the DS will simply forward received NACKs.  There >is IMO unneeded repititions in paragraph 2 and 3, and there is also text on intermediate nodes (different from DS/FTs and receivers) in the 3rd paragraph that are NOT specific to SSM architecture, i.e. >unneeded and confusing.  
> 
> [Qin]: Okay and will fix it in the new version.
> 
> >9) section 6.1. last paragraph
> 
> >A "media source" in SSM architecture has no direct relationship with the SSM receivers. So, the media souurce will not send a RTCP NACK to all receivers... What it can do is sending a NACK to the >DS, which then distributes via the SSM to all receivers. However I am not sure that a source can send a NACK?..This is ..well.. indeed confusing!
>  
> [Qin]: The example for media source to send NACK is the case when DS/FT is collocated with media source. In this case, the loss was detected and repair initiated much closer to the source
>  
> >10) section 6.2.
>  
> >The meat in this section is about the capability of a BRS to send a TPL message using its own SSRC to its receivers on the downstream link...
>  
> [Qin]: More exact to say, the section 6.2 focuses on when one branch of SSM tree encounter packet loss, how TPL is used to suppress other receiver sending unnecessary message.
>  
>  >But you do not specify how this happens.. Is this in >dedicated unicast sessions or in dedicated SSM? How are these sessions than associated with the original SSM for which a TPL message has been >created?
>  
> [Qin]:It does not matter it is in unicast session or SSM. But using TPL report in SSM session is more useful than in unicast session.
> Also I think it is not focus of this case to describe the association between different session.
>  
> >The second paragraph is more about retransmission and implementation  choices and should be deleted IMO
>  
> [Qin]: No, this second paragraph is about how the receiver deal with second loss raised by Janathan when TPL report has been applied. It is relevant.
>  
> >11)section 6.3
>  
> >Please explain why forwarding the NACK in the transport translator use case -which is the supposed activity of a transport translator- is not a possibility here ( iso mapping it to a TPL message). 
> >(Note again that both result in FB suppression!)
>  
> [Qin]:Firstly I think either forwarding NACK or TPLR messaage work and we are not mandating using TPLR message.
> Seconly, receiving NACK is not only way for RTP translator to be told by packet loss. what the translator is a quality monitor it may receive the packet loss not as NACKs but as part of the receiver reports and send TPL message. Here this case just gives an example.
>  
>  
>  
>  
> 
>  
> _______________________________________________
> Audio/Video Transport Core Maintenance
> avt@ietf.org
> https://www.ietf.org/mailman/listinfo/avt

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