Subject: [rtcweb] RETRACTION: Last Call: <draft-ietf-rtcweb-data-channel-11.txt> (WebRTC Data Channels) to Proposed Standard

From: IESG Secretary <[email-masked]>
Date: Mon, 11 Aug 2014 11:13:57 -0700

The IESG would like to retract the current Last Call on the following 
document:

- 'WebRTC Data Channels'
  <draft-ietf-rtcweb-data-channel-11.txt> as Proposed Standard

The document's state has been set back to "AD Evaluation."

---

From: Gunnar Hellstrom <[email-masked]>
Date: Sat, 16 Aug 2014 08:44:35 +0200

We have discussed the lack of description of failure handling in 
draft-ietf-rtcweb-data-channel a couple of times.

Explanations of mechanisms have been provided in mail answers that I 
have not seen documented elsewhere, but they have not been introduced in 
the draft.

I think that for specification and implementation of the WebRTC API, 
there is a need for clear specification how the channels behave in 
failure situations.

I suggest to insert a new chapter 6.7 in the draft with the following 
contents.

-------------------------------------------------------------------Proposed 
new section 
6.7-------------------------------------------------------------------------------------------
6.7 Transmission failure and error handling

Failures can occur in an open channel by transmission error detection 
and by SCTP watchdog error indications.
If transmission in a reliable channel fails, the association where the 
channel belongs will be aborted. If all retries for a watchdog expires, 
the corresponding association will be aborted.  All channels in an 
association that is aborted because of errors need to be closed by the 
party detecting the failure. Network error indications shall be provided 
to upper layers on all closed channels.

If retransmissions or transmission time is exceeded in a partially 
reliable channel, the transmission SHALL be allowed to continue with 
other data items. A transmission error indication SHALL be provided to 
upper layers on that channel.

If reception out-of order is detected from an SCTP channel for which 
ordered transmission is requested, the receiver SHALL close the data 
channel, and provide an transmission error indication to upper layers.

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 
proposal---------------------------------------------------------------------------------------------------------------

I am not sure about what the two last kinds of errors should result in 
and hope that the experts can adjust the wording.

Regards

Gunnar
------------------------------------------------------------------------
Gunnar Hellström
Omnitor
[email-masked]

---

From: Barry Dingle <[email-masked]>
Date: Sat, 16 Aug 2014 22:01:00 +1000

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

Should the 'error' indications' in the proposed text be more specific? That
is, should the error indications indicate the type of error. (The same
error indication for all errors could be sent and be compliant with the
currently proposed text.)

Note - I assume that you are proposing adding the new Section 6.7 to
draft-ietf-rtcweb-data-channel-11 . It already has a Section 6.7 titled
"Closing a channel". I assume you mean a new Section 6.8.

Cheers,
/Barry Dingle

On Sat, Aug 16, 2014 at 4:44 PM, Gunnar Hellstrom <
[email-masked]> wrote:

> Explanations of mechanisms have been provided in mail answers that I have
> not seen documented elsewhere, but they have not been introduced in the
> draft.
>
> I think that for specification and implementation of the WebRTC API, there
> is a need for clear specification how the channels behave in failure
> situations.
>
> Failures can occur in an open channel by transmission error detection and
> by SCTP watchdog error indications.
> channel belongs will be aborted. If all retries for a watchdog expires, the
> corresponding association will be aborted.  All channels in an association
> that is aborted because of errors need to be closed by the party detecting
> the failure. Network error indications shall be provided to upper layers on
> all closed channels.
>
> reliable channel, the transmission SHALL be allowed to continue with other
> data items. A transmission error indication SHALL be provided to upper
> layers on that 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.
> I am not sure about what the two last kinds of errors should result in and
> hope that the experts can adjust the wording.
>
> Regards
>
> Gunnar
>  ------------------------------
> Gunnar Hellström
> Omnitor
> _______________________________________________
> rtcweb mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/rtcweb
>
>

---

From: Gunnar Hellstrom <[email-masked]>
Date: Sat, 16 Aug 2014 15:25:28 +0200

