Subject: [AVTCORE] I-D Action:draft-ietf-avtcore-feedback-supression-rtp-00.txt

From: [email-masked]
Date: Mon, 14 Feb 2011 21:45:02 -0800

A New Internet-Draft is available from the on-line Internet-Drafts directories.
This draft is a work item of the Audio/Video Transport Core Maintenance Working Group of the IETF.

	Title           : RTCP Extension for Feedback Suppression Indication
	Author(s)       : W. Wu, et al.
	Filename        : draft-ietf-avtcore-feedback-supression-rtp-00.txt
	Pages           : 17
	Date            : 2011-02-14

In a large RTP session using the RTCP feedback mechanism defined in
RFC 4585, a media source or middlebox may experience transient
overload if some event causes a large number of receivers to send
feedback at once.  This feedback implosion can be mitigated if the
device suffering from overload can send a third party loss report
message to the receivers to inhibit further feedback.  This memo
defines RTCP extensions for third party loss report, to suppress NACK
and FIR feedback requests.  It also defines associated SDP
signalling.

A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-ietf-avtcore-feedback-supression-rtp-00.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.

---

From: Qin Wu <[email-masked]>
Date: Tue, 22 Feb 2011 16:57:39 +0800

Hi, Ali:
Thank for your comments to this draft. Summarized what we discussed on the
 list during the last meeting, I believe two issues are waiting for being addressed.

Issue 1:  How FEC is taken into account in this draft?

Currently this version does not touch this issue. But I agree both retransmission and FEC 
can be used to recover packet loss and will address this in the 01 version.

Issue 2:  It is not clear that how Distribution source in the SSM case react to different reports?

I think each distribution source may send its own Third Party Loss report to downstream receivers respectively.  
if the upstream Third Party Loss Report reports the different event, the downstream distribution sources forward Third Party Loss Report
 received from upstream to all the RTP receivers, over the multicast  channel. If the same event is reported from upstream distribution source, 
the downstream distribution source may suppress creating and sending its own report to the relevant RTP receivers. 

In response to these two pending comments, I propose to do the following changes to draft-ietf-avtcore-feedback-suppression-rtp.

Section 3
OLD TEXT:
"
   These intermediate nodes need to take into account such factors as
   the tolerable application delay, the network dynamics, and the media
   type.  When the packet loss is detected upstream of the intermediary
   and additional latency is tolerable, the intermediate node may itself
   send a feedback message asking for the suspected lost packet or ask
   for the correct decoder refresh point.  Because it has already
   provided the necessary feedback toward the source, the intermediate
   node can be reasonably certain that it will help the situation by
   sending a Third Party Loss Report message to all the relevant
   receivers, thereby indicating to the receivers that they should not
   transmit feedback messages for a period of time.

"
NEW TEXT:
"
  These intermediate nodes need to take into account such factors as
   the tolerable application delay, packet loss recovery techniques, the 
   network dynamics, and the media  type.  When the packet loss is 
  detected upstream of the intermediary and additional latency is tolerable,
  loss-repair methods such as Forward Error  Correction and retransmission 
  may be used to recover the missing packets.  Therefore the intermediate
   node can be reasonably certain that it will help the situation by
   sending a Third Party Loss Report message to all the relevant
   receivers, thereby indicating to the receivers that they should not
   transmit feedback messages for a period of time.
"
Section 6.1
OLD TEXT:
"
  Another possibility is when there may be multiple distribution sources placed
   between the media source and the receivers, the upstream distribution
   source may inform downstream distribution sources of the detected
   packet loss using Third Party Loss Report messages.  In response, the
   downstream distribution sources forward Third Party Loss Report
   received from upstream to all the RTP receivers, over the multicast
   channel. 
"

NEW TEXT:
"
Another possibility is when there may be multiple distribution sources placed
   between the media source and the receivers, each distribution source
   may send its own Third Party Loss report to downstream receivers 
    respectively. And also the upstream distribution source may inform 
   downstream distribution sources in the path of the detected  packet loss 
   using Third Party Loss Report messages.  In response, if the upstream 
   Third Party Loss Report reports the different event, the
   downstream distribution sources forward Third Party Loss Report
   received from upstream to all the RTP receivers, over the multicast
   channel. If the same event is reported from upstream distribution source, 
   the downstream distribution source may suppress creating and sending its 
  own report to the relevant RTP receivers. 
"
am I addressing your concerns? 

Regards!
-Qin
----- Original Message ----- 
From: <[email-masked]>
To: <[email-masked]>
Cc: <[email-masked]>
Sent: Tuesday, February 15, 2011 1:45 PM
Subject: I-D Action:draft-ietf-avtcore-feedback-supression-rtp-00.txt

> implementation to automatically retrieve the ASCII version of the

--------------------------------------------------------------------------------

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