Subject: Re: [rtcweb] Comments on draft-ietf-rtcweb-data-channel-06

From: Gunnar Hellstrom <[email-masked]>
Date: Sun, 15 Dec 2013 23:25:21 +0100

I took a look at the data channel draft.

I am missing descriptions of the requirements of how transmission 
failures are to be handled.

I suggest that section   6.6 "Transferring User Data on a Channel" is 
extended with a description on what happens if the transmission fails.
It is evident that there will be different actions for the different 
types of channels.

For unordered, unreliable channels, I assume that neither the 
transmitter nor the receiver will be notified of transmission failures.

For ordered, semi-reliable channels, I assume that the transmitter is 
notified about failure if the transmitting channel has no indication of 
successful transmission after the specified number of retransmissions or 
milliseconds.
Same with the receiver, but the error notification may not appear until 
next transmission is received, so that the gap can be detected.

Also the so called ordered reliable channel may fail. It just has a 
higher number of retries over a longer time. So, same information should 
be provided for that type.

And, is there just an error notification and then open for trying next 
transmission, or is the channel broken and needs to be opened again. I 
suggest that transmission can continue after the error notification.

Can duplications be guaranteed to be avoided in the ordered channel?
Can there be cases when the transmitter gets a notification about 
failure, but the receiver has received the data successfully?

How is this reflected in WebRTC API:s?

Thanks,

Gunnar

