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

On Dec 16, 2013, at 10:12 AM, Harald Alvestrand <harald@alvestrand.no> wrote:

> On 12/15/2013 11:25 PM, Gunnar Hellstrom wrote:
>> 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.
> 
> The traditional way of signalling the failiure of a reliable channel is
> to indicate that the channel has failed.
> 
>> 
>> 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.
> 
> This should expose the corresponding property of the SCTP protocol. I
> 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?
> 
> As far as I know, yes.
Correct, not only in ordered channels. SCTP does not deliver a user message
twice in all cases.
> 
>> Can there be cases when the transmitter gets a notification about
>> 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).
Just to be clear: Only an SCTP association can fail, not a stream.

Best regards
Michael
> 
> _______________________________________________
> rtcweb mailing list
> rtcweb@ietf.org
> https://www.ietf.org/mailman/listinfo/rtcweb
> 