Re: [AVTCORE] WG last call for RTCP Extension for Third-partyLoss Report (draft-ietf-avtcore-feedback-supression-rtp-09)

[Qin Wu <[e-mail]>]

Hi, Tom:
----- Original Message ----- 
From: "Van Caenegem, Tom (Tom)" <[e-mail]>
To: "Magnus Westerlund" <[e-mail]>; "IETF AVTCore WG" <[e-mail]>
Sent: Friday, January 20, 2012 11:48 PM
Subject: Re: [AVTCORE] WG last call for RTCP Extension for Third-partyLoss Report (draft-ietf-avtcore-feedback-supression-rtp-09)


>Hi Qin, Magnus,

>I have reviewed once more the draft, and these are my comments/questions...
>Thx
>Tom

>1)section 1


>There are cases where multiple receivers may initiate
>   the same, or an equivalent message towards the same media source.

>Suggest to have : There are cases where multiple receivers may initiate
>   the same, or an equivalent message towards the same media source or same feedback target.

[Qin]: Okay.

>2)section 1

>One common cause of such a
>   feedback storm is receivers utilizing RTP retransmission [RFC4588] as
>   a packet loss recovery technique, sending feedback using RTCP NACK
>   messages [RFC4585] without proper dithering of the retransmission
>   requests (e.g., not implementing the RFC 4585 dithering rules or
>   sending NACKs to a middlebox that doesn't redistribute them to other
>   receivers).

>Suggest to reposition the ")"  and use "feedback target" iso "middlebox"  (aligned with the vocabulary in the abstract)  and add additional clarification:
>One common cause of such a
>   feedback storm is receivers utilizing RTP retransmission [RFC4588] as
>   a packet loss recovery technique, sending feedback using RTCP NACK
>   messages [RFC4585] without proper dithering of the retransmission
>   requests (e.g., not implementing the RFC 4585 dithering rules) or
>   sending NACKs to a feedback target that doesn't redistribute them to other
>   receivers and where as a consequence the required feedback suppression behaviour of RTP receivers conforming to RFC 4588 is not activated.

[Qin]: Okay.

>3)section 1 

>RTCP feedback storms may cause short term overload, and in extreme
>   cases to pose a possible risk of increasing network congestion on the
>   control channel (e.g.  RTCP feedback), the data channel, or both.  It
>   is therefore desirable to provide a way of suppressing unneeded
>   feedback.

>I think this paragraph has some issues:-can you give an example on where lack of RTCP FB suppression message increases data channel congestion-"it is therefore desirable to (..) suppressing unneeded >feedbackWhat is meant with "unneeded" feedback?.. 

[Qin]: Regarding examples, I like to point you to look at the 1st paragraph and 2nd paragraph of Introduction section and two examples are clearly given over there. 

>from a receiver point of view, the feedback mechanism is desiredas it wants to inform it is missing a packet (and requesting a retransmission). From the >retransmission server point of view, this feedback is >also desired as it wants to know who is missing a packet so it can follow-up with a retransmission.So, instead, just state: "It is therefore desirable to >provide a way of suppressing feedback". I think it >would be better to highlight that feedback suppression has the obvious effect that the receiver may not receive -in time- a retransmission, (but further >disusison is outside the scope of this document), so it >would be good to add:"Such dedicated feedback suppression has as consequence that the receiver can be (temporarily) deprived from its repair service" 


>4) I still feel uncomfortbale with the paragraph:

>"One approach to this, suggested in [DVB-IPTV], involves sending a
>   NACK message to the other clients (or receiver) in the same group as
>   the sender of NACK.  However NACK is defined as a receiver report
>   sent from a receiver observing a packet loss, therefore it only
>   inform others that sender of NACK detected loss while the case where
>   the sender of the feedback has received reports that the indicated
>   packets were lost is not covered. 

>I suggest to delete this as it is more elaborated upon in the retransmission-for-ssm draft  (which reflects the same topology as addressed by DVB)

[Qin]: Okay.

>5) section 3

