Re: [rtcweb] WGLC for data channel drafts - missing descriptions of error situations

Michael Tuexen <Michael.Tuexen@lurchi.franken.de> Mon, 07 July 2014 20:01 UTC

Return-Path: <Michael.Tuexen@lurchi.franken.de>
X-Original-To: rtcweb@ietfa.amsl.com
Delivered-To: rtcweb@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C90711A0515 for <rtcweb@ietfa.amsl.com>; Mon, 7 Jul 2014 13:01:01 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.202
X-Spam-Level:
X-Spam-Status: No, score=-2.202 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_DE=0.35, RP_MATCHES_RCVD=-0.651, SPF_HELO_PASS=-0.001] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id zD-FCxg4aUFC for <rtcweb@ietfa.amsl.com>; Mon, 7 Jul 2014 13:00:57 -0700 (PDT)
Received: from mail-n.franken.de (drew.ipv6.franken.de [IPv6:2001:638:a02:a001:20e:cff:fe4a:feaa]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 4EA721B289C for <rtcweb@ietf.org>; Mon, 7 Jul 2014 13:00:51 -0700 (PDT)
Received: from [192.168.1.200] (p54819C6D.dip0.t-ipconnect.de [84.129.156.109]) (Authenticated sender: macmic) by mail-n.franken.de (Postfix) with ESMTP id DC3311C104925; Mon, 7 Jul 2014 22:00:48 +0200 (CEST)
Content-Type: text/plain; charset="iso-8859-1"
Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.6\))
From: Michael Tuexen <Michael.Tuexen@lurchi.franken.de>
In-Reply-To: <53B797C1.3080609@omnitor.se>
Date: Mon, 07 Jul 2014 22:00:46 +0200
Content-Transfer-Encoding: quoted-printable
Message-Id: <596034E6-7D76-4F82-AFD3-521B8C0217B8@lurchi.franken.de>
References: <CA+9kkMAzdcLhM_g+S6407=_SUBKu7hLhMrYSrqGP5tk3yEsP6w@mail.gmail.com> <53B71B6E.2010604@omnitor.se> <470AD025-E40B-43BD-B141-599489FB892C@lurchi.franken.de> <53B797C1.3080609@omnitor.se>
To: Gunnar Hellstrom <gunnar.hellstrom@omnitor.se>
X-Mailer: Apple Mail (2.1878.6)
Archived-At: http://mailarchive.ietf.org/arch/msg/rtcweb/Va-prhPqooexwOcpqS43MPjPd54
Cc: rtcweb@ietf.org
Subject: Re: [rtcweb] WGLC for data channel drafts - missing descriptions of error situations
X-BeenThere: rtcweb@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: Real-Time Communication in WEB-browsers working group list <rtcweb.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/rtcweb>, <mailto:rtcweb-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/rtcweb/>
List-Post: <mailto:rtcweb@ietf.org>
List-Help: <mailto:rtcweb-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/rtcweb>, <mailto:rtcweb-request@ietf.org?subject=subscribe>
X-List-Received-Date: Mon, 07 Jul 2014 20:01:02 -0000

On 05 Jul 2014, at 08:14, Gunnar Hellstrom <gunnar.hellstrom@omnitor.se> wrote:

> On 2014-07-04 23:34, Michael Tuexen wrote:
>> On 04 Jul 2014, at 23:23, Gunnar Hellstrom <gunnar.hellstrom@omnitor.se> 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.
> 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.
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...
>>> 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.
>> 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?)
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.
> 
> 
> 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? )
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
>>> gunnar.hellstrom@omnitor.se
>>> On 2014-06-10 20:52, 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
>>>> 
>>>> rtcweb@ietf.org
>>>> https://www.ietf.org/mailman/listinfo/rtcweb
>>> _______________________________________________
>>> rtcweb mailing list
>>> rtcweb@ietf.org
>>> https://www.ietf.org/mailman/listinfo/rtcweb
> 
>