Re: [rtcweb] How to multiplex between peers

["DRAGE, Keith (Keith)" <[e-mail]>]

This discussion seems to be hovering in some sort of middle ground.

Either 1)

It has not decided what transport to use for real time data, in which case it should document the requirements for such a transport protocol, and then evaluate whether existing solutions meet those requirements, versus developing an entirely new protocol.

Or 2)

I has decided that RTP should be used, in which case it should identify the shortcomings (i.e. a set of requirements on how it needs to be further developed) and send these to the AVTCORE working group.

Neither of those seem to be happening at the moment.

Regards

Keith

> -----Original Message-----
> From: [e-mail] [mailto:[e-mail]] On Behalf
> Of Stephan Wenger
> Sent: 21 July 2011 08:43
> To: Colin Perkins; Jonathan Lennox
> Cc: [e-mail]
> Subject: Re: [rtcweb] How to multiplex between peers
> 
> 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
> 
> 
> _______________________________________________
> rtcweb mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/rtcweb