Subject: Re: [AVT] I-D Action:draft-wu-avt-retransmission-supression-rtp-00.txt

From: Qin Wu <[email-masked]>
Date: Mon, 22 Feb 2010 19:55:48 +0800

Hi,all:
We have just submitted a new draft on "Proposal for an extension to RTCP for Retransmission Storm Suppression of RTP Stream"
A URL for this Internet-Draft is:
http://tools.ietf.org/html/draft-wu-avt-retransmission-supression-rtp-00
Your comments are welcome and appreciated!

Regards!
-Qin
----- Original Message ----- 
From: <[email-masked]>
To: <[email-masked]>
Sent: Monday, February 22, 2010 3:15 PM
Subject: I-D Action:draft-wu-avt-retransmission-supression-rtp-00.txt

>A New Internet-Draft is available from the on-line Internet-Drafts directories.
> Title           : Proposal for an extension to RTCP for Retransmission Storm Suppression of RTP Stream
> Author(s)       : W. Wu, et al.
> Filename        : draft-wu-avt-retransmission-supression-rtp-00.txt
> Pages           : 13
> Date            : 2010-02-21
> 
> This document extends Receiver Summary Information (RSI) report block
> to define a new sub-report block for retransmission suppression
> within the framework of RTP retransmission.  One of initial
> retransmission requests for the missing packets is RTCP NACK.  This
> feedback message conveys packet loss events.  Unlike NACK, this new
> sub-report block, which is referred to as the Retransmission Storm
> Suppression Report, also carries the information regarding
> retransmission suppression early indication events to the receiver
> before the receiver detects an original packet loss and all the
> packet loss repair methods are applied.  By using Retransmission
> Suppression together with NACK, the delay for the receiver to recover
> from the packet loss can be reduced and the risk of increasing
> network congestion can be mitigated or avoided.  This document also
> registers a new sub-report block type for Retransmission Storm
> Suppression within RTP retransmission framework.
> 
> A URL for this Internet-Draft is:
> http://www.ietf.org/internet-drafts/draft-wu-avt-retransmission-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.
>

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

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

---

From: David R Oran <[email-masked]>
Date: Mon, 22 Feb 2010 08:01:11 -0500

Interesting. We just send a NAK from the sender to act as a suppression mechanism.
If you are a receiver missing a packet and receive a NAK for that packet then you know there's no point in you asking for it.

On Feb 22, 2010, at 6:55 AM, Qin Wu wrote:

> Audio/Video Transport Working Group
> [email-masked]
> https://www.ietf.org/mailman/listinfo/avt

---

From: Qin Wu <[email-masked]>
Date: Fri, 26 Feb 2010 16:33:47 +0800

Thank for showing your interests and sorry for the late reply. please see my feedback belows.
----- Original Message ----- 
From: "David R Oran" <[email-masked]>
To: "Qin Wu" <[email-masked]>
Cc: <[email-masked]>
Sent: Monday, February 22, 2010 9:01 PM
Subject: Re: [AVT] I-D Action:draft-wu-avt-retransmission-supression-rtp-00.txt

[Qin]: That's one possible way we are going to do. Unfortunetetly packet loss usually happens in the middle path betweeen
 the sender and the receiver which leads to NACK implosion. so how the intermediate node prevents NACK implosion early 
before or after the receiver detects of  the packet missing is what we are really going to reslove in this I-D.

On the other hand, I can't see any work to talk about NAK sent from the sender to the receiver. what am I missing?
But if you look at the intermediate node as one sender from the receiver perspective, I should say we are on the same page.

---

From: David R Oran <[email-masked]>
Date: Fri, 26 Feb 2010 08:26:41 -0500

> before or after the receiver detects of  the packet missing is what we are really going to reslove in this I-D.
The RS can send it in the SSM case when it fails to receive certain multicast packets. 
In the ASM case, it works like any other distributed NAK suppression scheme.

The basic scheme would have the same properties either way - I was just asking why bother to invent a whole new packet format when NAK does exactly what you want. You just specify at a receiver that if you *receive* a NAK for packets you are missing, don't send your own.

