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

["Ali C. Begen (abegen)" <[e-mail]>]

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

I am not sure what your point here is. Looks like we are not in sync. But I said enough about this already.
 
[snip]
> >
> > 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.
> 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.

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?

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

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

That is my general expectation. 

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

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

 
> Our solution works in both scenarios.
> 
> >
> >> 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.
> >
> >> Thanks
> >> Roni Even as an individual