On 2014-08-16 14:01, Barry Dingle wrote:
> I agree that error handling is missing from 
> draft-ietf-rtcweb-data-channel .
>
> Should the 'error' indications' in the proposed text be more specific? 
> That is, should the error indications indicate the type of error. (The 
> same error indication for all errors could be sent and be compliant 
> with the currently proposed text.)
Yes, possibly more detailed failure cause information is beneficial. But 
this needs to be matched against the ambitions of the WebRTC API to be 
as similar as possible to the Websocket API.
And the Websocket API groups many error reasons into one error 
indication because of security risks.
See http://dev.w3.org/html5/websockets/

Maintenance and debugging might be hard without further refinement of 
error causes, while security is better with less specific information. A 
balanced proposal would be needed.

A specific improvement would be to indicate if it is the sending side or 
the receiving side or both that will get an error indication.

I have not seen the association concept in the WebRTC API. So, it seems 
that the association concept will be hidden in the implementation 
between the WebRTC API and the SCTP, because in interaction with SCTP, 
it is important to know when a new association needs to be opened, and 
when just a new channel can be opened in an existing association. The 
effect of the abortion of the association also needs to be understood by 
that layer and translated into separate rtcDataChannel API actions.

One further note: I have assumed that ICE connectivity failures is 
handled separately by the WebRTC API implementation and will cause both 
indications to API users and to the RTCweb data channel implementations. 
Is that right?

> draft-ietf-rtcweb-data-channel-11 . It already has a Section 6.7 
> titled "Closing a channel". I assume you mean a new Section 6.8.
Right, thanks.
>
> Cheers,
> /Barry Dingle
>
>
>
>
> On Sat, Aug 16, 2014 at 4:44 PM, Gunnar Hellstrom 
> <[email-masked] <mailto:[email-masked]>> wrote:
>
>     Explanations of mechanisms have been provided in mail answers that
>     I have not seen documented elsewhere, but they have not been
>     introduced in the draft.
>
>     I think that for specification and implementation of the WebRTC
>     API, there is a need for clear specification how the channels
>     behave in failure situations.
>
>     I suggest to insert a new chapter 6.7 in the draft with the
>     following contents.
>
>     Failures can occur in an open channel by transmission error
>     detection and by SCTP watchdog error indications.
>     If transmission in a reliable channel fails, the association where
>     the channel belongs will be aborted. If all retries for a watchdog
>     expires, the corresponding association will be aborted.  All
>     channels in an association that is aborted because of errors need
>     to be closed by the party detecting the failure. Network error
>     indications shall be provided to upper layers on all closed channels.
>
>     reliable channel, the transmission SHALL be allowed to continue
>     with other data items. A transmission error indication SHALL be
>     provided to upper layers on that channel.
>
>     If reception out-of order is detected from an SCTP channel for
>     which ordered transmission is requested, the receiver SHALL close
>     the data channel, and provide an transmission error indication to
>     upper layers.
>
>     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.
>     I am not sure about what the two last kinds of errors should
>     result in and hope that the experts can adjust the wording.
>
>     Regards
>
>     Gunnar
>     [email-masked] <mailto:[email-masked]>
>
>     [email-masked] <mailto:[email-masked]>

---

From: Harald Alvestrand <[email-masked]>
Date: Mon, 18 Aug 2014 10:30:18 +0200

On 08/16/2014 03:25 PM, Gunnar Hellstrom wrote:
>> Should the 'error' indications' in the proposed text be more 
>> specific? That is, should the error indications indicate the type of 
>> error. (The same error indication for all errors could be sent and be 
>> compliant with the currently proposed text.)
> Yes, possibly more detailed failure cause information is beneficial. 
> But this needs to be matched against the ambitions of the WebRTC API 
> to be as similar as possible to the Websocket API.
> error causes, while security is better with less specific information. 
> A balanced proposal would be needed.

The need for debugging is handled by advice on what information needs to 
be in the "message" part of the error indication.

If there is a need for consistent action to be taken by applications, I 
think that needs to be in the "name" part - that is, different errors - 
or in additional information passed in the error.

