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

From: "VAN CAENEGEM Tom" <[email-masked]>
Date: Mon, 1 Mar 2010 11:29:59 +0100

Hi Qin,

One comment/question on your reply :
Tom

-----Original Message-----
From: Qin Wu [mailto:[email-masked]] 
Sent: zaterdag 27 februari 2010 3:48
To: VAN CAENEGEM Tom; Roni Even; David R Oran
Cc: [email-masked]
Subject: Re: [AVT] I-D
Action:draft-wu-avt-retransmission-supression-rtp-00.txt

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.

Tom:  I understand your draft is about (avoiding) NACK storms. If in
IPTV deployments, the retransmission server is co-located with the
distribution source (which your draft implies), you can have clever
algorithms that allow the RS to deduce whether a packet loss event
impacts one or a few or a massive amount of receivers, without having
all receivers reacting immediately to observed packet loss (e.g. by
having immediate and non-immediate packet loss reporters among the RTP
receiver population as defined in DVB), and then use RSI for packet loss
suppression.  But am not sure this alone is sufficiently scalable
(depends of course how large the IPTV deployment is and how much it is
expected to grow), because Retransmission Servers may need to be
positioned closer in the network towards the receivers. Then using RSI
(that must be sourced by the HE, being the distribution source) for
signaling to enable reporting suppression is not the best approach.
Using a non-RSI approach like NACKs is a more generic solution and
decouples the solution from deployment topologies and size.  

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

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

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
> 
> 
> On Feb 26, 2010, at 3:33 AM, Qin Wu wrote:
> 
> > 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
> >
> >
> > 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.
> >
> > [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 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.
> 
> 
> > 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.
> >
> > On Feb 22, 2010, at 6:55 AM, Qin Wu wrote:
> >
> >> 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-
> supr
> >>> ession-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
> >>>
> >> _______________________________________________
> >> Audio/Video Transport Working Group [email-masked] 
> >> https://www.ietf.org/mailman/listinfo/avt

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

---

From: Qin Wu <[email-masked]>
Date: Mon, 01 Mar 2010 20:22:37 +0800

Hi, Tom:
Please see my reply inline.
----- Original Message ----- 
From: "VAN CAENEGEM Tom" <[email-masked]>
To: "Qin Wu" <[email-masked]>; "Roni Even" <[email-masked]>; "David R Oran" <[email-masked]>
Cc: <[email-masked]>
Sent: Monday, March 01, 2010 6:29 PM
Subject: RE: [AVT] I-D Action:draft-wu-avt-retransmission-supression-rtp-00.txt

Hi Qin,

-----Original Message-----
From: Qin Wu [mailto:[email-masked]] 
Sent: zaterdag 27 februari 2010 3:48
To: VAN CAENEGEM Tom; Roni Even; David R Oran
Cc: [email-masked]
Subject: Re: [AVT] I-D

Hi, Tom:

[Qin]: I fully agree with you on this. As also mentioned by Roni, maybe we have another case
for this storm suppresion,i.e., in the MCU case where packet loss happens between sender and MCU,
then a large amount of receivers may initiate fast update request. Therefore
we also need one more generic mechanism not only to suppress NACK implosion but also suppress 
fast update request from the receievers. So maybe we need to adopt one more generic appoach as you suggested.
Thanks.

Regards!
-Qin
----- Original Message -----
From: "VAN CAENEGEM Tom" <[email-masked]>
To: "Roni Even" <[email-masked]>; "David R Oran" <[email-masked]>;

Hi Qin, Roni

Regards
Tom 

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

Hi Dave,

Roni Even
As individual

avoided.