Re: [rtcweb] Non-media data service consensus and requirements

Randell Jesup <randell1@jesup.org> Thu, 07 July 2011 05:19 UTC

Return-Path: <randell1@jesup.org>
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 AA7BC21F899B for <rtcweb@ietfa.amsl.com>; Wed, 6 Jul 2011 22:19:10 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.399
X-Spam-Level:
X-Spam-Status: No, score=-2.399 tagged_above=-999 required=5 tests=[AWL=0.200, BAYES_00=-2.599]
Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Z83J3Ov5ZeUq for <rtcweb@ietfa.amsl.com>; Wed, 6 Jul 2011 22:19:10 -0700 (PDT)
Received: from arthur.webserversystems.com (arthur.webserversystems.com [174.132.191.98]) by ietfa.amsl.com (Postfix) with ESMTP id 3DCED21F899F for <rtcweb@ietf.org>; Wed, 6 Jul 2011 22:19:09 -0700 (PDT)
Received: from pool-98-111-140-38.phlapa.fios.verizon.net ([98.111.140.38] helo=[192.168.1.12]) by arthur.webserversystems.com with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.69) (envelope-from <randell1@jesup.org>) id 1QegzP-0006W5-RE for rtcweb@ietf.org; Thu, 07 Jul 2011 00:19:03 -0500
Message-ID: <4E1540FD.3070109@jesup.org>
Date: Thu, 07 Jul 2011 01:15:41 -0400
From: Randell Jesup <randell1@jesup.org>
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9.2.18) Gecko/20110616 Thunderbird/3.1.11
MIME-Version: 1.0
To: rtcweb@ietf.org
References: <4E0832FE.7010401@ericsson.com> <3B711EF7-9FC9-4E0C-A9D1-E115F41AF02D@cisco.com>
In-Reply-To: <3B711EF7-9FC9-4E0C-A9D1-E115F41AF02D@cisco.com>
Content-Type: text/plain; charset="ISO-8859-1"; format="flowed"
Content-Transfer-Encoding: 7bit
X-AntiAbuse: This header was added to track abuse, please include it with any abuse report
X-AntiAbuse: Primary Hostname - arthur.webserversystems.com
X-AntiAbuse: Original Domain - ietf.org
X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12]
X-AntiAbuse: Sender Address Domain - jesup.org
X-Source:
X-Source-Args:
X-Source-Dir:
Subject: Re: [rtcweb] Non-media data service consensus and requirements
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, 07 Jul 2011 05:19:10 -0000

On 7/6/2011 11:57 PM, Cullen Jennings wrote:
>> Are you supporting the inclusion of a unreliable datagram service
>> directly between peers?
> yes

I support it as well.

>> Please provide your view and any additional
>> statements of motivation that you desire to provide.
>>
>> Secondly, there is a question if there needs to have something that
>> provides reliable message (of arbitrary size) or byte stream oriented
>> data transport between the peers.
> I don't have a big need for this but don't have a problem with it if others need it

I think we need to provide at least unreliable datagram service, and 
probably reliable datagram service.

>> I personally foresee that people will
>> build JS libraries for this on top of a unreliable datagram service. If
>> you desire reliable data service as part of the standardized solution
>> please provide motivation and use case and requirements.

I'd rather have one well-debugged standard reliable datagram service 
than N so-so debugged 3rd-party services, which might not "play well 
together".

>> I also want to take a stab on what I personally see as the requirements
>> that exist on unreliable datagram service in the context of RTCWEB.
>>
>> - Unreliable data transmission
> +1
>
>> - Datagram oriented
>>    * Size limited by MTU
>>      - Path MTU discovery needed
> +1
>
>>    * Fragmentation by the application
> +1
>
>> - Low latency, i.e. Peer to Peer preferable
> +5
>
>> - Congestion Controlled, to be
>>    * Network friendly
> +1

And I'd say (generally to all the part of rtcweb) Unified Congestion 
Control of all streams that are part of the same session.

>>    * Not become a Denial of Service tool
> +1
>
>> - Security
>>   * Confidentiality
> +1
>>   * Integrity Protected
> +1
>>   * Source Authenticated (at least bound to the signalling peer)
> +1 - I might phrase this a bit differently but I think we are getting at the same thing. If we are going to have encryption, there no point in encrypting something if you have no idea you our sending encrypted data to and from. We need some sort of identity / autehntication

I'm not sure I agree on Integrity Protection and Source Authentication.  
There are use cases where we want to have a private conversation (no 
eavesdropping or video leaked to Youtube!), but don't care if someone 
can block or disrupt the call.  (Someone with control of a link or 
midbox can do that already.)  I think those are important optional services.

>>   * Ensure consent to receive data
> +5
>
> In addition to your, I'd like to add that I am trying to maximize the odds of it making though the various NATs and Firewalls involved with and enterprise or home user.

+5

-- 
Randell Jesup
randell-ietf@jesup.org