Subject: [AVT] Fwd: Retransmission and fast channel change with usage of RTP/RTCP

From: Colin Perkins <[email-masked]>
Date: Sat, 16 Feb 2008 18:23:18 +0000

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" <[email-masked]>
> Date: 12 February 2008 15:15:02 GMT
> To: <[email-masked]>, <[email-masked]>,  
> <[email-masked]>, <[email-masked]>,  
> <[email-masked]>, "Chantal Bonardi" <[email-masked]>
> Cc: "TISPANsupport" <[email-masked]>
> 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: +33 4 92 94 43 41
> http://portal.etsi.org

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

---

From: Randell Jesup <[email-masked]>
Date: Sun, 17 Feb 2008 00:36:53 -0500

Colin Perkins <[email-masked]> writes:
>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.

>> Retransmission and fast channel change with usage of RTP/RTCP.

Fast channel change: Since they're talking a change into a multicast group,
the limiting factors on a channel change are:

a) Signaling (may overlap)
b) Time to get added to the multicast group
c) Jitter buffer startup time
d) Delay until a iframe/equivalent
(perhaps some others)

An idea floated in that document was joining a unicast stream first, then
switching over to multicast.

For arguments sake, lets assume that in the multicast group iframes are 2
seconds apart, and we don't want channel-change to be <overhead> plus 0-2
seconds.

The proposal would be on channel change, the receiver might both register
to acquire the multicast group AND start receiving a parallel unicast
group.  (Assuming the sender is smart, and this is multicast, NOT
broadcast, then the sender could unicast the temporary stream and add them
to the multicast group at or just before the next multicast iframe.

In RTP terms, the receiver would probably see a source (SSRC) change, from
the unicast source to the multicast source.  If the receiver is
anticipating this it could make the switch fairly smoothly, since barring
loss the new source would start with an iframe.  Loss would need to be
dealt with in the normal way, but in this case the decoder wouldn't have a
"good" buffer to try to handle P/B frames if the first iframe was
lost/corrupted.  It could cheat and use the last frame from the unicast
source, or you could do something like continue to send the unicast source
for one (or more) iframe periods past the expected transition to multicast
- depends on how much bandwidth/encoder-complexity you're willing to allot.

Alternatively I wonder if you could unicast an iframe for the multicast
stream (using the same SSRC/etc), such that the receiver could jump into
the multicast stream before the next "normal" iframe there.  The trick is
that the iframe has to produce a full decoder reference buffer for the
multicast P/B frame stream (or at least one good enough to look ok until
the next real iframe).  It also has to deal with how you'd merge the
unicast and multicast data and deal with sequence/TS/etc issues.  I have a
few hackish ideas, which could work if you relax/break some rules
(duplicate seq/timestamps from the multicast data in the unicast (and send
the unicast iframe 'first' so the multicast data for those sequence numbers
would get ignored as dups, or send a "special" unicast stream with iframe
and a marker telling the decoder where (seq/TS) to switch to decoding the
multicast stream).

Just some late-night ramblings.

-- 
Randell Jesup
[email-masked]
"The fetters imposed on liberty at home have ever been forged out of the weapons
provided for defence against real, pretended, or imaginary dangers from abroad."
		- James Madison, 4th US president (1751-1836)

---

From: "Jose Rey" <[email-masked]>
Date: Thu, 21 Feb 2008 16:27:46 +0100

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: [email-masked] [mailto:[email-masked]] 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

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