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

[Frank Xia <[e-mail]>]

Hello Ali

Please check again

BR
Frank

----- Original Message ----- 
From: "Ali C. Begen (abegen)" <[e-mail]>
To: "Frank Xia" <[e-mail]>; "Roni Even" 
<[e-mail]>; <[e-mail]>
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
> >> 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.
Frank=>me too.

[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.
Frank=>Sorry for my typo.  I meant OSN not SN.

>     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?
Frank=>All I am talking is about OSN.

> >
> > 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.
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]
> >> 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.
Frank=>For RR.

[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.
Frank=>It is ok, however, it is not neccessarily to exlcude other 
possibilities.

> 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.
Frank=>Of course, you approach still works, however,
your above listed  reason does not stand.

-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