Subject: Re: [AVT] New Version Notification for draft-wu-avt-retransmission-supression-rtp-03

From: Qin Wu <[email-masked]>
Date: Fri, 15 Oct 2010 15:17:58 +0800

Hi, 
Thank for your comments, please see my reply inline.

Regards!
-Qin
> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]] On Behalf Of 
> Van Caenegem, Tom (Tom)
> Sent: Tuesday, October 12, 2010 4:35 PM
> To: Qin Wu; [email-masked]
> Subject: Re: [AVT] New Version Notification for draft-wu-avt-
> retransmission-supression-rtp-03
> 
> Hi Qin,
> 
> these are my comments on the draft 3 version:
> 
> -you know of course that DVB IPTV has defined a solution to addres 
> NACK storms. This solution was recently also adopted by OIPF. You 
> propose to define a new dedicated message for NACK suppression, 
> whereas in DVB/OIPF we defined that when an RTP receiver gets such a 
> NACK message, this receiver should not send a NACK itself (provided 
> the NACK was received before the receiver sends its own NACK). In a 
> similar way, this could also be defined for FIR messages. I have no 
> fundamental problem if AVT  decides to define a dedicated message, but 
> can you provide arguments why a NACK sent by the distribution 
> source/translator in a SSM to the client is not good enough for 
> imposing NACK suppression to a receiver, by definition?
> 
> -a general comment: suppressing NACKs from receivers is a very tricky 
> thing. Sometimes it may do more harm than do any good, and I feel this 
> discussion and possible negative impact is not really addressed in 
> this draft.

I am not sure what you mean here. The receivers do not suppress NACKs, the NACK suppression is sent by intermediary devices.

TOM: Sure. The draft basically specifies the Suppression message. But in terms of intermediate source/receiver behaviour, my read-out is as follows: 
1)a intermediate source can send at any time a NACK suppression

[Qin]: No, the intermediate source follows the timing of RTCP feedback messages
  defined in the Audio-Visual Profile with Feedback (AVPF).  

2)there is no normative language for the receiver what to do when this message is received

[Qin]: You may look at the new version of draft-wu-avt-retransmission-supression-rtp:
http://www.ietf.org/internet-drafts/draft-wu-avt-retransmission-supression-rtp-04.txt
According to normatve text of section 3 of draft-wu-avt-retransmission-supression-rtp-04:
the receiver will be silent when it receives feedback suppression message.
A receiver may still have sent a Feedback message before receiving a feedback suppression
 message, but further feedback messages for those sequence numbers
 will be suppressed by this technique.

In the text, the intermediate source seems to rely on a NACK from a "loss reporter" for sending NACK suppression messages. Is this some kind of trusted device? Can it always be guaranteed that the packets this loss reporter receives or does not receive, are the same packets received/not received for all receivers that get the NACK suppression (and optional the retransmission afterwards)? Why would a receiver not systematically send the NACK anyhow -even if it does understand the suppression message, to maximise its chance of getting a retransmission.. This is the kind of discussion that should be included IMO.

[Qin]: No, according to discussion so far on the list, relying on dedicated reciever as loss reporter to report packet loss by sending existing NACK may have some impact the performance. 
the intermediate source may has its own loss detection functionality and should not rely on NACK from such dedicated receiver disjointed from intermediate source.
So I have remove the case relying on NACK from a loss report from this draft. Hope this clarfiies.
Also I have moved the text associated with use cases to the example use case section. So they are just one example.

> 
> -in your figure 1, the SSM is sourced by the intermediate source which 
> hosts the feedback target and a "loss reporter". This does not 
> represent a realistic architecture as it would mean that for IPTV 
> scenario the head-end receives all RTCP messages from all receivers.
> You should include architectures where FT are decoupled from the SSM 
> source.

This is not IPTV specific feature so this is an example. There can be other cases.

TOM: The (only) figure in the draft (entitled "system architecture") shows that the "intermediate source" is sourcing the SSM, hence is also the distribution source. The draft is also explicit about this as it says: "The intermediate source must be able to communicate with all group members in order for either mechanism to be effective at suppressing feedback" 

This means that scenarios/architectures as addressed with RAMS (where the BRS is co-located with the FT which is in general separate from the DS) are outside the scope of this work?

[Qin]: Thank you for pointing out this. You may not realized we have removed this ambiguity in the new version of draft-wu-avt-retransmission-supression-rtp
http://www.ietf.org/internet-drafts/draft-wu-avt-retransmission-supression-rtp-04.txt
The main changes is:
a. Move the last 6 paragraph to the protocol overview section.
b. Remove the ambiguity text from protocol overview section and add some text in the SSM use cases section.
This architecture will focus on specifying more generic mechanism and discuss how the mechanism works in the different use cases including the scenario as addressed with RAMS.

> 
> -the definition of the "loss reporter" is somewhat obscure to me. From 
> various text fragments, it appears that a (NACK) FB message sent by 
> the loss reporter, will result in the intermediate source/distribution 
> source sending  a NACK storm suppression or FFS message to the clients 
> in the group.  This means to me that any packet loss reported by the 
> "loss reporter" is packet loss that will impact all receivers 
> downstream of the intermediate/distribution source. If this is not the 
> case, you will provide unneeded retransmissions. Is this a correct 
> interpretation? If so, please make this clear in the definition of 
> "loss reporter". If it is not, then mandating that getting a NACK from 
> a loss reporter results in a FFS message, is not recommended IMO.