On 2013-11-11 14:54, Magnus Westerlund wrote:
> Hi,
>
> I did review the data channel draft prior to the meeting and thought I
> would provide my comments.
>
> 1. Usage of RTCWeb vs WebRTC when referring to the whole solution. My
> recollection was that we agreed to use WebRTC for this. I think we
> should try to align this language. Audio, Security and RTP usage uses
> WebRTC, while Data channel, overview and Transport uses RTCWeb.
>
> 2. Section 3.2:
>     U-C 6:  Renegotiation of the set of media streams in the
>        PeerConnection.
>
> What "media streams" are being referred to here. Or is i better to
> express this as "Renegotiation of the configuration of the PeerConnection."?
>
> 3. Section 3.2:
>     U-C 7:  Proxy browsing, where a browser uses data channels of a
>        PeerConnection to send and receive HTTP/HTTPS requests and data,
>        for example to avoid local internet filtering or monitoring.
>
> Yes, this may be something that is possible, but to express it as a use
> cases intended to be supported might not be the best. We are after all
> likely talking about circumventing local security policies. I would also
> note that "Internet" is with capital I.
>
> 4. Section 4:
>     Req. 1:   Multiple simultaneous data channels MUST be supported.
>        Note that there may 0 or more media streams in parallel with the
>        data channels, and the number and state (active/inactive) of the
>        media streams may change at any time.
>
> Which "media stream" are you referring to in the above?
>
> 5. Section 4:
>     Req. 3:   Data channels MUST be congestion controlled; either
>        individually, as a class, or in conjunction with the media
>        streams, to ensure that data channels don't cause congestion
>        problems for the media streams, and that the RTCWeb PeerConnection
>        as a whole is fair with competing traffic such as TCP.
>
> A: What "media stream" are you referring to here?
>
> B: "and that the RTCWeb PeerConnection
>        as a whole is fair with competing traffic such as TCP."
>
> I don't think it is a MUST requirement. Neither am I convinced that a
> PeerConnection needs to be fair with an unspecified number of TCP
> traffic. It might be simplest to strike the last part.
>
> 6. Section 4:
> [ TBD: how this is encoded and what the impact of this is. ]
>
> Didn't we have some direction decisions on how priority was to be
> handled at least locally by the end-point. Please add this to the draft.
> I also hope that the way of representing priorities can get clearer from
> an API perspective.
>
> 7. Section 5:
> "   o  The congestion control is modifiable for integration with media
>        stream congestion control."
>
> I think this is an exaggeration, and not supported by current sets of
> specifications, if it is supported please provide a reference.
>
> 8. Section 5:
> "Using DTLS over UDP in combination with ICE enables NAT traversal in
> IPv4 based networks."
>
> I would like to point out that ICE do provide firewall traversal for
> firewalls with certain type of filtering rules like the basic stateful
> filtering. These apply to IPv6 equally, not only IPv4.
>
> 9.  Section 5:
> "   Each SCTP user message contains a so called Payload Protocol
>     Identifier (PPID) that is passed to SCTP by its upper layer and sent
>     to its peer.  This value can be used to multiplex multiple protocols
>     over a single SCTP association.  The sender provides for each
>     protocol a specific PPID and the receiver can demultiplex the
>     messages based on the received PPID."
>
> I have some difficulties in determining the relevance of this in the
> context of WebRTC. Can you please provide a clear explanation why PPID
> are relevant here. Will not all traffic from an WebRTC endpoint use the
> PPIDs associated with the data protocol, rather than any "native" PPIDs?
>
> 10. Section 5:
>
> Can you please clarifiy the demultiplexing for WebRTC by discussing
> STUN, vs SRTP vs DTLS and secondly that DTLS-SRTP and DTLS frames with
> SCTP can co-exist in the same DTLS stack. At least on an level where you
> can point to all the relevant sections in other specifications to
> explain that these can coexist given certain constraints. This is likely
> its own sub-section.
>
> 11. Section 5:
>
>     o  shares the DTLS connection with the media channels.
>
> what is "media channels"?
>
> 12. Section 5:
> "  Since DTLS is typically implemented in user-land, the SCTP stack also
>     needs to be a user-land stack."
>
> I wonder what the message of this sentence is? The reason is that I
> wonder what it should be saying if one implements DTLS in a kernel, or
> similar if one despite a DTLS user-land stack uses a SCTP stack in the
> kernel through access to raw sockets.
>
> 13. Section 5:
>     Incoming ICMP or ICMPv6 messages can't be processed by the SCTP
>     layer, since there is no way to identify the corresponding
>     association.
>
> Also here I get a bit confused, I assume what you are after is the issue
> that incoming ICMP messages will be arriving related to the UDP flow,
> not in relation to an kernel SCTP association, thus there is a routing
> issue for ICMP to reach the above DTLS existing SCTP association. Not
> impossible to solve, just not available with existing APIs.
>
> 14. Section 5:
>     "This protocol stack MUST support the usage of multiple SCTP streams."
>
> I wonder which layer is affected by this. Isn't this only affecting SCTP
> implementation and the higher layers? Can't you be more specific thus?
>
> 15. Section 5:
>     Using a congestion control
>     different from the standard one might improve the impact on the
>     parallel SRTP media streams.  Since SCTP does not support the
>     negotiation of a congestion control algorithm, alternate congestion
>     controls SHOULD only require a different sender side behavior using
>     existing information carried in the association.
>
> A: I wonder if adding a "yet" into the second sentence to make clear
> that in the future there might be support for negotiating congestion
> control.
>
> B: Also, what happens if one violate the SHOULD and require receiver
> side information and the peer don't support it. That clearly can't be
> acceptable? Can this be formulated in some other way that is tighter
> without preventing sender side changes?
>
> 16. Section 6.1:
>     o  The dynamic address reconfiguration extension defined in [RFC5061]
>        MUST be used to signal the support of the stream reset extension
>        defined in [RFC6525], other features of [RFC5061] MUST NOT be
>        used.
>
> A question, are theses other features, destructive to the SCTP
> association, or simply unnecessary to implement? If it is the first,
> then I think MUST NOT be used is fine, but if else, why not simple say
> that they are NOT REQUIRED to be implemented?
>
>
> 17. Section 6.1:
>     o  The partial reliability extension defined in [RFC3758] MUST be
>        supported.  In addition to the timed reliability PR-SCTP policy
>        defined in [RFC3758], the limited retransmission policy defined in
>        [I-D.tuexen-tsvwg-sctp-prpolicies] MUST be supported.
>
> So what is the status of this individual document, did it get adopted
> into TSVWG? I think this is an important question, as it is one thing
> where we can consider going forward without the extension and add it
> later when ready?
>
> 18. Section 6.2:
> "  Additionally,
>     the negotiation SHOULD include some type of congestion control
>     selection. "
>
> Okay, this appears very fuzzy. And what name space or specifications are
> you going to use to negotiate what the different options are?
>
> 19. Section 6.3:
> It will use the DTLS connection selected via SDP;
>     typically this will be shared via BUNDLE or equivalent with DTLS
>     connections used to key the DTLS-SRTP media streams.
>
> In which way is the DTSL connection "selected" via SDP?
>
> 20. Section 6.2:
>
>     When one side wants to open a channel using external negotiation, it
>     picks a Stream.  This can be based on the DTLS role (the client picks
>     even stream identifiers, the server odd stream identifiers) or done
>     in a different way.  However, the application is responsible for
>     avoiding collisions with existing Streams.  If it attempts to re-use
>     a Stream which is part of an existing Channel, the addition SHOULD
>     fail.  In addition to choosing a Stream, the application SHOULD also
>     inform the protocol of the options to use for sending messages.  The
>     application MUST ensure in an application-specific manner that the
>     other side will also inform the protocol that the selected Stream is
>     to be used, and the parameters for sending data from that side.
>
> So why is this specified here and not in the Data Protocol? Especially
> using RFC 2119 terms, it appears to be colliding or at least overlapping
> specifications?
>
> 21. Section 6.6
>     It is recommended that message size be kept within certain size
>     bounds (TBD) as applications will not be able to support arbitrarily-
>     large single messages.
>
> I guess this will be resolved by the WG session agreement, or?
>
> 22.
>
> Section 8:
>                +---------------------+-----------+-----------+
>                | Value               | SCTP PPID | Reference |
>                +---------------------+-----------+-----------+
>                | DOMString Last      | 51        | [RFCXXXX] |
>                | Binary Data Partial | 52        | [RFCXXXX] |
>                | Binary Data Last    | 53        | [RFCXXXX] |
>                | DOMString Partial   | 54        | [RFCXXXX] |
>                +---------------------+-----------+-----------+
>
> Where are the definitions of these definitions?
>
> 23. Section 10.2:
>
>     [I-D.tuexen-tsvwg-sctp-prpolicies]
>                Tuexen, M., Seggelmann, R., Stewart, R., and S. Loreto,
>                "Additional Policies for the Partial Delivery Extension of
>                the Stream Control Transmission Protocol", draft-tuexen-
>                tsvwg-sctp-prpolicies-03 (work in progress), October 2013.
>
> This is a normative reference.
>
> Cheers
>
> Magnus Westerlund
>
> ----------------------------------------------------------------------
> Multimedia Technologies, Ericsson Research EAB/TVM
> ----------------------------------------------------------------------
> Ericsson AB                | Phone  +46 10 7148287
> Färögatan 6                | Mobile +46 73 0949079
> SE-164 80 Stockholm, Sweden| mailto: [email-masked]
> ----------------------------------------------------------------------
>
> _______________________________________________
> rtcweb mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/rtcweb