>
> A specific improvement would be to indicate if it is the sending side 
> or the receiving side or both that will get an error indication.
>
> I have not seen the association concept in the WebRTC API. So, it 
> seems that the association concept will be hidden in the 
> implementation between the WebRTC API and the SCTP, because in 
> interaction with SCTP, it is important to know when a new association 
> needs to be opened, and when just a new channel can be opened in an 
> existing association. The effect of the abortion of the association 
> also needs to be understood by that layer and translated into separate 
> rtcDataChannel API actions.
>
> handled separately by the WebRTC API implementation and will cause 
> both indications to API users and to the RTCweb data channel 
> implementations. Is that right?

I can't parse this in terms that fit my implementation - there is no 
distinction between the "RTCweb data channel implementation" and "the 
WebRTC API implementation" - it's all the WebRTC implementation, and 
there is no distinction that can be surfaced.

What's the change that needs to be there?

>>     Explanations of mechanisms have been provided in mail answers
>>     that I have not seen documented elsewhere, but they have not been
>>     introduced in the draft.
>>
>>     If transmission in a reliable channel fails, the association
>>     where the channel belongs will be aborted. If all retries for a
>>     watchdog expires, the corresponding association will be aborted. 
>>     All channels in an association that is aborted because of errors
>>     need to be closed by the party detecting the failure. Network
>>     error indications shall be provided to upper layers on all closed
>>     channels.
>>
>>     If retransmissions or transmission time is exceeded in a
>>     partially reliable channel, the transmission SHALL be allowed to
>>     continue with other data items. A transmission error indication
>>     SHALL be provided to upper layers on that channel.
>>

---

From: Harald Alvestrand <[email-masked]>
Date: Mon, 18 Aug 2014 13:15:41 +0200

Picking up a single point....

> corresponding data channel.

This struct me when thinking about the zero-length-data proposal: If we 
ever want to add another such feature *without* explicitly negotiating 
the use of the feature at setup time, we can't do this.

If we want the possibility of un-negotiated extensions, we HAVE to say 
(somewhere)

   If a message with an unsupported PPID is received, it is silently 
ignored.

OTOH, if we're convinced we never need that kind of extensibility, any 
way we do this is fine.

              Harald

---

From: Gunnar Hellstrom <[email-masked]>
Date: Mon, 18 Aug 2014 13:23:44 +0200

On 2014-08-18 13:15, Harald Alvestrand wrote:
> This struct me when thinking about the zero-length-data proposal: If 
> we ever want to add another such feature *without* explicitly 
> negotiating the use of the feature at setup time, we can't do this.
>
[GH] That sounds wise, and also in line with the security aspects that 
make Websocket be very conservative about signaling errors and their 
reasons. WebRTC data channels have the ambition to be similar.
/Gunnar

---

From: Gunnar Hellstrom <[email-masked]>
Date: Mon, 18 Aug 2014 13:56:37 +0200

On 2014-08-18 10:30, Harald Alvestrand wrote:
>>> error. (The same error indication for all errors could be sent and 
>>> be compliant with the currently proposed text.)
>> error causes, while security is better with less specific 
>> information. A balanced proposal would be needed.
>
> The need for debugging is handled by advice on what information needs 
> to be in the "message" part of the error indication.
>
> If there is a need for consistent action to be taken by applications, 
> I think that needs to be in the "name" part - that is, different 
> errors - or in additional information passed in the error.
There are at least the following reasons:

1. Sending seems to have failed ( you do not know, it might be the 
feedback that failed and the receiver got the message ).

2. Transport aborted because of network errors. (transmission retry 
limit exceeded on a reliable channel in the association, or a watchdog 
expired )

( further  error causes appear in the WebRTC API, such as buffer full 
when requesting SEND )

>> also needs to be understood by that layer and translated into 
>> separate rtcDataChannel API actions.
>>
Probably none for the lack of the Association concept on the application 
level.
Below the API, the implementation need to keep track of the association 
and all channels using that association, so that a new association is 
requested only when the old has been aborted.

