Subject: [AVT] Observations on MPEG2-TS preamble drafts

From: Roni Even <[email-masked]>
Date: Sun, 25 Oct 2009 23:51:08 +0200

Hi,

I read both drafts and I would like to present my view as an individual
trying to clarify what I understand from both drafts and give my view on
some of the issues raised on the mailing list.

I would like to start with an observation that RAMS is not a retransmission
solution as specified in RFC 4588  "RTP retransmission is an effective
packet loss recovery technique for  real-time applications with relaxed
delay bounds.". There is no packet loss in this case. It is using the same
mechanism to convey information that will look to the RR as a retransmission
stream using the RTP packet structure defined in section 4 of RFC 4588 and
the SDP description from RFC 4588.  Yet the RR did not know that it was
missing any RTP packet with specific sequence numbers since he was not
expecting them in the unicast stream until they arrived and the OSN value is
not that meaningful to it.
 
Now when talking about the preamble / PSI or information that the RR needs
which may have been transmitted many packets ago I see in the two drafts two
directions to convey the information
 
1.       Specified in the Begen draft is to convey the information using a
new payload format that will include the needed information as a set of TLOV
elements payload.
2.       Specified in Xia draft that conveys the information looking like a
regular MPEG2 TS retransmission packet but since it is generated by the RS
it may get an OSN that is before the OSN of the first RAMS unicast stream.
 
I cannot say which one is better. My personal analysis is that in both cases
the RS will need to cache this information and will need to create the right
packet structure which is the TLOV in the first case and an MPEG2 TS PSI
packet in the second case. The RR will need to support this payload format
in the first case while I assume that in the second case it will look like a
regular MPEG2 TS stream.
 
 Other points that I see is that in the first case the packet may be smaller
in size and the extensibility can allow the RS to provide additional
information that was not part of the original stream (I am not sure if that
was the meaning here). In the second case it looks like the RR will see an
MPEG2 TS stream and will not need to support the TLOV payload format.

I do not have any view about what is the right way and I was only trying to
see if I understand both proposals. 
 
Thanks
Roni Even as an individual

---

From: "Ali C. Begen (abegen)" <[email-masked]>
Date: Sun, 25 Oct 2009 17:22:56 -0700

Roni,

Your summary is pretty accurate except a few points I point out below.

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]] On Behalf Of Roni Even
> Sent: Sunday, October 25, 2009 5:51 PM
> To: [email-masked]
> Subject: [AVT] Observations on MPEG2-TS preamble drafts
> 
> Hi,
> 
> I read both drafts and I would like to present my view as an individual trying to clarify
> what I understand from both drafts and give my view on some of the issues raised on the
> mailing list.
> 
> 
> 
> I would like to start with an observation that RAMS is not a retransmission solution as
> specified in RFC 4588  "RTP retransmission is an effective packet loss recovery technique
> for  real-time applications with relaxed delay bounds.". There is no packet loss in this

This is open to interpretation. I view RAMS as the receiver has lost everything so far (or for a long time) and subsequently lost its "synchronization (or whatever we wanna call it)" with the primary mcast stream and thus is asking the retransmission server to send whatever that is necessary to put him back on track. This is what we said in our slides since day one. 

But, this is not that relevant to the current discussion.

> case. It is using the same mechanism to convey information that will look to the RR as a
> retransmission stream using the RTP packet structure defined in section 4 of RFC 4588 and
> the SDP description from RFC 4588.  Yet the RR did not know that it was missing any RTP
> packet with specific sequence numbers since he was not expecting them in the unicast
> stream until they arrived and the OSN value is not that meaningful to it.

OSN is meaningful when it joins the mcast session. Now, it can put the packets in the right order and the only relation between the retransmission (burst) packets and the multicast source packets is the OSN field.
 
> Now when talking about the preamble / PSI or information that the RR needs which may have
> been transmitted many packets ago I see in the two drafts two directions to convey the
> information
> 
> 1.       Specified in the Begen draft is to convey the information using a new payload
> format that will include the needed information as a set of TLOV elements payload.
> 2.       Specified in Xia draft that conveys the information looking like a regular MPEG2
> TS retransmission packet but since it is generated by the RS it may get an OSN that is
> before the OSN of the first RAMS unicast stream.

In both drafts, the preamble packets are created by the server. We differ in what we put in the packets. In Frank's draft, I am still missing how one can set the OSN field. I also asked Frank to demonstrate how he generated the preamble packets.

I will give a "very" simple example here. Suppose each RTP packet is carrying 7 TS packets and the server is receiving all the RTP packets sent in the multicast session (numbers below denote the RTP seqnums). 

... RTP_(N+2)   RTP_(N+1)   RTP_(N)   RTP_(N-1) ...

Assume that the current preamble (recall that preamble data varies over time) data is a combination of the information carried in the second TS packet in RTP_(N-1) and the third TS packet in RTP_(N+1).

In our approach, we extract this information and create the necessary TLOV elements, generate a new RTP packet and send it to the RTP receiver requesting RAMS for this multicast stream.