---

From: Harald Alvestrand <[email-masked]>
Date: Mon, 16 Dec 2013 10:12:37 +0100

On 12/15/2013 11:25 PM, Gunnar Hellstrom wrote:
> notified about failure if the transmitting channel has no indication
> of successful transmission after the specified number of
> retransmissions or milliseconds.
> Same with the receiver, but the error notification may not appear
> until next transmission is received, so that the gap can be detected.
>
> higher number of retries over a longer time. So, same information
> should be provided for that type.

The traditional way of signalling the failiure of a reliable channel is
to indicate that the channel has failed.

> suggest that transmission can continue after the error notification.

This should expose the corresponding property of the SCTP protocol. I
expect SCTP experts will answer that.
> Can duplications be guaranteed to be avoided in the ordered channel?

As far as I know, yes.

> failure, but the receiver has received the data successfully?

Yes. Avoiding such a situation is logically impossible; you'd get into
an infinite regression of ACKs otherwise.

> How is this reflected in WebRTC API:s?

The WebRTC API has no defined function for notification of
single-message transmission failure. So it reflects the assumption that
one either gets no indication at all (for unreliable and limited-retry)
or channel failure (for reliable).

---

From: Gunnar Hellstrom <[email-masked]>
Date: Mon, 16 Dec 2013 21:48:43 +0100