For the ICE connectivity failure, I want to know if my assumption is 
right that the ICE connectivity and its indications of failing 
connectivity are handled by separate API elements, so that it is the 
application that needs to request closing of channels when ICE 
connectivity fails,   while for retransmission excess and connection 
watchdog failures the association will be aborted by underlaying levels, 
and closing with error will be signaled on all channels in that 
association from lower layer.

Therefore, I have not mentioned failing ICE connectivity in the comments 
to rtcweb-data-channel. If the assumption is wrong, failing ICE 
connectivity should be added to the reasons for the association to be 
aborted in the rtcweb-data-channel draft.

/Gunnar

>
>
>>
>>
>>>
>>> Note - I assume that you are proposing adding the new Section 6.7 
>>> to  draft-ietf-rtcweb-data-channel-11 . It already has a Section 6.7 
>>>     that I have not seen documented elsewhere, but they have not
>>>     been introduced in the draft.
>>>
>>>     error indications shall be provided to upper layers on all
>>>     closed channels.
>>>
>>>     which ordered transmission is requested, the receiver SHALL
>>>     close the data channel, and provide an transmission error
>>>     indication to upper layers.
>>>
>>>     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.

---

From: "Makaraju, Maridi Raju (Raju)" <[email-masked]>
Date: Mon, 18 Aug 2014 12:03:04 +0000

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.

<Raju/> This is one of the interop concern I expressed on using EMPTY PPID without negotiating it. </Raju>

This struct me when thinking about the zero-length-data proposal: If we ever want to add another such feature *without* explicitly negotiating the use of the feature at setup time, we can't do this.
<Raju> Right. I am in favor of explicitly negotiating such new PPIDs. </Raju>

If we want the possibility of un-negotiated extensions, we HAVE to say (somewhere)

  If a message with an unsupported PPID is received, it is silently ignored.

OTOH, if we're convinced we never need that kind of extensibility, any way we do this is fine.
<Raju> Silently dropping these "unknown" PPIDs may have issues like the sender may "assume" the msg is "accepted" by the receiver, especially for the EMPTY_PPID kind of use case where there is no response required. Also, at the receiving side an "unknown" PPID might  have been received due to an error at the sending side (rather than transit). In such error cases it is better to drop the call rather than "limp along". Having an explicit negotiation allows the implementation to take an informed decision.
Sorry to keep going back, but the earlier proposal I made about OOB PPID may solve this issue by allowing user to negotiate an additional OOB PPID.
The same mechanism can be extended to allow users to define and use arbitrary PPIDs. I am aware that this complicates the spec/API further, but listing it here for completeness and further discussion.
</Raju>
BR
Raju

             Harald

---

From: "Makaraju, Maridi Raju (Raju)" <[email-masked]>
Date: Mon, 18 Aug 2014 12:12:22 +0000

From: rtcweb [mailto:[email-masked]] On Behalf Of Gunnar Hellstrom
Sent: Monday, August 18, 2014 6:24 AM

  If a message with an unsupported PPID is received, it is silently ignored.
[GH] That sounds wise, and also in line with the security aspects that make Websocket be very conservative about signaling errors and their reasons. WebRTC data channels have the ambition to be similar.
/Gunnar
<Raju>
Per the following excerpts from websocket RFC, if an "unknown" opcode is received then the connection fails. I think PPID is same level as Opcode (websocket binary and text data are represented as 2 opcodes). Did I miss something?
5.2<http://tools.ietf.org/html/rfc6455#section-5.2>.  Base Framing Protocol

Opcode:  4 bits

      Defines the interpretation of the "Payload data".  If an unknown
      opcode is received, the receiving endpoint MUST _Fail the
      WebSocket Connection_.  The following values are defined.

</Raju>

BR
Raju

             Harald

rtcweb mailing list

[email-masked]<mailto:[email-masked]>

---

From: Martin Thomson <[email-masked]>
Date: Mon, 18 Aug 2014 09:49:54 -0700

> OTOH, if we're convinced we never need that kind of extensibility, any way

I think that I want that kind of extensibility.  People who care about
secure text and files might also.

---