Now, what does Frank's draft do here? I see two possible answers: 
i) Extract those two TS packets and put them in a new RTP packet and send it. If this is the case, what payload format is used? Is it 4588? If so, how is the OSN field set? If not, which format is used?
ii) Retransmit the two RTP packets (i.e., N-1 and N+1) intact. In this case, 4588 can be used similar to RAMS. But, this introduces new problems. 

First, in this example the amount of info we needed was equal to or (likely) smaller than 2 TS packets, but we transmitted two full RTP packets. This is not only inefficient but also increases the chances of loss for the preamble data. Our approach squeezes all the preamble data out of several TS packets and often generates a single RTP packet. If that packet makes it, we are done. However, if the other approach will be transmitting k RTP packets (because k different RTP packets carried partial preamble data), the failure probability will go from p to k*p. This is no good.

If (i) is used instead of (ii), due to padding and other redundant info in TS packets, it is still likely that the server will generate more RTP packets than the TLOV-based approach. So, failure chances will almost always be higher.
 
> I cannot say which one is better. My personal analysis is that in both cases the RS will
> need to cache this information and will need to create the right packet structure which is
> the TLOV in the first case and an MPEG2 TS PSI packet in the second case. The RR will need

Yes, the server needs to do some processing one way or another. Generating the TLOV elements is not a concern at the server since the server is already dealing with lots of TLV elements in RAMS transactions anyway. More importantly, the number of TLOV elements that the server needs to create is proportional to the number of MPEG2-TS streams in the system. OTOH, the number of TLV elements the server needs to create for RAMS is proportional to the number of RAMS requests, which is proportional to both the number of receivers and the number of MPEG2-TS streams in the system. If you consider that number of receivers is in the order of tens of thousands per server in a typical system whereas the number of streams is in the order of hundreds, it is quite clear that TLOV encoding of the preamble data is not a concern for the server.

> to support this payload format in the first case while I assume that in the second case it
> will look like a regular MPEG2 TS stream.
> 
>  Other points that I see is that in the first case the packet may be smaller in size and
> the extensibility can allow the RS to provide additional information that was not part of
> the original stream (I am not sure if that was the meaning here). In the second case it

Yes, in addition it also gives us the flexibility of using the preamble data in the best way for the specific decoder. Not every MPEG2-TS stream produced by even standard-compliant encoders will be RAMS-friendly. Often the preamble data will dispersed over a large time frame, across multiple packets with different repetition intervals. And even the standard-compliant decoders will be showing a different behavior based on how the preamble data is placed in the stream. So, to produce the best results, different decoders will often need the preamble data in slightly different ways. The server cannot know that and should not bother with it.

Our post processing at the client enables us to address the specific requirements of each decoder. We do the heavy lifting at the server, but also need some receiver-side processing to get the best result.

> looks like the RR will see an MPEG2 TS stream and will not need to support the TLOV
> payload format.

Frank's draft attempts to simplify the receiver-side implementation by avoiding the "post processing" stage that our draft needs. Any receiver implementing RAMS must already support TLV encoding/decoding and I don't see how avoiding the post processing of TLOV elements (which is really not different at all than TLV elements) will simplify the receiver implementation.

> I do not have any view about what is the right way and I was only trying to see if I
> understand both proposals.

Thanks for the summary. I hope I've made some points clearer. 

Cheers, acbegen.

---

From: Frank Xia <[email-masked]>
Date: Sun, 25 Oct 2009 20:47:01 -0500

Hi Roni

Thank for your review, and your summary is accurate.

We do recognize Avi's draft flexibility, at the same time,
I believe our draft also has some advantages which are
to try to avoid post-processing and to make preamble 
acquistion be agnostic to RR.

BR
Frank
  ----- Original Message ----- 
  From: Roni Even 
  To: [email-masked] 
  Sent: Sunday, October 25, 2009 4:51 PM
  Subject: [AVT] Observations on MPEG2-TS preamble drafts

  Hi,

  I read both drafts and I would like to present my view as an individual trying to clarify what I understand from both drafts and give my view on some of the issues raised on the mailing list.

I would like to start with an observation that RAMS is not a retransmission solution as specified in RFC 4588  "RTP retransmission is an effective packet loss recovery technique for  real-time applications with relaxed delay bounds.". There is no packet loss in this case. It is using the same mechanism to convey information that will look to the RR as a retransmission stream using the RTP packet structure defined in section 4 of RFC 4588 and the SDP description from RFC 4588.  Yet the RR did not know that it was missing any RTP packet with specific sequence numbers since he was not expecting them in the unicast stream until they arrived and the OSN value is not that meaningful to it. Now when talking about the preamble / PSI or information that the RR needs which may have been transmitted many packets ago I see in the two drafts two directions to convey the information 1.       Specified in the Begen draft is to convey the information using a new payload format that will include the needed information as a set of TLOV elements payload.2.       Specified in Xia draft that conveys the information looking like a regular MPEG2 TS retransmission packet but since it is generated by the RS it may get an OSN that is before the OSN of the first RAMS unicast stream.Frank=> I cannot say which one is better. My personal analysis is that in both cases the RS will need to cache this information and will need to create the right packet structure which is the TLOV in the first case and an MPEG2 TS PSI packet in the second case. The RR will need to support this payload format in the first case while I assume that in the second case it will look like a regular MPEG2 TS stream.  Other points that I see is that in the first case the packet may be smaller in size and the extensibility can allow the RS to provide additional information that was not part of the original stream (I am not sure if that was the meaning here). In the second case it looks like the RR will see an MPEG2 TS stream and will not need to support the TLOV payload format.  I do not have any view about what is the right way and I was only trying to see if I understand both proposals.  ThanksRoni Even as an individual     

