Re: [rtcweb] PseudoTCP implementation (Re: realiable data service)

Tim Panton <tim@phonefromhere.com> Sat, 23 July 2011 12:51 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 A529D21F899F for <rtcweb@ietfa.amsl.com>; Sat, 23 Jul 2011 05:51:01 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.524
X-Spam-Level:
X-Spam-Status: No, score=-2.524 tagged_above=-999 required=5 tests=[AWL=0.075, BAYES_00=-2.599, HTML_MESSAGE=0.001]
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 mVH7v1-bUG12 for <rtcweb@ietfa.amsl.com>; Sat, 23 Jul 2011 05:51:00 -0700 (PDT)
Received: from zimbra.f1f9.com (zimbra.f1f9.com [192.67.4.169]) by ietfa.amsl.com (Postfix) with ESMTP id 7196121F899D for <rtcweb@ietf.org>; Sat, 23 Jul 2011 05:51:00 -0700 (PDT)
Received: from localhost (localhost [127.0.0.1]) by zimbra.f1f9.com (Postfix) with ESMTP id 5D6CA4AC003; Sat, 23 Jul 2011 13:50:51 +0100 (BST)
X-Virus-Scanned: amavisd-new at zimbra.f1f9.com
Received: from zimbra.f1f9.com ([127.0.0.1]) by localhost (zimbra.f1f9.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 8Wip6yNurWTB; Sat, 23 Jul 2011 13:50:30 +0100 (BST)
Received: from [192.168.157.49] (unknown [93.89.81.113]) by zimbra.f1f9.com (Postfix) with ESMTPSA id B942D4AC002; Sat, 23 Jul 2011 13:50:29 +0100 (BST)
Mime-Version: 1.0 (Apple Message framework v1244.3)
Content-Type: multipart/alternative; boundary="Apple-Mail=_C392BC58-FEB5-4886-B7C5-CAF8005B11F8"
From: Tim Panton <tim@phonefromhere.com>
In-Reply-To: <87CA4E28-DF95-4A03-9809-BC1B2077B4B1@cisco.com>
Date: Sat, 23 Jul 2011 13:50:29 +0100
Message-Id: <4A87F081-90D0-4BAC-97C0-B75686AFF758@phonefromhere.com>
References: <4E0832FE.7010401@ericsson.com> <4E1DC07B.7000807@ericsson.com> <D1BE71E1-4F3B-474E-8A28-AA53CE6B684E@cisco.com> <CA+9kkMCJiE+bfEqZzOBo46aXVH-H2sehHh6UJv3tVdJKGjaokQ@mail.gmail.com> <49CD37FC-7951-45A0-84C4-A443F8B151F3@cisco.com> <4E24AF7C.4080604@jesup.org> <CB57E808-FB8D-41D7-90C6-0EA1051629A8@cisco.com> <4E26D4D6.3020602@alvestrand.no> <CAOJ7v-3RLhaxOWyNJ6p4nE7QyFxOCAeM7xoENPvNhYhoDmyKOw@mail.gmail.com> <87CA4E28-DF95-4A03-9809-BC1B2077B4B1@cisco.com>
To: Cullen Jennings <fluffy@cisco.com>
X-Mailer: Apple Mail (2.1244.3)
Cc: rtcweb@ietf.org
Subject: Re: [rtcweb] PseudoTCP implementation (Re: 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: Sat, 23 Jul 2011 12:51:01 -0000

On 23 Jul 2011, at 03:33, Cullen Jennings wrote:

> 
> On Jul 20, 2011, at 8:37 , Justin Uberti wrote:
>> 
>> Yes, I was going to send a similar email. There are some deficiencies/optimizations for the fact it runs over ICE-UDP - doesn't do path MTU discovery, no checksum, no OOB data - but it is based on TCP and implements slow start and other congestion avoidance mechanisms, and is actively used by a number of applications where reliable transfer is important, such as file transfer and remote desktop applications.
>> 
>> 
> 
> It would be really interesting to see someone write a draft that subsets TCP to make it 
> 

I just want to flag that TCP isn't an especially good fit here, datagrams delivered in events are a very useful
abstraction in JavaScript, which doesn't really do streams of data very well. 

I know we can do datagrams over TCP,  but
it seems wasteful to de-packetize in the TCP layer, just to try and re-packetize it a couple of layers further up.

If there is a reliable datagram protocol as opposed to a reliable stream, I'd go for the datagram every time.

Tim.