From: Michael Tuexen <[email-masked]>
Date: Tue, 26 Aug 2014 22:26:18 +0200

On 16 Aug 2014, at 08:44, Gunnar Hellstrom <[email-masked]> wrote:

> We have discussed the lack of description of failure handling in draft-ietf-rtcweb-data-channel a couple of times.
> 
> Explanations of mechanisms have been provided in mail answers that I have not seen documented elsewhere, but they have not been introduced in the draft.
> 
> I think that for specification and implementation of the WebRTC API, there is a need for clear specification how the channels behave in failure situations.
> 
> I suggest to insert a new chapter 6.7 in the draft with the following contents.  
Hi Gunnar,

see my comments in-line.

Best regards
Michael
> 
> -------------------------------------------------------------------Proposed new section 6.7-------------------------------------------------------------------------------------------
> Failures can occur in an open channel by transmission error detection and by SCTP watchdog error indications.
> If transmission in a reliable channel fails, the association where the channel belongs will be aborted. If all retries for a watchdog expires, the corresponding association will be aborted.  All channels in an association that is aborted because of errors need to be closed by the party detecting the failure. Network error indications shall be provided to upper layers on all closed channels.
I think we could change Section
6.2.  Association Setup
to
6.2.  Association Handling
and state there that if an association is terminated, for example due to error cases, all data channels are closed.
> 
> If retransmissions or transmission time is exceeded in a partially reliable channel, the transmission SHALL be allowed to continue with other data items. A transmission error indication SHALL be provided to upper layers on that channel. 
I think the handling of the PR-SCTP stuff is clear. Whether this should be exposed in the API is a W3C issue, I think.
> 
> If reception out-of order is detected from an SCTP channel for which ordered transmission is requested, the receiver SHALL close the data channel, and provide an transmission error indication to upper layers.  
I think we discussed this at the IETF and the conclusion was that this kind of check is not done.
> 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 text is already in Section 6.6.
> -----------------------------------------------------------------------end of proposal---------------------------------------------------------------------------------------------------------------

> 
> I am not sure about what the two last kinds of errors should result in and hope that the experts can adjust the wording.
> 
> Regards
> 
> Gunnar
> Gunnar Hellström
> Omnitor

---

From: Michael Tuexen <[email-masked]>
Date: Tue, 26 Aug 2014 22:26:58 +0200

On 16 Aug 2014, at 14:01, Barry Dingle <[email-masked]> wrote:

> I agree that error handling is missing from draft-ietf-rtcweb-data-channel . 
> 
> Should the 'error' indications' in the proposed text be more specific? That is, should the error indications indicate the type of error. (The same error indication for all errors could be sent and be compliant with the currently proposed text.) 
There is no way in transporting an error indication...

Best regards
Michael
> 
> Note - I assume that you are proposing adding the new Section 6.7 to  draft-ietf-rtcweb-data-channel-11 . It already has a Section 6.7 titled "Closing a channel". I assume you mean a new Section 6.8. 
> 
> Cheers,
> /Barry Dingle
> 
> 
> 
> 
> On Sat, Aug 16, 2014 at 4:44 PM, Gunnar Hellstrom <[email-masked]> wrote:

---

From: Michael Tuexen <[email-masked]>
Date: Tue, 26 Aug 2014 22:36:34 +0200

> OTOH, if we're convinced we never need that kind of extensibility, any way we do this is fine.
Harald,

I think it is important to specify how unsupported PPIDs handled. Either close the data channel
or ignore the message.

What I don't understand how ignoring gives you extensibility. If one sides sends a new PPID, and
the other sides ignores it, the sender (at the SCTP level) thinks that the message was received
without any problem, since SCTP doesn't take the PPID into account. So user messages are lost.

Best regards
Michael

---

From: Martin Thomson <[email-masked]>
Date: Tue, 26 Aug 2014 14:22:11 -0700

> without any problem, since SCTP doesn't take the PPID into account. So user messages are lost.

I think that the use of a new PPID can be negotiated prior to use, so
there aren't big problems with any action recommended here.  Resetting
the stream might work, assuming that we can distinguish between an
error and a graceful close correctly, that is.

