Re: [rtcweb] STUN for keep-alive - RTCP-less applications

Hadriel Kaplan <HKaplan@acmepacket.com> Thu, 22 September 2011 10:58 UTC

Return-Path: <HKaplan@acmepacket.com>
X-Original-To: rtcweb@ietfa.amsl.com
Delivered-To: rtcweb@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9BC5021F8C76 for <rtcweb@ietfa.amsl.com>; Thu, 22 Sep 2011 03:58:05 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.525
X-Spam-Level:
X-Spam-Status: No, score=-2.525 tagged_above=-999 required=5 tests=[AWL=0.074, BAYES_00=-2.599]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id bSGxSQ5SLTJX for <rtcweb@ietfa.amsl.com>; Thu, 22 Sep 2011 03:58:04 -0700 (PDT)
Received: from etmail.acmepacket.com (etmail.acmepacket.com [216.41.24.6]) by ietfa.amsl.com (Postfix) with ESMTP id 8378321F8C6B for <rtcweb@ietf.org>; Thu, 22 Sep 2011 03:58:04 -0700 (PDT)
Received: from MAIL2.acmepacket.com (10.0.0.22) by etmail.acmepacket.com (216.41.24.6) with Microsoft SMTP Server (TLS) id 8.2.254.0; Thu, 22 Sep 2011 07:00:34 -0400
Received: from MAIL1.acmepacket.com ([169.254.1.150]) by Mail2.acmepacket.com ([169.254.2.157]) with mapi id 14.01.0270.001; Thu, 22 Sep 2011 07:00:34 -0400
From: Hadriel Kaplan <HKaplan@acmepacket.com>
To: Magnus Westerlund <magnus.westerlund@ericsson.com>
Thread-Topic: [rtcweb] STUN for keep-alive - RTCP-less applications
Thread-Index: AQHMeRbZIKUT9mUbYkyr0iQzRJ1k0w==
Date: Thu, 22 Sep 2011 11:00:32 +0000
Message-ID: <0C42CC63-CA1A-4F64-B522-BC1DAB477471@acmepacket.com>
References: <7F2072F1E0DE894DA4B517B93C6A05852233EDB21D@ESESSCMS0356.eemea.ericsson.se> <4E70D2E6.1000809@alvestrand.no> <CABcZeBORi5NLSsztnMfkwL43p9oKG9mi6e1WWOaiafAO_DpTVg@mail.gmail.com> <7F2072F1E0DE894DA4B517B93C6A05852233D45FA3@ESESSCMS0356.eemea.ericsson.se> <CABcZeBO9hUSYZhLrcfbaK9HLGXq-q1EvqWOy6-gAN5xom6Z2-A@mail.gmail.com> <092401cc749b$8fd64940$af82dbc0$@com> <CABcZeBPgRD6kb2gg=m9NckSa1wrzwzJS6527nYqFG34b0cjfgQ@mail.gmail.com> <4E765E4A.3050801@alvestrand.no> <7532C74D-D0D7-474D-80C7-61C07E9290AA@edvina.net> <2B265ADC-44C3-48CC-95A6-B90ED6E42FA7@acme packet.com> <7D7982AF-7478-4AFD-9F39-ED04A43FEF53@edvina.net> <673BCA71-B624-4DCA-B681-7012E6F9D202@acmepacket.com> <4E799E18.30000@ericsson.com> <855B9078-A81F-45D9-B12F-46CC46C15B60@acmepacket.com> <4E79D5DF.4050402@ericsson.com> <68121E70-4363-47F8-8761-23728C56D003@acmepacket.com> <9348BF4A-8674-4888-9DDC-C734FB935A28@csperkins.org> <7B9A57BB-A585-487D-9655-D835C527059B@acmepacket.com> <4E7AE83E.9090508@ericsson.com>
In-Reply-To: <4E7AE83E.9090508@ericsson.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
x-originating-ip: [216.41.24.34]
Content-Type: text/plain; charset="Windows-1252"
Content-ID: <B232591BBF4A6A4B9DB7F234DBDD9469@acmepacket.com>
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
X-Brightmail-Tracker: AAAAAQAAAWE=
Cc: "<rtcweb@ietf.org>" <rtcweb@ietf.org>, Colin Perkins <csp@csperkins.org>
Subject: Re: [rtcweb] STUN for keep-alive - RTCP-less applications
X-BeenThere: rtcweb@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Real-Time Communication in WEB-browsers working group list <rtcweb.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/rtcweb>, <mailto:rtcweb-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/rtcweb>
List-Post: <mailto:rtcweb@ietf.org>
List-Help: <mailto:rtcweb-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/rtcweb>, <mailto:rtcweb-request@ietf.org?subject=subscribe>
X-List-Received-Date: Thu, 22 Sep 2011 10:58:05 -0000

On Sep 22, 2011, at 3:48 AM, Magnus Westerlund wrote:

> On 2011-09-21 23:19, Hadriel Kaplan wrote:
>> 
>> We still don't need RTCP for that - use received RTP sequence number
>> gaps, if necessary. (yeah it assumes symmetric path and bandwidth,
>> and bi-dir media)
> 
> That doesn't really work without RTCP. You are assuming that path load
> is symmetric so that any loss in A-B direction will be correspondingly
> reflected on the flow in B-A direction. That is certainly not a common
> property for IP paths. Thus without RTCP the sender has no knowledge
> about what packet loss rate his flow is seeing.

That would be the part where I said "(yeah it assumes symmetric path and bandwidth, and bi-dir media)".
:)


>> But anyway, there is no means of "dialing-down" G.711.  It's not
>> adaptive.  Or are we saying the sender should start skipping samples
>> and hope the receiver does PLC?
> 
> Well, switch to a lower bandwidth codec.

That's not really possible in the PSTN. :(
One could drop it to AMR or G.729 in some cases, but those are under royalty so I doubt an rtcweb browser will do them.


>> Really, the user will hang up if call quality sucks.  We don't need
>> to be smarter than humans.
> 
> However, that is still not the only issue here. I agree that as long as
> there is a human in the other end listening to the flow that is fine.
> 
> But if you don't have a human listening the premise of RTCWEB is that
> you will be able to establish data flows across a path that is in fact
> not connected to the rendering element in the other end. Thus no user
> will detect the high packet loss and turn of the flow. It will continue
> and be a DoS attack on the congested link because this flow takes
> significantly more than its fair share.
> 
> That is my issue.

Right, but as I said previously, if the concern is a malicious server/JS, it can do it anyway even with congestion control.
If the concern is just that the far-end is dead or terminated the call but the local side didn't get the memo, we can solve that other ways.


> We are coming back to the most difficult trade-offs for RTCWEB. Legacy
> interoperability vs Security. We have several different aspects which
> makes legacy interoperability with a too simple device a big security risk.
> 
> Media transmission consent -> Requiring ICE support
> Path Overload DoS concerns -> Requiring Congestion Control for both
> media and data.
> RTCWEB deployment model and concerns for privacy and confenditality ->
> Media security (what level is still not agreed on)
> 
> All of the above are clear barriers against legacy interoperability.

Yup.  I don't doubt we'll need some form of media-plane gateway either in the web server or separate to interop with legacy - I'm just trying to keep it from becoming so expensive and complicated that it would be cheaper/easier/better to use SIP softclients or plugins instead.

-hadriel