------------------------------------------------------------------------------

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

---

From: Eric Friedrich <[email-masked]>
Date: Mon, 26 Oct 2009 09:36:48 -0400

Frank-
   I appreciate the simplicity in your design to avoid post-processing  
of the preamble. Unfortunately, different RR implementations require  
different preamble structures. This is one reason Ali & I have  
concisely specified the contents of the TLOVs- to show what may differ  
from one RR to another. I would like to see a similar specification as  
to preamble contents in your proposal as well.

That said, I don't believe your proposal restricts you from  
customizing a preamble to a certain type of RR, it just requires some  
additional work. In our draft, the RR-specific code runs as part of  
the TLOV post-processing. Since the main advantage behind your draft  
is no post-processing, the RS would have to customize the preamble to  
each specific RR. Customizing the preamble on the RS introduces the  
need for the RS to know exactly what the RR expects in the preamble.  
This is not impossible, but does introduce more complexity into your  
proposal.

I don't believe that preamble acquisition can or should be agnostic to  
RR. The wide range of RR's (both legacy and future) requires that any  
solution be flexible enough to serve the differing needs of each.

Thanks,
Eric

On Oct 25, 2009, at 9:47 PM, Frank Xia wrote:

> I read both drafts and I would like to present my view as an  
> individual trying to clarify what I understand from both drafts and  
> give my view on some of the issues raised on the mailing list.
>
> I would like to start with an observation that RAMS is not a  
> retransmission solution as specified in RFC 4588  "RTP  
> retransmission is an effective packet loss recovery technique for   
> real-time applications with relaxed delay bounds.". There is no  
> packet loss in this case. It is using the same mechanism to convey  
> information that will look to the RR as a retransmission stream  
> using the RTP packet structure defined in section 4 of RFC 4588 and  
> the SDP description from RFC 4588.  Yet the RR did not know that it  
> was missing any RTP packet with specific sequence numbers since he  
> was not expecting them in the unicast stream until they arrived and  
> the OSN value is not that meaningful to it.
>
> Now when talking about the preamble / PSI or information that the RR  
> needs which may have been transmitted many packets ago I see in the  
> two drafts two directions to convey the information
>
> 1.       Specified in the Begen draft is to convey the information  
> using a new payload format that will include the needed information  
> as a set of TLOV elements payload.
> 2.       Specified in Xia draft that conveys the information looking  
> like a regular MPEG2 TS retransmission packet but since it is  
> generated by the RS it may get an OSN that is before the OSN of the  
> first RAMS unicast stream.
> Frank=>
>
> I cannot say which one is better. My personal analysis is that in  
> both cases the RS will need to cache this information and will need  
> to create the right packet structure which is the TLOV in the first  
> case and an MPEG2 TS PSI packet in the second case. The RR will need  
> to support this payload format in the first case while I assume that  
> in the second case it will look like a regular MPEG2 TS stream.
>
>  Other points that I see is that in the first case the packet may be  
> smaller in size and the extensibility can allow the RS to provide  
> additional information that was not part of the original stream (I  
> am not sure if that was the meaning here). In the second case it  
> looks like the RR will see an MPEG2 TS stream and will not need to  
> support the TLOV payload format.
>
>
> I do not have any view about what is the right way and I was only  
> trying to see if I understand both proposals.
>
> Thanks

---

From: Frank Xia <[email-masked]>
Date: Mon, 26 Oct 2009 10:08:31 -0500

Hi Eric

Thank your comments.

Theoretically,  both  solutions works.  All the information
received by RR is from RS.  RS has enough information
(according to my understanding, you are questioning RR's
processing capability, e.g. CPU, memory).

However, from engineering perspective, there are some differences.
Your solution is RR-oriented and needs post-processing, while
ours is RS-oriented and needs some pre-processing.

Please also see my other inline response.

BR
Frank
----- Original Message ----- 
From: "Eric Friedrich" <[email-masked]>
To: "Frank Xia" <[email-masked]>
Cc: "Roni Even" <[email-masked]>; <[email-masked]>
Sent: Monday, October 26, 2009 8:36 AM
Subject: Re: [AVT] Observations on MPEG2-TS preamble drafts

