Re: [rmcat] 5 tuples and rmcat-cc-requirements-01

Dave Taht <dave.taht@gmail.com> Fri, 24 January 2014 16:38 UTC

MIME-Version: 1.0
In-Reply-To: <52E2900A.5040804@jesup.org>
References: <CAA93jw7FDddn2n23fm=rdUsDyGakNfyLkJDgNjoC43fSc4GnSA@mail.gmail.com> <52C17E9F.8060703@alvestrand.no> <CAA93jw4g7bBrxJFfhqVkq0EpezBTY+hahhAJyt5wh=1zTs1EiA@mail.gmail.com> <52C60213.9000401@alvestrand.no> <F737F9D9-4253-4813-A34A-3EAF5915D52F@ifi.uio.no> <CAA93jw6MZ9PObAMvkceAmJhzBkVnPBM9SeRM+m=s7QXAQAv_Rw@mail.gmail.com> <52E0141F.4060805@jesup.org> <52E2900A.5040804@jesup.org>
Date: Fri, 24 Jan 2014 11:38:42 -0500
Message-ID: <CAA93jw67vewx_hTSNKUg=J4N9sKgBEVk31oXQ9aM0jhdALrKRQ@mail.gmail.com>
From: Dave Taht <dave.taht@gmail.com>
To: Randell Jesup <randell-ietf@jesup.org>
Content-Type: text/plain; charset="ISO-8859-1"
Content-Transfer-Encoding: quoted-printable
Cc: "rmcat@ietf.org" <rmcat@ietf.org>
Subject: Re: [rmcat] 5 tuples and rmcat-cc-requirements-01
Precedence: list

On Fri, Jan 24, 2014 at 11:08 AM, Randell Jesup <randell-ietf@jesup.org> wrote:
> On 1/22/2014 1:55 PM, Randell Jesup wrote:
>>
>> I'm going to make deeper comments once I read through everything, but some
>> detail points while I have them in front of me:
>>
>> One big issue for bundle is that ICE takes time, and it takes time
>> proportional to the number of ports you have to open.  From experience, the
>> more ports needing to be opened the more probably you can get.  For
>> Hangout-like conferencing, "classic" RTP setup would mean 5 + 4(n-1) ports
>> where N is the number of participants at least, or more likely 7 + 6(n-1)
>> (assuming we do simulcast and do it on a separate RTP/RTCP stream).  It also
>> means 4 or 6 times the amount of TURN ports needed by a service offering
>> WebRTC. (One day, ICE and TURN will die the horrible death they should when
>> IPV6 is the norm - but even then it may be needed for things like firewalls
>> that block UDP.)
>>
>> This drives a) RTP/RTCP mux (already being done, and predates WebRTC), and
>> BUNDLE.  With both, you can get 2 or 1 ports for a conference (depending on
>> if you bundle the DataChannel flow).
>
>
> Amplifying my own point, this clearly impacts a lot of important performance
> aspects of media exchange.  Classically people answered handsets and it
> takes time to get them to the ear/mouth; that gave you 100-500ms to finish
> call setup after "accept".  With GUIs and headsets or speakerphones, people
> will press and say "hello"; at best you have 150ms. I've found you'll get
> clipping in speakerphones with press-to-accept if streams aren't flowing in
> 200ms, preferably less.  300ms is quite noticeable.
>
> Sometimes you can hide this delay by warming up channels before the user
> accepts.  However, that's not always possible, and also may fall afoul of
> other requirements (avoiding exposing physical location by IP without user
> interaction, avoid DoS attacks (incoming request produces a burst of ICE
> traffic in response as well as port reservations in the firewall), etc).
>
> Also, there are more chances you'll run into port conflicts that cause NATs
> to switch "mode"; some non-symmetric NATs will port-preserve if it's not
> in-use/mapped, but when forced to map to another port will switch to
> symmetric NAT.  Really.  So with a large number of ports you might get
> different characteristics in the NAT (some requiring TURN, some not), and
> also even in simpler cases if there are multiple network interfaces you
> might end up with some ports on one interface and some on another, or some
> randomly deciding that a longer-delay candidate is better, etc.  The odds
> get worse the larger the number of ports.

I am beginning to feel a lot more of your pain. :/

However I still stand by

A) wanting to ensure that requirements driven by ICE/turn/nat negotiation
hassles don't affect direct e2e problems, and to ensure the API exposes
the ability to do saner things e2e in the absence of of
ice/turn/nat/middleboxes,
and (especially) over ipv6.

B) wanting to clearly separate audio and video tuples.

C) wanting world peace.

D) from a congestion control and analysis perspective I'd dearly like
to be able to
work without all these middleboxware for a while, and it is also coming
clear to me that I'd like to take a hard look at their behaviors also.

>
>
> --
> Randell Jesup -- rjesup a t mozilla d o t com
>



-- 
Dave Täht

Fixing bufferbloat with cerowrt: http://www.teklibre.com/cerowrt/subscribe.html

[rmcat] 5 tuples and rmcat-cc-requirements-01 Dave Taht
Re: [rmcat] 5 tuples and rmcat-cc-requirements-01 Harald Alvestrand
Re: [rmcat] 5 tuples and rmcat-cc-requirements-01 Michael Welzl
Re: [rmcat] 5 tuples and rmcat-cc-requirements-01 Dave Taht
Re: [rmcat] 5 tuples and rmcat-cc-requirements-01 Harald Alvestrand
Re: [rmcat] 5 tuples and rmcat-cc-requirements-01 Michael Welzl
Re: [rmcat] 5 tuples and rmcat-cc-requirements-01 Dave Taht
Re: [rmcat] 5 tuples and rmcat-cc-requirements-01 Michael Welzl
Re: [rmcat] 5 tuples and rmcat-cc-requirements-01 Dave Taht
Re: [rmcat] 5 tuples and rmcat-cc-requirements-01 John Leslie
Re: [rmcat] 5 tuples and rmcat-cc-requirements-01 Michael Welzl
Re: [rmcat] 5 tuples and rmcat-cc-requirements-01 Michael Welzl
Re: [rmcat] 5 tuples and rmcat-cc-requirements-01 Michael Ramalho (mramalho)
Re: [rmcat] 5 tuples and rmcat-cc-requirements-01 Michael Welzl
Re: [rmcat] 5 tuples and rmcat-cc-requirements-01 Ingemar Johansson S
Re: [rmcat] 5 tuples and rmcat-cc-requirements-01 John Leslie
Re: [rmcat] 5 tuples and rmcat-cc-requirements-01 Randell Jesup
Re: [rmcat] 5 tuples and rmcat-cc-requirements-01 Randell Jesup
Re: [rmcat] 5 tuples and rmcat-cc-requirements-01 Randell Jesup
Re: [rmcat] 5 tuples and rmcat-cc-requirements-01 Dave Taht
Re: [rmcat] 5 tuples and rmcat-cc-requirements-01 Mirja Kuehlewind
Re: [rmcat] 5 tuples and rmcat-cc-requirements-01 Randell Jesup