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

["Ali C. Begen (abegen)" <abegen at cisco.com>]

> -----Original Message-----
> From: Roni Even [mailto:Even.roni at huawei.com]
> Sent: Monday, October 26, 2009 4:17 PM
> To: Ali C. Begen (abegen); 'Frank Xia'; avt at ietf.org
> Subject: RE: [AVT] Observations on MPEG2-TS preamble drafts
> 
> Ali,
> See inline
> 
> > -----Original Message-----
> > From: Ali C. Begen (abegen) [mailto:abegen at cisco.com]
> > Sent: Monday, October 26, 2009 9:48 PM
> > To: Roni Even; Frank Xia; avt at ietf.org
> > Subject: RE: [AVT] Observations on MPEG2-TS preamble drafts
> >
> > 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.
> 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.

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.

> >
> > 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)
> 
> 
> RE: There will be an OSN field of 99

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

-acbegen

 
> > 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
> >
> >
> > > -----Original Message-----
> > > From: Roni Even [mailto:Even.roni at huawei.com]
> > > Sent: Monday, October 26, 2009 3:05 PM
> > > To: 'Frank Xia'; Ali C. Begen (abegen); avt at ietf.org
> > > Subject: RE: [AVT] Observations on MPEG2-TS preamble drafts
> > >
> > > 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