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

Harald Alvestrand <harald@alvestrand.no> Mon, 16 December 2013 09:12 UTC

Return-Path: <harald@alvestrand.no>
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 237141ADDBF for <rtcweb@ietfa.amsl.com>; Mon, 16 Dec 2013 01:12:44 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.838
X-Spam-Level:
X-Spam-Status: No, score=-1.838 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, J_CHICKENPOX_31=0.6, RP_MATCHES_RCVD=-0.538] 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 KtM1nFenJkqH for <rtcweb@ietfa.amsl.com>; Mon, 16 Dec 2013 01:12:39 -0800 (PST)
Received: from eikenes.alvestrand.no (eikenes.alvestrand.no [IPv6:2001:700:1:2:213:72ff:fe0b:80d8]) by ietfa.amsl.com (Postfix) with ESMTP id A5B371A1F61 for <rtcweb@ietf.org>; Mon, 16 Dec 2013 01:12:39 -0800 (PST)
Received: from localhost (localhost [127.0.0.1]) by eikenes.alvestrand.no (Postfix) with ESMTP id AC96F39E125 for <rtcweb@ietf.org>; Mon, 16 Dec 2013 10:12:41 +0100 (CET)
X-Virus-Scanned: Debian amavisd-new at eikenes.alvestrand.no
Received: from eikenes.alvestrand.no ([127.0.0.1]) by localhost (eikenes.alvestrand.no [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id wKf4eQZxkVUs for <rtcweb@ietf.org>; Mon, 16 Dec 2013 10:12:41 +0100 (CET)
Received: from [192.168.1.156] (unknown [188.113.88.47]) by eikenes.alvestrand.no (Postfix) with ESMTPSA id E6EC339E062 for <rtcweb@ietf.org>; Mon, 16 Dec 2013 10:12:40 +0100 (CET)
Message-ID: <52AEC405.6070107@alvestrand.no>
Date: Mon, 16 Dec 2013 10:12:37 +0100
From: Harald Alvestrand <harald@alvestrand.no>
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:24.0) Gecko/20100101 Thunderbird/24.1.1
MIME-Version: 1.0
To: rtcweb@ietf.org
References: <5280E181.20104@ericsson.com> <52AE2C51.5000600@omnitor.se>
In-Reply-To: <52AE2C51.5000600@omnitor.se>
X-Enigmail-Version: 1.6
Content-Type: text/plain; charset="ISO-8859-1"
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 09:12:44 -0000
X-List-Received-Date: Mon, 16 Dec 2013 09:12:44 -0000

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.
>
> 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).