> to indicate that the channel has failed.
So, let us try to get proposed text in order for a suitable behavior for 
the data channel draft.

In the data channel draft, section 6.6, I suggest to add something like:
--------------------------------------------------------------
"In case of transmission problems, a reliable channel and a 
partially-reliable channel performs retries. The retries for a reliable 
channel are limited by SCTP parameters. The retries for a 
partially-reliable channel are limited by the parameter set by the 
application at channel creation time.

If transmission on a reliable channel is considered unsuccessful by the 
transport protocol, the channel is regarded to have failed. An error 
report is provided to the upper layer on the transmitter side. An error 
report is provided on the  receiver side if the receiver has any 
indication that a transmission was intended.
If the channel is ordered, then no data from the lost transmission and 
onwards is lost.

If transmission on a partially-reliable channel is unsuccessful after 
the specified retry limit, the channel reports temporary failure to the 
transmitting application and accepts new send requests. If the channel 
is un-ordered, the receiving side will not notify the application about 
the loss.
If the channel is ordered, then the channel on the receive side provides 
a loss indication in place of the lost data.

If transmission on a nonreliable channel is unsuccessful, it is not 
reported as any failure."

-------------------------------------------------------------
It could also be collected in a separate section "Data transmission 
failures" after section 6.6.

Further thoughts:

For an application designer, it is important to know for how long the 
channel will stall in case of transmission problems before it is 
regarded to have failed. I could not find information for the general 
case in SCTP.
Can anyone guide on this: How long does SCTP try with a reliable 
transmission before it gives up?

Not until that is known, it can be judged if a reliable or 
partially-reliable channel is the right choice for the planned application.

> expect SCTP experts will answer that.
Yes, please. I did not find it in RFC 4960.
> or channel failure (for reliable).
This sounds not logical for ordered partially-reliable channels.  I 
think a gap indication shall be provided through the API.
I inserted that thought for the text proposal for 
draft-ietf-rtcweb-data-channel-06, and something similar is needed in 
the API as well.

/Gunnar

---

From: Gunnar Hellstrom <[email-masked]>
Date: Sat, 28 Dec 2013 01:03:25 +0100

There is a set of parameters for SCTP in RFC 4690 with proposed values 
in chapter 15.

I suggest that the data-channel draft specifies somewhere that the 
values recommended in SCTP chapter 15 SHOULD be used whenever there is 
no reason to select other values.

The following is an extract from SCTP chapter 15:
15 <http://tools.ietf.org/html/rfc4960#section-15>. Suggested SCTP 
Protocol Parameter Values

    The following protocol parameters are RECOMMENDED:

       RTO.Initial - 3 seconds
       RTO.Min - 1 second
       RTO.Max - 60 seconds
       Max.Burst - 4
       RTO.Alpha - 1/8
       RTO.Beta - 1/4
       Valid.Cookie.Life - 60 seconds
       Association.Max.Retrans - 10 attempts
       Path.Max.Retrans - 5 attempts (per destination address)
       Max.Init.Retransmits - 8 attempts
       HB.interval - 30 seconds
       HB.Max.Burst - 1

-------------------------

Some of them are for example used in chapter 8, fault management, where 
also some of my earlier questions are touched.

This is my deduction of a typical error scenario:

The retry mechanism seems to possibly result in retries after about 1, 
3, 7, 15 and 31 seconds after the initial transmission of a chunk of 
data. If still not successful, the path is considered to fail. If no 
other path is available, the connection fails.  ( this assumes a 
connection with about <400  ms delay )