There's really nothing new here other than the exact algorithms for the SSM case, which you don't put in your draft anyway. If you're interested in the SSM-related algorithms, please see USPTO 11/736,463. If you want to update the I.D. with detials on the actual supression algorithms, I'll file an IPR disclosure on the above-referenced patent application.

Cheers, DaveO.

DaveO.

---

From: Roni Even <[email-masked]>
Date: Fri, 26 Feb 2010 16:10:29 +0200

Hi Dave,
Thanks for point out your IPR. I think that the major motivation was to
prevent NACK implosions and not to address the repair process which can be
application specific.

I think that using NACK is also an option that will require to add the
semantics of suppression when sent by the media sender. 

Roni Even
As individual

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]] On Behalf Of
> David R Oran
> Sent: Friday, February 26, 2010 3:27 PM
> To: Qin Wu
> Cc: [email-masked]
> > Subject: Re: [AVT] I-D
> > Action:draft-wu-avt-retransmission-supression-rtp-00.txt
> >
> >
> > If you are a receiver missing a packet and receive a NAK for that
> packet then you know there's no point in you asking for it.
> >
> > [Qin]: That's one possible way we are going to do. Unfortunetetly
> > packet loss usually happens in the middle path betweeen the sender
> and
> > the receiver which leads to NACK implosion. so how the intermediate
> node prevents NACK implosion early before or after the receiver detects
> of  the packet missing is what we are really going to reslove in this
> I-D.
> >
> The basic scheme would have the same properties either way - I was just
> asking why bother to invent a whole new packet format when NAK does
> exactly what you want. You just specify at a receiver that if you
> *receive* a NAK for packets you are missing, don't send your own.
> 
> There's really nothing new here other than the exact algorithms for the
> SSM case, which you don't put in your draft anyway. If you're
> interested in the SSM-related algorithms, please see USPTO 11/736,463.
> If you want to update the I.D. with detials on the actual supression
> algorithms, I'll file an IPR disclosure on the above-referenced patent
> application.
> 
> Cheers, DaveO.
> 
> 
> DaveO.
> 
> 
> > On the other hand, I can't see any work to talk about NAK sent from
> the sender to the receiver. what am I missing?
> > But if you look at the intermediate node as one sender from the
> receiver perspective, I should say we are on the same page.
> >
> >> We have just submitted a new draft on "Proposal for an extension to
> RTCP for Retransmission Storm Suppression of RTP Stream"
> >> http://tools.ietf.org/html/draft-wu-avt-retransmission-supression-
> rtp
> >> -00 Your comments are welcome and appreciated!
> >>
> >> Regards!
> >> -Qin
> >>> Title           : Proposal for an extension to RTCP for
> Retransmission Storm Suppression of RTP Stream
> >>> This document extends Receiver Summary Information (RSI) report
> >>> block to define a new sub-report block for retransmission
> >>> suppression within the framework of RTP retransmission.  One of
> >>> initial retransmission requests for the missing packets is RTCP
> >>> NACK.  This feedback message conveys packet loss events.  Unlike
> >>> NACK, this new sub-report block, which is referred to as the
> >>> Retransmission Storm Suppression Report, also carries the
> >>> information regarding retransmission suppression early indication
> >>> events to the receiver before the receiver detects an original
> >>> packet loss and all the packet loss repair methods are applied.  By
> >>> using Retransmission Suppression together with NACK, the delay for
> >>> the receiver to recover from the packet loss can be reduced and the
> >>> risk of increasing network congestion can be mitigated or avoided.
> >>> This document also registers a new sub-report block type for
> >>> Retransmission Storm Suppression within RTP retransmission
> framework.
> >>>
> >>> http://www.ietf.org/internet-drafts/draft-wu-avt-retransmission-
> supr
> >>> ession-rtp-00.txt
> >>>
> >> --------------------------------------------------------------------
> -
> >> -----------
> >>
> >>
> >>> Internet-Draft directories: http://www.ietf.org/shadow.html or
> >>> ftp://ftp.ietf.org/ietf/1shadow-sites.txt
> >>>