---

From: Gunnar Hellstrom <[email-masked]>
Date: Tue, 26 Aug 2014 23:23:15 +0200

>> I suggest to insert a new chapter 6.7 in the draft with the following contents.
Hi Michael
and see my answers in-line
> and state there that if an association is terminated, for example due to error cases, all data channels are closed.
I meant 6.8.
I think a failure section is better placed after all sections on 
opening, closing and data transfer. Then it starts to be clear to the 
reader what can go wrong.
And I think failure handling is so important that it is worth having a 
section on its own with a heading that can be found in the contents.

When you say that all data channels are closed, can you then also tell 
how that is indicated to the application.

I also think that the basic reasons for Association termination by error 
should be explained briefly in the data-channel specification, so that 
the reader does not need to dig through the SCTP RFC to try to find 
them.  The watchdog failures and the exess retries in reliable channels, 
etc.   I cannot understand why you want to avoid explaining the mechanisms.
> I think the handling of the PR-SCTP stuff is clear. Whether this should be exposed in the API is a W3C issue, I think.
I do not think it is clear. It merely mentions the names of the types of 
channels. The failure cases need also to be described.
And, it is a case for the API description and the data-channel spec to 
be aligned. What the W3C API spec specify will happen in case of failure 
needs to be supported by the data-channel spec. I have made proposals to 
WebRTC as well. Please align.
> I think we discussed this at the IETF and the conclusion was that this kind of check is not done.
Well, why not describe what happens, so that further questions or 
misunderstandings are avoided?  You mean that what SCTP provides is also 
what the data-channel provides.

> This text is already in Section 6.6.
Yes, there is a paragraph saying:
"

    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.
"
Since my proposal was to create a separate failure handling section 6.8, my proposal would be to move all failure descriptions to
6.8, also the ones from 6.6.

A question: You usually say that the Association is aborted in case of error and all its channels closed.
But here it is said that just the channel is closed.  Please clarify.

Regards
/Gunnar

---

From: Michael Tuexen <[email-masked]>
Date: Tue, 26 Aug 2014 23:41:30 +0200

> error and a graceful close correctly, that is.
You can't. It is just closed, there is error indication included.

Best regards
Michael

---

From: Paul Kyzivat <[email-masked]>
Date: Tue, 26 Aug 2014 17:44:36 -0400

> error and a graceful close correctly, that is.

There isn't currently any way to distinguish graceful close from a reset 
due to error is there?

PPID 50 is currently being used just for DATA_CHANNEL_OPEN and 
Data_CHANNEL_ACK. But the message format has made provision for 512 
different message types. Some others could be used, now or in the 
future, for other housekeeping, such as giving a reason for a reset.

One approach would be to define DATA_CHANNEL_CLOSE, and specify that it 
be used just before reset when the close is graceful.

	Thanks,
	Paul

---

From: Martin Thomson <[email-masked]>
Date: Tue, 26 Aug 2014 15:01:00 -0700

On 26 August 2014 14:44, Paul Kyzivat <[email-masked]> wrote:
> One approach would be to define DATA_CHANNEL_CLOSE, and specify that it be
> used just before reset when the close is graceful.

Or define a DATA_CHANNEL_ERROR, which would let you explain why.
Assuming that SCTP doesn't suffer from the same problems TCP does with
sending just prior to a close.

---

From: Michael Tuexen <[email-masked]>
Date: Wed, 27 Aug 2014 13:07:41 +0200

On 26 Aug 2014, at 23:44, Paul Kyzivat <[email-masked]> wrote:

> There isn't currently any way to distinguish graceful close from a reset due to error is there?
> 
> PPID 50 is currently being used just for DATA_CHANNEL_OPEN and Data_CHANNEL_ACK. But the message format has made provision for 512 different message types. Some others could be used, now or in the future, for other housekeeping, such as giving a reason for a reset.
> 
> One approach would be to define DATA_CHANNEL_CLOSE, and specify that it be used just before reset when the close is graceful.
What you are suggesting is to use the Data Channel Establishment Protocol also
for error signalling... This doesn't fit since for the error it doesn't matter
whether the channel was established with DCEP or by any other mechanism.