> Frank-
>   I appreciate the simplicity in your design to avoid post-processing  of 
> the preamble. Unfortunately, different RR implementations require 
> different preamble structures. This is one reason Ali & I have  concisely 
> specified the contents of the TLOVs- to show what may differ  from one RR 
> to another. I would like to see a similar specification as  to preamble 
> contents in your proposal as well.
Frank=>This is also one reason we try to screen the diversity of RR 
implementations.
No matter what a RR is implemented, this RR should be able to processing
ISO13818-1  compliant TS.  OK,We will elaborate our draft, but you already
got the main idea.

>
> That said, I don't believe your proposal restricts you from  customizing a 
> preamble to a certain type of RR, it just requires some  additional work. 
> In our draft, the RR-specific code runs as part of  the TLOV 
> post-processing. Since the main advantage behind your draft  is no 
> post-processing, the RS would have to customize the preamble to  each 
> specific RR. Customizing the preamble on the RS introduces the  need for 
> the RS to know exactly what the RR expects in the preamble.  This is not 
> impossible, but does introduce more complexity into your  proposal.
Frank=>You are right. Our solution is never intented to preclude any
RR-specific post-processing.  RR can do any optimization based on standard
TS.  There is no any information loss for our solution.
However, I am not favoring to do any un-certain prediction.

> solution be flexible enough to serve the differing needs of each.
Frank=>For me, the preamble acquistion should be agnostic to RR
IF there is no obvious engineering obstacle.   You don't know exactly
the needs of wide range of RR, why you assert your solution is better than 
ours? :-).

I don't buy that your solution takes advantages just because
your solution has more "by-products".
Let's define the scope of this problem and focus on the core.

>> retransmission solution as specified in RFC 4588  "RTP  retransmission is 
>> an effective packet loss recovery technique for   real-time applications 
>> with relaxed delay bounds.". There is no  packet loss in this case. It is 
>> using the same mechanism to convey  information that will look to the RR 
>> as a retransmission stream  using the RTP packet structure defined in 
>> section 4 of RFC 4588 and  the SDP description from RFC 4588.  Yet the RR 
>> did not know that it  was missing any RTP packet with specific sequence 
>> numbers since he  was not expecting them in the unicast stream until they 
>> arrived and  the OSN value is not that meaningful to it.
>>
>> needs which may have been transmitted many packets ago I see in the  two 
>> drafts two directions to convey the information
>>
>> 1.       Specified in the Begen draft is to convey the information  using 
>> a new payload format that will include the needed information  as a set 
>> of TLOV elements payload.
>> like a regular MPEG2 TS retransmission packet but since it is  generated 
>> by the RS it may get an OSN that is before the OSN of the  first RAMS 
>> unicast stream.
>> Frank=>
>>
>> I cannot say which one is better. My personal analysis is that in  both 
>> cases the RS will need to cache this information and will need  to create 
>> the right packet structure which is the TLOV in the first  case and an 
>> MPEG2 TS PSI packet in the second case. The RR will need  to support this 
>> payload format in the first case while I assume that  in the second case 
>> it will look like a regular MPEG2 TS stream.
>>
>> additional information that was not part of the original stream (I  am 
>> not sure if that was the meaning here). In the second case it  looks like 
>> the RR will see an MPEG2 TS stream and will not need to  support the TLOV 
>> payload format.
>>
>>
>> I do not have any view about what is the right way and I was only  trying 
>> to see if I understand both proposals.
>>
>> Thanks

---

From: Frank Xia <[email-masked]>
Date: Mon, 26 Oct 2009 11:07:24 -0500

Hi Ali

See my inline comments.

Cheers
Frank

----- Original Message ----- 
From: "Ali C. Begen (abegen)" <[email-masked]>
To: "Roni Even" <[email-masked]>; <[email-masked]>
Sent: Sunday, October 25, 2009 7:22 PM
Subject: Re: [AVT] Observations on MPEG2-TS preamble drafts

>> trying to clarify
>> retransmission solution as
> This is open to interpretation. I view RAMS as the receiver has lost 
> everything so far (or for a long time) and subsequently lost its 
> "synchronization (or whatever we wanna call it)" with the primary mcast 
> stream and thus is asking the retransmission server to send whatever that 
> is necessary to put him back on track. This is what we said in our slides 
> since day one.
>
>> missing any RTP
> OSN is meaningful when it joins the mcast session. Now, it can put the 
> packets in the right order and the only relation between the 
> retransmission (burst) packets and the multicast source packets is the OSN 
> field.
Frank=>The RR has never meant to to receive the burst packet before.
IMHO, there is no such relationship in rapid acquistion (fast channel 
change) case.