---

From: "VAN CAENEGEM Tom" <[email-masked]>
Date: Fri, 26 Feb 2010 15:31:29 +0100

Hi Qin, Roni

"On the other hand, I can't see any work to talk about NAK sent from the
sender to the receiver. what am I missing?"

In the DVB retransmission specification (released in 2008 and published
as an annex F of ETSI TS 102034 v1.4.1) we also included a couple of
solutions which address NACK storm avoidance or mitigation, for SSM with
retransmission function:

-we make use of the rtcp-ssm architecture where the feedback target
coincides with the retransmission server and this retransmission server
sends unicast retransmissions towards  'downstream" RTP receivers when
they indicated missing packets by means of NACK. This is also the
architecture that is adopted in the RAMS draft.

-we defined in DVB a "upstream receiver" which is logically positioned
upstream of a SSM feedback target/retransmission server and which
transmits a RTCP NACK FB message upon packet loss detection to this FB
target. This packet loss detection will impact also the downstream
receivers, and to avoid the NACK storm, the SSM feedback target fowards
this RTCP NACK FB to all downstream RTP receivers (translator). We
actually called this message a RTCP FeedForward (but it has the exact
symantics of the NACK FB!). When the receiver receives such a RTCP FB
(/FF), it shall abstain from sending a RTCP FB NACK itself.

-this NACK FB (/FF) is transmitted on a dedicated SSM that is sourced at
this Feedback target, and the same SSM can then be used to retransmit
the (missing)  retransmission packet over IP multicast, once the
Retransmission server was able to acquire the missing packet

The concept of upstream receiver provides a scalable way of addressing
packet loss upstream of the feedback target/retransmission server.
However, there may also be packet loss on a aggregation link downstream
of a feedback target/retransmission server which may also impact a
massive amount of RTP receivers. To cover this case, we provided
signaling for configuring RTP receivers such that
	-RTP receivers signal their NACK in a random period after packet
loss detection (mitigating the NACK storm, as some receivers will
receive the RTCP FF before the time they would have transmitted the RTCP
FB NACK themselves)
or
	-A small subset of RTP receivers are "immediate" (packet loss)
reporters, the larger group of receivers respects a fixed waiting time
before reporting. Based on SSRC of the RTP receiver (random chosen), a
receiver knows whether it is immediate reporter or not. When the
retransmission server only receives NACKs from immediate reporting
receivers, it knows it should transmit (or rather forward) a RTCP FB
itself over the retransmission SSM, combined with the retransmission
packet.

I think the very weak spot of your proposal is that it does not address
NACK storms as a result of packet loss on the network segment between
Distribution source and the RTP receivers, whereas this segment may
represent the largest part of the network. For instance, in IPTV
network, the Distribution Source actually represents the HeadEnd (where
the media sender(s) can often be considered part of this DS), and hence
the complete IP network is not covered and still subject to NACK storms.

Regards
Tom 

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of
Roni Even
Sent: vrijdag 26 februari 2010 15:10
To: 'David R Oran'; 'Qin Wu'
Cc: [email-masked]
Subject: Re: [AVT]I-D
Action:draft-wu-avt-retransmission-supression-rtp-00.txt

Hi Dave,
Thanks for point out your IPR. I think that the major motivation was to
prevent NACK implosions and not to address the repair process which can
be application specific.

Roni Even
As individual

> > Thank for showing your interests and sorry for the late reply. 
> > please
> see my feedback belows.
> node prevents NACK implosion early before or after the receiver 
> detects of  the packet missing is what we are really going to reslove 
> in this I-D.
> >
> The basic scheme would have the same properties either way - I was 
> just asking why bother to invent a whole new packet format when NAK 
> does exactly what you want. You just specify at a receiver that if you
> There's really nothing new here other than the exact algorithms for 
> the SSM case, which you don't put in your draft anyway. If you're 

