Re: [rtcweb] realiable data service
Tim Panton <tim@phonefromhere.com> Mon, 18 July 2011 14:20 UTC
Return-Path: <tim@phonefromhere.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 09B8621F8BB1 for <rtcweb@ietfa.amsl.com>; Mon, 18 Jul 2011 07:20:05 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.299
X-Spam-Level:
X-Spam-Status: No, score=-2.299 tagged_above=-999 required=5 tests=[AWL=-0.300, BAYES_00=-2.599, J_CHICKENPOX_83=0.6]
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 Ow+RVDcjN6TM for <rtcweb@ietfa.amsl.com>; Mon, 18 Jul 2011 07:20:00 -0700 (PDT)
Received: from zimbra.westhawk.co.uk (zimbra.westhawk.co.uk [192.67.4.167]) by ietfa.amsl.com (Postfix) with ESMTP id 8323A21F8BB9 for <rtcweb@ietf.org>; Mon, 18 Jul 2011 07:20:00 -0700 (PDT)
Received: from [192.168.0.14] (unknown [93.89.81.113]) by zimbra.westhawk.co.uk (Postfix) with ESMTP id D0AEB37A902; Mon, 18 Jul 2011 15:29:44 +0100 (BST)
Mime-Version: 1.0 (Apple Message framework v1084)
Content-Type: text/plain; charset="us-ascii"
From: Tim Panton <tim@phonefromhere.com>
In-Reply-To: <4E243B77.1000900@ericsson.com>
Date: Mon, 18 Jul 2011 15:19:54 +0100
Content-Transfer-Encoding: quoted-printable
Message-Id: <271CD938-00F7-423D-BA6E-6407811DC80E@phonefromhere.com>
References: <4E0832FE.7010401@ericsson.com> <4E1DC07B.7000807@ericsson.com> <D1BE71E1-4F3B-474E-8A28-AA53CE6B684E@cisco.com> <F43A8952-0CF3-4683-923F-DF1ED0B4344B@phonefromhere.com> <4E243B77.1000900@ericsson.com>
To: Magnus Westerlund <magnus.westerlund@ericsson.com>
X-Mailer: Apple Mail (2.1084)
Cc: "rtcweb@ietf.org" <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 14:20:05 -0000
On 18 Jul 2011, at 14:56, Magnus Westerlund wrote: > On 2011-07-15 19:29, Tim Panton wrote: >> 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 . > > I would warn about thinking this is easy. It is easy to get something > that works on sunny days, it is hard to build something that is secure, > efficient, robust and fair. > Agreed, getting all 4 in any protocol is hard, indeed I don't think I've seen it done yet. > I would like to point out that a reliable protocol do need a number of > functions. If those are achieve from a lower layer or need to be > implemented in this protocol is a choice. However, functionalities such as: > > - Congestion Control > - Flow Control > - Retransmission > - RTT estimation > - Buffer handling > - Parameter and functionality negotiation Agreed, but only Retransmission is specific to reliable datagrams (as opposed to unreliable ones). > > Are likely all need for a safe and stable and future safe protocol. > > There are good reasons for choosing something there is experience in > that it works. > > For example I took a quick look at RFC5456 which appears to not have > congestion control. I think it is partly relying on that the transported > flow will adopt them self if trunking, or if not, that they become > useless and the call terminates because of that. RFC5456 has 2 sorts of packet - miniframes, which typically form the bulk of the traffic are handled unreliably. - fullframes which are mostly used for signalling but some of which are reliable datagrams (e.g. the TEXT frame type). I was saying we could (in theory) ignore the miniframes and adopt the fullframe sequence,ack,retry mechanisms for the reliable datagram transport. The core protocol has been 'repurposed' in this way before : http://www.dundi.com/dundi.txt so it is definitely possible. I take your point about the lack of congestion control, but the ACK mechanism could be used to detect incipient congestion. > > cheers > > Magnus Westerlund > > Tim.
- Re: [rtcweb] Non-media data service consensus and… Jonathan Rosenberg
- [rtcweb] Non-media data service consensus and req… Magnus Westerlund
- Re: [rtcweb] Non-media data service consensus and… Emil Ivov
- Re: [rtcweb] Non-media data service consensus and… Bernard Aboba
- Re: [rtcweb] Non-media data service consensus and… Emil Ivov
- Re: [rtcweb] Non-media data service consensus and… Matthew Kaufman
- Re: [rtcweb] Non-media data service consensus and… Christopher Blizzard
- Re: [rtcweb] Non-media data service consensus and… Bernard Aboba
- Re: [rtcweb] Non-media data service consensus and… Matthew Kaufman
- Re: [rtcweb] Non-media data service consensus and… Emil Ivov
- Re: [rtcweb] Non-media data service consensus and… Igor Faynberg
- Re: [rtcweb] Non-media data service consensus and… Emil Ivov
- Re: [rtcweb] Non-media data service consensus and… Magnus Westerlund
- Re: [rtcweb] Non-media data service consensus and… Manuel Simoni
- Re: [rtcweb] Non-media data service consensus and… Magnus Westerlund
- Re: [rtcweb] Non-media data service consensus and… Igor Faynberg
- Re: [rtcweb] Non-media data service consensus and… Timothy B. Terriberry
- Re: [rtcweb] Non-media data service consensus and… Dzonatas Sol
- Re: [rtcweb] Non-media data service consensus and… Dzonatas Sol
- Re: [rtcweb] Non-media data service consensus and… Randell Jesup
- Re: [rtcweb] Non-media data service consensus and… Magnus Westerlund
- Re: [rtcweb] Non-media data service consensus and… Manuel Simoni
- Re: [rtcweb] Non-media data service consensus and… Dzonatas Sol
- Re: [rtcweb] Non-media data service consensus and… Christopher Blizzard
- Re: [rtcweb] Non-media data service consensus and… Cullen Jennings
- Re: [rtcweb] Non-media data service consensus and… Cullen Jennings
- Re: [rtcweb] Non-media data service consensus and… Randell Jesup
- [rtcweb] Consensus Call on Non-media data service… Magnus Westerlund
- Re: [rtcweb] Consensus Call on Non-media data ser… Dzonatas Sol
- Re: [rtcweb] Consensus Call on Non-media data ser… Dzonatas Sol
- Re: [rtcweb] Consensus Call on Non-media data ser… Dzonatas Sol
- Re: [rtcweb] Consensus Call on Non-media data ser… Magnus Westerlund
- Re: [rtcweb] Consensus Call on Non-media data ser… Dzonatas Sol
- [rtcweb] realiable data service Cullen Jennings
- Re: [rtcweb] realiable data service Tim Panton
- Re: [rtcweb] realiable data service Emil Ivov
- Re: [rtcweb] realiable data service Dzonatas Sol
- Re: [rtcweb] realiable data service Dzonatas Sol
- Re: [rtcweb] realiable data service Randell Jesup
- Re: [rtcweb] realiable data service Dzonatas Sol
- Re: [rtcweb] realiable data service Dzonatas Sol
- Re: [rtcweb] realiable data service Ted Hardie
- Re: [rtcweb] realiable data service Serge Lachapelle
- Re: [rtcweb] realiable data service Silvia Pfeiffer
- Re: [rtcweb] realiable data service Tim Panton
- Re: [rtcweb] realiable data service Magnus Westerlund
- Re: [rtcweb] realiable data service Tim Panton
- Re: [rtcweb] realiable data service Randell Jesup
- Re: [rtcweb] realiable data service Ted Hardie
- Re: [rtcweb] realiable data service Cullen Jennings
- Re: [rtcweb] realiable data service Cullen Jennings
- Re: [rtcweb] realiable data service Tim Panton
- Re: [rtcweb] realiable data service Cullen Jennings
- Re: [rtcweb] realiable data service Dzonatas Sol
- Re: [rtcweb] realiable data service Matthew Kaufman
- Re: [rtcweb] realiable data service Cullen Jennings
- Re: [rtcweb] realiable data service Randell Jesup
- Re: [rtcweb] realiable data service Magnus Westerlund
- Re: [rtcweb] realiable data service Henry Sinnreich
- Re: [rtcweb] realiable data service Justin Uberti
- Re: [rtcweb] realiable data service Randell Jesup
- Re: [rtcweb] realiable data service Emil Ivov
- Re: [rtcweb] realiable data service Serge Lachapelle
- Re: [rtcweb] realiable data service Emil Ivov
- Re: [rtcweb] realiable data service Dzonatas Sol
- Re: [rtcweb] realiable data service Dzonatas Sol
- Re: [rtcweb] realiable data service Dzonatas Sol
- Re: [rtcweb] realiable data service Cullen Jennings
- Re: [rtcweb] realiable data service Cullen Jennings
- Re: [rtcweb] realiable data service Stefan Håkansson LK
- Re: [rtcweb] realiable data service Emil Ivov
- [rtcweb] PseudoTCP implementation (Re: realiable … Harald Alvestrand
- Re: [rtcweb] realiable data service Randell Jesup
- Re: [rtcweb] PseudoTCP implementation (Re: realia… Justin Uberti
- Re: [rtcweb] realiable data service Serge Lachapelle
- Re: [rtcweb] realiable data service Serge Lachapelle
- Re: [rtcweb] realiable data service Bernard Aboba
- Re: [rtcweb] realiable data service Peter Saint-Andre
- Re: [rtcweb] PseudoTCP implementation (Re: realia… Cullen Jennings
- Re: [rtcweb] PseudoTCP implementation (Re: realia… Tim Panton
- Re: [rtcweb] PseudoTCP implementation (Re: realia… Emil Ivov
- Re: [rtcweb] PseudoTCP implementation (Re: realia… Justin Uberti
- Re: [rtcweb] PseudoTCP implementation (Re: realia… Cullen Jennings
- Re: [rtcweb] PseudoTCP implementation (Re: realia… Justin Uberti
- Re: [rtcweb] PseudoTCP implementation (Re: realia… Harald Alvestrand
- Re: [rtcweb] PseudoTCP implementation (Re: realia… Justin Uberti