>> needs which may have
>> a new payload
> In both drafts, the preamble packets are created by the server. We differ 
> in what we put in the packets. In Frank's draft, I am still missing how 
> one can set the OSN field. I also asked Frank to demonstrate how he 
> generated the preamble packets.
>
> I will give a "very" simple example here. Suppose each RTP packet is 
> carrying 7 TS packets and the server is receiving all the RTP packets sent 
> in the multicast session (numbers below denote the RTP seqnums).
>
> Assume that the current preamble (recall that preamble data varies over 
> time) data is a combination of the information carried in the second TS 
> packet in RTP_(N-1) and the third TS packet in RTP_(N+1).
>
> In our approach, we extract this information and create the necessary TLOV 
> elements, generate a new RTP packet and send it to the RTP receiver 
> requesting RAMS for this multicast stream.
>
> i) Extract those two TS packets and put them in a new RTP packet and send 
> it. If this is the case, what payload format is used? Is it 4588? If so, 
> how is the OSN field set? If not, which format is used?
> ii) Retransmit the two RTP packets (i.e., N-1 and N+1) intact. In this 
> case, 4588 can be used similar to RAMS. But, this introduces new problems.
Frank=>Sorry for not making things clearer in our draft.  Let me have 
another shot.
1)RS identifies necessary TSes
2)RS creates new RTP packets in the format of 4588.
    a) Let's say there are two RTP packets to convey preamble,
    b) and given the SN of the first unicast burst RTP is N.
    c) The OSNs of the two preamble RTP packets are  N-2, N-1 respectively.

>
> First, in this example the amount of info we needed was equal to or 
> (likely) smaller than 2 TS packets, but we transmitted two full RTP 
> packets. This is not only inefficient but also increases the chances of 
> loss for the preamble data. Our approach squeezes all the preamble data 
> out of several TS packets and often generates a single RTP packet. If that 
> packet makes it, we are done. However, if the other approach will be 
> transmitting k RTP packets (because k different RTP packets carried 
> partial preamble data), the failure probability will go from p to k*p. 
> This is no good.
Frank=>I tried to give you a calculation,  and you can calcuate again.
The size preamble information is small.  If you talk about the failure 
probability,
you should also take into account of  unicast burst.

In a word, either efficiency or failure probablity is  not a issue just 
because
the traffic volume of preamble information is small comparing to
unicast burst.

>
> If (i) is used instead of (ii), due to padding and other redundant info in 
> TS packets, it is still likely that the server will generate more RTP 
> packets than the TLOV-based approach. So, failure chances will almost 
> always be higher.
Frank=>see my above comments

>> cases the RS will
> Yes, the server needs to do some processing one way or another. Generating 
> the TLOV elements is not a concern at the server since the server is 
> already dealing with lots of TLV elements in RAMS transactions anyway. 
> More importantly, the number of TLOV elements that the server needs to 
> create is proportional to the number of MPEG2-TS streams in the system. 
> OTOH, the number of TLV elements the server needs to create for RAMS is 
> proportional to the number of RAMS requests, which is proportional to both 
> the number of receivers and the number of MPEG2-TS streams in the system. 
> If you consider that number of receivers is in the order of tens of 
> thousands per server in a typical system whereas the number of streams is 
> in the order of hundreds, it is quite clear that TLOV encoding of the 
> preamble data is not a concern for the server.
Frank=>TLOV is feaible, however, RR agnostic method is probably simpler.

>> smaller in size and
> Yes, in addition it also gives us the flexibility of using the preamble 
> data in the best way for the specific decoder. Not every MPEG2-TS stream 
> produced by even standard-compliant encoders will be RAMS-friendly. Often 
> the preamble data will dispersed over a large time frame, across multiple 
> packets with different repetition intervals. And even the 
> standard-compliant decoders will be showing a different behavior based on 
> how the preamble data is placed in the stream. So, to produce the best 
> results, different decoders will often need the preamble data in slightly 
> different ways. The server cannot know that and should not bother with it.
Frank=>Extracting preamble information is a common step between your 
solution and ours.
The server is trying to do some basic work which works with  all RR, and 
IMHO preamble
acquisition is one of these work.

>
> Our post processing at the client enables us to address the specific 
> requirements of each decoder. We do the heavy lifting at the server, but 
> also need some receiver-side processing to get the best result.
>
> Frank's draft attempts to simplify the receiver-side implementation by 
> avoiding the "post processing" stage that our draft needs. Any receiver 
> implementing RAMS must already support TLV encoding/decoding and I don't 
> see how avoiding the post processing of TLOV elements (which is really not 
> different at all than TLV elements) will simplify the receiver 
> implementation.
Frank=>You assume all RR MUST implement RAMS.  What if there is some other 
alternative?
e.g Network-based Rapid Acquisition of Multicast RTP Sessions in
http://tools.ietf.org/id/draft-xia-avt-proxy-rapid-acquisition-00.txt.

Our solution works in both scenarios.

---

From: "Ali C. Begen (abegen)" <[email-masked]>
Date: Mon, 26 Oct 2009 09:43:30 -0700

[snip]
> IMHO, there is no such relationship in rapid acquistion (fast channel

I am not sure what your point here is. Looks like we are not in sync. But I said enough about this already.
 
[snip]
>     b) and given the SN of the first unicast burst RTP is N.

Where did you come up with this? The SN of the first burst packet can be anything.

>     c) The OSNs of the two preamble RTP packets are  N-2, N-1 respectively.

