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

From: Magnus Westerlund <[email-masked]>
Date: Thu, 19 Jan 2012 15:44:34 +0100

WG,

This is to announce the start of a 2 week WG last call for the
"RTCP Extension for Third-party Loss Report"
with intended status of standards track. The WG last call ends on the
3rf of February.

There is no known IPR disclosure against this draft.

https://datatracker.ietf.org/doc/draft-ietf-avtcore-feedback-supression-rtp/?include_text=1

Cheers

Magnus Westerlund

----------------------------------------------------------------------
Multimedia Technologies, Ericsson Research EAB/TVM
----------------------------------------------------------------------
Ericsson AB                | Phone  +46 10 7148287
Färögatan 6                | Mobile +46 73 0949079
SE-164 80 Stockholm, Sweden| mailto: [email-masked]
----------------------------------------------------------------------

---

From: Magnus Westerlund <[email-masked]>
Date: Thu, 19 Jan 2012 15:48:40 +0100

Hi,

I have a few comments that I propose have addressed after the WG last
call. I only consider two of those as having any real substance. I
believe the document to ready for publication request when these issues
has been addressed. And when I say addressed, I mean discussed and a way
forward agreed on and that implemented if need. It may very well be to
say that my opinion is rough in regards to the WG's.

1. Section 4.2:

Synchronization source (SSRC):32 bits

      The SSRC value of the media source that is requested to send a
      decoder refresh point or that is indicated that it lost
      synchronization with the video stream.

I think this definition is wrong. Shouldn't it be the SSRC for who's
media stream the media sender is already aware of an expressed need for
taking action that a PLI or FIR reqiests of this SSRC?

I don't think the above is the right text for the spec, but I just
trying to express what the right type of definition would be.

2. Section 5.

"A new feedback value "tplr" needs to be defined for the Third Party
   Loss Report message to be used with Session Description Protocol
   (SDP) [RFC4566] using the Augmented Backus-Naur Form (ABNF)
   [RFC4585]."

I do wonder, do we really need to define a new feedback value? If this
already is associated either with generic NACK, with uses just "nack" or
PLI which is "nack pli" or FIR which is "ccm fir" on the a=rtcp-fb line.
 Wouldn't it be more natural to use "nack tllei" and either "nack pslei"
or "ccm pslei"?

NITS

N1. Section 3:
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.

and

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

Missing space after comma.

N2. Section 3.

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.

Strange sentence. "more closer" is probably best reduced to just
"closer". However, closer would benefit from a "closer to the media
source than ..."

N3. Section 4.1,

Within the common packet header for feedback messages (as defined in
   section 6.1 of [RFC4585]), the "SSRC of packet sender" field
   indicates the source of the request, and the "SSRC of media source"
   denotes the media sender of the flow for which the indicated losses
   are being suppressed .

additional space at the end of the sentence.

N4. Section 4.1.
  "The BLP's definition is identical to that given in [RFC4585]."

I think a section reference into RFC4585 is recommended.

N5. Section 4.2:

FIR [RFC5104]or PLI [RFC4585].

Missing space between first ref and "or".

And should shouldn't that "or" be an "and"? The message can suppress
both FIR and PLI messages.

N6. When using references, like in section 6.1:
"In SSM RTP sessions as described in [RFC5760], ..."

It would be much clearer if one included the title of the RFC before the
reference, like this:

In SSM RTP sessions as described in "RTP Control Protocol (RTCP)
Extensions for Single-Source Multicast Sessions with Unicast Feedback"
[RFC5760], ...

N7. Section 6.1:
"since the summary feedback does not
   mandate the forwarding of NACK downstream."

Missing initial capital letter on Since.

N8. Section 6.3:
If the translator acting as quality monitor [Monarch]is
   aware of packet loss, it may use the SSRC of monitor as packet sender
   SSRC to create NACK message and send it to the receivers that is not
   aware of packet loss.

it should be the "the monitor" and missing space after [Monarch]

Cheers

Magnus Westerlund

---

From: "Van Caenegem, Tom (Tom)" <[email-masked]>
Date: Fri, 20 Jan 2012 16:48:03 +0100

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.

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.

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?.. 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.  This document specifies a new
   third-party loss report for this function.  It supplements the
   existing the use of RTCP NACK packet and further is more precise in
   the uses where the network is active to suppress feedback."

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)

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?

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

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?

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

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

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? 

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

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

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

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

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

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of Magnus Westerlund
Sent: donderdag 19 januari 2012 15:45
To: IETF AVTCore WG
Subject: [AVTCORE] WG last call for RTCP Extension for Third-party Loss Report (draft-ietf-avtcore-feedback-supression-rtp-09)

WG,

This is to announce the start of a 2 week WG last call for the "RTCP Extension for Third-party Loss Report"
with intended status of standards track. The WG last call ends on the 3rf of February.

Cheers

Magnus Westerlund

_______________________________________________
Audio/Video Transport Core Maintenance
[email-masked]
https://www.ietf.org/mailman/listinfo/avt

---

From: Qin Wu <[email-masked]>
Date: Mon, 30 Jan 2012 17:03:43 +0800

Hi, Magnus:
Thank for your valuable comments, please see my replies inline below.

Regards!
-Qin
----- Original Message ----- 
From: "Magnus Westerlund" <[email-masked]>
To: <[email-masked]>; <[email-masked]>
Sent: Thursday, January 19, 2012 10:48 PM
Subject: Re: [AVTCORE] WG last call for RTCP Extension for Third-party Loss Report (draft-ietf-avtcore-feedback-supression-rtp-09)

Hi,

1. Section 4.2:

[Qin]: Agree. How about changing the text as:
"
Section 4.2:

      The SSRC value of the media source that has already been aware the
      receiver lost synchronization with the video stream and signal to
      the receiver not sending a decoder refresh point
"

2. Section 5.

[Qin]: Make sense, I will use "nack tllei" and "nack pslei" instead of defining new feedback value "tplr".

NITS

N1. Section 3:

and

[Qin]: Fixed.

N2. Section 3.

[Qin]: Fixed.

N3. Section 4.1,

[Qin]: Fixed.

N4. Section 4.1.

[Qin]: Fixed.

N5. Section 4.2:

[Qin]: Fixed.

[Qin]: Fixed.

N7. Section 6.1:

[Qin]: Fixed.

N8. Section 6.3:

[Qin]: Fixed.

Cheers

Magnus Westerlund

---

From: Qin Wu <[email-masked]>
Date: Tue, 31 Jan 2012 10:37:21 +0800

Hi, Tom:
----- Original Message ----- 
From: "Van Caenegem, Tom (Tom)" <[email-masked]>
To: "Magnus Westerlund" <[email-masked]>; "IETF AVTCore WG" <[email-masked]>
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)

>   the same, or an equivalent message towards the same media source or same feedback target.

[Qin]: Okay.

>   receivers and where as a consequence the required feedback suppression behaviour of RTP receivers conforming to RFC 4588 is not activated.

[Qin]: Okay.

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

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

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

>Q: forward to whom?

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

>   as receiving NACK.", as being redundant...

[Qin]: Okay.

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

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

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

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