Subject: [rtcweb] Open data channel issues

From: Michael Tuexen <[email-masked]>
Date: Wed, 26 Feb 2014 00:44:47 +0100

Dear all,

Magnus asked me to send a list of open issues regarding data channels
to the list. Here is my current list:

* Priority
  The W3C hasn't defined it yet. Neither for the (S)RTP media nor for the
  data channels. We agreed on using a non strict policy for the data channels
  (some sort of wighted fair queueing). That is all.

* Protocol
  It seems not to be clear what needs to be provided when registering a
  (sub)-protocol at IANA. And the name of the registry is unclear...

* SCTP parameters.
  There was discussed the issue how to set SCTP parameters, especially path.max.retrans
  and association.max.retrans. Also HB.Interval might be of interest.
  RFC 4060 recommends path.max.retrans=5, association.max.retrans=10, but has multihoming
  in mind. To avoid the dormant state, path.max.retrans = association.max.retrans should be used.
  I would suggest 10 for this value. Should HEARTBEATs be disabled?

* U-C 7: Proxy browsing

* Alternate CC for SCTP
  Currently there is only the standard CC. However, in some places negotiation of CC is
  mentioned.

I'm currently going through the backlog of comments regarding the data channels
ID and I'll try to address the issues. If I find other issues, I send an update
to the above list.

Best regards
Michael

---

From: Magnus Westerlund <[email-masked]>
Date: Wed, 26 Feb 2014 08:50:29 +0100

Thanks Michael,

WG, please consider these open issues and try to form your own position
on them. They are intended to be discussed at the meeting. If you have
proposals on how to resolve them or other input you are very welcome to
provide that on the list.

Thanks

Magnus

On 2014-02-26 00:44, Michael Tuexen wrote:
> _______________________________________________
> rtcweb mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/rtcweb
> 
> 

-- 

Magnus Westerlund

----------------------------------------------------------------------
Services, Media and Network features, Ericsson Research EAB/TXM
----------------------------------------------------------------------
Ericsson AB                 | Phone  +46 10 7148287
Färögatan 6                 | Mobile +46 73 0949079
SE-164 80 Stockholm, Sweden | mailto: [email-masked]
----------------------------------------------------------------------

---

From: Paul Kyzivat <[email-masked]>
Date: Wed, 26 Feb 2014 14:50:00 -0500

Michael,

There have been no replies to my comments:

http://www.ietf.org/mail-archive/web/rtcweb/current/msg11518.html
http://www.ietf.org/mail-archive/web/rtcweb/current/msg11519.html

The first of those is about channels, the 2nd about DCEP. One of my 
issues is that the partitioning between those two drafts is awkward. At 
the least some things from DCEP should be moved to the channel draft. It 
might be better to just merge those two drafts, or do a serious refactoring.

	Thanks,
	Paul

---

From: Randell Jesup <[email-masked]>
Date: Wed, 26 Feb 2014 16:02:03 -0500

On 2/26/2014 2:50 PM, Paul Kyzivat wrote:
> issues is that the partitioning between those two drafts is awkward. 
> At the least some things from DCEP should be moved to the channel 
> draft. It might be better to just merge those two drafts, or do a 
> serious refactoring.

There seem to have been a number of responses to your second posting at 
least.

> How about:

    Each SCTP user message contains a so called Payload Protocol
    Identifier (PPID) that is passed to SCTP by the data channel layer
    and sent to its peer.  This value is used to multiplex WebRTC Data
    Channel Establishment Protocol messages (defined in [I-D.ietf-rtcweb-
    data-protocol]) with messages containing user data on a data
    channel. The PPID is also used to distinguish UTF-8 encoded user
    data and binary encoded user data.

That seems reasonable and clearer.

> * Section 6.5
> This section contains:

    Data channels can be opened by using internal or external
    negotiation.  The details are out of scope of this document.

    A simple protocol for internal negotiation is specified in
    [I-D.ietf-rtcweb-data-protocol] and MUST be supported.

> But internal and external negotiation are not defined in this document.
>

 > I *thought* that internal negotiation was by definition negotiation 
by use of
 > rtcweb-data-protocol. (draft-ejzak-mmusic-data-channel-sdpneg-00 
thinks so too,
 > but calls it "in-band negotiation".) There should be a good 
definition of these
 > terms, or reference to one. And more discussion if there can be other 
kinds of
 > internal negotiation. (If so, how would one be chosen?)

Well, the text above says that ietf-rtcweb-data-protocol specifies an 
internal negotiation protocol,
so it's not that far off.  The split does allow someone to use an 
alternative negotiation protocol
(internal or external).

