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

[Qin Wu <[e-mail]>]

Hi, Tom:
Thank for your followingup comments. please see my replies below.
>----- Original Message ----- 
>From: "Van Caenegem, Tom (Tom)" <[e-mail]>
>To: "Qin Wu" <[e-mail]>; "'IETF AVTCore WG'" <[e-mail]>
>Sent: Tuesday, September 06, 2011 7:10 PM
>Subject: RE: comments on "draft-ietf-avtcore-feedback-supression-rtp-06"


>Qin,
>Appreciate your swift responses! Second round..
>Tom

________________________________

>From: Qin Wu [mailto:[e-mail]] 
>Sent: dinsdag 6 september 2011 11:03
>To: Van Caenegem, Tom (Tom); 'IETF AVTCore WG'
>Subject: Re: comments on "draft-ietf-avtcore-feedback-supression-rtp-06"


>Hi,Tom
>Thank for your early feedback to this new version and please see my replies below.

----- Original Message ----- 
>From: Van Caenegem, Tom (Tom) <mailto:[e-mail]>  
>To: 'IETF AVTCore WG' <mailto:[e-mail]>  
>Cc: Qin Wu <mailto:[e-mail]>  
>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". 


>Tom: yes, better. 

[Qin]: Good.

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

>Tom: I think it is worthwhile to clarify this in the ID, i.e. what "without proper" means in this context. I think you should add that the probability this will happen is of course dependent from the size of the >group of receivers.

[Qin]:Okay. Any proposed text?

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

>Tom: I am sorry I (still) do not understand this..  

[Qin]: what I am saying here is 
In general case, NACK can be sent either in multicast or in unicast.
Multicast NACK can be used to inform other receiver in the group not sending NACK but is not used to request the lost packet . 
Unicast NACK can be used by receivers to send retransmission requests to a specified media source for the specified lost packet.
When one receiver A detect packet loss wants to inform others not send NACK while all the other receivers want to request the same lost packet by sending retransmission request using NACK, 
However Multicast NACK from the receiver A may arrive late after multiple other receivers send unicast NACK to the same source for the same lost packet. In this case, multicast NACK from the receiver can not prevent other receiver from sending unicast NACK.
Does it make sense to you?

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



>Tom: IMO the main reason why this new message is defined is because an intermediate has received a packet loss indication that impacts a large group of receivers, and hence issues the TPL message to >those receivers to avoid FB implosion.  But alternatively, the intermediate may also send a NACK to avoid FB implosion.

>Examples:

>When the intermediate detects the loss itself, it should send a NACK, not a TPL. 

>When the packet loss indication to the intermediate is an RTCP NACK, it can either send a TPL message or  foward this NACK acting as a translator.

>I do not agree with your statement that sending a NACK is confusing to the receiver, and which seems to be a justification for defining the TPL message.

[Qin]:Just for clarification.
Firstly, in some cases, some receivers want to send unicast NACK to ask for the lost packet. Other receivers want to send multicast NACK or unicast NACK to inform other receivers in the same group not send NACK for the same loss event. In such cases, it does introduce confusion to the intermediary.
Secondly, NACK can be sent either to intermediary/media source for lost packet or sent from one receiver to other receivers to suppress them sending NACK, therefore in some case it is straightforward to the receiver, e.g., when there is very few downstream receivers, in some other cases when there is large number downstream receivers, they send a large number of NACK at the same time, simply forwarding NACK by intermediary from each downstream receiver introduce unnecessary NACK for the same packet loss multiple times. In this case, it seems the NACK forwarding only can be used to suppress each receiver sending a second new NACK out. The cost is if you have one hundred downstream receivers, they almost send NACK for the same loss at the same times, the intermediary is required to forward the NACK for the same loss one hundred times.
However if you use TPLR, there is no such issue since TPLR is defined as a message sent from the network to the receiver. When the intermediary is told about the packet loss, intermediary can filter duplicated NACK from each downstream receiver out for the same loss, then send only one TPLR in multicast channel to all the downstream receiver. Therefore the cost and complexity can be greatly reduced.
Does this make sense to you?

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



