Re: [rtcweb] realiable data service

Cullen Jennings <fluffy@cisco.com> Mon, 18 July 2011 18:21 UTC

Return-Path: <fluffy@cisco.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 87DD521F8640 for <rtcweb@ietfa.amsl.com>; Mon, 18 Jul 2011 11:21:30 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -104.232
X-Spam-Level:
X-Spam-Status: No, score=-104.232 tagged_above=-999 required=5 tests=[AWL=-1.633, BAYES_00=-2.599, USER_IN_WHITELIST=-100]
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 GE+iJN8NkzZq for <rtcweb@ietfa.amsl.com>; Mon, 18 Jul 2011 11:21:29 -0700 (PDT)
Received: from rcdn-iport-8.cisco.com (rcdn-iport-8.cisco.com [173.37.86.79]) by ietfa.amsl.com (Postfix) with ESMTP id 2AD6D21F85B9 for <rtcweb@ietf.org>; Mon, 18 Jul 2011 11:21:25 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=fluffy@cisco.com; l=10008; q=dns/txt; s=iport; t=1311013285; x=1312222885; h=subject:mime-version:from:in-reply-to:date:cc: content-transfer-encoding:message-id:references:to; bh=dhotEnfdRZNuF4h6RgQeuF5okO08Z3+CsUjBpXNMN9o=; b=kvpWfG1iNh8eOzvdTDdUI1po3AwLS2VZcZmnnQtncHUxbLIEPIEVUz+g 2K9Gt3mZ3ayXw3q2aw7qaVcbldD19qoIzhVUtTMP6/Fbjnxn9JlRrL1qm 5yMJzhfuRQNB8Jj/x3695sTrgHM6GW0s/cYkejQcx3qZrkAYjTOvsf0pQ s=;
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: Av0EAEJ4JE6rRDoI/2dsb2JhbABUp3p3iHykRJ4dAoVbXwSHVIsSkHU
X-IronPort-AV: E=Sophos;i="4.67,223,1309737600"; d="scan'208";a="4052316"
Received: from mtv-core-3.cisco.com ([171.68.58.8]) by rcdn-iport-8.cisco.com with ESMTP; 18 Jul 2011 18:21:24 +0000
Received: from sjc-vpn3-1134.cisco.com (sjc-vpn3-1134.cisco.com [10.21.68.110]) by mtv-core-3.cisco.com (8.14.3/8.14.3) with ESMTP id p6IILNnI004413; Mon, 18 Jul 2011 18:21:23 GMT
Mime-Version: 1.0 (Apple Message framework v1084)
Content-Type: text/plain; charset=iso-8859-1
From: Cullen Jennings <fluffy@cisco.com>
In-Reply-To: <F43A8952-0CF3-4683-923F-DF1ED0B4344B@phonefromhere.com>
Date: Mon, 18 Jul 2011 11:21:23 -0700
Content-Transfer-Encoding: quoted-printable
Message-Id: <992E0971-8B50-4459-8779-78EC8F0C3AEB@cisco.com>
References: <4E0832FE.7010401@ericsson.com> <4E1DC07B.7000807@ericsson.com> <D1BE71E1-4F3B-474E-8A28-AA53CE6B684E@cisco.com> <F43A8952-0CF3-4683-923F-DF1ED0B4344B@phonefromhere.com>
To: Tim Panton <tim@phonefromhere.com>
X-Mailer: Apple Mail (2.1084)
Cc: rtcweb@ietf.org
Subject: Re: [rtcweb] realiable data service
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: Mon, 18 Jul 2011 18:21:30 -0000

On Jul 15, 2011, at 10:29 , Tim Panton wrote:

> If we don't specify a  reliable transport then all the page authors will end adding a reliable layer in javascript, it will be as ugly as DTMF in RTP !

Tim, I agree with your concern here. My largest concern of not specifying something is that it just means we will see a million different things done in JavaScript. That's pretty much what we have in the IETF today. Lots of protocols implement a different reliability layer on top of UDP. However, it has not been all that bad and it has been very hard to get the transport guys to go and define one that everyone can use (I've presented in transport asking for this in the past). The end result has not really been all that bad. The protocols work even thought each one did there own reliability systems so I have not been all that worried about it. I'm not sure DTMF is a fair example to compare to...

> Or worse it will be spray and pray.

sort of like we do with audio and video in RTP :-) 


> Most of the use-cases I can think of need  sequenced and reliable datagrams. If I'm playing a game I don't want it to
> drop or mis-order any one of the actions in the unholster, point, shoot  sequence :-)

A game might have a UI that requires you to do but due to round trip latency times, most games  are going to send over the write something more like an object to type bullet exists at this location in Phase/Time space and let both sides simulate from that and decide if there was a hit or not. The phase/time space is just the location of the bullet, information about it such as it's type, and it's velocity vector as well as the point in time. That might get acked or retransmitted or just ignored on loss depending on the reliability of the game but a FPS is going to have crappy UE if it both side to multiple lock step transaction to keep state like unholster, point, shoot in sync between the sides. 

> 
> I don't think it is very hard to implement, we could take RFC 5456's sequencing and retry mechanism for example.
> or indeed Plan9's IL .

Again, no object to someone coming up with a good proposal (I suspect that 5456 would get more than a bit of push back) but it's not on my high priority list because the games I can think of could probably work fine with a proposal more like the above than needing a reliable protocol. That said, I do share your concern about we will just see lots of crappy implementations of this a reliable protocol for file transfer on top of whatever we do for this RTCWeb work. 

> 
> Tim.
> 
> 
> On 15 Jul 2011, at 16:51, Cullen Jennings wrote:
> 
>> 
>> I'd like to push back on the reliable service. I've yet to hear a use case for it that was real time. It's very hard to do a reliable real time protocol and we have seen zero proposal for this. For non real time data, just dump it in dropbox of whatever your equivalent is and don't do it peer to peer. Unless someone has a real need, and wants to put forward a proposal, I don't see a need to focus energy on this right now. I'd rather work on the thing everyone agrees they do need which is the unreliable transfer. 
>> 
>> Cullen <in my individaul contribut role> 
>> 
>> On Jul 13, 2011, at 8:57 , 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
>>>> 
>>> 
>>> 
>>> -- 
>>> 
>>> 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
>> 
>> 
>> Cullen Jennings
>> For corporate legal information go to:
>> http://www.cisco.com/web/about/doing_business/legal/cri/index.html
>> 
>> 
>> _______________________________________________
>> rtcweb mailing list
>> rtcweb@ietf.org
>> https://www.ietf.org/mailman/listinfo/rtcweb
> 


Cullen Jennings
For corporate legal information go to:
http://www.cisco.com/web/about/doing_business/legal/cri/index.html