Re: [rtcweb] How to multiplex between peers

[Stephan Wenger <[e-mail]>]

Hi Colin,

On 7.20.2011 23:51 , "Colin Perkins" <[e-mail]> wrote:

>On 21 Jul 2011, at 00:24, Jonathan Lennox wrote:
>...
>> I've read draft-perkins-rtcweb-rtp-usage-02, and I still don't
>>understand what you're claiming SSRC-muxing would break.
>> 
>> Running audio and video (and FEC, and RTX, and simulcast video, and
>>Real-Time Text, and etc. etc.) in a single RTP session does, not, as far
>>as I've been able to tell (after a lot of thought), break anything in
>>RTP.
>> 
>> To be sure, it's not backward compatible with RTP endpoints that assume
>>a single source per session.  It would also be hard to retrofit SDP to
>>describe and negotiate it.  And for some use cases it requires some
>>source-level signaling, as in RFC 5576.  But the RTP model, per se, is
>>perfectly amenable to it, as far as I can tell.
>
>
>Section 2.2.1 of draft-perkins-rtcweb-rtp-usage-02 lists several problems
>that occur when multiplexing RTP sessions onto a single lower-level flow.
>
>There are clearly some limitations caused: separate endpoints, quality of
>service, limitations with mixers and translators, retransmission, FEC,
>sampling group membership, and so on. There is also some breakage when
>several sessions are multiplexed: RTCP is problematic with several clock
>rates per session, SSRC allocation is broken, and the RTCP reporting
>interval and timing rules are broken.
>
>You may not think some of these are important. Some can be avoided by the
>use of appropriate signalling. Some can be mitigated by allowing multiple
>different media types in an RTP session, or by splitting the SSRC space.
>I'm not arguing that there aren't ways to fix this problem, or ignore it
>in some cases, but they cause various degrees of change to RTP, and need
>to be carefully evaluated by AVTCORE if they're to be done.

Rtcweb is working towards what I would call a "system"
specification--something, the IETF (or at least RAI) is not usually
involved in.  Outside the IETF, it's not uncommon that "system"
specifications effectively modify an underlying base specification--RTP in
this case.  Such modifications can as easily remove functionality deemed
unnecessary as add new one.

Speaking about session multiplexing as an example, I would guess that a
lot of people here are implicitly arguing removal of functionality of RTP
not needed for the application--namely multicast support.  SSRC
(re-)allocation) may be broken, but since there should not be any need for
it (no multicast), who cares?  RTCP reporting intervals and timing rules
are broken: again, who cares if the RTP/RTCP communication relationship is
either endpoint-endpoint or endpoint-MCU (and RTCP is not being forwarded
to all endpoints)?  RTCP-Terminating MCU and not Mixer in RFC 5117
namespace?  We will not see network flooding or something with RTCP RRs in
point-to-point RTP communication relationships... I have not thought about
RTCP's issues with multiple clock rates, but those difficulties are
probably not insurmountable, either, because, while there may be multiple
clock rates, those ought to be a finite, and small, set.

Now to my key point: you argue these things need to be "carefully
evaluated" in AVTCORE.
IMO, while it may be desirable for AVTCORE experts to chip in (as they do
on this very thread already:-), it is by no means necessary.  Neither
formally, not practically.  And certainly AVTCORE should not assume a
"blocking" position.  This puts IETF system level specification at a
disadvantage to system level specification work elsewhere (where it
happens on a daily basis, see ITU, see 3GPP), and where no one asks for
AVTCORE's permission to re-use RTP data structures without re-using all of
RTP.  Tinkering with the multicast functionally of RTP is not new, there
is a lot of implementation experience in the field, and for once we can
indeed rely on "running code" answers.

I advocate pragmatism.
(And, heretic as I am, in the long term we should think about RTPv3,
dumping multicast.  Have I said this before? :-)

Regards,
Stephan

P.s.: I haven't though much about shim layers or other techniques that
multiplex RTP sessions on a single low level flow.  If any of these ideas
were implemented only to preserve RTP functionalities not needed for the
application in question, then I would argue that being a silly idea.

> 
>
>-- 
>Colin Perkins
>http://csperkins.org/
>
>
>
>_______________________________________________
>rtcweb mailing list
>[e-mail]
>https://www.ietf.org/mailman/listinfo/rtcweb