Huh? You seem to be mixing the OSN and SN fields in the burst/retransmission packets. OSN field relates to the seqnums of the source RTP packets sent in the multicast session. The SN fields are just the seqnums used in the retransmission session. They have no relation to each other. The important relation is the OSN values and the seqnums of the primary source packets.

The two RTP packets carrying your preamble (in this example) have seqnums of N-1 and N+1, but the retransmissions of these packets have OSN values of N-2 and N-1. Is that what you are saying?

> you should also take into account of  unicast burst.

There is a difference in failure probability if I transmit k packets instead of one packet for the preamble data. The amount of data can be small but the failure probability depends on how I transmit it. 

In addition, the example given above is oversimplified. If you wanna transmit every full RTP packet that has something to do with the preamble data, you will end up transmitting a lot of them because preamble data is not contiguous. 
 
[snip]
> Frank=>TLOV is feaible, however, RR agnostic method is probably simpler.

For whom? Every different type of decoder/set-top will need customization one way or another.
 
[snip]
> Frank=>You assume all RR MUST implement RAMS.  What if there is some other

That is my general expectation. 

> http://tools.ietf.org/id/draft-xia-avt-proxy-rapid-acquisition-00.txt.

If a proxy can handle the RAMS for a non-RAMS client, the same proxy can also handle the "post-processing" for that client, too. Unless I am missing something, our approach should also work.

-acbegen

---

From: Frank Xia <[email-masked]>
Date: Mon, 26 Oct 2009 13:51:10 -0500

Hello Ali

Please check again

BR
Frank

----- Original Message ----- 
From: "Ali C. Begen (abegen)" <[email-masked]>
To: "Frank Xia" <[email-masked]>; "Roni Even" 
<[email-masked]>; <[email-masked]>
Sent: Monday, October 26, 2009 11:43 AM
Subject: RE: [AVT] Observations on MPEG2-TS preamble drafts

[snip]
> >> case. It is using the same mechanism to convey information that will 
> >> look
> >> to the RR as a
> >> retransmission stream using the RTP packet structure defined in section 
> >> 4
> >> of RFC 4588 and
> >> packet with specific sequence numbers since he was not expecting them 
> >> in
> >> the unicast

I am not sure what your point here is. Looks like we are not in sync. But I 
said enough about this already.
Frank=>me too.

[snip]
>     b) and given the SN of the first unicast burst RTP is N.

Where did you come up with this? The SN of the first burst packet can be 
anything.
Frank=>Sorry for my typo.  I meant OSN not SN.

>     c) The OSNs of the two preamble RTP packets are  N-2, N-1 

Huh? You seem to be mixing the OSN and SN fields in the burst/retransmission 
packets. OSN field relates to the seqnums of the source RTP packets sent in 
the multicast session. The SN fields are just the seqnums used in the 
retransmission session. They have no relation to each other. The important 
relation is the OSN values and the seqnums of the primary source packets.

The two RTP packets carrying your preamble (in this example) have seqnums of 
N-1 and N+1, but the retransmissions of these packets have OSN values of N-2 
and N-1. Is that what you are saying?
Frank=>All I am talking is about OSN.

> you should also take into account of  unicast burst.

There is a difference in failure probability if I transmit k packets instead 
of one packet for the preamble data. The amount of data can be small but the 
failure probability depends on how I transmit it.
Frank=>According to my simple calcuation, there is not big difference.
You can figure out based on you model.

In addition, the example given above is oversimplified. If you wanna 
transmit every full RTP packet that has something to do with the preamble 
data, you will end up transmitting a lot of them because preamble data is 
not contiguous.

[snip]
> >> the TLOV in the first case and an MPEG2 TS PSI packet in the second 
> >> case.
> >> The RR will need
> >

For whom? Every different type of decoder/set-top will need customization 
one way or another.
Frank=>For RR.

[snip]

That is my general expectation.
Frank=>It is ok, however, it is not neccessarily to exlcude other 
possibilities.

> http://tools.ietf.org/id/draft-xia-avt-proxy-rapid-acquisition-00.txt.

If a proxy can handle the RAMS for a non-RAMS client, the same proxy can 
also handle the "post-processing" for that client, too. Unless I am missing 
something, our approach should also work.
Frank=>Of course, you approach still works, however,
your above listed  reason does not stand.

-acbegen

> >> trying

---

From: Roni Even <[email-masked]>
Date: Mon, 26 Oct 2009 21:04:47 +0200

Ali,
I am also confused. The RAMS draft references the OSN only in step 8 of
section 6.2 (terminate) and reading step 8 I do not see why you think that
the Xia proposal will break in this case.
Thanks
Roni Even

