Re: [AVTCORE] Fwd: I-D Action: draft-westerlund-avtcore-multistream-and-simulcast-00.txt

Jonathan,

Thanks for the comments.

See inline for further comments.

On 2011-07-15 00:35, Jonathan Lennox wrote:
> On Jul 5, 2011, at 6:54 AM, Magnus Westerlund wrote:
> 
>> WG,
>> 
>> As an individual Bo Burman and I have written this internet draft
>> that discusses multistream and simulcast issues and proposes a set
>> of extensions to resolve the issues. Feedback is much appreciated.
> 
> 
> Hi, Magnus.
> 
> Thank you for writing this draft; I think multi-stream is a very
> important area of RTP, one that's hasn't had enough attention paid to
> it.
> 
> The draft discusses a number of different issues: multi-stream,
> simulcast, RTX, FEC, etc., but seems to assume that these are
> separate-but-related problems that can be solved independently,
> possibly with different solutions to the different problems.
> 
> I don't believe that this is the case; instead, I believe that in
> practice you will end up with sessions carrying multiple sources,
> each of which could be be simulcast, with RTX and FEC being used
> independently for any or all of the simulcast streams.  Thus we need
> one solution that can handle all these problems at once, including
> the interactions among them.  (Vidyo has been doing multi-stream with
> scalable coding for many years.)

I try to take as encompassing view of this as possible. Yes, we don't
include RTX or FEC in the discussion currently. I think mostly because
we didn't need to. RTX clearly has two different modes, either SSRC or
Session multiplexing. FEC depends on which type of FEC one intend to use
for what multiplexing that is available.

I think we should try to make clear indications going forward for how
these should be structured in future extensions.

> 
> As the draft concludes, the multi-stream scenario is best handled by
> SSRC-multiplexing, as was originally envisioned by RTP.  Given that
> this is the case, it's not clear to me that it's a good idea to use a
> separate (and in my opinion, less flexible) mechanism for the
> specific special case of simulcast.  Instead, given the pressure from
> groups such as RTCweb to reduce the port consumption of RTP, I'd
> recommend SSRC-multiplexing across the board.

Jonathan lets me ask you a question. Is any hesitation to use several
RTP sessions when most suitable due to the port consumption issue or for
some other reason? And here we can debate what is most suitable.

My view is that multiple SSRCs in an RTP session is a very good
mechanism for streams that one expect to be treated the same way in both
central nodes or in end-points. When it comes to sets of streams that
needs a different treatment, I think it is logical and a powerful
construct to use the RTP session for separating these sets of streams.

Yes, the number of underlying transport flows is an important concern in
some use cases. But, I think we shouldn't use that as a reason for
removing an important concept in RTP. If the issue we have is that one
RTP session results in one UDP flow, then lets do something about that
instead of removing the RTP session concept.

> 
> Note also that in the case of multiple sources which are each
> independently simulcast, the simulcast structure of different sources
> could well be different.   (E.g., source A could be available in two
> resolutions, while source B has only one and source C has three.)
> It'd be extremely difficult to map this in session-multiplexed
> simulcast, whereas for SSRC-multiplexed simulcast it should be no
> more complex than the single-simulcast-source scenario.

This is a valid concern, but which I think we have a reasonable straight
story for. In the direction you have a certain number of simulcast
versions you negotiate that number of session and their individual
configurations.

If one looks at the example in Section 8.5.2.2, you see that we have
there 3 simulcast versions going towards a central mixer. The return
channel from the mixer are only two different sessions, supporting to
receive all the possible payload types we can get from the other
participants. And the difference between these two return sessions are
if they are content:main or content:alternative. In other words what we
do with the streams locally when rendering them.

The two main points we have for choosing Session multiplexing is:
A) RTP sessions provides a context for what purpose the streams in them
have.

B) We don't need to define any new signalling to negotiate the different
simulcast levels. Only a bit of binding together the streams and we are
done. The SCS and SCR grouping semantics and the SRCNAME is really all
we require for getting session multiplexed simulcast to work. The rest
is to provide improvements over todays order when it comes to bandwidth
signalling and media control in centralized conferencing.

cheers

Magnus Westerlund

----------------------------------------------------------------------
Multimedia Technologies, Ericsson Research EAB/TVM
----------------------------------------------------------------------
Ericsson AB                | Phone  +46 10 7148287
Färögatan 6                | Mobile +46 73 0949079
SE-164 80 Stockholm, Sweden| mailto: magnus.westerlund <at> ericsson.com
----------------------------------------------------------------------

_______________________________________________
Audio/Video Transport Core Maintenance
avt <at> ietf.org
https://www.ietf.org/mailman/listinfo/avt