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

[Colin Perkins <csp at csperkins.org>]

Jose,

[catching up on old email]

On 21 Feb 2008, at 15:27, Jose Rey wrote:
> 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.

Seems like a reasonable approach.

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

You probably want to exchange RTCP information, so that all the  
devices see the full SSRC space, making this one RTP session.

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

Explicit SDP signalling of the different roles, addresses, and SSRC  
values used would seem to be a good thing. It might also be possible  
to include role hints in-band in RTCP packets, although we'd need to  
think through the implications of that.

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

You mean correlated loss downstream of the retransmission proxy?

> 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



-- 
Colin Perkins
http://csperkins.org/


_______________________________________________
Audio/Video Transport Working Group
avt at ietf.org
https://www.ietf.org/mailman/listinfo/avt