Subject: [rtcweb] Data Channel control messages

From: Paul Kyzivat <[email-masked]>
Date: Sat, 29 Mar 2014 11:24:28 -0400

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

---

From: Michael Tuexen <[email-masked]>
Date: Sat, 29 Mar 2014 18:49:45 +0100

On 29 Mar 2014, at 16:24, Paul Kyzivat <[email-masked]> wrote:

> There is a thread going on public-webrtc: WebRTC and backpressure (how to stop reading?)
> 
> 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
> [email-masked]
> https://www.ietf.org/mailman/listinfo/rtcweb
>