[rtcweb] Data Channel control messages

Paul Kyzivat <pkyzivat@alum.mit.edu> Sat, 29 March 2014 15:24 UTC

Return-Path: <pkyzivat@alum.mit.edu>
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 752C51A063A for <rtcweb@ietfa.amsl.com>; Sat, 29 Mar 2014 08:24:32 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.235
X-Spam-Level:
X-Spam-Status: No, score=-1.235 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, SPF_SOFTFAIL=0.665] 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 vLm_D3eDnuY2 for <rtcweb@ietfa.amsl.com>; Sat, 29 Mar 2014 08:24:31 -0700 (PDT)
Received: from qmta02.westchester.pa.mail.comcast.net (qmta02.westchester.pa.mail.comcast.net [IPv6:2001:558:fe14:43:76:96:62:24]) by ietfa.amsl.com (Postfix) with ESMTP id 498971A05D3 for <rtcweb@ietf.org>; Sat, 29 Mar 2014 08:24:31 -0700 (PDT)
Received: from omta01.westchester.pa.mail.comcast.net ([76.96.62.11]) by qmta02.westchester.pa.mail.comcast.net with comcast id jTPD1n0010EZKEL51TQUi4; Sat, 29 Mar 2014 15:24:28 +0000
Received: from Paul-Kyzivats-MacBook-Pro.local ([50.138.229.164]) by omta01.westchester.pa.mail.comcast.net with comcast id jTQU1n00N3ZTu2S3MTQUgV; Sat, 29 Mar 2014 15:24:28 +0000
Message-ID: <5336E5AC.5030809@alum.mit.edu>
Date: Sat, 29 Mar 2014 11:24:28 -0400
From: Paul Kyzivat <pkyzivat@alum.mit.edu>
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:24.0) Gecko/20100101 Thunderbird/24.4.0
MIME-Version: 1.0
To: "rtcweb@ietf.org" <rtcweb@ietf.org>
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>
In-Reply-To: <53365D1A.8050501@jesup.org>
Content-Type: text/plain; charset="ISO-8859-1"; format="flowed"
Content-Transfer-Encoding: 7bit
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=comcast.net; s=q20140121; t=1396106668; bh=DvXuy4zeDhmDItmQpUWWf3J5FGAtM7bRYxq/+S/nYGI=; h=Received:Received:Message-ID:Date:From:MIME-Version:To:Subject: Content-Type; b=PJmu7CU5ia+IfTNTdZJ8z7Uk3Nzq2pofiZaaScRdLKS7RQIh3lGGO6Nzh/YQKjA70 ftwzr3SBVM0ZfUHLfcaqlBpQycNTpqbX0BTIyk9nShP7493y0/a37wglAlaSV8zFZT MQch6eMK6iBaOVisBRSk0oWMUUNQTQCKaLFFMj9Iv7gkV8Jyrh4hXk2xzHomvSgEd6 zcWJFPw12F7sSnWITYS4z+Lk1huZjLuSzxs/oJ5BoZTECiGrWzTh0lqdETIpHYgkmI Db1kdDKhi4EHgFLiyzBD6KLyui1QF8SSSkDOyAUdfAkikOSJqs/4GJtCbStgOB3HmG WhbtQqATYXI4g==
Archived-At: http://mailarchive.ietf.org/arch/msg/rtcweb/doetBUL12j1k2Zr_D3hSzArqE8M
Subject: [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 15:24:32 -0000

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.

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.

	Thanks,
	Paul