Subject: [AVT] Comments on "draft-yang-avt-switch-multicast-short-timeshift-00.txt"

From: "Van Caenegem, Tom (Tom)" <[email-masked]>
Date: Mon, 8 Nov 2010 13:39:34 +0100

Hi,
If I understand well, the draft's proposed solution targets use cases where clients request a short-time-shifted unicast stream, when originally receiving the stream over multicast. The unicast stream is requested from a so-called MST server using new RTCP messaging, and by means of RTCP message exchange with this server, the client will be able to switch back to the multicast stream. This is because similar as with RAMS, the unicast data is burst from the MST cache allowing to catch-up with the multicast again. The benefit of this operation is that there will be less unicast streams.
The draft explicitly states it is only targeting short/small time shift use cases, so my take is there should be an indication to the client what is small and what is long time shift, and I guess that for long time shift, the protocol operation and solution will hence be different.
My main comment is:  why have a specific solution only for small time-shifts, why not choosing for a generic solution?
Say a client pauses a live stream (transported over multicast), and the pause/time shift-implementation is network based (in other words there is no continuous buffering of the data at the client -even while in pause- which is also apparently the assumption in this draft), AND the play is resumed only after a long pause, then some other mechanism -like e.g. RTSP- would be used, where the client sets-up a unicast RTP session with a unicast RTP streamer. Suppose the end-user does FFW and gets to the point where it could hook up again with the multicast stream, then also here the client would then better leave the unicast and revert to the multicast stream.  In that case there is not even need to specify anything "new": in case of RTSP information exchange, the REDIRECT method can be used, after which the client terminates the unicast session and joins back the multicast (where it could be leveraging RAMS and/or RTP retransmissions).
Note that if a client is engaged in a short time shift (say 30 seconds) and the end-user also presses FFW, the proposed solution of the draft -where all data is burst- will be less network efficient as compared to using RTSP, because the RTSP server will transmit less data in FFW mode.
Now consider the use case where a client makes a short pause or a short REW on a live stream and then just plays-out the stream.
Also here the solution to "force" the client back to the multicast stream, can leverage RTSP: simply have the (RTSP) client asking the requested content -with approriate time range- using speed header with value > 1, followed at an appropriate time by a REDIRECT from the RTSP server to indicate to the client it should switch back to the multicast.
My conclusion is that with RTSP the same network resource savings can be obtained as the draft's proposal, which combined with retransmissions and RAMS, results in a similar user experience. And this is a generic solution. I am missing the rationale to define a specific solution as per your proposal for the short time-shift use case.
The important differentiator of this draft's  (limited) use case  with the RAMS solution (targeting faster zapping and for which a dedicated RTCP interaction has been defined) is, that in this draft, there are media timing control aspects involved that are imposed by the client (e.g. "play back from time X"). This is naturally addressed (better) with existing RTSP.
Tom

---

From: Peilin YANG <[email-masked]>
Date: Tue, 09 Nov 2010 14:29:25 +0800

Dear Tom,

Thank you very much for your comments. Please see inline.

Best regards,

Peilin

----- 原邮件 -----
发件人: "Van Caenegem, Tom (Tom)" <[email-masked]>
日期: 星期一, 十一月 8日, 2010 下午8:40
主题: [AVT] Comments on "draft-yang-avt-switch-multicast-short-timeshift-00.txt"
收件人: "[email-masked]" <[email-masked]>

Hi,

If I understand well, the draft's proposed solution targets use cases where clients request a short-time-shifted unicast stream, when originally receiving the stream over multicast. The unicast stream is requested from a so-called MST server using new RTCP messaging, and by means of RTCP message exchange with this server, the client will be able to switch back to the multicast stream. This is because similar as with RAMS, the unicast data i
s burst from the MST cache allowing to catch-up with the multicast again. The benefit of this operation is that there will be less unicast streams.  

Peilin: For long time-shifts, e.g a client does FRW to a previous point(e.g an hour ago), it needs a very long time to catch up to multicast stream if the end-user doesn't hope to miss some detail about playback of multicast stream. At the use case of small time-shift, it may very fast switch back to multicast stream. 

