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

Cullen Jennings <fluffy@cisco.com> Sun, 24 July 2011 14:49 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 5789421F8745 for <rtcweb@ietfa.amsl.com>; Sun, 24 Jul 2011 07:49:06 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -103.668
X-Spam-Level:
X-Spam-Status: No, score=-103.668 tagged_above=-999 required=5 tests=[AWL=-1.069, 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 CAcYBABw96hC for <rtcweb@ietfa.amsl.com>; Sun, 24 Jul 2011 07:49:05 -0700 (PDT)
Received: from rcdn-iport-1.cisco.com (rcdn-iport-1.cisco.com [173.37.86.72]) by ietfa.amsl.com (Postfix) with ESMTP id 7C7BD21F84F0 for <rtcweb@ietf.org>; Sun, 24 Jul 2011 07:49:05 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=fluffy@cisco.com; l=1547; q=dns/txt; s=iport; t=1311518945; x=1312728545; h=subject:mime-version:from:in-reply-to:date:cc: content-transfer-encoding:message-id:references:to; bh=OCTZRZKBvzVHbStngKyOaYbxgj9m47lxPV9awq5utjE=; b=WI7yfGJU7e+t9rXfLdkH4nC7zMWhOgsoHmF9EuCFVxMNaHHPT09xn2bt V7dHEixX4tinXbHgk5VQHbWA6zakqi+upol7AxdXTod3qwVjT0ovZFqty OqPh6arLRBZLdJJPRAVCA8I7HWV4GjDrmjtMwPiGjvJiHuew+qBd6dqTK w=;
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: Av8EALswLE6rRDoG/2dsb2JhbAA1AQEBAQIBFAEUShIRCgIODAIyAgIUUQc+hC+ifXeIfASdb40jkAOBK4QFMF8EknCFB4t1
X-IronPort-AV: E=Sophos;i="4.67,256,1309737600"; d="scan'208";a="5902554"
Received: from mtv-core-1.cisco.com ([171.68.58.6]) by rcdn-iport-1.cisco.com with ESMTP; 24 Jul 2011 14:49:03 +0000
Received: from [10.21.119.151] ([10.21.119.151]) by mtv-core-1.cisco.com (8.14.3/8.14.3) with ESMTP id p6OEn2f5010182; Sun, 24 Jul 2011 14:49:03 GMT
Mime-Version: 1.0 (Apple Message framework v1084)
Content-Type: text/plain; charset="utf-8"
From: Cullen Jennings <fluffy@cisco.com>
In-Reply-To: <4E2AE828.2060204@jitsi.org>
Date: Sun, 24 Jul 2011 10:49:02 -0400
Content-Transfer-Encoding: quoted-printable
Message-Id: <BAA6A5A6-D7C9-49C9-831A-AFCAB2438F3C@cisco.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> <4E2AE828.2060204@jitsi.org>
To: Emil Ivov <emcho@jitsi.org>
X-Mailer: Apple Mail (2.1084)
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: Sun, 24 Jul 2011 14:49:06 -0000

agree on the high level API you want something datagram oriented... I was just thinking about the congestion control / reliability approach of TCP and fine if a reliable , in order, datagram is put on top of that. 

inline ...

On Jul 23, 2011, at 11:26 , Emil Ivov wrote:

> На 23.07.11 04:33, Cullen Jennings написа:
>> It would be really interesting to see someone write a draft that subsets TCP to make it 
>> 
>> 1) still be congestion safe and TCP friendly 
>> 
>> 2) be valid TCP from point of view nats and firewalls
> 
> Why does it need to be valid TCP? What NATs and firewalls will see is
> valid UDP which is the whole point, isn't it?

I should not have put nats you are right - I'm so used to typing nats and fws :-) On the firewalls that do protocol inspection, they may very well want to be able to parse this layer and even the things inside it. I suspect that code that is there is already valid TCP from the point of view of firewalls so I doubt this requirement really changes anything one way or the other. 

> 
> The fact that the protocol carried in the datagrams is TCP-like only
> matters to the application.

Sort of, lots of firewalls are configured not to allow UDP packets to pass unless they understand what is in them.

> 
> Emil
> 
> --
> http://jitsi.org
> 


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