Re: [rtcweb] New Version Notification for draft-jesup-rtcweb-data-01.txt

Michael Tüxen <Michael.Tuexen@lurchi.franken.de> Sat, 05 November 2011 21:10 UTC

Return-Path: <Michael.Tuexen@lurchi.franken.de>
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 77C7121F85D1 for <rtcweb@ietfa.amsl.com>; Sat, 5 Nov 2011 14:10:29 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.992
X-Spam-Level:
X-Spam-Status: No, score=-1.992 tagged_above=-999 required=5 tests=[AWL=0.307, BAYES_00=-2.599, MIME_8BIT_HEADER=0.3]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id pMoSlb5-o433 for <rtcweb@ietfa.amsl.com>; Sat, 5 Nov 2011 14:10:28 -0700 (PDT)
Received: from mail-n.franken.de (drew.ipv6.franken.de [IPv6:2001:638:a02:a001:20e:cff:fe4a:feaa]) by ietfa.amsl.com (Postfix) with ESMTP id C5C8821F85AE for <rtcweb@ietf.org>; Sat, 5 Nov 2011 14:10:27 -0700 (PDT)
Received: from [192.168.1.200] (p508FBA09.dip.t-dialin.net [80.143.186.9]) (Authenticated sender: macmic) by mail-n.franken.de (Postfix) with ESMTP id 1CC451C0C0BCA; Sat, 5 Nov 2011 22:10:20 +0100 (CET)
Mime-Version: 1.0 (Apple Message framework v1251.1)
Content-Type: text/plain; charset=us-ascii
From: =?iso-8859-1?Q?Michael_T=FCxen?= <Michael.Tuexen@lurchi.franken.de>
In-Reply-To: <4EB2B61D.1010000@jesup.org>
Date: Sat, 5 Nov 2011 22:10:18 +0100
Content-Transfer-Encoding: quoted-printable
Message-Id: <36EE558D-548B-4280-A370-D809C7E522E5@lurchi.franken.de>
References: <20111031211134.8188.49554.idtracker@ietfa.amsl.com> <4EAF64FF.8020101@jesup.org> <02485FF93524F8408ECA9608E47D9F2007CACFFAC2@nambx05.corp.adobe.com> <4EB21DEF.5060606@jesup.org> <4EB29275.8000204@ericsson.com> <4EB2B61D.1010000@jesup.org>
To: Randell Jesup <randell-ietf@jesup.org>
X-Mailer: Apple Mail (2.1251.1)
Cc: rtcweb@ietf.org
Subject: Re: [rtcweb] New Version Notification for draft-jesup-rtcweb-data-01.txt
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, 05 Nov 2011 21:10:29 -0000

On Nov 3, 2011, at 4:41 PM, Randell Jesup wrote:

> On 11/3/2011 9:09 AM, Magnus Westerlund wrote:
>> When it comes to the actual usage of either of IP/UDP/SCTP/DTLS and
>> IP/UDP/DTLS/SCTP we have the same two dependencies on other WGs.
>> 
>> First we need a SCTP over foo document, which is TSVWG. The SCTP over
>> UDP is already an WG document and making some progress. For SCTP over
>> DTLS there would be need for a new document, or possibly get that
>> defined in the same as SCTP over UDP directly.
>> 
>> Secondly if one uses SDP one needs a definition of how one expresses
>> this on the media description line. That includes the "proto" identifier
>> itself and any additional information, like direction for establishing
>> the connection which would be similar to what COMEDIA defines for TCP
>> (RFC 4145).
> 
> We probably need to do these in any case (SCTP or not).
> 
>>> From a time perspective IP/UDP/SCTP/DTLS is the quicker road as the SCTP
>> over UDP is already in progress and DTLS over SCTP is defined.
> 
> Right, but that also means we'd need to define reliable stream-like layers on top of DTLS-over-SCTP, deal with large message fragmentation, etc.  Perhaps someone with more DTLS-over-SCTP knowledge (Michael, Randy) could detail what the impact would be.  (I'll also start reviewing the DTLS-over-SCTP draft.)
If the upper layer knows that you use stream n in "stream line mode", you can just
ignore the message framing. Pretty simple. No changes needed. Runs over SCTP or DTLS.

If you need large messages with message boundaries, it can be added to SCTP.
It should be not too hard. Randy and myself will look into it... However, 
to allow multiplexing with having more than one message being sent concurrently,
a new chunk is necessary.

Just one note: DTLS-over-SCTP is an RFC and you can find a patch for OpenSSL at
http://sctp.fh-muenster.de/dtls-patches.html

>> So what exist here is really:
>> 
>> https://datatracker.ietf.org/doc/draft-ietf-mmusic-sctp-sdp/
>> https://datatracker.ietf.org/doc/rfc6083/ (DTLS over SCTP)
>> https://datatracker.ietf.org/doc/draft-ietf-tsvwg-sctp-udp-encaps/
>> 
>> 
>>> 
>>> In response I have to say: put a protocol proposal on the table or
>>> gather a group to do so, and do so ASAP, because if we don't get an
>>> alternative, it *will* be either SCTP/DTLS/(ICE/UDP) or
>>> pseudo-TCP/DTLS/(ICE/UDP), and I don't know what we'd do for the
>>> unreliable congestion-controlled channels (maybe DCCP).
>> 
>> Personally view:
>> 
>> I think the choice will be between either
>> 
>> DTLS/SCTP/UDP or SCTP/DTLS/UDP
>> 
>> and
>> 
>> TCP/UDP + DCCP/UDP
> 
> I agree that this is the fundamental choice, barring some surprise. There is one other option, though I would vote against it and I doubt anyone really wants it: drop internal data streams and require use of websockets for data (and that means no unreliable streams, which severely crimps real-time data use).
> 
> 
> Sometimes it seems like it would be easier to rubber-stamp (document if you prefer) an existing protocol design done outside the standards process than to develop one inside of it, which is a problem, but not one we'll solve here.
> 
> Realize that if we don't find a solution that works within the standards process, the vendors in question will be forced to implement something that gives the desired functionality in the timeframe required, and then it would turn into a case of a defacto standard in need of documentation.  Obviously I think all here would prefer to avoid that scenario.
> 
>>> If you do put forward a proposal, do you really believe it can be
>>> done, standardized, agreed to and implemented in the timeframe
>>> required? Specifying SCTP/DTLS seems relatively straightforward
>>> compared to standardizing a new protocol...  The timeframe for this
>>> is quite constrained already; one of the strongest arguments against
>>> SCTP would also be timeframe, except that SCTP gives us
>>> congestion-controlled unreliable data, which pseudo-TCP-over-DTLS
>>> doesn't - we'd have to use yet another unspecified mechanism for
>>> congestion control of the unreliable data channels.
>>> 
>> 
>> I personally don't think think this can be done in short time frames
>> within the IETF. The reason is that IETF will have to do the following
>> to get this going and in the end produce an RFC:
> 
> [snip 16 steps]
> 
>> Just the required process steps in the above is on the order of 3
>> months. My guess is that even if interest in this holds it is 3-4 years
>> before IETF can conclude on a new transport protocol.
> 
> Even getting to the point where we have a complete enough draft within the IETF is probably a minimum of 2 years (witness OPUS/codec).
> 
> 
> -- 
> Randell Jesup
> randell-ietf@jesup.org
> _______________________________________________
> rtcweb mailing list
> rtcweb@ietf.org
> https://www.ietf.org/mailman/listinfo/rtcweb
>