>Tom: it is true that we will complicate things here. But if the intermediate sending an RTCP TPLR needs to comply with the same rules as a normal RTP receiver, its feedback suppression will not be >(always) effective. A receiver that gets a TPL message should indeed simply comply with the same rules as getting a NACK when having detected the same packet loss (FB suppression from RFC 4585).

[Qin]:Okay,agree.

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

>Tom: I agree (see above), but my point is that an intermediate can in some cases also send/forward a NACK. In some cases not. 

[Qin]: Okay.


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

>Tom: it does matter: this "system: can for instance not be a simple (end) RTP receiver, otherwise forwarding the TPL messages goes against its intention: FB suppression!

[Qin]:Okay.

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

>Tom: If you want an example on how FB suppression interferes with retransmission, I rather prefer you to refer to the ID  "draft-vancaenegem-avtcore-retransmission-for-ssm-00" 

>.  I recall that the agreement on the exploder was that this WG draft will not discuss retransmission.

[Qin]:I disagree since this is not simply about how to deal with retransmission. When the receiver get the first TPLR, it set a timer to estimate when to receive the retransmitted packet or another TPLR, if it receive another TPLR, the timer should be restarted. If either retransmitted packet or another TPLR is not received, the receiver should fall back to normal receiver behavior as if there is no TPLR for suppression. I will do some rewording in this paragraph.

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

>Tom: well.. I am a bit lost here.. you describe SSM (RFC 5760), but where all receivers send multicast NACKs and they also send a unicast NACK to the DS?  Acoording to RFC 5760, a receiver only >sends unicast NACK to the FT (which can co-incide with the DS). If the receivers send multicast NACKs, this is about AnySourceMulticast.  

[Qin]:
 I agree this sentence does not apply to SSM case. According to RFC5760, in SSM, NACK from each downstream receiver is unicast to FT in the DS. The DS then sends NACK as multicast RTCP packet to all the downstream receivers.
Therefore I will remove it.
BTW: I suspect you can not define ASM as one receiver sending multicast NACK. For SSM session without Feedback Target, why does the receiver can not send multicast NACK?



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

>Tom: a media source is NOT supposed to send NACK message for packets it has sourced itself.  FB messages can only be sourced by receivers of that particular RTP stream 

[Qin]: I agree NACK should be sent from receiver of RTP stream rather than sender of RTP stream. However I still think TPLR can be sent from media source to the receiver if the media source have ways to know the loss.

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

>Tom: what you do is describing an architecture where TPL messages are only sent to a subset of all SSM receivers. 

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


>Tom:  FB suppression (via a NACK or a TPL) for such architecture is more detailed in  "draft-vancaenegem-avtcore-retransmission-for-ssm-00"   In order to avoid conflicts, I suggest to refer to this ID.

[Qin]: I think this case is just a general case to explain how to use TPLR in RAMS case, nothing else. I am not sure it really conflicts.

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

>Tom: if a receiver receives a TPL, my understanding is that it will not send a NACK anymore. If your understanding is different, please explain.  The receiver is NOT aware of any (second) loss.. it has >received a TPL message and if you say that this imposes a FB supression rule as described in RFC 4585, what more needs to be explained?
>I also do not understand why this "event" description is linked to this specific use case?  

[Qin]:Just clarification. The receiver is just temporarily hold NACK for a certain time. What receiver will do is to set a timer to wait for retransmitted packet or another TPLR, if either retransmission packet or another TPLR is received, the receiver will fall back to normal receiver behavior. 

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

>Tom: OK, worthwhile to mention this in the draft, and maybe you could consider to say why a translator would source a TPL message rather than FW-ing a NACK, or vice versa.

[Qin]: Okay. will do some rephrase in this section.



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

>Tom: agree, but the example is.. that the monitor send a NACK to the translator, so see my comment above.

[Qin]: See above.