Re: [rtcweb] Data Channel control messages

Michael Tuexen <Michael.Tuexen@lurchi.franken.de> Sat, 29 March 2014 17:49 UTC

Return-Path: <Michael.Tuexen@lurchi.franken.de>
X-Original-To: rtcweb@ietfa.amsl.com
Delivered-To: rtcweb@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 96B601A0762 for <rtcweb@ietfa.amsl.com>; Sat, 29 Mar 2014 10:49:55 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.561
X-Spam-Level:
X-Spam-Status: No, score=-1.561 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_DE=0.35, SPF_HELO_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id tBzftNqR36_J for <rtcweb@ietfa.amsl.com>; Sat, 29 Mar 2014 10:49:53 -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 25B3A1A06A5 for <rtcweb@ietf.org>; Sat, 29 Mar 2014 10:49:52 -0700 (PDT)
Received: from [192.168.1.200] (p508F3C48.dip0.t-ipconnect.de [80.143.60.72]) (Authenticated sender: macmic) by mail-n.franken.de (Postfix) with ESMTP id 99F831C104301; Sat, 29 Mar 2014 18:49:48 +0100 (CET)
Content-Type: text/plain; charset="us-ascii"
Mime-Version: 1.0 (Mac OS X Mail 7.2 \(1874\))
From: Michael Tuexen <Michael.Tuexen@lurchi.franken.de>
In-Reply-To: <5336E5AC.5030809@alum.mit.edu>
Date: Sat, 29 Mar 2014 18:49:45 +0100
Content-Transfer-Encoding: quoted-printable
Message-Id: <BE7BB38F-33E5-45E8-96DC-09D7732E7F39@lurchi.franken.de>
References: <CAN+ZGEk8J-NJxi28zE=NzPw278iHN+MwLzfW7XJGqj9j5TSn_A@mail.gmail.com> <9DFE7071-67FE-4B03-A6ED-40E24F23C4D7@lurchi.franken.de> <CAN+ZGEkdXgoQ=Cd0MoVUZnKu+UMSw6T=5WFE4K4ypmqG-oFr0A@mail.gmail.com> <41B81DE9-3989-4856-B5D1-F0E2A9BD1F76@lurchi.franken.de> <CAN+ZGEkpuiytW05L_kxLBWQgwqUbLfHgx_8+TwYsF6f17ZWw7g@mail.gmail.com> <A3354D98-13B4-411B-AC2C-721CA986B1E2@lurchi.franken.de> <53365D1A.8050501@jesup.org> <5336E5AC.5030809@alum.mit.edu>
To: Paul Kyzivat <pkyzivat@alum.mit.edu>
X-Mailer: Apple Mail (2.1874)
Archived-At: http://mailarchive.ietf.org/arch/msg/rtcweb/5Xpg6JFJ6zWDuP9oX_S_0FEgWbA
Cc: "rtcweb@ietf.org" <rtcweb@ietf.org>
Subject: Re: [rtcweb] Data Channel control messages
X-BeenThere: rtcweb@ietf.org
X-Mailman-Version: 2.1.15
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, 29 Mar 2014 17:49:55 -0000

On 29 Mar 2014, at 16:24, Paul Kyzivat <pkyzivat@alum.mit.edu> wrote:

> There is a thread going on public-webrtc: WebRTC and backpressure (how to stop reading?)
> 
> That has gotten to the point where there is an rtcweb issue:
> 
> On 3/29/14 1:41 AM, Randell Jesup wrote:
> 
>>> No. You could continue to map  the channel messages byte-by-byte
>>> on SCTP messages. But you would introduce some control message
>>> (also in SCTP DATA chunks) which you would send reliably and
>>> put in whatever information is needed. For me this looks pretty simple...
>> 
>> Agreed; we have considerable latitude to define additional control
>> messages in DATA chunks, if we decide this is useful.
>> If we're careful, it may even be backwards compatible (ignored if not
>> supported) without have to negotiate or probe for support.  But we'd
>> need to know exactly *why* we'd consider changing things at this late
>> date, and for what practical gain, given it would perhaps negatively
>> impact the duck-typing between WebSockets and DataChannels and cause
>> more delay and slow adoption.
> 
> PPID 50, defined in draft-ietf-rtcweb-data-protocol, certainly has the potential to be extended with additional control messages. (It has a one byte message type field with only two values defined.) That seems the obvious place where such messages could be defined.
DCEP is extensible in the way that you can add new message types. But it is a protocol for in-band negotiation
of a data channel. We should keep this focus.

The discussion at W3C focussed on messages not related to the establishment of a data channel, so I would
suggest to use a different PPID.
> 
> Even if the control messages aren't to be defined now, it would be good to set the stage. For one thing, those control messages ought to be usable even for data channels that are established by means other than DCEP. Right now PPID 50 is only for DCEP. Also, as Randell implies above, it might be a good idea to define the extensibility mechanism - e.g., that messages bearing unknown message types be ignored, or that they get a specific response indicating that they are not supported.
I think at the last IETF we agreed to reset the channel. We can change that to ignore unknown PPIDs...

Best regards
Michael
> 
> 	Thanks,
> 	Paul
> 
> _______________________________________________
> rtcweb mailing list
> rtcweb@ietf.org
> https://www.ietf.org/mailman/listinfo/rtcweb
>