> From: Frank Xia [mailto:[email-masked]]
> Sent: Monday, October 26, 2009 8:51 PM
> To: Ali C. Begen (abegen); Roni Even; [email-masked]
> > >> stream until they arrived and the OSN value is not that meaningful
> to
> > >> it.
> > >
> > > retransmission (burst) packets and the multicast source packets is
> the
> > > OSN
> > > field.
> > > carrying 7 TS packets and the server is receiving all the RTP
> packets
> > > sent
> > > In our approach, we extract this information and create the
> necessary
> > > TLOV
> > > i) Extract those two TS packets and put them in a new RTP packet
> and
> > > send
> > > out of several TS packets and often generates a single RTP packet.
> If
> > > that
> both
> > >> need to cache this information and will need to create the right
> packet
> > >> structure which is
> > > proportional to the number of RAMS requests, which is proportional
> to
> > > both
> > > thousands per server in a typical system whereas the number of
> streams
> > > is
> > > see how avoiding the post processing of TLOV elements (which is
> really
> > > not

---

From: "Ali C. Begen (abegen)" <[email-masked]>
Date: Mon, 26 Oct 2009 12:48:20 -0700

Hi Roni,

I am not sure where you are confused. Ignoring the preamble for now, consider the following scenario:

RS receives the RAMS request, figures out the burst starting point. Assume the burst will start with the source packet with seqnum 100. The burst will continue until it catches up with the multicast. So, the burst packets sent by RS will have OSN fields set to 100, 101, 102, .... so on.

However, the seqnum field in the RTP header of the first burst packet could be 2000 (a random number). The second burst packet will have seqnum field set to 2001, so on. Assuming the burst will end when RS sends the source packet with seqnum 103, this is what we get:

1st burst packet (SN: 2000, OSN: 100)
2nd burst packet (SN: 2001, OSN: 101)
3rd burst packet (SN: 2002, OSN: 102)
4th burst packet (SN: 2003, OSN: 103)

When RR joined the multicast, the first packet RR receives could be the one with seqnum 103. RR will know that it is a duplicate, and will discard it. There could be re-ordering, but it does not matter. By using the OSN fields of the burst packets and the seqnum fields of the multicast packets, RR puts everything in the right order.

Now, if a preamble RTP packet needs to be sent prior to the burst, in our approach this is what we do:

1st preamble packet (SN: 2000 - there is no OSN field)
1st burst packet (SN: 2001, OSN: 100)
2nd burst packet (SN: 2002, OSN: 101)
3rd burst packet (SN: 2003, OSN: 102)
4th burst packet (SN: 2004, OSN: 103)

What I am saying is that the seqnums in the retransmission session (where we payload-type multiplex the preamble packets with the burst packets) are independent of the OSNs of the burst packets. More precisely, its starting value has nothing to do with the OSNs.

I am still not clear what Frank proposes in his proposal and am looking forward to some explanatory diagrams in the meeting. If the RTP packets carrying the Preamble data will be retransmitted intact, 4588 can be used provided that the OSN fields are properly set. But, as I mentioned earlier, that introduces new problems.

HTH,
-acbegen

> From: Roni Even [mailto:[email-masked]]
> Sent: Monday, October 26, 2009 3:05 PM
> To: 'Frank Xia'; Ali C. Begen (abegen); [email-masked]

---

From: Roni Even <[email-masked]>
Date: Mon, 26 Oct 2009 22:16:44 +0200

Ali,
See inline

> From: Ali C. Begen (abegen) [mailto:[email-masked]]
> Sent: Monday, October 26, 2009 9:48 PM
> To: Roni Even; Frank Xia; [email-masked]
> RS receives the RAMS request, figures out the burst starting point.
> Assume the burst will start with the source packet with seqnum 100. The
> burst will continue until it catches up with the multicast. So, the
> burst packets sent by RS will have OSN fields set to 100, 101, 102,
> .... so on.
RE: they can start with OSN 90 where the RS knows that 90 till 100 are the
new generated packets. The RR does not care.
> 
> However, the seqnum field in the RTP header of the first burst packet
> could be 2000 (a random number). The second burst packet will have
> seqnum field set to 2001, so on. Assuming the burst will end when RS
> sends the source packet with seqnum 103, this is what we get:
> 
> When RR joined the multicast, the first packet RR receives could be the
> one with seqnum 103. RR will know that it is a duplicate, and will
> discard it. There could be re-ordering, but it does not matter. By
> using the OSN fields of the burst packets and the seqnum fields of the
> multicast packets, RR puts everything in the right order.
> 

RE: There will be an OSN field of 99

> What I am saying is that the seqnums in the retransmission session
> (where we payload-type multiplex the preamble packets with the burst
> packets) are independent of the OSNs of the burst packets. More
> precisely, its starting value has nothing to do with the OSNs.
> 
> I am still not clear what Frank proposes in his proposal and am looking
> forward to some explanatory diagrams in the meeting. If the RTP packets
> carrying the Preamble data will be retransmitted intact, 4588 can be
> used provided that the OSN fields are properly set. But, as I mentioned
> earlier, that introduces new problems.
> 
> HTH,
> -acbegen
> 
>

---

From: "Ali C. Begen (abegen)" <[email-masked]>
Date: Mon, 26 Oct 2009 13:32:12 -0700

> Sent: Monday, October 26, 2009 4:17 PM
> To: Ali C. Begen (abegen); 'Frank Xia'; [email-masked]

That is IMO a misuse of the OSN field. Suppose you used 90-99 for the newly generated packets and one got lost (say 95). Now, RR may ask for retransmission for 95. The server needs to remember that the client is asking for the fake 95 but not the original 95 sent in the multicast session. For retransmission, all these new packets need to be stored for a while. Ow, the whole RAMS may fail.

Or, the client might be receiving FEC as well. Again, assume 95 was lost and it will try to repair it by using the packets it received so far. The current FEC block might be using the packets from 90 to 110. But, in this case FEC will fail since we will be feeding fake packets to the FEC decoding process.

> RE: There will be an OSN field of 99

No, because we are not using 4588 format in our draft.

-acbegen

---

From: Roni Even <[email-masked]>
Date: Mon, 26 Oct 2009 23:13:24 +0200

Ali,
Inline
Roni

<snip>
> > >
> > > Hi Roni,
> > >
> > > I am not sure where you are confused. Ignoring the preamble for
> now,
> > > consider the following scenario:
> > >
> That is IMO a misuse of the OSN field. Suppose you used 90-99 for the
> newly generated packets and one got lost (say 95). Now, RR may ask for
> retransmission for 95. The server needs to remember that the client is
> asking for the fake 95 but not the original 95 sent in the multicast
> session. For retransmission, all these new packets need to be stored
> for a while. Ow, the whole RAMS may fail.

RE: I assume this is the RS problem

> Or, the client might be receiving FEC as well. Again, assume 95 was
> lost and it will try to repair it by using the packets it received so
> far. The current FEC block might be using the packets from 90 to 110.
> But, in this case FEC will fail since we will be feeding fake packets
> to the FEC decoding process.
> 
RE: this may be a problem but it opens a different topic for RAMS, do you
think that the same FEC is needed for the multicast and unicast. This will
mean that the RS will need to negotiate FEC for the unicast based on the
multicast, is this a requirement? 

Does it mean that the RS will receive the multicast with FEC and if there
was a packet loss fpr the RS it will reconstruct the missing packet using
FEC for sending to the unicast but build also the missing fec information.
There is also a problem in the general RAMS case if the RS retransmit the
multicast with the FEC information to the unicast session since it may use
block that include packets before the first unicast stream.

I think that FEC handling in this case is not simple and the RS may decide
to strip FEC from the multicast and either build FE for the unicast or send
without it. In this case there is no problem with FEC since the RS will
build it on the unicast. 

> > > Now, if a preamble RTP packet needs to be sent prior to the burst,
> in
> > > our approach this is what we do:
> > >
RE: I thought that in your proposal the preamble is a separate payload
subtype and will have a different payload type number and sequence numbers
space, so it may have 2000 but will be better with other number space.

> > > > I am also confused. The RAMS draft references the OSN only in
> step 8
> > > of
> > > > section 6.2 (terminate) and reading step 8 I do not see why you
> think
> > > that

---

From: "Ali C. Begen (abegen)" <[email-masked]>
Date: Mon, 26 Oct 2009 14:44:46 -0700

> RE: I assume this is the RS problem

Yes, this will put extra burden on the RS to keep state information, which is something we wanna minimize/avoid. If RS fails to implement it properly, RR will pay for it.

> multicast, is this a requirement?

First of all, I just gave this as an example to show why faking the OSN field was a bad idea.

Here, I was referring to the FEC sent for the primary multicast stream, whether in the same multicast session or in a different session. That FEC is sent by the media source, not by RS. I don't think the RS should be generating any FEC for the burst traffic, as it defeats the purpose of RAMS. But, when RR joins the multicast, it may start receiving FEC data as well. If it does, it may certainly use it, when needed.

See http://www.ietf.org/id/draft-begen-avt-rams-scenarios-00.txt for an example.
 
> FEC for sending to the unicast but build also the missing fec information.

RS can receive FEC and use it for loss recovery if it wants to. There might be clients who want to do rapid acquisition on the FEC stream, too. Not that I am saying it is a good idea, but RAMS really does not care.

> block that include packets before the first unicast stream.

It is true that the FEC block boundaries are not necessarily aligned with the RAMS burst starting points.
 
> without it. In this case there is no problem with FEC since the RS will

If you look at the draft above, you will see discussion around topics like this one. In that draft, I am suggesting that RAMS should be per stream, not multicast session. If we agree on that, the clients that want rapid acquisition for the source stream only or both the source and FEC streams can be handled properly.

Building FEC for the unicast burst is not a good idea in general, IMO as it will chew up the bandwidth unnecessarily, especially if retransmission for the missing burst packets is an option. If not, FEC can be considered. 
 
> subtype and will have a different payload type number and sequence numbers

Yes, it will be a separate payload type number in the PT field, but we think it should better be PT-multiplexed with the other 4588-formatted burst packets in the retransmission session in case of RAMS (thus they share the seqnum space). This is mostly because our preamble data is often 1 packet and the preamble data is related to the burst packets so PT  multiplexing seems to be acceptable (at least to us). It has the same clockrate, so no complications there, either. Ow, I am aware that PT multiplexing is not a suggested way of sending different PTs.

-acbegen