Re: [MMUSIC] [AVTCORE] Comments on draft-begen-mmusic-redundancy-grouping-01

["Ali C. Begen (abegen)" <[e-mail]>]

> -----Original Message-----
> From: [e-mail] [mailto:[e-mail]] On Behalf Of Magnus Westerlund
> Sent: Friday, July 22, 2011 8:39 AM
> To: mmusic (E-mail); IETF AVTCore WG
> Subject: [AVTCORE] Comments on draft-begen-mmusic-redundancy-grouping-01
> 
> Hi,
> 
> (Primarily as individual, but the WG home question is as WG chair)
> 
> I have reviewed this draft and some comments on it.

Thanks for the review.
 
> 1. If this solution proposal is to be taken forward I think it needs to
> be discussed in AVTCORE. The reason is that it has several RTP details
> that needs to be figured out to make stream duplication issue free in a
> general usage. I will take up a few of these issues in the below comments.

That is why we asked for a slot in avtcore on wed.
 
> 2. One aspect this document has is a relation to what is discussed in
> draft-westerlund-avtcore-multistream-and-simulcast-00. Stream
> duplication both results in a certain form of multi-stream and also has
> a similar but slightly different semantics to simulcast in that the
> streams are two representations of a single original media source. In
> this case they are clones, but not true duplicates due to that RTP
> doesn't handle try duplicates well.

The data carried in the redundant streams are identical but the rtp header differs due to the different SSRCs. That is all. SSRC muxing nicely fits the use case we are tackling with. Simulcasting is quite different from our use case because in simulcasting different RTP streams most likely carry different data.
 
> 3. Another issue that also the authors has identified is the question of
> what one do when one has multiple media streams from the same end-point.

>From the same end-point (e.g., source) there could of course of multiple media streams. You can use SSRC muxing for example to identify your streams and use ssrc-group to group them if needed.

The concern in that editorial note was what if there were multiple streams in each m line but what if you wanted grouping/association among only a subset.

For example,

        m=video 30000 RTP/AVP 101 102
        ....
        m=video 30000 RTP/AVP 103 104

I can easily associate 101 and 102 if I want to, but what if 101 and 103 were associated with each other. Can I use a=group line? Probably not. But, I don't know why you would need that kind of relation in the first place (even if you need, there are probably less messy ways to express them). If that had been a very desirable feature, SDP and grouping semantics along with RTP would not have defined in their current form I guess.

> And in a general case one can't use the CNAME to separate the sources.
> The reason is that two media sources that has a common timing
> (synchronization) context do needs to indicate that by having the same
> CNAME. Thus there are need for some additional mechanism to ensure that

If 101 and 103 are associated, why can't I use the same CNAME for those streams? If 102 and 104 are associated/related, I would use a common CNAME for them, too (but theirs would be separate from 101 and 103's).

> SSRC carrying RTP media streams that are duplicates of each other do in
> fact be labeled explicitly. I also note that a SDP based solution is not
> sufficient to resolve this issue. I think we need something in RTP, so
> that SSRC collisions can be handled.

I can't say I am following.

> 4. In addition there is a few questions how this duplication really
> should set some RTP fields. Is the duplication only working on Sequence

That is the easiest way for a middle box or endpoint doing the stream merging (duplicate suppression). If seqnums are different, what would one do? look into the payload?

> number level? There seem to be additional questions, for example in the
> need to have RTP timestamp considerations between the streams. They need
> to point identically into the joint timeline. Otherwise outages, or
> receiver taking synch from one and not the other stream can end up with
> different synchronizations. Becomes especially interesting to discuss
> when the time shifted transmission.

The duplicate streams are coming from the same source, so they have the same timestamp as well as seqnums. It has to be this way because the node merging the streams will not re-write anything at all. It is a simple suppression operation. Beauty of it is that things stay pretty simple to use and implement without any changes to RTP/RTCP plane at all.

As for the time-shifted transmission, I suppose you are referring to the temporal diversity/delayed duplication (draft-begen-mmusic-temporal-interleaving-02). Well, in that case, timestamps are still the same for the reasons above. Changing the timestamps for the delayed packets does not bring any benefit (actually it complicates things) since the ultimate RTP application will still receive one and only one RTP stream.

> 5. The draft also discussed Payload Type differences and have them in
> the SDP examples. I don't see how that is appropriate. If the streams

When you are doing SSRC muxing, you put multiple streams in the same m line and they end up having different PT numbers. What is wrong with that? If they are in separate m lines, they could have the same PT number.

> are true encoding duplicates then they should use the same payload type
> configuration, and thus a single payload type should be sufficient and
> in fact recommended, unless the source encoding truly changes.

See above.

> 6. I think it is worth discussing also the benefits of SSRC multiplexed
> versus the session multiplexed. In multicast context there is clear
> benefits from a control and congestion perspective to have session
> multiplexed versions and these mapped onto different multicast groups
> enabling a receiver to choose one or both streams.

This is what we have in section 5.2. Different streams can be sent in different multicast sessions but it does not mean that they are separate RTP sessions. I discussed this in detail with Colin. Thanks to him for trying to teach me over and over what an RTP session actually means.
 
> 7. Thus I think the signalling aspects of this is the minor part.
> Although there clearly are some aspects of this needing discussion. For
> example clearer offer/answer rules for handling these.

We have some text around O/A stuff. But frankly, I don’t see any use case where duplication will be used in a unicast application. I mean if redundancy is needed, one should use FEC instead for unicast transport. Duplication is a nice use case for multicast transport where the bw overhead is easier to justify and the implementation is easier. And one would naturally implement this spec in networks where he already knows that the network elements support this spec. So, maybe we should remove the whole O/A text anyway and write that this will only be used declaratively.

-acbegen
 
> Cheers
> 
> Magnus Westerlund
> 
> ----------------------------------------------------------------------
> Multimedia Technologies, Ericsson Research EAB/TVM
> ----------------------------------------------------------------------
> Ericsson AB                | Phone  [phone]
> Färögatan 6                | Mobile [phone]
> SE-164 80 Stockholm, Sweden| mailto: [e-mail]
> ----------------------------------------------------------------------
> 
> _______________________________________________
> Audio/Video Transport Core Maintenance
> [e-mail]
> https://www.ietf.org/mailman/listinfo/avt