SCTP is not totally clear about if the upper layer shall be told about 
the failure.

In 8.2 it says:

When the value in the error counter exceeds the protocol parameter
    'Path.Max.Retrans' of that destination address, the endpoint should
    mark the destination transport address as inactive, and a
    notification SHOULD be sent to the upper layer.

(There are other cases in 8.1 with even more vague requirement to report 
the failure to the upper layer. )

I suggest that the data channel draft shall be clear about that the 
higher layer gets an error indication, indicating how much data the 
sending side has marked as unsent.

The retries for the partially-reliable channel type seems to only have 
any meaning if it is set to a value <5
The retry time for the partially-reliable channel will also have an 
upper liit set by the maximum retry period for the reliable channel, but 
it is harder to peredict what the limits are.  31 seconds seems to be 
one of the shortest total retry periods appearing, so times <30 s makes 
sense as partially-reliable total retry timeout.

Gunnar

------------------------------------------------------------------------

[email-masked]

On 2013-12-16 21:48, Gunnar Hellstrom wrote:
> So, let us try to get proposed text in order for a suitable behavior 
> for the data channel draft.
>
> partially-reliable channel performs retries. The retries for a 
> reliable channel are limited by SCTP parameters. The retries for a 
> If transmission on a reliable channel is considered unsuccessful by 
> the transport protocol, the channel is regarded to have failed. An 
> error report is provided to the upper layer on the transmitter side. 
> An error report is provided on the  receiver side if the receiver has 
> any indication that a transmission was intended.
> the specified retry limit, the channel reports temporary failure to 
> the transmitting application and accepts new send requests. If the 
> channel is un-ordered, the receiving side will not notify the 
> application about the loss.
> If the channel is ordered, then the channel on the receive side 
> provides a loss indication in place of the lost data.
>

---

From: Michael Tuexen <[email-masked]>
Date: Sat, 28 Dec 2013 10:45:09 +0100

On Dec 28, 2013, at 1:03 AM, Gunnar Hellstrom <[email-masked]> wrote:

> There is a set of parameters for SCTP in RFC 4690 with proposed values in chapter 15.
> 
> I suggest that the data-channel draft specifies somewhere that the values recommended in SCTP chapter 15 SHOULD be used whenever there is no reason to select other values.
I'm not sure what the value of stating that is... Isn't it clear?
> 15. Suggested SCTP Protocol Parameter Values
> 
> 
> Some of them are for example used in chapter 8, fault management, where also some of my earlier questions are touched.
However, SCTP over DTLS uses a single homed setup only, so we might want to clarify Association.Max.Retrans
and Path.Max.Retrans. We might want to use a setting with Association.Max.Retrans = Path.Max.Retrans
to avoid the dormant state. Making such a statement makes sense for me.
> The retry mechanism seems to possibly result in retries after about 1, 3, 7, 15 and 31 seconds after the initial transmission of a chunk of data. If still not successful, the path is considered to fail. If no other path is available, the connection fails.  ( this assumes a connection with about <400  ms delay )
No. You still haven't tried Association.Max.Retrans. There is the case where all
paths have failed, but the association hasn't yet. This is sometimes called the
dormant state. It is not clearly specified what to do in this state. There
are implementations which continue to try (the FreeBSD implementation is an example),
other might fail the association earlier that expected.
> 
> 
> 
> SCTP is not totally clear about if the upper layer shall be told about the failure. 
RFC 4960 specifies mostly the protocol on the wire. If you want an informational
API, please have a look at RFC 6458.
> (There are other cases in 8.1 with even more vague requirement to report the failure to the upper layer. )
> 
> 
> I suggest that the data channel draft shall be clear about that the higher layer gets an error indication, indicating how much data the sending side has marked as unsent. 
That is an API issue and is, as far as I understand, discussed in the W3C.
> 
> 
> The retries for the partially-reliable channel type seems to only have any meaning if it is set to a value <5
> The retry time for the partially-reliable channel will also have an upper liit set by the maximum retry period for the reliable channel, but it is harder to peredict what the limits are.  31 seconds seems to be one of the shortest total retry periods appearing, so times <30 s makes sense as partially-reliable total retry timeout.
Please note that some chunk might be retransmitted more often than Association.Max.Retrans or
Path.Max.Retrans if the error counter gets cleared somehow. For example by successfully transmitting
a different chunk or a successful HEARTBEAT. In FreeBSD we limit the number of retransmissions
of each chunk and fail the association if that threshold is hit. This can happen, for example,
if small HEARTBEATs make it through the peer, but a large DATA chunk doesn't.