How about:

    Data channels can be opened by using negotiation within the SCTP association or external
    negotiation.  External negotiation is defined as any method which results in an agreement
    as to the parameters of a channel and the creation thereof.
    The details are out of scope of this document.

    A simple protocol for negotiation within the SCTP association is specified in
    [I-D.ietf-rtcweb-data-protocol] and MUST be supported.

Perhaps someone can wordsmith "external negotiation" better.

> * Section 6.6:
> Say:

    All data sent on a Channel in both directions MUST be sent over the
    underlying stream using the reliability defined when the Channel was
    opened unless the options are changed, or per-message options are
    specified by a higher level.

 > Is the recipient to consider it an error if messages are received 
with options different from those
 > defined for the channel? Also, is it an error if messages are 
received with a PPID that isn't specified
 > in Section 8? (And what about PPID 50?)

> How are such channel errors to be treated?

I'd propose that if messages are received with options that don't match 
the initial definition, that fact should be ignored and the message 
processed.
If messages with an unknown PID are received, those messages should be 
ignored.

In both cases, logging of such an event to the application (or onerror 
calls in WebRTC W3 JS layers) is allowed but not required. Note that the 
onerror callback is currently under-defined, so this might change.

-- 
Randell Jesup -- rjesup a t mozilla d o t com

---

From: Paul Kyzivat <[email-masked]>
Date: Wed, 26 Feb 2014 17:06:56 -0500

> There seem to have been a number of responses to your second posting at

Well - *one*, and my reply. My mistake - I lost track, and only checked 
the first one when I sent this. :-(

> That seems reasonable and clearer.

Thanks.

> Perhaps someone can wordsmith "external negotiation" better.

ISTM the issue is that Internal vs. External isn't the key distinction. 
What is key is that there is one method that MUST be *supported* but 
need not be the only one used. Other mechanisms may be used. It doesn't 
really matter whether they are conducted internally (over the SCTP 
association) or externally (anything else).

E.g., I could use DCEP to establish one channel, and then use my own 
private protocol over that to negotiate other channels. Would that be 
internal or external negotiation? Does it matter?

> If messages with an unknown PID are received, those messages should be

I could live with that. It comes to a philosophical issue of whether you 
want to fail soft or fail hard.

Could just explicitly say that behavior when the per-message SCTP 
parameters are inconsistent with the channel is nonconformant to this 
specification and undefined. And that behavior when PPIDS other than 50, 
51, and 54 (did I remember right?) are used is also nonconformant and 
undefined.

Note that the current partitionion makes it hard to specify conforming 
use of PPID 50. From a channel perspective you can use it, but from a 
DCEP perspective you can only use it a certain way.

(This would be easier if the two were merged. Since DCEP is mandatory to 
implement, there seems little reason to keep them separate.

> onerror callback is currently under-defined, so this might change.

If there is a goal to report errors in a defined way then that would 
change things.

	Thanks,
	Paul

---

From: Christer Holmberg <[email-masked]>
Date: Wed, 26 Feb 2014 22:21:38 +0000

Hi,

>> by use of  > rtcweb-data-protocol. 
>> (draft-ejzak-mmusic-data-channel-sdpneg-00
>> thinks so too,
>> definition of these  > terms, or reference to one. And more discussion 
>> if there can be other kinds of  > internal negotiation. (If so, how 
>> would one be chosen?)
>>
>> internal negotiation protocol, so it's not that far off.  The split 
>> does allow someone to use an alternative negotiation protocol 
>> (internal or external).
>>
>> How about:
>>
>What is key is that there is one method that MUST be *supported* but need not be the only one >used. Other mechanisms may be used. It doesn't really matter whether they are conducted >internally (over the SCTP association) or externally (anything else).

I think the MUST-be-supported-method is a separate question.

>E.g., I could use DCEP to establish one channel, and then use my own private protocol over that to >negotiate other channels. Would that be internal or external negotiation? Does it matter?

I guess they would both be in-band methods. Maybe using in-band and out-of-band terminology would be more clear - and more aligned with existing terminology.

Regards,

Christer

---

From: Paul Kyzivat <[email-masked]>
Date: Wed, 26 Feb 2014 20:15:07 -0500

> I guess they would both be in-band methods. Maybe using in-band and out-of-band terminology would be more clear - and more aligned with existing terminology.

My point is that the real distinction is between the one std mechanism 
and everything else. For purposes of discussions here it doesn't matter 
whether the non-std mechanisms are in-band or out of band.

(Of course to the people using them the distinction is significant. But 
it is their problem, not ours.)

	Thanks,
	Paul