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

[Qin Wu <[e-mail]>]

Hi, Ali
Thank for your comments, please see my reply inline.
----- Original Message ----- 
From: "Ali C. Begen (abegen)" <[e-mail]>
To: "Qin Wu" <[e-mail]>; <[e-mail]>
Sent: Sunday, October 10, 2010 12:38 AM
Subject: RE: [AVT] New Version Notification for draft-wu-avt-retransmission-supression-rtp-03


Comments:
1) Abstract is too long, could you shorten it?

[Qin] Okay.

Typos in abstract:
a) .. that *are* sending ...

[Qin]: You may misunderstand, the subject is actually "sending a feedback message"

b) RTP messages -> RTP packets

[Qin]: yes.

c) "the sender of the report will either proactively recover": Well, it does not have to be the sender of the report who will attempt the recovery. I would rephrase this.

[Qin]: Okay.

2) Throughout the document, avoiding "sender" might be a good idea. For the source, use media or distribution source. Sender may mean different things in different contexts.

[Qin]: Okay.

3) Intro 1st paragraph: The retransmission payload format is 4588 not 4585.

[Qin]: Good catch, thanks.

4) Most of the discussion in the introduction section can be shortened in a concrete way by referring to other existing RFC in this area. I am actually quite surprised that RFC 5740 is not mentioned at all here. I would rather refer to RFC 5740 (rather than DVB-IPTV).

[Qin]; Okay.

5) Do not use (upper-case) 2119 keywords in the introduction. IESG does not like it :)

[Qin]: Okay.

6) Section 2: The definitions seem to evolve around SSM. Why would not they apply to ASM?

[Qin]: Right, they should apply to ASM.

7) Section 3 and further on: There are several lower-case 2119 keywords in the text which you might wanna replace.

[Qin]: Okay, thanks.

8) Section 6.1.1 says "If the loss reporter is part of group, the Distribution source MUST filter this packet out and not forward it back to this loss reporter." How does it filter that loss reporter out?

[Qin]: It is one optimized behavior.
One possible way to do this is that the Distribution Source knows the address of loss reporter or know in which port it can receive the RTCP message from the loss reporter.
Is that reasonable?

9) What about the cases where the receiver will actually not send a NACK despite the packet loss? Consider where there is also a FEC stream that can recover the lost packets. Should the loss reporter listen to the FEC channel as well and act accordingly?

[Qin]: Good question. I think if the reciever know it will not send a NACK, then the distribution source should know as well. In such case, the distribution source may choose not to send feedback suppression message to the receiver.

10) You seem to assume that different loss reporters will always see the same losses. That is not necessarily true. What should be reported back to the receivers if the reports coming to the FT are conflicting? Do you report the union or intersection of the reports back to the receivers?

[Qin]: If there are duplication reports, the Distribution source should filter the duplicated report out and only send one copy of report to the reciever. What the distribution source does is to create one summary report which only append different loss in this summary report.

11) You also seem to be relating this NACK implosion to retransmission. I would actually prefer to keep the retransmission stuff out of the text here (just mention it in the introduction and then forget about it). Whether the distribution source actually retransmits the missing packets or not has nothing to do with the messages defined in this draft.

[Qin] Okay.

-acbegen 



> -----Original Message-----
> From: [e-mail] [mailto:[e-mail]] On Behalf Of Qin Wu
> Sent: Saturday, October 09, 2010 12:49 PM
> To: [e-mail]
> 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: <[e-mail]>
> To: <[e-mail]>
> 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
> > [e-mail]
> > 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
> >