Say a client pauses a live stream (transported over multicast), and the pause/time shift-implementation is network based (in other words there is no continuous buffering of the data at the client -even while in pause- which is also apparently the assumption in this draft), AND the play is resumed only after a long pause, then some other mechanism -like e.g. RTSP- would be used, where the client sets-up a unicast RTP session with a unicast R
TP streamer. Suppose the end-user does FFW and gets to the point where it could hook up again with the multicast stream, then also here the client would then better leave the unicast and revert to the multicast stream.  In that case there is not even need to specify anything "new": in case of RTSP information exchange, the REDIRECT method can be used, after which the client terminates the unicast session and joins back the multicast (where i
t could be leveraging RAMS and/or RTP retransmissions).

Peilin: The end-user can do FFW to the current multicast stream and revert to the multicast stream, even directly terminate the unicast and revert to the mutlicast stream without FFW. At this use case, the end-user will miss some details of the playback. But this is another user case which is different from the use case in draft. Sometimes, the end-users don't want to miss some details. At this use case, the draft implements an auto reverse
 switch, and the end-user doesn't perceive this. 

Peilin: As I explain above. The solution based on existing RTSP is different from the draft. I agree that it is a generic solution, but it cannot content the use case in the draft.

Tom

---

From: "Van Caenegem, Tom (Tom)" <[email-masked]>
Date: Tue, 9 Nov 2010 10:24:22 +0100

Hi Peilin,

You say " The solution based on existing RTSP is different from the draft. I agree that it is a generic solution, but it cannot content the use case in the draft."

Why do you say that the RTSP-based solution cannot address the use case from your draft? I explained a possible way to do this (see below).

Regards
Tom 

-----Original Message-----
From: Peilin YANG [mailto:[email-masked]] 
Sent: dinsdag 9 november 2010 7:29
To: Van Caenegem, Tom (Tom)
Cc: [email-masked]
Subject: Re:[AVT] Comments on "draft-yang-avt-switch-multicast-short-timeshift-00.txt"

Dear Tom,

Best regards,

Peilin

----- 原邮件 -----
发件人: "Van Caenegem, Tom (Tom)" <[email-masked]>
日期: 星期一, 十一月 8日, 2010 下午8:40
主题: [AVT] Comments on "draft-yang-avt-switch-multicast-short-timeshift-00.txt"
收件人: "[email-masked]" <[email-masked]>

Hi,

If I understand well, the draft's proposed solution targets use cases where clients request a short-time-shifted unicast stream, when originally receiving the stream over multicast. The unicast stream is requested from a so-called MST server using new RTCP messaging, and by means of RTCP message exchange with this server, the client will be able to switch back to the multicast stream. This is because similar as with RAMS, the unicast data i s burst from the MST cache allowing to catch-up with the multicast again. The benefit of this operation is that there will be less unicast streams.  

Say a client pauses a live stream (transported over multicast), and the pause/time shift-implementation is network based (in other words there is no continuous buffering of the data at the client -even while in pause- which is also apparently the assumption in this draft), AND the play is resumed only after a long pause, then some other mechanism -like e.g. RTSP- would be used, where the client sets-up a unicast RTP session with a unicast R TP streamer. Suppose the end-user does FFW and gets to the point where it could hook up again with the multicast stream, then also here the client would then better leave the unicast and revert to the multicast stream.  In that case there is not even need to specify anything "new": in case of RTSP information exchange, the REDIRECT method can be used, after which the client terminates the unicast session and joins back the multicast (where i t could be leveraging RAMS and/or RTP retransmissions).

Peilin: The end-user can do FFW to the current multicast stream and revert to the multicast stream, even directly terminate the unicast and revert to the mutlicast stream without FFW. At this use case, the end-user will miss some details of the playback. But this is another user case which is different from the use case in draft. Sometimes, the end-users don't want to miss some details. At this use case, the draft implements an auto reverse  switch, and the end-user doesn't perceive this. 

Tom

---

From: Peilin YANG <[email-masked]>
Date: Wed, 10 Nov 2010 15:49:09 +0800

Dear Tom,

Many thanks.

You mean that "a RTSP client requests content using speed header with value >1, and follows by REDIRECT to indicate to the client to join the multicast" can address the use case in my draft?

