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

Dzonatas Sol <dzonatas@gmail.com> Wed, 13 July 2011 22:12 UTC

Return-Path: <dzonatas@gmail.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 3909321F8B73 for <rtcweb@ietfa.amsl.com>; Wed, 13 Jul 2011 15:12:18 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.671
X-Spam-Level:
X-Spam-Status: No, score=-4.671 tagged_above=-999 required=5 tests=[AWL=-1.072, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1]
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 FJLi4attB631 for <rtcweb@ietfa.amsl.com>; Wed, 13 Jul 2011 15:12:14 -0700 (PDT)
Received: from mail-iy0-f172.google.com (mail-iy0-f172.google.com [209.85.210.172]) by ietfa.amsl.com (Postfix) with ESMTP id CDAA821F8B6B for <rtcweb@ietf.org>; Wed, 13 Jul 2011 15:12:13 -0700 (PDT)
Received: by iye7 with SMTP id 7so7047537iye.31 for <rtcweb@ietf.org>; Wed, 13 Jul 2011 15:12:13 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=message-id:date:from:user-agent:mime-version:to:subject:references :in-reply-to:content-type:content-transfer-encoding; bh=eTL0E1Hk2b7zU8erOpgE3XHTk7cclFR51fXLCcdTu2Q=; b=vnxvyX464/fCQmbBmhsNWeTWJ1LUBWeSOqJIoMlEUC9F6ZsTI3edrAXez9s/GYeJcs bloqMdhNQONCr5jSVBV330CVLXOgiYB/FtRbZlRcZELwLZVQAqiFVB8qc/1ffXrEMPiC tbNEhE8o/s3N7Du0KYPxGKC8rWtwPQGgyjxlw=
Received: by 10.42.28.2 with SMTP id l2mr1635610icc.57.1310595132708; Wed, 13 Jul 2011 15:12:12 -0700 (PDT)
Received: from [192.168.0.50] ([70.133.70.225]) by mx.google.com with ESMTPS id a5sm2205410icb.15.2011.07.13.15.12.10 (version=TLSv1/SSLv3 cipher=OTHER); Wed, 13 Jul 2011 15:12:11 -0700 (PDT)
Message-ID: <4E1E1835.5070602@gmail.com>
Date: Wed, 13 Jul 2011 15:12:05 -0700
From: Dzonatas Sol <dzonatas@gmail.com>
User-Agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.9.1.16) Gecko/20110505 Icedove/3.0.11
MIME-Version: 1.0
To: Dzonatas Sol <dzonatas@gmail.com>, "rtcweb@ietf.org" <rtcweb@ietf.org>
References: <4E0832FE.7010401@ericsson.com> <4E1DC07B.7000807@ericsson.com> <4E1DD0FF.5070506@gmail.com> <4E1DE3D8.2060206@gmail.com>
In-Reply-To: <4E1DE3D8.2060206@gmail.com>
Content-Type: text/plain; charset="UTF-8"; format="flowed"
Content-Transfer-Encoding: 8bit
Subject: Re: [rtcweb] Consensus Call on 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: Wed, 13 Jul 2011 22:12:18 -0000

Updated: medium path flow called either "petrifaction" or "cloud". I 
know there are better words, oh ya, "traits".

Trinary machines... enjoy.

