Re: [AVT] Fwd: Retransmission and fast channel change with usage ofRTP/RTCP

["Jose Rey" <[e-mail]>]

Hi Colin, hi all,

regarding retransmission: DVB is currently developing a solution for retransmission in VoD and live multicast IPTV services. The unicast VoD scenario is rather simple. The multicast one isn't, thus we would like to ask the community for feedback.

The multicast solution is based on the draft specifying unicast feedback for SSM. We intend to use up to two SSM sessions (one for media, one optional for repair) plus one unicast repair session per receiver. The Distribution Source of the media session would be the network provider's head end. The Distribution Source of the repair session is the "retransmission proxy", typically located very near to the customer, usually at the (IP)-DSLAM. The repair session is used to mitigate correlated packet losses, affecting one or several hundreds of users. Finally, the Feedback Target is also co-located with the retransmission proxy. 

In the typical scenario as above, the correlated losses happen upstream of the retransmission proxy, e.g., due to L2 protection switching. These losses are critical, as they can cause NACK storms. In order to avoid these, an RTP client is placed halfway down the of the media SSM tree, thus detecting and reporting packet losses. "Halfway" means, in practice, at the retransmission proxy. So, in the end, we have a retransmission proxy that detects and reports upstream packet loss, hosts the feedback target, and serves retransmissions (both unicast and multicast). Each being a different logical entity with a different SSRC. 

Now, since the RTP client at the retransmission proxy cannot send its NACK in the media SSM group, it is proposed to send these in the *repair* SSM through its Distribution Source, i.e. the retransmission server, either as RFC-4585-NACKs or in summarized RSI form. However, by doing this, we are mixing the SSRC spaces of two different (but associated) sessions. Also the retransmission client doesn't know what to do with this feedback as it would just think the NACK is from another *repair* client. 

A proposed solution for indicating the repair client what to do with this forwarded NACK would be to use an additional SDP attribute listing the SSRC of the RTP client (we would indicate the SSRCs of the retransmission proxy and feedback target as well). The repair clients would then know, by looking at the SSRCs that it is a forwarded NACK from the media SSM and that they must forward it to the media client for NACK damping. The appropriate semantics would probably have to be writen down in an I-D.

Now, that's one scenario. Another one, though less common, is where losses happen dowstream of the retransmission proxy, where it cannot detect them. We are still thinking about a solution for that.

We would welcome feedback on this proposal or similar work being done elsewhere. If anyone has a better idea, we would of course consider it. 

Thanks,

José for Tom, Jeff and myself

> -----Original Message-----
> From: [e-mail] [mailto:[e-mail]] On 
> Behalf Of Colin Perkins
> Sent: Saturday, February 16, 2008 7:23 PM
> To: IETF AVT WG
> Subject: [AVT] Fwd: Retransmission and fast channel change 
> with usage ofRTP/RTCP
> 
> The AVT working group has received the following liaison 
> statement from TISPAN WG3 IPTV on Retransmission and fast 
> channel change with usage of RTP/RTCP. The TISPAN working 
> group asks for our feedback on a number of issues. Please 
> send any comments on this to the chairs by
> 25 February, so we can draft a response.
> 
> Colin (as chair)
> 
> 
> 
> Begin forwarded message:
> > From: "TISPANsupport" <[e-mail]>
> > Date: 12 February 2008 15:15:02 GMT
> > To: <[e-mail]>, <[e-mail]>, 
> > <[e-mail]>, <[e-mail]>, 
> > <[e-mail]>, "Chantal Bonardi" 
> <[e-mail]>
> > Cc: "TISPANsupport" <[e-mail]>
> > Subject: Retransmission and fast channel change with usage 
> of RTP/RTCP
> >
> > Good afternoon,
> >
> > Please find enclosed a liaison statement from TISPAN WG3 IPTV on 
> > Retransmission and fast channel change with usage of RTP/RTCP.
> >
> > Thank you for your prompt feed-back on this LS.
> >
> > Date of Next WG3 IPTV Meeting 03-07 March 2008.
> >
> >
> > Best regards,
> > Helene Schmidt
> > Technical Body Support
> > ETSI Standardization Projects (ESP)
> > 650, Route des Lucioles,
> > FR - 06921 Sophia Antipolis
> > Tel: [phone]
> > http://portal.etsi.org
> 
> 


Panasonic R&D Center Germany GmbH
63225 Langen, Hessen, Germany
Reg: AG Offenbach (Hessen) HRB 33974
Managing Director: Thomas Micke


_______________________________________________
Audio/Video Transport Working Group
[e-mail]
http://www.ietf.org/mailman/listinfo/avt