>The Third Party Loss Report
>   (TPLR) message is generated by a RTP system that may not seen the
>   actual packet loss.  It is sent following the same timing rule as
>   sending NACK defined in [RFC4585]. 

>Q: what is RTP system?  Can it be an RTP receiver?

[Qin]: No, I propose to change RTP system into intermediary for consistency.

>Q: would be good to add a section reference to RFC 4588 wrt the timing rule

[Qin]: Okay.

>6) section 3

>"RTP Systems in the network that
>   receive a Third Party Loss Report SHOULD NOT send their own
>   additional Third Party Loss Report messages for the same packet
>   sequence numbers.  They should simply forward the Third Party Loss
>   Report message received from upstream direction, additionally, they
>   may generate their own Third Party Loss Report that.."

>Q: forward to whom?

[Qin]: to the reciever(s), will add this into the update.

>7) section 3, editorial (I think!);

>When a receiver gets a Third Party Loss Report message, it should
>   follow the rules for NACK suppression in RFC 4585 and refrain from
>   sending a feedback request (e.g., NACK or FIR) for the missing
>   packets reported in the message,which is dealt with in the same way
>   as receiving NACK.

>Suggest to delete ",which is dealt with in the same way
>   as receiving NACK.", as being redundant...

[Qin]: Okay.

>8) section 3

>"To increase the robustness to the loss of a TPLR or of a transmission
>   RTP data packet, TPLR or the RTP packet for the same missing Packet
>   may be retransmitted when RTP systems are aware that the same packet
>   loss occurs again.  If the additional TPLR arrives at receiver, the
>   receiver should deal with the additional TPLR in the same way as
>   receiving the first TPLR for the same packet and no additional
>   behavior for receiver is required.  When the retransmitted packet is
>   received by the receiver,it should take its normal behavior as if
>   there is no current feedback suppression."

>A couple of items here:

>-do you mean "..of a REtransmission RTP data packet"?  Not sure why you link multiple transmissions of TPLR with multiple transmissions of a retransmission packet?

>-" when RTP systems are aware that the same packet loss occurs again" 
>Do you mean the loss of the TPLR message?-the sentence is anyhow strange because when you start the sentence as you did (to increase the robustness..), isn't there a silent assumption that the RTP >"system" is NO aware that the packet loss occurs again? 

[Qin]:You are right, will remove this.

>-"When the retransmitted packet is
>   received by the receiver,it should take its normal behavior as if
>   there is no current feedback suppression."

>Feedback suppression is based/defined on a per packet basis or group of packets' basis (as announced in the TPLR).. so if a (retransmission) packet is received by RTP receiver, there is no longer a need >to send feedback ( a NACK) by the receiver... So what is the normal behaviour here?


[Qin]: You are right, since packet loss recovery mechanism is not focus of this document, I propose to remove the part about multiple transmissions of a retransmission packet from the above paragraph.

>9) section 3:

>"Since Third Party Loss Report interacts strongly with repair timing,
>   it has to work together with feedback to not adversely impact the
>   repair of lost source packets.  In order not to incur a lot of NACK
>   requests due to additional TPLR described above, it is recommended
>   that the RTP system sending TPLR should be implemented more closer to
>   the media source.  When the loss was detected and repair initiated
>   much closer to the media source, the delay for the receiver to
>   recover from packet loss can be reduced through the combination of
>   intermediary feedback to the source and Third Party Loss Report
>   downstream."

>-what do you mean with TPL reports must work together with feedback? It supresses feedback! 

[Qin]: A TPLR is sent to inform some participants in a session about feedback they would not otherwise see, and so the sender of the TPLR has to work together with the sends of NACKs to ensure that appropriate reports are sent to all receivers.

>This paragraph is quite problematic for me.. you cannot really make statements on proximity of systems without topology considerations..

>-what does "incur a lot of NACK requests" mean ?

>-I do not understand how an RTP system sending TPLR operating in proximity to the media source can help here.. as the RTP system sending the TPL needs to wait for a NACK ..from a receiver, before >sending a TPLR, this will not really help.

[Qin]: I agree with you that this draft shouldn't talk about topology. To avoid further confusion, I propose to remove this paragraph.