Re: [rtcweb] Comments on draft-ietf-rtcweb-data-channel-06
Gunnar Hellstrom <gunnar.hellstrom@omnitor.se> Mon, 16 December 2013 20:48 UTC
Return-Path: <gunnar.hellstrom@omnitor.se>
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 662731AD8E3 for <rtcweb@ietfa.amsl.com>; Mon, 16 Dec 2013 12:48:54 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.301
X-Spam-Level:
X-Spam-Status: No, score=-1.301 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, J_CHICKENPOX_31=0.6, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=no
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 Acy_bfHEQgPU for <rtcweb@ietfa.amsl.com>; Mon, 16 Dec 2013 12:48:51 -0800 (PST)
Received: from vsp-authed-01-02.binero.net (vsp-authed02.binero.net [195.74.38.226]) by ietfa.amsl.com (Postfix) with ESMTP id DBF1A1AD8E2 for <rtcweb@ietf.org>; Mon, 16 Dec 2013 12:48:49 -0800 (PST)
Received: from smtp01.binero.se (unknown [195.74.38.28]) by vsp-authed-01-02.binero.net (Halon Mail Gateway) with ESMTPS for <rtcweb@ietf.org>; Mon, 16 Dec 2013 21:48:41 +0100 (CET)
Received: from [192.168.50.32] (81-224-110-16-no227.business.telia.com [81.224.110.16]) (Authenticated sender: gunnar.hellstrom@omnitor.se) by smtp-08-01.atm.binero.net (Postfix) with ESMTPA id B4E503A105 for <rtcweb@ietf.org>; Mon, 16 Dec 2013 21:48:41 +0100 (CET)
Message-ID: <52AF672B.2090100@omnitor.se>
Date: Mon, 16 Dec 2013 21:48:43 +0100
From: Gunnar Hellstrom <gunnar.hellstrom@omnitor.se>
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:24.0) Gecko/20100101 Thunderbird/24.2.0
MIME-Version: 1.0
To: rtcweb@ietf.org
References: <5280E181.20104@ericsson.com> <52AE2C51.5000600@omnitor.se> <52AEC405.6070107@alvestrand.no>
In-Reply-To: <52AEC405.6070107@alvestrand.no>
Content-Type: text/plain; charset="ISO-8859-1"; format="flowed"
Content-Transfer-Encoding: 7bit
Subject: Re: [rtcweb] Comments on draft-ietf-rtcweb-data-channel-06
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, 16 Dec 2013 20:48:54 -0000
On 2013-12-16 10:12, Harald Alvestrand 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. 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. > >> 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. Yes, please. I did not find it in RFC 4960. >> Can duplications be guaranteed to be avoided in the ordered channel? > As far as I know, yes. > >> 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). 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 > > _______________________________________________ > rtcweb mailing list > rtcweb@ietf.org > https://www.ietf.org/mailman/listinfo/rtcweb
- [rtcweb] Comments on draft-ietf-rtcweb-data-chann… Magnus Westerlund
- Re: [rtcweb] Comments on draft-ietf-rtcweb-data-c… Gunnar Hellstrom
- Re: [rtcweb] Comments on draft-ietf-rtcweb-data-c… Harald Alvestrand
- Re: [rtcweb] Comments on draft-ietf-rtcweb-data-c… Gunnar Hellstrom
- Re: [rtcweb] Comments on draft-ietf-rtcweb-data-c… Gunnar Hellstrom
- Re: [rtcweb] Comments on draft-ietf-rtcweb-data-c… Michael Tuexen
- Re: [rtcweb] Comments on draft-ietf-rtcweb-data-c… Michael Tuexen
- Re: [rtcweb] Comments on draft-ietf-rtcweb-data-c… Michael Tuexen
- Re: [rtcweb] Comments on draft-ietf-rtcweb-data-c… Gunnar Hellstrom
- Re: [rtcweb] Comments on draft-ietf-rtcweb-data-c… Michael Tuexen
- Re: [rtcweb] Comments on draft-ietf-rtcweb-data-c… Gunnar Hellstrom
- Re: [rtcweb] Comments on draft-ietf-rtcweb-data-c… Michael Tuexen
- Re: [rtcweb] Comments on draft-ietf-rtcweb-data-c… Michael Tuexen
- Re: [rtcweb] Comments on draft-ietf-rtcweb-data-c… Michael Tuexen
- Re: [rtcweb] Comments on draft-ietf-rtcweb-data-c… Gunnar Hellstrom
- Re: [rtcweb] Comments on draft-ietf-rtcweb-data-c… Michael Tuexen
- Re: [rtcweb] Comments on draft-ietf-rtcweb-data-c… Michael Tuexen
- Re: [rtcweb] Comments on draft-ietf-rtcweb-data-c… Randell Jesup
- Re: [rtcweb] Comments on draft-ietf-rtcweb-data-c… Magnus Westerlund