Re: [rtcweb] realiable data service

Ted Hardie <ted.ietf@gmail.com> Mon, 18 July 2011 16:59 UTC

Return-Path: <ted.ietf@gmail.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 D409021F8BB5 for <rtcweb@ietfa.amsl.com>; Mon, 18 Jul 2011 09:59:50 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.598
X-Spam-Level:
X-Spam-Status: No, score=-3.598 tagged_above=-999 required=5 tests=[AWL=-0.000, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1]
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 bEJFYORw1m19 for <rtcweb@ietfa.amsl.com>; Mon, 18 Jul 2011 09:59:50 -0700 (PDT)
Received: from mail-yx0-f172.google.com (mail-yx0-f172.google.com [209.85.213.172]) by ietfa.amsl.com (Postfix) with ESMTP id CAAC721F8B3A for <rtcweb@ietf.org>; Mon, 18 Jul 2011 09:59:49 -0700 (PDT)
Received: by yxp4 with SMTP id 4so1681438yxp.31 for <rtcweb@ietf.org>; Mon, 18 Jul 2011 09:59:49 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=xBaO1cbtT5iZnxSz2CIXuPA18eZROnNSe80m3kW2oXk=; b=GphVzRCYwtLFW7yT26L3pfi4ZRJJY051kcwe515QnH4dxz6AFPipDIKmfrHt+lC23K YaNyeFUqfPAYmhxdI/x2ur2CdX1BtDbpBqLTj5ANLSXZVrkM3CE0JwCNElQSBWmeyRwx R7LikJiFTla4haRhp9BwVBim8GyiLBuJfXhAY=
MIME-Version: 1.0
Received: by 10.236.181.98 with SMTP id k62mr2673547yhm.346.1311008136802; Mon, 18 Jul 2011 09:55:36 -0700 (PDT)
Received: by 10.236.105.133 with HTTP; Mon, 18 Jul 2011 09:55:36 -0700 (PDT)
In-Reply-To: <4E243B77.1000900@ericsson.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>
Date: Mon, 18 Jul 2011 09:55:36 -0700
Message-ID: <CA+9kkMAO=KjMRT9s3NhKAZfcXyrsAKM4KfOpLrOYouL=fzPPWw@mail.gmail.com>
From: Ted Hardie <ted.ietf@gmail.com>
To: Magnus Westerlund <magnus.westerlund@ericsson.com>
Content-Type: multipart/alternative; boundary="20cf305b10764ab0ee04a85ade61"
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 16:59:51 -0000

Forgive the top-posting, but I want to make a meta-comment.  If we were
planning on building something from scratch, I would strongly agree that it
would be quite tough going, especially given our timelines.  But this
working group is not allowed to re-use existing work, it is strongly
encouraged to do so.  Picking a protocol to implement which has the
characteristics below is a lot less difficult than re-starting the exercise
from scratch.

Providing XMPP, DTLS, or SCTP between the endpoints certainly has
challenges, but it would *not* involve starting from scratch.

regards,

Ted


On Mon, Jul 18, 2011 at 6:56 AM, Magnus Westerlund <
magnus.westerlund@ericsson.com> 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.
>
> 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
>
> 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.
>
> 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
>