The way would be to define error messages with a different PPID and define the
message format. If I remember it correctly, we discussed this at an IETF meeting
and the conclusion was to not have such messages...
Is the WG now changing its mind? After WG LC?

Best regards
Michael

---

From: Michael Tuexen <[email-masked]>
Date: Wed, 27 Aug 2014 13:09:31 +0200

> Or define a DATA_CHANNEL_ERROR, which would let you explain why.
This would require defining a simple packet format and register a PPID for
it. However, this was discussed in the past and the result was that no
error messages were wanted... Is this conclusion not valid anymore?
> sending just prior to a close.
What TCP problems are you referring to?

Best regards
Michael

---

From: Harald Alvestrand <[email-masked]>
Date: Wed, 27 Aug 2014 13:16:50 +0200

> error and a graceful close correctly, that is.

If there is negotiation, there is no problem.

If there is no negotiation, starting to use the new feature will either 
lead to ignored messages or lead to a crashed connection.

Ignored messages are not a problem if they form part of an ignorable 
extension (for instance if someone decided to once in a while send 
checksums over all the data sent so far - doesn't matter to those that 
don't understand it, since it doesn't carry any extra data).

Crashed connections are usually a problem, so that will mean "no 
unnegotiated extensions, ever".

I'm happy with either way of doing it, as long as we're explicit about it.

---

From: "Makaraju, Maridi Raju (Raju)" <[email-masked]>
Date: Wed, 27 Aug 2014 11:38:55 +0000

> I'm happy with either way of doing it, as long as we're explicit about it.
<Raju>
+1 for negotiation.
I think it is highly preferred to negotiate these additional PPIDs in all cases as 
anything other than a binary or text  PPID is additional capability. Use of any additional
capabilities must at least be negotiated using JSEP. 
One element of negotiation could be "what must be done for unrecognized PPIDs?": ignore them or
abort the connection.

</Raju>

---

From: Michael Tuexen <[email-masked]>
Date: Wed, 27 Aug 2014 14:18:31 +0200

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

> I think a failure section is better placed after all sections on opening, closing and data transfer. Then it starts to be clear to the reader what can go wrong.
> And I think failure handling is so important that it is worth having a section on its own with a heading that can be found in the contents.
OK. What do others think? Should error handling be moved into a separate section?
> 
> When you say that all data channels are closed, can you then also tell how that is indicated to the application.
I consider this an API issue. When looking at
http://dev.w3.org/2011/webrtc/editor/webrtc.html
wouldn't that mean to fire onclose() on all data channels of the peer connection?
> 
> I also think that the basic reasons for Association termination by error should be explained briefly in the data-channel specification, so that the reader does not need to dig through the SCTP RFC to try to find them.  The watchdog failures and the exess retries in reliable channels, etc.   I cannot understand why you want to avoid explaining the mechanisms.
Could go into a failure section, if the WG agrees that we want to have some... Any opinions?
> I do not think it is clear. It merely mentions the names of the types of channels. The failure cases need also to be described.
> And, it is a case for the API description and the data-channel spec to be aligned. What the W3C API spec specify will happen in case of failure needs to be supported by the data-channel spec. I have made proposals to WebRTC as well. Please align.
From an SCTP point of view, you can get a notification at the sender side if a message is abandoned, but not at the receiver side.
I don't see that such an information is exposed to the JS application...
> Well, why not describe what happens, so that further questions or misunderstandings are avoided?  You mean that what SCTP provides is also what the data-channel provides.
So isn't the text cited by you below not enough?
> 6.8, also the ones from 6.6.
Understood. Can we get some agreement if we want this or not in the WG?
> But here it is said that just the channel is closed.  Please clarify.
That is a good point... When I wrote this sentence, I was thinking about errors like
illegal ordering (which means the receiver expects ordered but got unordered, or expects
reliable transfer, but sees SSN holes...). I was not thinking about an indication that
the association is gone. So what about:

<t>If a message with an unsupported PPID is received or some error condition
related to the received message is detected by the receiver
(for example, illegal ordering),
the receiver SHOULD close the corresponding data channel.</t>

Best regards
Michael

---

From: Michael Tuexen <[email-masked]>
Date: Wed, 27 Aug 2014 14:50:50 +0200

On 27 Aug 2014, at 13:16, Harald Alvestrand <[email-masked]> wrote:

> If there is no negotiation, starting to use the new feature will either lead to ignored messages or lead to a crashed connection.
> 
> Ignored messages are not a problem if they form part of an ignorable extension (for instance if someone decided to once in a while send checksums over all the data sent so far - doesn't matter to those that don't understand it, since it doesn't carry any extra data).
> 
> Crashed connections are usually a problem, so that will mean "no unnegotiated extensions, ever".
> 
I agree with you, don't have a preference. Up to now the consensus was to close the channel...
I can add a sentence to make clear that this means no unnegotiated  extensions.

Best regards
Michael

---

From: Michael Tuexen <[email-masked]>
Date: Wed, 27 Aug 2014 14:52:51 +0200

> One element of negotiation could be "what must be done for unrecognized PPIDs?": ignore them or
Do we really need to negotiate that? The consensus up to now was to close the channel.
So if you negotiate the PPIDs and honor the result, you will never run into this issue...

Best regards
Michael

---

From: Martin Thomson <[email-masked]>
Date: Wed, 27 Aug 2014 11:46:33 -0700

> error messages were wanted... Is this conclusion not valid anymore?

I have no recollection of discussing this, but will admit to not
reading every email on the topic.

> What TCP problems are you referring to?

The sort where you send data followed immediately by a FIN (or RST)
and find that the data disappeared.  c.f.,
http://tools.ietf.org/html/rfc7230#page-57 (top)

---

From: "Makaraju, Maridi Raju (Raju)" <[email-masked]>
Date: Wed, 27 Aug 2014 19:08:47 +0000

> So if you negotiate the PPIDs and honor the result, you will never run into
<Raju>
I like your response to Herald: "I can add a sentence to make clear that this means no unnegotiated  extensions."
So, all un-negotiated extensions results in closing the data channel; which leaves possibility for
negotiating extensions in future and handling them appropriately.
</Raju>

---

From: Michael Tuexen <[email-masked]>
Date: Wed, 27 Aug 2014 21:40:46 +0200

> reading every email on the topic.
I think this was discussed at an IETF meeting... Basically the questions was
if we want to define any protocol for data channels. DCEP is not covered by
this question, since it is a protocol to set channels up.
> http://tools.ietf.org/html/rfc7230#page-57 (top)
No, SCTP does not have this problem when resetting streams. Messages get delivered.
However, what can happen is that when using an unordered channel, that the message
sent last before resetting the channel, is not the one received as the last message
before the SCTP Stream Reset request is received...

Best regards
Michael

---

From: Harald Alvestrand <[email-masked]>
Date: Wed, 27 Aug 2014 23:07:28 +0200

> http://tools.ietf.org/html/rfc7230#page-57 (top)
Re TCP: I think the RFC 7230 problem is an application (or API) problem,
not a protocol problem.

This only happens if a data receiver uses the POSIX close(3) interface
to close a socket, instead of shutting it down gently (with shutdown(2)
using SHUT_WR, I think).

Anyone who sends RST is OK with data being lost. RST is a signal that
"I'm shutting this stuff down, I don't care whether your data arrived or
not".

-- 
Surveillance is pervasive. Go Dark.

---

From: Gunnar Hellstrom <[email-masked]>
Date: Wed, 27 Aug 2014 23:22:16 +0200

There is an ambition to be as close as possible to Websocket.
Websocket is specified in RFC 6455.
It has an negotiation mechanism for extensions.  See chapter 9
And it closes channels in case of reception tht is not according to the 
protocol. ( e.g. Section 10.7 )

So, it could be wise to copy that behavior, to maintain the ambitions of 
keeping these data channel types similar.

/Gunnar