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

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

> > > 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.
> 
> 
> RE: I assume this is the RS problem

Yes, this will put extra burden on the RS to keep state information, which is something we wanna minimize/avoid. If RS fails to implement it properly, RR will pay for it.

> >
> 
> > 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.
> >
> RE: this may be a problem but it opens a different topic for RAMS, do you
> think that the same FEC is needed for the multicast and unicast. This will
> mean that the RS will need to negotiate FEC for the unicast based on the
> multicast, is this a requirement?

First of all, I just gave this as an example to show why faking the OSN field was a bad idea.

Here, I was referring to the FEC sent for the primary multicast stream, whether in the same multicast session or in a different session. That FEC is sent by the media source, not by RS. I don't think the RS should be generating any FEC for the burst traffic, as it defeats the purpose of RAMS. But, when RR joins the multicast, it may start receiving FEC data as well. If it does, it may certainly use it, when needed.

See http://www.ietf.org/id/draft-begen-avt-rams-scenarios-00.txt for an example.
 
> Does it mean that the RS will receive the multicast with FEC and if there
> was a packet loss fpr the RS it will reconstruct the missing packet using
> FEC for sending to the unicast but build also the missing fec information.

RS can receive FEC and use it for loss recovery if it wants to. There might be clients who want to do rapid acquisition on the FEC stream, too. Not that I am saying it is a good idea, but RAMS really does not care.

> There is also a problem in the general RAMS case if the RS retransmit the
> multicast with the FEC information to the unicast session since it may use
> block that include packets before the first unicast stream.

It is true that the FEC block boundaries are not necessarily aligned with the RAMS burst starting points.
 
> I think that FEC handling in this case is not simple and the RS may decide
> to strip FEC from the multicast and either build FE for the unicast or send
> without it. In this case there is no problem with FEC since the RS will
> build it on the unicast.

If you look at the draft above, you will see discussion around topics like this one. In that draft, I am suggesting that RAMS should be per stream, not multicast session. If we agree on that, the clients that want rapid acquisition for the source stream only or both the source and FEC streams can be handled properly.

Building FEC for the unicast burst is not a good idea in general, IMO as it will chew up the bandwidth unnecessarily, especially if retransmission for the missing burst packets is an option. If not, FEC can be considered. 
 
> > > >
> > > > 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.
> >
> >
> RE: I thought that in your proposal the preamble is a separate payload
> subtype and will have a different payload type number and sequence numbers

Yes, it will be a separate payload type number in the PT field, but we think it should better be PT-multiplexed with the other 4588-formatted burst packets in the retransmission session in case of RAMS (thus they share the seqnum space). This is mostly because our preamble data is often 1 packet and the preamble data is related to the burst packets so PT  multiplexing seems to be acceptable (at least to us). It has the same clockrate, so no complications there, either. Ow, I am aware that PT multiplexing is not a suggested way of sending different PTs.

-acbegen

> space, so it may have 2000 but will be better with other number space.