On 07/13/2011 11:28 AM, Dzonatas Sol wrote:
> One more thing, the constraint on that reduce-reduce is the high path.
>
> P.S. "noise-reduction", we do not get upset over "soft" patents for 
> noise reduction, please do...
>
> On 07/13/2011 10:08 AM, Dzonatas Sol wrote:
>> Instead of "NAT traversal", can we reduce-reduce that term to 
>> "synopsis". I've deleted my justification for that several times.
>>
>> On 07/13/2011 08:57 AM, Magnus Westerlund wrote:
>>> Hi,
>>>
>>> I have reviewed the input both the last 2 weeks and the discussion back
>>> in April.
>>>
>>> I see a strong support but with at least 2 people disagreeing to a 
>>> basic
>>> p2p datagram functionality. The use cases are various and some just
>>> state that they see it as important functionality to provide to empower
>>> the web application.
>>>
>>> Based on this I declare a rough consensus on that we should provide a
>>> non-media data service that is unreliable datagram oriented directly
>>> between the peers.
>>>
>>> One of objections against this was lack of clear requirements for what
>>> the service. The straw men requirements I included has gotten some
>>> discussion. Mostly support for them, but it is clear to me that we need
>>> to further develop them. I would recommend the proponents for driving
>>> proposals towards meeting this functionality to further discuss the
>>> requirements taking the input so far into consideration.
>>>
>>> When it comes to reliable data transfer between peers there has been 
>>> 4-5
>>> that wanted the functionality, 2 additional that explicitly stated they
>>> where okay with it. No additional that has stated against it.
>>>
>>> My interpretation is that we are close to having a rough consensus for
>>> reliable data service, but we have so far seen no proponent willing to
>>> suggest a solution for this. I would also note that a solution is 
>>> likely
>>> a functionality block that isn't dependent on more than the
>>> signaling/negotiation and the NAT traversal and thus can be added a
>>> later stage or be worked on with a completion date further into the
>>> future than other pieces already.
>>>
>>> So for reliable data I would recommend that someone takes on the 
>>> role of
>>> proponent and provides a draft with their perceived requirements and a
>>> straw man proposal for how to solve these requirements so we have
>>> something more tangible to discuss.
>>>
>>> Cheers
>>>
>>> Magnus
>>>
>>> On 2011-06-27 09:36, Magnus Westerlund wrote:
>>>> WG,
>>>>
>>>> At the interim it was planned to have a bit discussion on the datagram
>>>> service for RTCWEB. The first question to try to resolve if there
>>>> is consensus for including some form of non real-time media (i.e. not
>>>> audio, video) service between peers. This is a bit tangled with the
>>>> actual requirements and use cases. But there was views both for it and
>>>> against it on the mailing list. So lets continue and try to come to a
>>>> conclusion on this discussion.
>>>>
>>>> The use cases mentioned on the mailing list are:
>>>>
>>>> - Dynamic meta data for Conference and other real-time services
>>>>
>>>> - Gaming data with low latency requirements
>>>>
>>>> Does anyone like to add additional use cases?
>>>>
>>>> Based on my personal understanding this points to primarily have the
>>>> RTCWEB provide a unreliable datagram service. This clearly needs
>>>> additional requirements to be secure and safe to deploy, but more 
>>>> about
>>>> this below. I still like to ask the WG here a question.
>>>>
>>>> Are you supporting the inclusion of a unreliable datagram service
>>>> directly between peers? 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 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 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
>>>> - Datagram oriented
>>>>     * Size limited by MTU
>>>>       - Path MTU discovery needed
>>>>     * Fragmentation by the application
>>>> - Low latency, i.e. Peer to Peer preferable
>>>> - Congestion Controlled, to be
>>>>     * Network friendly
>>>>     * Not become a Denial of Service tool
>>>> - Security
>>>>    * Confidentiality
>>>>    * Integrity Protected
>>>>    * Source Authenticated (at least bound to the signalling peer)
>>>>    * Ensure consent to receive data
>>>>
>>>> Please debate the above. This is an attempt to ensure that we can
>>>> establish WG consensus on both data service and any requirements.
>>>>
>>>> cheers
>>>>
>>>> Magnus Westerlund
>>>>
>>>> ----------------------------------------------------------------------
>>>> Multimedia Technologies, Ericsson Research EAB/TVM
>>>> ----------------------------------------------------------------------
>>>> Ericsson AB                | Phone  +46 10 7148287
>>>> F�r�gatan 6                | Mobile +46 73 0949079
>>>> SE-164 80 Stockholm, Sweden| mailto: magnus.westerlund@ericsson.com
>>>> ----------------------------------------------------------------------
>>>>
>>>> _______________________________________________
>>>> rtcweb mailing list
>>>> rtcweb@ietf.org
>>>> https://www.ietf.org/mailman/listinfo/rtcweb
>>>>
>>>
>>
>>
>
>


-- 
--- http://twitter.com/Dzonatas_Sol ---
Web Development, Software Engineering
Ag-Biotech, Virtual Reality, Consultant