Best regards
Michael
>> So, let us try to get proposed text in order for a suitable behavior for the data channel draft. 
>> 
>> "In case of transmission problems, a reliable channel and a partially-reliable channel performs retries. The retries for a reliable channel are limited by SCTP parameters. The retries for a partially-reliable channel are limited by the parameter set by the application at channel creation time. 
>> 
>> If transmission on a reliable channel is considered unsuccessful by the transport protocol, the channel is regarded to have failed. An error report is provided to the upper layer on the transmitter side. An error report is provided on the  receiver side if the receiver has any indication that a transmission was intended. 
>> If the channel is ordered, then no data from the lost transmission and onwards is lost. 
>> 
>> If transmission on a partially-reliable channel is unsuccessful after the specified retry limit, the channel reports temporary failure to the transmitting application and accepts new send requests. If the channel is un-ordered, the receiving side will not notify the application about the loss. 
>> If the channel is ordered, then the channel on the receive side provides a loss indication in place of the lost data. 
>> 
>> If transmission on a nonreliable channel is unsuccessful, it is not reported as any failure." 
>> 
>> It could also be collected in a separate section "Data transmission failures" after section 6.6. 
>> 
>> Further thoughts: 
>> 
>> For an application designer, it is important to know for how long the channel will stall in case of transmission problems before it is regarded to have failed. I could not find information for the general case in SCTP. 
>> Can anyone guide on this: How long does SCTP try with a reliable transmission before it gives up? 
>> 
>> Not until that is known, it can be judged if a reliable or partially-reliable channel is the right choice for the planned application. 
>> 
>> 
>>> 
>> This sounds not logical for ordered partially-reliable channels.  I think a gap indication shall be provided through the API. 
>> I inserted that thought for the text proposal for draft-ietf-rtcweb-data-channel-06, and something similar is needed in the API as well. 
>> 
>> 
>> 
>> /Gunnar 
>>>

---

From: Michael Tuexen <[email-masked]>
Date: Sat, 28 Dec 2013 11:52:37 +0100

> expect SCTP experts will answer that.
SCTP has no notion of a failed stream, only the association can fail.
This would correspond to the peer connection.
However, a peer can violate the protocol on a data channel. I would
suggest to simply reset the corresponding streams in that case.
>> Can duplications be guaranteed to be avoided in the ordered channel?
Correct, not only in ordered channels. SCTP does not deliver a user message
twice in all cases.

> or channel failure (for reliable).
Just to be clear: Only an SCTP association can fail, not a stream.

Best regards
Michael

---

From: Michael Tuexen <[email-masked]>
Date: Sat, 28 Dec 2013 12:42:17 +0100

> In the data channel draft, section 6.6, I suggest to add something like:
Please note that not only the channel fails, but all channels using the same SCTP association.
Since a peer connection currently uses a single SCTP association, this means all data channel
of that peer connection fail.
> If transmission on a partially-reliable channel is unsuccessful after the specified retry limit, the channel reports temporary failure to the transmitting application and accepts new send requests.…
I think you are discussion API issues here. I think they are not discussed within the IETF...
However, SCTP can provide on the sender side a notification that some use message has been
abandoned.
> If transmission on a nonreliable channel is unsuccessful, it is not reported as any failure."
It is the association maximum transmit counter. However, some implementation fail the association
if it goes into the dormant state, which means that all paths are inactive.
> Not until that is known, it can be judged if a reliable or partially-reliable channel is the right choice for the planned application.
Reliable means, that all channels are taken down if a message doesn't make it through.
Partial reliable means, that transmission of a message can fail, the association stays up.
> I inserted that thought for the text proposal for draft-ietf-rtcweb-data-channel-06, and something similar is needed in the API as well.
I think the API should be discussed in the W3C...

