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

[Roni Even <Even.roni at huawei.com>]

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

> 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