> >>> Filename        :
draft-wu-avt-retransmission-supression-rtp-00.txt
> >>> packet loss and all the packet loss repair methods are applied.  
> >>> By using Retransmission Suppression together with NACK, the delay 
> >>> for the receiver to recover from the packet loss can be reduced 
> >>> and the risk of increasing network congestion can be mitigated or
avoided.
> >> Audio/Video Transport Working Group [email-masked]

---

From: Roni Even <[email-masked]>
Date: Fri, 26 Feb 2010 17:18:29 +0200

Hi Tom,
I think that using NACK for suppression is a good idea. I saw another use
case which may benefit using a new RTCP message or a different semantics for
NACK. This is the case a view switching conferencing bridges (MCU). In this
case when there are video packet loss between the sender and the MCU, the
receivers may request fast update requests and suppression of this messages
may be good. Currently the MCUs are filtering out the messages based on
local logic when forwarding them to the source. This is not a retransmission
case and the MCU requires new information from the media sender. This has to
do with the real-time nature of conversional services who do not use
retransmission.

Having an "upstream receiver" can be mentioned but I assume that it does not
require any specific protocol on top of the NACK suppression message, and is
just an implementation example.

As for using signaling for configuring part of the RTP receivers to act as
reporters in multicast cases, I agree that it will help and we can look at
it, we may need to verify if it can be done in AVT.

Roni Even
As individual

> VAN CAENEGEM Tom
> Sent: Friday, February 26, 2010 4:31 PM
> To: Roni Even; David R Oran; Qin Wu
> Cc: [email-masked]
> > >>> A New Internet-Draft is available from the on-line Internet-
> Drafts
> > directories.
> > >> ------------------------------------------------------------------
> -
> > >> -
> > -
> > >> -----------
> > >>
> > >>

---

From: Qin Wu <[email-masked]>
Date: Sat, 27 Feb 2010 10:48:22 +0800

Hi, Tom:
Thank for your valuable clarification on this. Your reference and comments are really helpful 
to improve our work. Actually what we are going to resolve in this I-D is NACK storm
 happens not only uplink stream but also downstream aggregate link.So packet loss on
the network segement between distribution source and receiever is also what we need to
cover in this I-D. Unfortunately, downstream access link is also located between the distribution source
and receiver which will not result in massive NACK storm but the packet retransmission in one specified
access segement. So we need to distinguish between downstream aggregate link 
and downstream access link.
And also I agree it is good idea to use some of receivers as reporter 
for preventing NACK storm occuring in the downstream aggregate links. 
Packet sender SSRC can be used to identify these dedicated receiever. I can consider this
in the updated version.

Regards!
-Qin
----- Original Message ----- 
From: "VAN CAENEGEM Tom" <[email-masked]>
To: "Roni Even" <[email-masked]>; "David R Oran" <[email-masked]>; "Qin Wu" <[email-masked]>
Cc: <[email-masked]>
Sent: Friday, February 26, 2010 10:31 PM
Subject: RE: [AVT]I-D Action:draft-wu-avt-retransmission-supression-rtp-00.txt

Hi Qin, Roni

Regards
Tom 

-----Original Message-----

Hi Dave,

Roni Even
As individual

avoided.

---

From: Qin Wu <[email-masked]>
Date: Sat, 27 Feb 2010 10:48:15 +0800

Hi, David:
I am not saying our proposal is the best single solution. NAK may be also okay.But I am wondering whether scematics of NAK
needs to extended otherwise how to distinguish NACK sent from receiver and NACK sent from sender.
Anyway I would like to hear the other opinions on this.
Regards!
-Qin
----- Original Message ----- 
From: "David R Oran" <[email-masked]>
To: "Qin Wu" <[email-masked]>
Cc: <[email-masked]>
Sent: Friday, February 26, 2010 9:26 PM
Subject: Re: [AVT] I-D Action:draft-wu-avt-retransmission-supression-rtp-00.txt

Cheers, DaveO.

DaveO.