Best regards
Michael

---

From: Gunnar Hellstrom <[email-masked]>
Date: Sat, 28 Dec 2013 17:07:38 +0100

Thanks Michael for good clarifications.

You are right that the part of the discussions about API-only 
considerations need to be taken in the webrtc list in W3C.
But the data channel and the SCTP implementation and parameters need to 
be specified clearly enough for the API to be able to deliver its 
specified characteristics.

So, I hope that some of the details discussed here will show up as 
details in  draft-ietf-rtcweb-data-channel

E.g. a chapter on failure handling, for the three types of channels: 
Unreliable, partially-reliable and reliable, and what happens when they 
encounter transmission failures.

/Gunnar

---

From: Michael Tuexen <[email-masked]>
Date: Sat, 28 Dec 2013 18:17:58 +0100

On Dec 28, 2013, at 5:07 PM, Gunnar Hellstrom <[email-masked]> wrote:

> You are right that the part of the discussions about API-only considerations need to be taken in the webrtc list in W3C.
> But the data channel and the SCTP implementation and parameters need to be specified clearly enough for the API to be able to deliver its specified characteristics.
> 
> So, I hope that some of the details discussed here will show up as details in  draft-ietf-rtcweb-data-channel
I think it makes sense to cover the specifics of being single homed. I'll add text to avoid the dormant state.
> 
> E.g. a chapter on failure handling, for the three types of channels: Unreliable, partially-reliable and reliable, and what happens when they encounter transmission failures.
If the association fails, all data channels fail. It doesn't matter if they are ordered or not,
reliable or not. That is pretty simple. A data channel can't fail (except for a peer violating
the protocol) without all other data channels belonging to the same association also failing.
Do you think that this should me mentioned?

Best regards
Michael

---

From: Gunnar Hellstrom <[email-masked]>
Date: Sat, 28 Dec 2013 21:36:29 +0100

> Do you think that this should me mentioned?
Yes, I think it is important to clearly explain that a reliable channel 
can fail and inform about how that happens and how it is reported.

Can you explain why SCTP is so fuzzy about that situation in section 
8.1, ending with:
"

  (and thus the association enters the CLOSED state).  In addition, the
    endpoint MAY report the failure to the upper layer and optionally
    report back all outstanding user data remaining in its outbound
    queue.  The association is automatically closed when the peer
    endpoint becomes unreachable."

I think rtcweb-data-channel usage of SCTP need to require to get the report about the failure.

Regards
Gunnar Hellström

---

From: Michael Tuexen <[email-masked]>
Date: Sun, 29 Dec 2013 19:50:08 +0100

On Dec 28, 2013, at 9:36 PM, Gunnar Hellstrom <[email-masked]> wrote:

> Yes, I think it is important to clearly explain that a reliable channel can fail and inform about how that happens and how it is reported.
OK. I'll add a sentence or two about the endpoint failure detection where
I also describe the specifics of single homing.
> 
> Can you explain why SCTP is so fuzzy about that situation in section 8.1, ending with:

All the API description is non-normative... The focus was on specifying the
packets on the wire and the procedures necessary for interoperability, but
not on the API. We have a separate informational RFC (RFC 6458) which describes
how a socket API could look like. The kernel implementations of FreeBSD, Linux
and Solaris are following that RFC.
>   endpoint becomes unreachable."
In the socket API, the user has subscribe to some events to get
the messages back. The default is off...
> I think rtcweb-data-channel usage of SCTP need to require to get the report about the failure.
I think there are onerror callbacks...

Best regards
Michael

---