Normally the REDIRECT terminates a service and another service will be provided with a complete absolute URI pointing to the resource to which the client SHOULD reconnect, follows with a corresponding RSTP method. If a default URI is used in the Location header to indicate join the multicast, it may confuse the client.
In addition, Unicast stream of time-shift must joint seamlessly subsequent multicast stream without any packet loss, RAMS mechnism can implement it and RTSP doesn't provide this mechamism. 

Best regards,
Peilin

----- 原邮件 -----
发件人: "Van Caenegem, Tom (Tom)" <[email-masked]>
日期: 星期二, 十一月 9日, 2010 下午5:27
主题: RE: Re:[AVT] Comments on "draft-yang-avt-switch-multicast-short-timeshift-00.txt"
收件人: Peilin YANG <[email-masked]>
抄送: "[email-masked]" <[email-masked]>

Hi Peilin,

Regards
Tom 

-----Original Message-----
From: Peilin YANG [mailto:[email-masked]] 
Sent: dinsdag 9 november 2010 7:29
To: Van Caenegem, Tom (Tom)
Cc: [email-masked]
Subject: Re:[AVT] Comments on "draft-yang-avt-switch-multicast-short-timeshift-00.txt"

Dear Tom,

Best regards,

Peilin

----- 原邮件 -----
发件人: "Van Caenegem, Tom (Tom)" <[email-masked]>
日期: 星期一, 十一月 8日, 2010 下午8:40
主题: [AVT] Comments on "draft-yang-avt-switch-multicast-short-timeshift-00.txt"
收件人: "[email-masked]" <[email-masked]>

Hi,

Say a client pauses a live stream (transported over multicast), and the pause/time shift-implementation is network based (in other words there is no continuous buffering of the data at the client -even while in pause- which is also apparently the assumption in this draft), AND the play is resumed only after a long pause, then some other mechanism -like e.g. RTSP- would be used, where the client sets-up a unicast RTP session with a unicast R
 TP streamer. Suppose the end-user does FFW and gets to the point where it could hook up again with the multicast stream, then also here the client would then better leave the unicast and revert to the multicast stream.  In that case there is not even need to specify anything "new": in case of RTSP information exchange, the REDIRECT method can be used, after which the client terminates the unicast session and joins back the multicast (where 
i t could be leveraging RAMS and/or RTP retransmissions).

Tom

---

From: David R Oran <[email-masked]>
Date: Wed, 10 Nov 2010 08:22:20 -0500

> Normally the REDIRECT terminates a service and another service will be provided with a complete absolute URI pointing to the resource to which the client SHOULD reconnect, follows with a correspond…
Why? Multicast streams can be addressed using a URI. Shouldn't confuse a client any more than some orthogonal RAMS enhancement mechanism they have to understand, and likely less.

> In addition, Unicast stream of time-shift must joint seamlessly subsequent multicast stream without any packet loss, RAMS mechnism can implement it and RTSP doesn't provide this mechamism. 
Ah, there's special sauce there, and if you go there please remind me to file an IPR disclosure. It was the major consideration for why the original Cisco RAMS scheme did pre-compuation of the entire burst and coordination through the client rather than the server.

By the way, I don't think Mark was saying "don't use RAMS", but rather you don't have to invent any new RAMS machinery, especially machinery that only works if the delta T is small. From a control channel standpoint, you just treat the redirect like a channel change. You can line up the streams any number of ways (including the ones I have some IPR on) but in general either SCTE timecode (which can have frame-clock accuracy) or RTCP timestamp correlation (if the same source is sending both the unicast and multicast streams) would work.

So, I'm on the same page with Mark - since the general problem of switching from unicast to multicast needs to be solved (and I think is actually already solved by existing protocols and clients) we don't need anything new, especially something new that addresses a very narrow use case.

Oh, and by the way, nearly all the systems I've worked with or used myself have a small glitch when transitioning from either fast forward or forward skip to play (yes even in pure unicast and even local file playout) and the user experience is not degraded badly. There are a variety of reasons for this (e.g. forward skip is discontinuous anyway, and fast forward schemes still don't do deceleration). Therefore, I wouldn't even worry about a small glitch due to imperfect alignment of the unicast and multicast streams, at least until such time as somebody bothers to build a client that does FF deceleration properly.

