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.