The draft only says the intermediate device will send NACK suppression and leaves open the application behavior in the upstream side. The discussion so far suggested that it should be out of scope for the draft.

TOM: My remark here was about the "loss reporter" concept, not about how -"plain normal"- receivers should respond on the NACK suppression message. As written above, the draft's architecture in which you position the NACK suppression seems restricted and not covering RAMS architecture.

[Qin] See above.

> 
> -I do not understand why a "loss reporter" MUST not receive the FFS 
> message -which is meant to be sent on the SSM-, and I also do not get 
> how you can avoid that the "loss reporter" would receive this FFS 
> message, as a "loss reporter" that is downstream of the intermediate 
> source must be receiving the SSM in order to detect missing packets.
> 
> -you introduce the "immediate reporting RTP client" terminology from 
> the DVB IPTV spec that is referenced, but its definition does not 
> align with how it is defined in the DVB spec. So, please,  either 
> stick to the DVB definition or use a different term.

TOM: I hope above two comments will be addressed and further discussed as well, 

[Qin]: Based on the discussion with Ingemar, David, Ali and you, it seems the discussion suggest that relying on NACK from dedicated receiver is not a good idea and has some harm. So I have removed this use case from the draft. 
Do it make sense?

and I have another question: the draft defines how one can signal in SDP, support for the NACK suppression.  Is that for SDP to be received by the RTP receivers?

[Qin]: Yes, the reciever should understand feedback suppression message.

 If so, why must that be declared in the SDP?

[Qin]: Any other choice? what's your proposal?

Thx
Tom

> 
> Regards
> Tom
> 
> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]] On Behalf Of 
> Qin Wu
> Sent: zaterdag 9 oktober 2010 6:49
> To: [email-masked]
> Subject: [AVT] New Version Notification for draft-wu-avt-
> retransmission-supression-rtp-03
> 
> Folks,
> 
> We have updated draft-wu-avt-retransmission-suppression-rtp which 
> should now reflect the discussion we had since IETF78.
> 
> The feedback suppression solution has also been greatly generalized 
> comparing to the previous version.
> 
> Comments are solicited.
> 
> Regards!
> -Qin
> ----- Original Message -----
> From: <[email-masked]>
> To: <[email-masked]>
> Sent: Saturday, October 09, 2010 12:45 PM
> Subject: I-D Action:draft-wu-avt-retransmission-supression-rtp-03.txt
> 
> 
> >A New Internet-Draft is available from the on-line Internet-Drafts
> directories.
> >
> > Title           : RTCP Report Extension for Feedback Suppression
> > Author(s)       : W. Wu, et al.
> > Filename        : draft-wu-avt-retransmission-supression-rtp-03.txt
> > Pages           : 24
> > Date            : 2010-10-08
> >
> > This document specifies an extension to the RTCP feedback messages 
> > defined in the Audio-Visual Profile with Feedback (AVPF).  This 
> > extension allows an intermediate node in the network (such as an RTP
> > translator) inform downstream receivers that sending a feedback 
> > message concerning a specified set of RTP messages may be 
> > unnecessary, or even harmful.  For example, in a source-specific 
> > multicast session with large fan-out, packet loss close to the media 
> > or distribution source of the session is detected as a loss by a 
> > large number of receivers.  The RTCP NACK messages used to request 
> > retransmission of the missing packets are all addressed to the media 
> > sender, or a designated feedback target.  This may result in a 
> > phenomenon known variously as a "NACK implosion" or "feedback storm".
> > The Feedback Suppression message defined herein is used to notify 
> > receivers that packet loss was detected and that the sender of the 
> > report will either proactively recover, or no recovery is possible.
> > Receivers respond to receipt of a feedback suppression message by 
> > not sending a feedback message (e.g. a NACK) that they otherwise 
> > would, This in turn reduces load on both the feedback target and on 
> > the network.  This document registers two new RTCP messages for 
> > Feedback Suppression.
> >
> > A URL for this Internet-Draft is:
> > http://www.ietf.org/internet-drafts/draft-wu-avt-retransmission-
> supression-rtp-03.txt
> >
> > Internet-Drafts are also available by anonymous FTP at:
> > ftp://ftp.ietf.org/internet-drafts/
> >
> > Below is the data which will enable a MIME compliant mail reader 
> > implementation to automatically retrieve the ASCII version of the 
> > Internet-Draft.
> >
> 
> 
> ----------------------------------------------------------------------
> -
> ---------
> 
> 
> > _______________________________________________
> > I-D-Announce mailing list
> > [email-masked]
> > https://www.ietf.org/mailman/listinfo/i-d-announce
> > Internet-Draft directories: http://www.ietf.org/shadow.html or 
> > ftp://ftp.ietf.org/ietf/1shadow-sites.txt
> >
> _______________________________________________
> Audio/Video Transport Working Group
> [email-masked]
> https://www.ietf.org/mailman/listinfo/avt