DaveO.

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

---

From: "Van Caenegem, Tom (Tom)" <[email-masked]>
Date: Wed, 10 Nov 2010 14:32:14 +0100

Hi Peilin,
. 
RTSP was given as example as it is the default protocol to set-up/control unicast RTP streams. The URI in the REDIRECT RTSP does not need to be a RTSP URI, it can be a multicast URI. For example DVB has defined dvb-mcast URI schemes. More generic multicast URI schemes can be defined (if not already existing?). Upon receiving a RTSP redirect to such a multicast URI, the RTSP client just closes the RTSP session, and then the multicast is joined by the RTP receiver.

Your concern about seamless "switching" between unicast and multicast is of course valid. 

In RAMS the unicast RTP streams are indeed formatted as retransmission packets, and retransmission packets in the unicast streams can be associated one-to-one with packets in the original multicast, allowing seamless switching, with or without aid of retransmissions.

A straightforward way to enable the same seamless switching experience when leaving the unicast and connecting to multicast, is that the unicast RTP packets (with the unicast stream being an exact replica of the multicast stream, but time-shifted) keep the RTP Sequence number that was used when transporting the RTP packets over multicast. Once the receiver has joined the multicast, it can leverage retransmission service to close any "gap" observed by the client. 

There can be other ways as well, or a specific solution can be defined, maybe leveraging RAMS with a specific extension, but as indicated before, a solution that can be used for both long and small time shifted  RTP streams and leveraging established protocols/architectures makes much more sense to me, compared to defining a new protocol for just one specific use case.

Regards
Tom 

-----Original Message-----
From: Peilin YANG [mailto:[email-masked]] 
Sent: woensdag 10 november 2010 8:49
To: Van Caenegem, Tom (Tom)
Cc: [email-masked]
Subject: Re:[AVT] Comments on "draft-yang-avt-switch-multicast-short-timeshift-00.txt"

Dear Tom,

Many thanks.

Best regards,
Peilin

----- 原邮件 -----
发件人: "Van Caenegem, Tom (Tom)" <[email-masked]>
日期: 星期二, 十一月 9日, 2010 下午5:27
主题: RE: Re:[AVT] Comments on "draft-yang-avt-switch-multicast-short-timeshift-00.txt"
收件人: Peilin YANG <[email-masked]>
抄送: "[email-masked]" <[email-masked]>

Hi Peilin,

Regards
Tom 

-----Original Message-----
From: Peilin YANG [mailto:[email-masked]]
Sent: dinsdag 9 november 2010 7:29
To: Van Caenegem, Tom (Tom)
Cc: [email-masked]
Subject: Re:[AVT] Comments on "draft-yang-avt-switch-multicast-short-timeshift-00.txt"

Dear Tom,

Best regards,

Peilin

----- 原邮件 -----
发件人: "Van Caenegem, Tom (Tom)" <[email-masked]>
日期: 星期一, 十一月 8日, 2010 下午8:40
主题: [AVT] Comments on "draft-yang-avt-switch-multicast-short-timeshift-00.txt"
收件人: "[email-masked]" <[email-masked]>

Hi,

Tom

---

From: David R Oran <[email-masked]>
Date: Wed, 10 Nov 2010 10:15:35 -0500

Resend: I meant Tom (as in Van Caenegem), not Mark (as in Watson) in the prior post. Fixed below

By the way, I don't think Tom was saying "don't use RAMS", but rather you don't have to invent any new RAMS machinery, especially machinery that only works if the delta T is small. From a control channel standpoint, you just treat the redirect like a channel change. You can line up the streams any number of ways (including the ones I have some IPR on) but in general either SCTE timecode (which can have frame-clock accuracy) or RTCP timestamp correlation (if the same source is sending both the unicast and multicast streams) would work.

So, I'm on the same page with Tom - since the general problem of switching from unicast to multicast needs to be solved (and I think is actually already solved by existing protocols and clients) we don't need anything new, especially something new that addresses a very narrow use case.

DaveO.