From: Michael Tuexen <[email-masked]>
Date: Sun, 29 Dec 2013 20:38:33 +0100

On Dec 29, 2013, at 11:41 AM, Gunnar Hellstrom <[email-masked]> wrote:

> On 2013-12-28 10:45, Michael Tuexen wrote:
> Yes, maybe you are right. RFC 4960 chapter 15 is called:
> "
> That sounds vague, but the first line of that chapter says:
> 
> " The following protocol parameters are RECOMMENDED:"
> 
> And according to RFC 2119, that means "
> that there
> may exist valid reasons in particular circumstances to ignore a particular item, but the full implications must be understood and carefully weighed before choosing a different course."
> So, yes, you are right, this is exactly what I asked for. My request can be dropped here, but some information about the resulting characteristics need instead to be described in the API specification so that developers know what they are using.
OK.
>  I have initiated that discussion in webrtc now.
Great. Thanks.

Best regards
Michael
> Yes, that is stated in a note in RFC 4960 section 8.2, but would be good to bring up more clearly in the data-channel spec. 
> But since we set Association.Max.Retrans=Path.Max.Retrans=5,  this will be the behavior. And timed out Heartbeats every 30 seconds also count in the retransmission counters. So, for all practical situations in WebRTC, the reliable channel will stall between 30 and 60 seconds and then have made 4 or 5 retransmissions of the data. If still not successful, the channel will fail.
> 
> 
>  
>>> 
>>> 
> I also see a risk that if the unreliable transfer mode is selected, it is said that each data chunk is sent once. But I think that there might be situations when data is never sent, if other channels get priority and are in retransmissions and reach the retransmission limit before this unreliable data chunk has been transmitted.
> Right?
>> 
>> Best regards
>> Michael
>> 
>>> 
>>> Gunnar
>>> 
>>> 
>>> 
>>> 
>>>

---

From: Michael Tuexen <[email-masked]>
Date: Sun, 29 Dec 2013 21:07:24 +0100

Hi Gunnar,

I missed your but-first comments in my last response. So here are the
responses to your other comments.

Best regards
Michael
On Dec 29, 2013, at 2:37 PM, Gunnar Hellstrom <[email-masked]> wrote:

> So, yes, you are right, this is exactly what I asked for. My request can be dropped here, but some information about the resulting characteristics need instead to be described in the API specification so that developers know what they are using. I have initiated that discussion in webrtc now.
> 
> 
Agreed.
> But since we set Association.Max.Retrans=Path.Max.Retrans=5,  this will be the behavior. And timed out Heartbeats every 30 seconds also count in the retransmission counters. So, for all practical s…
I think we need to set Association.Max.Retrans=Path.Max.Retrans, however, not
sure about the value. Could be 5 or 10 or another value. As long as they are
the same, we avoid the dormant state. 10 would be more in line with the
original intend...
> I also see a risk that if the unreliable transfer mode is selected, it is said that each data chunk is sent once. But I 
If you limit the lifetime, the user might not be sent at all. That is what you request.
If you limit the number of retransmissions, the message get sent the at most the number
of times you specified. The number can be smaller, because the messages gets acked
or the association terminates.
> think that there might be situations when data is never sent, if other channels get priority and are in retransmissions and reach the retransmission limit before this unreliable data chunk has been transmitted.
> Right?
Possible.

Best regards
Michael

---

From: Gunnar Hellstrom <[email-masked]>
Date: Sun, 29 Dec 2013 22:04:11 +0100

> I think there are onerror callbacks...
Right. There are both onerror and onclose.  So, it is just missing 
information on when and why these are called.

/Gunnar

---

From: Michael Tuexen <[email-masked]>
Date: Sun, 29 Dec 2013 23:39:44 +0100

On Dec 29, 2013, at 10:04 PM, Gunnar Hellstrom <[email-masked]> wrote:

> Right. There are both onerror and onclose.  So, it is just missing information on when and why these are called.
Correct. And what the arguments of the callbacks are...

Best regards
Michael