Subject: Re: [rtcweb] WGLC for data channel drafts

From: Michael Tuexen <[email-masked]>
Date: Fri, 4 Jul 2014 19:22:57 +0200

On 24 Jun 2014, at 15:51, Christian Groves <[email-masked]> wrote:

> Some comments:
> 
> draft-ietf-rtcweb-data-channel talks about unreliable use cases. Draft-ietf-rtcweb-data-protocol-06 in clause 4 also mentions "reliable or unreliable message transmission". However there is no channel type for "unreliable" only "DATA_CHANNEL_RELIABLE_xxx" and "DATA_CHANNEL_PARTIAL_RELIABLE_xxx". Are the "unreliable" use cases/text actually "partial reliable"? The requirements suggest that unreliable transport is needed but the solution offered is for reliable and partial reliability.
unreliable is not reliable for me. Partial reliable is another term for it. In PR-SCTP
terminology, partial reliable is used. So you have two incarnations of unreliable:
* timer based
* number of retransmission based.
> 
> draft-ietf-rtcweb-data-channel-10
> ---------------------------------
> Cl. 6.1 bullet 1: Would "stream reconfiguration" be a better term than "stream reset"? RFC6525 allows reset and addition of streams.
You are right, the extension is called stream reconfiguration. However, WebRTC doesn't
use the addition of streams. The maximum number is always negotiated.
> Cl. 6.1 bullet 2: "dynamic address reconfiguration" is the name of the RFC 5061. Is the part that Data Channel supports only the "Supported Extensions" parameter (cl.4.2.7/RFC5061)?
Correct.

Thanks for your comments.

Best regards
Michael
> 
> Regards, Christian
> 
> On 11/06/2014 4:52 AM, Ted Hardie wrote:
>> Dear WG,
>> 
>> This starts a working group last call for our core Data Channel drafts:
>> 
>> draft-ietf-rtcweb-data-protocol-06.txt
>> draft-ietf-rtcweb-data-channel-10.txt
>> 
>> Please review them in detail, especially for areas which may be of concern to the broader IETF community.  This WGLC will end on June 27, 2014.
>> 
>> Ted, Sean, Cullen
>> 
>> 
>> _______________________________________________
>> rtcweb mailing list
>> [email-masked]
>> https://www.ietf.org/mailman/listinfo/rtcweb
> 
> _______________________________________________
> rtcweb mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/rtcweb
>

---

From: Michael Tuexen <[email-masked]>
Date: Fri, 4 Jul 2014 19:23:13 +0200

On 27 Jun 2014, at 15:00, Harald Alvestrand <[email-masked]> wrote:

> On 06/10/2014 08:52 PM, Ted Hardie wrote:
>> Dear WG,
>> 
> This is my Last Call review of these two drafts.
First of all, thank you very much for the comments.
> 
> First of all: The drafts are ready for IETF Last Call.
> Second: There are a number of details that should be fixed. Whether that happens before IETF Last Call or not is not of great concern to me.
I'll submit an update. That gives all the same basis for further discussions.
> ----------------------------------------------
> Abstract
> 
> Ten years from now, the RFC will exist, but the RTCWEB WG will not. I suggest replacing "The Real-Time Communication in Web browsers working group is charged to" with "The WebRTC framework specifies".
OK so it reads:
<t>The WebRTC framework specifies protocol support for direct interactive
rich communication using audio, video, and data between two peers' web-browsers.
> 
> 1. Introduction
> 
> It's a little abrupt. Some more words of introduction may be needed here. Something like this:
> 
> In the WebRTC framework, communication between the parties consists of media (for example audio and video) and non-media data. Media is sent using SRTP, and is not specified further here. Non-media data is handled by...."
Done. Good suggestion.
> 
> I suggest a global replace of "non-SRTP media data" with "non-media data" (3 occurences total). "non-SRTP media data" can be parsed as "media data that is not carried over SRTP", which is not the intended meaning.
Done.
> 
> 4. Requirements
> 
> Suggest striking "and that the WebRTC PeerConnection as a whole is fair with competing traffic such as TCP". The RMCAT discussions have proved how difficult it is just to define that, far less achieve it.
> If we want to say something in relation to TCP, I would suggest "and that the WebRTC PeerConnection does not cause excessive problems when run in parallel with TCP connections".
Taken.
> 
> 5. SCTP over DTLS over UDP Considerations
> 
> In the paragraph on SCTP multihoming, I suggest using "the DTLS layer" instead of "the lower layer". There are multiple lower layers, identifying which one is mentioned here improves clarity.
OK.
> 
> The term "user-land" is used here, while Req. 10 uses "user application space". I suggest using "user application space" in both places.
OK.
> 
> The paragraph "When using DTLS as the lower layer..." repeats the info that SCTP multihoming is not used. It may be enough to say this once.
Taken out.
> 
> "The partial reliability extension MUST support policies..." - this paragraph would be more implementable if specific policies, specified in an I-D or RFC, were referenced.
References added.
> 
> The split between section 5 and section 6 seems odd. In particular, the section "This SCTP stack and its upper layer...." down to "exactly once and delivered in the order received." seems to belong to section 6 not section 5.
Text reorganised and removed duplicate text.
> 
> 6.1 SCTP Protocol Considerations
> 
> I think the -ndata messsage interleaving MUST be implemented, according to previous consensus.
> "SHOULD be used" seems both meaningless and unneccssary.
I think the current text covers the case that it is not available in implementations yet.
If you write MUST be implemented, a conformant implementation would reject interworking
with currently existing implementations.
> 
> 6.2 Association setup
> 
> Nit: "that can negotiated" -> "that can be negotiated"
Fixed.
> 
> 6.4 Channel definition
> 
> The title should probably be "WebRTC Data Channel Definition".
OK.
> 
> As part of getting the WGs out of the document, the first sentence should be "The  WebRTC DataChannels are bidirectional."
OK.
> "Among other things" is a bad term to have in a document at Last Call time. Can we remove it?
Done.
> 
> The SHOULD for -ndata- interleaving should be MUST implement and MUST offer. If it is not successfully negotiated at association setup time (is that how it works?), the "SHOULD limit" clause is appropriate.
But if it is MUST implement and MUST offer, how could it be not negotiated? If it
is offered by both sides, it is used. The SHOULD covers that it might not be supported.
So I think the text is in tune with other parts of the data channel documents.
> 
> 6.7 Closing a channel
> 
> Nit: "available to reuse" -> "available for reuse"
> Nit: "before resetting the stream" -> "before the stream is reset"
Both fixed.
> 
> 7 Security considerations
> 
> Is there a security worry with an attacker sending over-long messages in an attempt to cause OOM situations?
OK, I added:
<t>I should be noted that a receiver must be prepared that the sender tries
to send arbitrary large messages.</t>
> 
> draft-ietf-rtcweb-data-protocol-06
> ---------------------------------------------
> Abstract: Same worry about WG reference.
Same as above.
> 
> 3. Terminology
> 
> Stream is defined in terms of stream, which is unhealthy. A reference to a section of a relevant SCTP document would be better.
> 
> The term "SCTP stream" occurs at least 18 times in the document (out of approx 41 occurences of "stream" overall). We should either use "SCTP stream" consistently" or stick to "Stream" consistently.
Changed to Stream consistently.
> 
> The term "SCTP stream identifier" (or "stream identifier") should be called out in the terminology.
OK.
> 
> The term "data channel" occurs 36 times. Consider standardizing on either Channel or Data Channel, and either capitalizing it or not.
OK. Using Data Channel consistently.
> 
> 6 Procedures
> Nit: "the sender of it can start" -> "the sender of the DATA_CHANNEL_OPEN can start"
Done.
> 
> "If a DATA_CHANNEL_OPEN message is received .... the stream identifier corresponds to the role of the peer" - is there a reason to insist that the protocol machine enforce the odd/even rule?
I would like to define what happens if the peer does not follow the rule... It has to
be handled by any implementation, so why leave it up to the implementer?
> `(actually the next paragraph does not cover the odd/even rule violation case, which is probably just an unintentional mistake - I prefer writing this kind of thing in "IF <condition> ... ELSE ....
Jepp, that was unintentional...
>  - because if one writes it as "IF <condition>; IF <opposite condition>", the risk of losing some edge cases is high.
> 
> An alternative formulation for the second paragraph is "If the DATA_CHANNEL_OPEN message doesn't satisfy the conditions above, for instance if..."
Good point. I will use:
<t>If the DATA_CHANNEL_OPEN message doesn't satisfy the conditions above,
for instance if a DATA_CHANNEL_OPEN message is received on an already used
Stream or there are any problems with parameters within the DATA_CHANNEL_OPEN
message, the odd/even rule is violated or the DATA_CHANNEL_OPEN message itself
is not well-formed, the receiver MUST close the corresponding channel using the
procedure described in <xref target='I-D.ietf-rtcweb-data-channel'/> and
MUST NOT send a DATA_CHANNEL_ACK message in response to the received message.
> 
> 7 Security Considerations
> 
> The "When using..." paragraph sounds a bit off. What about saying
> 
> This protocol does not provide privacy, integrity or authentication. It needs to be used as part of a protocol suite that contains all these things. Such a protocol suite is specified in [-dtls-encaps].
Taken.
> 
> Dependency worries
> ---------------------------
> -protocol- depends normatively on these non-WG documents:
> 
> draft-ietf-tsvwg-sctp-ndata ("I-D exists")
This is currently being worked on.
> draft-ietf-tsvwg-sctp-dtls-encaps ("AD is watching")
This is passed WG LC, just incorporating the comments. So there will be a new rev tomorrow.
> draft-ietf-tsvwg-sctp-prpolicies ("I-D exists")
The WG LC started yesterday. Reviews very welcome!
> draft-ietf-mmusic-sctp-sdp ("I-D exists")
I don't know about the status of this.
> 
> None of these are in the IESG queue. Are we confident of their speed of progress?
> 
> 
> This concludes my review. I think the protocol definition is ready, and needs no changes.
> 
> 
> 
>

---

From: Gunnar Hellstrom <[email-masked]>
Date: Fri, 04 Jul 2014 23:23:58 +0200

I cannot find that what happens in transmission error situations is 
described in any of these drafts.

Both reliable and partially reliable transmission can fail, and the 
application designer need to know what happens.

We discussed it earlier, and came to the conclusion that
A failing reliable channel will tear down the connection and some 
indication will be provided if possible to the application.
A failing partially reliable channel will enable transmission of next 
data item. ( I do not remember if the application will get any error 
indication or if it needs to have its own sequence checking if it is 
interested in knowing if there are no gaps. )

I suggest that a section on failure handling is added. I get the 
impression that it is in the data-channel draft it would be best suited.

Regards

Gunnar
------------------------------------------------------------------------
Gunnar Hellström
Omnitor
[email-masked]
On 2014-06-10 20:52, Ted Hardie wrote:
> Please review them in detail, especially for areas which may be of 
> concern to the broader IETF community.  This WGLC will end on June 27, 
> 2014.
>
> Ted, Sean, Cullen
>
>

---

From: Michael Tuexen <[email-masked]>
Date: Fri, 4 Jul 2014 23:34:42 +0200

On 04 Jul 2014, at 23:23, Gunnar Hellstrom <[email-masked]> wrote:

> I cannot find that what happens in transmission error situations is described in any of these drafts.
> 
> Both reliable and partially reliable transmission can fail, and the application designer need to know what happens.
I don't understand the notion of "reliable and partially reliable transmission can fail"...
If a user message gets abandoned (so the stack gives up transmitting/retransmitting it, but
the association stays alive), I don't think it is signalled via the JS API, but that might
be an issue of W3C. If the association fails, all data channel fail. This is signalled.
However, this is something for the W3C document.
> A failing reliable channel will tear down the connection and some indication will be provided if possible to the application.
> A failing partially reliable channel will enable transmission of next data item. ( I do not remember if the application will get any error indication or if it needs to have its own sequence checking if it is interested in knowing if there are no gaps. )
> 
> I suggest that a section on failure handling is added. I get the impression that it is in the data-channel draft it would be best suited.
But this is about the API. So it should go into the W3C document.

Best regards
Michael

---

From: Gunnar Hellstrom <[email-masked]>
Date: Sat, 05 Jul 2014 08:14:25 +0200

> However, this is something for the W3C document.
The W3C mechanism makes use of the rtcweb-data-channel.
The rtcweb-data-channel should tell what happens in error situations and 
if that is possible to be signaled to higher layers.
The higher layers should have specified the requirements on the 
data-channel.
If no requirements can be found, we should either propose behavior in 
error situations or request to get requirements stated from upper layers.
> But this is about the API. So it should go into the W3C document.
The API can only provide the functions provided by the mechanisms it has 
underneath.

There was a mail discussion in webRTC about the error situations.
A conclusion was that if a reliable channel reaches its retry limit ( 
that is usually only about 5 for WebRTC) or some other indication that 
the channel failed to convey the data, then the channel shall be broken 
(by the channel) and indications provided to both sides if possible. 
(another reasons mentioned was missed heartbeats for the whole 
association, setting a retry time limit of - what was it - - - 15 seconds?)

If the retries or retransmission time is exceeded for a partially 
reliable channel, the conclusion was that communication can continue 
with next data item. I am not sure if the applications were to get any 
notification about that or if they need to introduce sequence number 
checking themselves if they are interested to know.

I cannot see how we can avoid describing the mechanisms needed and what 
happens to the channel.

I found a sentence about this  in section 6.6 of the data-channel-11 draft.

"

If a message with an unsupported PPID is received or some error is
    detected by the receiver (for example, illegal ordering), the
    receiver SHOULD close the corresponding data channel."

This paragraph could be extended to tell more about error situations in 
open channels.
I suggest to move this sentence to a new section and add description of 
other situations. The sentence only tells about errors detected at the 
receiving end. But it can also be the transmitting end that detects the 
problem. It should be stated what shall be done then.T

Something like this ( with my questions in paranthesis).
-------------------------------------------------------Proposed error 
handling section in 
rtcweb-data-channel---------------------------------------------------------------------------
6.7 Transmission failure and error handling
Failures can occur when a data channel is open.

If transmission in a reliable channel fails, the channel shall be closed 
by the party detecting the failure and an error indication provided.   
    ( what does STCP do in this situation? )

If a watchdog times out, the channel shall be closed with an error 
indication.         ( if this is part of the channel mechanisms, I have 
not seen where it is defined.)

If retransmissions or transmission time is exceeded in a partially 
reliable channel, the transmission SHALL be allowed to continue with 
next data item.

If reception out-of order is detected from an SCTP channel for which 
ordered transmission is requested, the receiver SHALL close the data 
channel.

If a message with an unsupported PPID is received or some logical error 
is detected by the receiver, the receiver SHALL close the corresponding 
data channel.

--------------------End of proposed section on failure 
handling---------------------------------------------------------------------------------------------------------------------------

Regards

/Gunnar

---

From: Michael Tuexen <[email-masked]>
Date: Mon, 7 Jul 2014 22:00:46 +0200

On 05 Jul 2014, at 08:14, Gunnar Hellstrom <[email-masked]> wrote:

> The rtcweb-data-channel should tell what happens in error situations and if that is possible to be signaled to higher layers.
> The higher layers should have specified the requirements on the data-channel.
> If no requirements can be found, we should either propose behavior in error situations or request to get requirements stated from upper layers.
SCTP tells the user if the association has failed. At that point all data channels
must be closed. But I think this is something which needs to be stated in the
W3C document...
> The API can only provide the functions provided by the mechanisms it has underneath.
> 
> A conclusion was that if a reliable channel reaches its retry limit ( that is usually only about 5 for WebRTC) or some other indication that the channel failed to convey the data, then the channel shall be broken (by the channel) and indications provided to both sides if possible. (another reasons mentioned was missed heartbeats for the whole association, setting a retry time limit of - what was it - - - 15 seconds?)
A reliable channel doesn't have a limit. The association has. If the association breaks,
all data channels are gone.
> 
> If the retries or retransmission time is exceeded for a partially reliable channel, the conclusion was that communication can continue with next data item. I am not sure if the applications were to 
It will continue. It is not a stop and wait...
> get any notification about that or if they need to introduce sequence number checking themselves if they are interested to know.
I don't think so. I don't see anything in the JS API.
> 
> 
> 
> I cannot see how we can avoid describing the mechanisms needed and what happens to the channel.
> 
> 
> This paragraph could be extended to tell more about error situations in open channels.
> I suggest to move this sentence to a new section and add description of other situations. The sentence only tells about errors detected at the receiving end. But it can also be the transmitting end that detects the problem. It should be stated what shall be done then.T
> 
> -------------------------------------------------------Proposed error handling section in rtcweb-data-channel---------------------------------------------------------------------------
> If transmission in a reliable channel fails, the channel shall be closed by the party detecting the failure and an error indication provided.      ( what does STCP do in this situation? )
This can't happen. Only the association can fail and in this case all data channels are gone...
> 
> If a watchdog times out, the channel shall be closed with an error indication.         ( if this is part of the channel mechanisms, I have not seen where it is defined.)
If you think about SCTP HEARTBEATs, it is like the above. But it is more likely
that ICE will detect it first.
> 
> If retransmissions or transmission time is exceeded in a partially reliable channel, the transmission SHALL be allowed to continue with next data item.
It is not stop and wait... next item might be transmitted before the message is abandoned.
> 
> If reception out-of order is detected from an SCTP channel for which ordered transmission is requested, the receiver SHALL close the data channel.
This is covered by the text cited above.
> 
> If a message with an unsupported PPID is received or some logical error is detected by the receiver, the receiver SHALL close the corresponding data channel.
This is covered by the text cited above.

So I think the only thing not covered is what to do if the SCTP association fails,
but it is obvious to me that all channels are gone. Do we need to state that
explicitly? What do others think?

Best regards
Michael
> --------------------End of proposed section on failure handling---------------------------------------------------------------------------------------------------------------------------
> 
> 
> 
> Regards
> 
> /Gunnar
> 
>> 
>> Best regards
>> Michael
>>> Regards
>>> 
>>> Gunnar
>>> Gunnar Hellström
>>> Omnitor

---

From: Gunnar Hellstrom <[email-masked]>
Date: Tue, 08 Jul 2014 00:39:16 +0200

Thaks Michael,
You provide important additional information added to the section 6.7  
on transmission failure handling for the data-channel draft that I 
proposed below. I cannot find this information anywhere else, so I think 
it is important to provide it in the data-channel draft so that the W3C 
API authors can see what mechanisms are available and describe the API 
from that.

You say that the association breaks if a number of retries fail. But 
cannot the association contain both reliable and partially reliable 
channels? How would the decision logic to break the association because 
a number of failures be formed when there are different kinds of 
channels in the association? Or do I remember wrongly? Is there only one 
type of channels in an association.

You also say that both missed heartbeats and broken ICE connections may 
break the association. Where do you suggest that that combined behavior 
should be described? Also in the data-channel draft?

Thaks,

Gunnar

+46708204288

---

From: Barry Dingle <[email-masked]>
Date: Tue, 8 Jul 2014 13:58:20 +1000

I agree with the change to the Abstract in
draft-ietf-rtcweb-data-channel-10 (see below) as Michael proposed.

> Ten years from now, the RFC will exist, but the RTCWEB WG will not. I
suggest replacing "The Real-Time Communication in Web browsers working
group is charged to" with "The WebRTC framework specifies".
OK so it reads:
<t>*The WebRTC framework specifies protocol support for direct interactive*
* rich communication using audio, video, and data between two peers'
web-browsers.*

But there is great variety in the first introductory words in the abstracts
in the RTCWEB RFC's. Why not use the one agreed introduction in ALL RTCWEB
RFC's?

Michael's words seem to be appropriate for all.

Cheers,
/Barry Dingle

On Sat, Jul 5, 2014 at 3:23 AM, Michael Tuexen <
[email-masked]> wrote:

> concern to the broader IETF community.  This WGLC will end on June 27, 2014.
> >
> > Second: There are a number of details that should be fixed. Whether that
> happens before IETF Last Call or not is not of great concern to me.
> > Ten years from now, the RFC will exist, but the RTCWEB WG will not. I
> suggest replacing "The Real-Time Communication in Web browsers working
> group is charged to" with "The WebRTC framework specifies".
> OK so it reads:
> > In the WebRTC framework, communication between the parties consists of
> media (for example audio and video) and non-media data. Media is sent using
> SRTP, and is not specified further here. Non-media data is handled by...."
> Done. Good suggestion.
> >
> > I suggest a global replace of "non-SRTP media data" with "non-media
> data" (3 occurences total). "non-SRTP media data" can be parsed as "media
> data that is not carried over SRTP", which is not the intended meaning.
> Done.
> >
> > 4. Requirements
> >
> > Suggest striking "and that the WebRTC PeerConnection as a whole is fair
> with competing traffic such as TCP". The RMCAT discussions have proved how
> difficult it is just to define that, far less achieve it.
> > If we want to say something in relation to TCP, I would suggest "and
> that the WebRTC PeerConnection does not cause excessive problems when run
> in parallel with TCP connections".
> Taken.
> >
> > In the paragraph on SCTP multihoming, I suggest using "the DTLS layer"
> instead of "the lower layer". There are multiple lower layers, identifying
> which one is mentioned here improves clarity.
> OK.
> >
> > The term "user-land" is used here, while Req. 10 uses "user application
> space". I suggest using "user application space" in both places.
> OK.
> >
> > The paragraph "When using DTLS as the lower layer..." repeats the info
> that SCTP multihoming is not used. It may be enough to say this once.
> Taken out.
> >
> > "The partial reliability extension MUST support policies..." - this
> paragraph would be more implementable if specific policies, specified in an
> I-D or RFC, were referenced.
> References added.
> >
> > The split between section 5 and section 6 seems odd. In particular, the
> section "This SCTP stack and its upper layer...." down to "exactly once and
> delivered in the order received." seems to belong to section 6 not section
> 5.
> > As part of getting the WGs out of the document, the first sentence
> should be "The  WebRTC DataChannels are bidirectional."
> OK.
> > The SHOULD for -ndata- interleaving should be MUST implement and MUST
> offer. If it is not successfully negotiated at association setup time (is
> that how it works?), the "SHOULD limit" clause is appropriate.
> > Stream is defined in terms of stream, which is unhealthy. A reference to
> a section of a relevant SCTP document would be better.
> >
> > The term "SCTP stream" occurs at least 18 times in the document (out of
> approx 41 occurences of "stream" overall). We should either use "SCTP
> stream" consistently" or stick to "Stream" consistently.
> > The term "data channel" occurs 36 times. Consider standardizing on
> either Channel or Data Channel, and either capitalizing it or not.
> > "If a DATA_CHANNEL_OPEN message is received .... the stream identifier
> corresponds to the role of the peer" - is there a reason to insist that the
> protocol machine enforce the odd/even rule?
> > `(actually the next paragraph does not cover the odd/even rule violation
> case, which is probably just an unintentional mistake - I prefer writing
> this kind of thing in "IF <condition> ... ELSE ....
> >  - because if one writes it as "IF <condition>; IF <opposite
> condition>", the risk of losing some edge cases is high.
> >
> > An alternative formulation for the second paragraph is "If the
> DATA_CHANNEL_OPEN message doesn't satisfy the conditions above, for
> instance if..."
> Good point. I will use:
> > This protocol does not provide privacy, integrity or authentication. It
> needs to be used as part of a protocol suite that contains all these
> things. Such a protocol suite is specified in [-dtls-encaps].
> Taken.
> >
> > Dependency worries

---

From: Gunnar Hellstrom <[email-masked]>
Date: Tue, 08 Jul 2014 09:45:07 +0200

The w3c API specification is still very vague about error situations and 
how they are discovered and signaled. But there are some indications 
that it expects the rtcweb-data-protocol or rtcweb-data-channel 
specification to provide details.

In the API specification of the send() method at
http://dev.w3.org/2011/webrtc/editor/webrtc.html#dictionary-rtcdatachannelinit-members

Action point 5 under send() , it says:

"5. Attempt to senddataonchannel'sunderlying data transport 
<http://dev.w3.org/2011/webrtc/editor/webrtc.html#dfn-underlying-data-transport>; 
if the data cannot be sent, e.g. because it would need to be buffered 
but the buffer is full, the user agent/must/abruptly close 
<http://dev.w3.org/2011/webrtc/editor/webrtc.html#data-transport-closed>channel'sunderlying 
data transport 
<http://dev.w3.org/2011/webrtc/editor/webrtc.html#dfn-underlying-data-transport>with 
an error 
<http://dev.w3.org/2011/webrtc/editor/webrtc.html#data-transport-closed-error>."

The buffer-full reason for failure described is just an example. This 
opens for other reasons of failure. I think the rtcweb drafts should 
specify the reasons for failure that are under their control, (and the 
text in the API spec improved to give a better view of what reasons for 
failure there are. )

There is also an anomaly in the sentence. It says that " if the data 
cannot be sent, the user agent/must/abruptly close 
<http://dev.w3.org/2011/webrtc/editor/webrtc.html#data-transport-closed>channel'sunderlying 
data transport. 
<http://dev.w3.org/2011/webrtc/editor/webrtc.html#dfn-underlying-data-transport>
You say that if the channel is specified as partially reliable, failures 
to send will not be signaled and the channel will not be closed. These 
statements contradict each other. For this case, it might be the wording 
in the API specification that needs to be improved and specify that " if 
the channel was specified as reliable and the data cannot be sent.....".
But knowledge about what is expected from the channel and the 
association is needed to be able to specify this correctly.

I see a clear need for the rtcweb data channel specifications to specify 
the failure situations under their control or signaled by underlying 
transport.
Please use the new section 6.7 I provided as a proposal in this thread 
and refine it from your knowledge about the real behavior.

Regards

Gunnar

------------------------------------------------------------------------
Gunnar Hellström
Omnitor
[email-masked] 2014-07-08 00:39, Gunnar Hellstrom wrote:
> proposed below. I cannot find this information anywhere else, so I 
> think it is important to provide it in the data-channel draft so that 
> the W3C API authors can see what mechanisms are available and describe 
> the API from that.
>
> channels? How would the decision logic to break the association 
> because a number of failures be formed when there are different kinds 
> of channels in the association? Or do I remember wrongly? Is there 
> only one type of channels in an association.
>
> You also say that both missed heartbeats and broken ICE connections 
> may break the association. Where do you suggest that that combined 
> behavior should be described? Also in the data-channel draft?
>
> Thaks,
>
> Gunnar
>
>
>
>
>> On 05 Jul 2014, at 08:14, Gunnar Hellstrom<[email-masked]>  wrote:
>>
>>>> On 04 Jul 2014, at 23:23, Gunnar Hellstrom<[email-masked]>  wrote:
>>>>

---

From: Harald Alvestrand <[email-masked]>
Date: Tue, 08 Jul 2014 14:32:08 +0200

On 07/08/2014 05:58 AM, Barry Dingle wrote:
> > Ten years from now, the RFC will exist, but the RTCWEB WG will not. 
> I suggest replacing "The Real-Time Communication in Web browsers 
> working group is charged to" with "The WebRTC framework specifies".
> OK so it reads:
> *rich communication using audio, video, and data between two peers' 
> web-browsers.*
>
> But there is great variety in the first introductory words in the 
> abstracts in the RTCWEB RFC's. Why not use the one agreed introduction 
> in ALL RTCWEB RFC's?
>

I wouldn't mind having standard words in the abstract. It saves arguing.

The call for consensus to do so has to come from our chairs, but I'm 
willing to be part of the consensus (if the proposed text isn't too 
egregrious).

>
> Cheers,
> /Barry Dingle
>
>
>
> On Sat, Jul 5, 2014 at 3:23 AM, Michael Tuexen 
> <[email-masked] 
> <mailto:[email-masked]>> wrote:
>
>     On 27 Jun 2014, at 15:00, Harald Alvestrand <[email-masked]
>     <mailto:[email-masked]>> wrote:
>
>     >> Please review them in detail, especially for areas which may be
>     of concern to the broader IETF community.  This WGLC will end on
>     June 27, 2014.
>     >
>     > Second: There are a number of details that should be fixed.
>     Whether that happens before IETF Last Call or not is not of great
>     concern to me.
>     > Ten years from now, the RFC will exist, but the RTCWEB WG will
>     not. I suggest replacing "The Real-Time Communication in Web
>     browsers working group is charged to" with "The WebRTC framework
>     specifies".
>     OK so it reads:
>     > In the WebRTC framework, communication between the parties
>     consists of media (for example audio and video) and non-media
>     data. Media is sent using SRTP, and is not specified further here.
>     Non-media data is handled by...."
>     Done. Good suggestion.
>     >
>     > I suggest a global replace of "non-SRTP media data" with
>     "non-media data" (3 occurences total). "non-SRTP media data" can
>     be parsed as "media data that is not carried over SRTP", which is
>     not the intended meaning.
>     Done.
>     >
>     > 4. Requirements
>     >
>     > Suggest striking "and that the WebRTC PeerConnection as a whole
>     is fair with competing traffic such as TCP". The RMCAT discussions
>     have proved how difficult it is just to define that, far less
>     achieve it.
>     > If we want to say something in relation to TCP, I would suggest
>     "and that the WebRTC PeerConnection does not cause excessive
>     problems when run in parallel with TCP connections".
>     Taken.
>     >
>     > In the paragraph on SCTP multihoming, I suggest using "the DTLS
>     layer" instead of "the lower layer". There are multiple lower
>     layers, identifying which one is mentioned here improves clarity.
>     OK.
>     >
>     > The term "user-land" is used here, while Req. 10 uses "user
>     application space". I suggest using "user application space" in
>     both places.
>     OK.
>     >
>     > The paragraph "When using DTLS as the lower layer..." repeats
>     the info that SCTP multihoming is not used. It may be enough to
>     say this once.
>     Taken out.
>     >
>     > "The partial reliability extension MUST support policies..." -
>     this paragraph would be more implementable if specific policies,
>     specified in an I-D or RFC, were referenced.
>     References added.
>     >
>     > The split between section 5 and section 6 seems odd. In
>     particular, the section "This SCTP stack and its upper layer...."
>     down to "exactly once and delivered in the order received." seems
>     to belong to section 6 not section 5.
>     > As part of getting the WGs out of the document, the first
>     sentence should be "The  WebRTC DataChannels are bidirectional."
>     OK.
>     > The SHOULD for -ndata- interleaving should be MUST implement and
>     MUST offer. If it is not successfully negotiated at association
>     setup time (is that how it works?), the "SHOULD limit" clause is
>     appropriate.
>     > Is there a security worry with an attacker sending over-long
>     messages in an attempt to cause OOM situations?
>     OK, I added:
>     > Stream is defined in terms of stream, which is unhealthy. A
>     reference to a section of a relevant SCTP document would be better.
>     >
>     > The term "SCTP stream" occurs at least 18 times in the document
>     (out of approx 41 occurences of "stream" overall). We should
>     either use "SCTP stream" consistently" or stick to "Stream"
>     consistently.
>     > The term "data channel" occurs 36 times. Consider standardizing
>     on either Channel or Data Channel, and either capitalizing it or not.
>     > "If a DATA_CHANNEL_OPEN message is received .... the stream
>     identifier corresponds to the role of the peer" - is there a
>     reason to insist that the protocol machine enforce the odd/even rule?
>     > `(actually the next paragraph does not cover the odd/even rule
>     violation case, which is probably just an unintentional mistake -
>     I prefer writing this kind of thing in "IF <condition> ... ELSE ....
>     DATA_CHANNEL_OPEN message doesn't satisfy the conditions above,
>     for instance if..."
>     Good point. I will use:
>     procedure described in <xref
>     target='I-D.ietf-rtcweb-data-channel'/> and
>     > This protocol does not provide privacy, integrity or
>     authentication. It needs to be used as part of a protocol suite
>     that contains all these things. Such a protocol suite is specified
>     in [-dtls-encaps].
>     Taken.
>     >
>     > Dependency worries
>     > [email-masked] <mailto:[email-masked]>
>     [email-masked] <mailto:[email-masked]>

---

From: Gunnar Hellstrom <[email-masked]>
Date: Thu, 24 Jul 2014 20:23:37 +0200

Michael said below:
"So I think the only thing not covered is what to do if the SCTP 
association fails, but it is obvious to me that all channels are gone. 
Do we need to state that explicitly? What do others think?"

I have not seen any response. I think it belongs to a complete 
specification to cover error situations.
You say that all channels are gone in an error situation. How do you 
define "gone". Who will get an indication and what cleaning up is needed?

I still think a good chapter on error handling is needed, both in the 
API speciifcation and in the data-channel specification. Even if there 
are mechanisms for part of this error handling in SCTP, I think that the 
data-channel specification should tell how the error situations 
influence rtcweb data channels..

I have seen developers wondering in discussion groups why the WebRTC 
channels often get disconnected when they should be reliable. But that 
is in the definition of "reliable", that when all (about 5)  retries are 
done  or any of the timeout mechanisms expire, the association breaks up 
and channels disappear. And from your answers, I get that also the 
partially reliable type of channels will be gone if either the 
association watchdog or the ICE connectivity check fails but not if just 
the configured retransmission limit is reached. I cannot find any 
summary of these mechanisms, so it is just from your responses that I 
have learnt to know them vaguely.

I have earlier proposed some wordings for the data-channel draft. Can it 
be picked up, corrected and inserted into the specification?   ( same 
for the API, and it would be good to coordinate the additions. )

Regards

Gunnar

---

From: Barry Dingle <[email-masked]>
Date: Sat, 26 Jul 2014 15:42:15 +1000

I agree that error handling is missing from draft-ietf-rtcweb-data-channel.

WebRTC 1.0 does not reference SCTP. It only references the
draft-ietf-rtcweb-data-channel.

*SCTP* (RFC 4960) Section '10.2 SCTP-to-ULP' describes the signals that are
sent from the SCTP to the Upper Layer Protocol. There are 8 Notifications
including 'DATA ARRIVE', 'NETWORK STATUS CHANGE', 'COMMUNICATION ERROR'.

We need to indicate in draft-ietf-rtcweb-data-channel how the 'Error
signals' are passed from SCTP to WebRTC 1.0. In addition, WebRTC 1.0 needs
a new Section "5.4 Error Handling" (before the existing Garbage Collection)
that is similar in style to Section "4.6 Error Handling" (of
RTCPeerConnection).

Gunnar - Can you repeat your suggested text additions to
draft-ietf-rtcweb-data-channel as there was some discussion relating to it?

Once we have some agreed draft-ietf-rtcweb-data-channel text, then we can
get some action on WebRTC 1.0.

Cheers,
/Barry Dingle

On Fri, Jul 25, 2014 at 4:23 AM, Gunnar Hellstrom <
[email-masked]> wrote:

> association fails, but it is obvious to me that all channels are gone. Do
> we need to state that explicitly? What do others think?"
>
> I still think a good chapter on error handling is needed, both in the API
> speciifcation and in the data-channel specification. Even if there are
> mechanisms for part of this error handling in SCTP, I think that the
> data-channel specification should tell how the error situations influence
> rtcweb data channels..
>
> channels often get disconnected when they should be reliable. But that is
> in the definition of "reliable", that when all (about 5)  retries are done
> or any of the timeout mechanisms expire, the association breaks up and
> channels disappear. And from your answers, I get that also the partially
> reliable type of channels will be gone if either the association watchdog
> or the ICE connectivity check fails but not if just the configured
> retransmission limit is reached. I cannot find any summary of these
> mechanisms, so it is just from your responses that I have learnt to know
> them vaguely.
>
> be picked up, corrected and inserted into the specification?   ( same for
> the API, and it would be good to coordinate the additions. )
>
> Regards
>
> Gunnar
>
>
>
>
>
>
>
>
>
>
>  ------------------------------
> Gunnar Hellström
> Omnitor
> On 05 Jul 2014, at 08:14, Gunnar Hellstrom <[email-masked]> <[email-masked]> wrote:
>
>
>  On 04 Jul 2014, at 23:23, Gunnar Hellstrom <[email-masked]> <[email-masked]> wrote:
>
>
> [email-masked]
> [email-masked]://www.ietf.org/mailman/listinfo/rtcweb
>
> rtcweb mailing [email-masked]://www.ietf.org/mailman/listinfo/rtcweb
>
>
>

---

From: Michael Tuexen <[email-masked]>
Date: Sat, 26 Jul 2014 08:18:26 +0200

On 24 Jul 2014, at 20:23, Gunnar Hellstrom <[email-masked]> wrote:

> Michael said below:
> "So I think the only thing not covered is what to do if the SCTP association fails, but it is obvious to me that all channels are gone. Do we need to state that explicitly? What do others think?"
> 
> I have not seen any response. I think it belongs to a complete specification to cover error situations.
> You say that all channels are gone in an error situation. How do you define "gone". Who will get an indication and what cleaning up is needed?
What I mean by all channels are gone is that the association has been terminated,
either graceful or not. However, there is no graceful shutdown of the association
been specified for WebRTC, so this only applies to the case where the peer is not
reachable anymore. That is why I use the term gone...
> 
> I still think a good chapter on error handling is needed, both in the API speciifcation and in the data-channel specification. Even if there are mechanisms for part of this error handling in SCTP, I       think that the data-channel specification should tell how the error situations influence rtcweb data channels..
Again: If the association fails, all data channels fail and should get whatever onError
is appropriate, but that is an API issue and needs to be specified by W3C.
> 
> I have seen developers wondering in discussion groups why the WebRTC channels often get disconnected when they should be reliable. But that is in the definition of "reliable", that when all (about 5)  retries are done  or any of the timeout mechanisms expire, the association breaks up and channels disappear. And from your answers, I get that also the partially reliable type of 
I wouldn't expect 5, but 10. See
http://tools.ietf.org/html/draft-ietf-tsvwg-sctp-dtls-encaps-05#section-6.1
and
http://tools.ietf.org/html/rfc4960#section-15
> channels will be gone if either the association watchdog or the ICE connectivity check fails but not if just the configured retransmission limit is reached. I cannot find any summary of these 
And that is correct. If you send a message on an unreliable channel with let's say 2
retransmissions, a message will be abandoned after two retransmissions, but the channel stays
alive.

Best regards
Michael
> mechanisms, so it is just from your responses that I have learnt to know them vaguely.
> 
> I have earlier proposed some wordings for the data-channel draft. Can it be picked up, corrected and inserted into the specification?   ( same for the API, and it would be good to coordinate the additions. ) 
> 
> Regards
> 
> Gunnar
> 
> 
> 
> 
>     
> 
> 
> 
> 
> 
> Gunnar Hellström
> Omnitor

---

From: Michael Tuexen <[email-masked]>
Date: Sat, 26 Jul 2014 08:19:56 +0200

On 26 Jul 2014, at 07:42, Barry Dingle <[email-masked]> wrote:

> WebRTC 1.0 does not reference SCTP. It only references the draft-ietf-rtcweb-data-channel. 
> 
> SCTP (RFC 4960) Section '10.2 SCTP-to-ULP' describes the signals that are sent from the SCTP to the Upper Layer Protocol. There are 8 Notifications including 'DATA ARRIVE', 'NETWORK STATUS CHANGE', 'COMMUNICATION ERROR'. 
> 
> We need to indicate in draft-ietf-rtcweb-data-channel how the 'Error signals' are passed from SCTP to WebRTC 1.0. In addition, WebRTC 1.0 needs a new Section "5.4 Error Handling" (before the existing Garbage Collection) that is similar in style to Section "4.6 Error Handling" (of RTCPeerConnection). 
Again: This is an API issue and needs to be discussed in the W3C document. Whatever signal
you want to provide to the JS application needs to be specified there.
This is at least what I think... 

Best regards
Michael
> 
> Gunnar - Can you repeat your suggested text additions to draft-ietf-rtcweb-data-channel as there was some discussion relating to it? 
> 
> Once we have some agreed draft-ietf-rtcweb-data-channel text, then we can get some action on WebRTC 1.0. 
> 
> Cheers,
> /Barry Dingle
> 
> 
> 
> On Fri, Jul 25, 2014 at 4:23 AM, Gunnar Hellstrom <[email-masked]> wrote:
> Michael said below:
> I have seen developers wondering in discussion groups why the WebRTC channels often get disconnected when they should be reliable. But that is in the definition of "reliable", that when       all (about 5)  retries are done  or any of the timeout mechanisms expire, the association breaks up and channels disappear. And from your answers, I get that also the partially reliable type of channels will be gone if either the association watchdog or the ICE connectivity check fails but not if just the configured retransmission limit is reached. I cannot find any summary of these mechanisms, so it is just from your responses that I have learnt to know them vaguely.
>