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

[Roni Even <[e-mail]>]

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

> -----Original Message-----
> From: Frank Xia [mailto:[e-mail]]
> Sent: Monday, October 26, 2009 8:51 PM
> To: Ali C. Begen (abegen); Roni Even; [e-mail]
> Subject: Re: [AVT] Observations on MPEG2-TS preamble drafts
> 
> 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