Re: [rtcweb] Data channel comments and questions

Salvatore Loreto <salvatore.loreto@ericsson.com> Fri, 30 March 2012 19:15 UTC

Return-Path: <salvatore.loreto@ericsson.com>
X-Original-To: rtcweb@ietfa.amsl.com
Delivered-To: rtcweb@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2370821F86C7 for <rtcweb@ietfa.amsl.com>; Fri, 30 Mar 2012 12:15:12 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -110.124
X-Spam-Level:
X-Spam-Status: No, score=-110.124 tagged_above=-999 required=5 tests=[AWL=0.475, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id pOwizo6hYCU0 for <rtcweb@ietfa.amsl.com>; Fri, 30 Mar 2012 12:15:11 -0700 (PDT)
Received: from mailgw10.se.ericsson.net (mailgw10.se.ericsson.net [193.180.251.61]) by ietfa.amsl.com (Postfix) with ESMTP id E12F621F86C6 for <rtcweb@ietf.org>; Fri, 30 Mar 2012 12:15:10 -0700 (PDT)
X-AuditID: c1b4fb3d-b7c4fae00000507f-4d-4f76063da11e
Authentication-Results: mailgw10.se.ericsson.net x-tls.subject="/CN=esessmw0247"; auth=fail (cipher=AES128-SHA)
Received: from esessmw0247.eemea.ericsson.se (Unknown_Domain [153.88.253.124]) (using TLS with cipher AES128-SHA (AES128-SHA/128 bits)) (Client CN "esessmw0247", Issuer "esessmw0247" (not verified)) by mailgw10.se.ericsson.net (Symantec Mail Security) with SMTP id 74.D2.20607.D36067F4; Fri, 30 Mar 2012 21:15:09 +0200 (CEST)
Received: from mail.lmf.ericsson.se (153.88.115.8) by esessmw0247.eemea.ericsson.se (153.88.115.94) with Microsoft SMTP Server id 8.3.213.0; Fri, 30 Mar 2012 21:15:03 +0200
Received: from nomadiclab.lmf.ericsson.se (nomadiclab.lmf.ericsson.se [131.160.33.3]) by mail.lmf.ericsson.se (Postfix) with ESMTP id A55B02321 for <rtcweb@ietf.org>; Fri, 30 Mar 2012 22:15:03 +0300 (EEST)
Received: from nomadiclab.lmf.ericsson.se (localhost [127.0.0.1]) by nomadiclab.lmf.ericsson.se (Postfix) with ESMTP id A57D15261B for <rtcweb@ietf.org>; Fri, 30 Mar 2012 22:15:03 +0300 (EEST)
Received: from Salvatore-Loretos-MacBook-Pro.local (localhost [127.0.0.1]) by nomadiclab.lmf.ericsson.se (Postfix) with ESMTP id 2FCD152619 for <rtcweb@ietf.org>; Fri, 30 Mar 2012 22:15:03 +0300 (EEST)
Message-ID: <4F760634.207@ericsson.com>
Date: Fri, 30 Mar 2012 21:15:00 +0200
From: Salvatore Loreto <salvatore.loreto@ericsson.com>
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.6; rv:10.0.2) Gecko/20120216 Thunderbird/10.0.2
MIME-Version: 1.0
To: rtcweb@ietf.org
References: <E44893DD4E290745BB608EB23FDDB7621B12D4@008-AM1MPN1-042.mgdnok.nokia.com>
In-Reply-To: <E44893DD4E290745BB608EB23FDDB7621B12D4@008-AM1MPN1-042.mgdnok.nokia.com>
Content-Type: text/plain; charset="ISO-8859-1"; format="flowed"
Content-Transfer-Encoding: 8bit
X-Virus-Scanned: ClamAV using ClamSMTP
X-Brightmail-Tracker: AAAAAA==
Subject: Re: [rtcweb] Data channel comments and questions
X-BeenThere: rtcweb@ietf.org
X-Mailman-Version: 2.1.12
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: Fri, 30 Mar 2012 19:15:12 -0000

Hi Markus,

see in line

On 3/29/12 10:23 PM, Markus.Isomaki@nokia.com wrote:
> Hi,
>
> Some comments on the data channel proposal:
>
> 1. Congestion control: If no real-time sessions are on, TCP-style loss-driven congestion control is fine. However, if voice/video session is up, such congestion control would be disasterous to the real-time traffic quality if sendind or receiving more than a slight amount of data. Especially in mobile access networks the user would bloat his/her own buffers very easily. In that case, some less-than-best-effort congestion control algorithm รก la LEDBAT would be required. It would be best to make this a MUST requirement on implementations, otherwise we will get a lot of crappy video even if the codec was better than H.261 :-)
good point worth to discuss

the congestion control algorithm in the actual SCTP open source userland 
implementation is a TCP-friendly congestion control.
As I said during the presentation we can change it if we see the reason 
not to use it (and you have already some good one)...
however it should be clear that at moment SCTP does not have any way to 
negotiate the congestion control algorithm to use in an association.

So whatever we choose it will be the one used in all the possible 
scenarios (e.g. voice/video session up or down, etc).

>
> 2. Multihoming and interface switching: I don't suggest going for the multipath support on the SCTP level. I think it would be best to deal with this through ICE in the same way as for RTP, i.e. adding and removing candidates as interfaces become available or go. Or let the application handle it by creating a new data channel and continue from the breakpoint. The most important requirement is that the application gets notified about these changes downstrairs so it can act.
that is exact the proposal in the data-channel draft.
Anyway you can not use multihoming because of the fact that SCTP runs on 
top of DTLS
>
>
> 3. HTTP tunneling: In practice we are going to need HTTP tunneling last-resort option for the data channel as well. If doing so, what will the protocol stack look like? Is it SCTP/DTLS/UDP/HTTP/TLS/TCP? Or can we collapse some of these layers. I think we'd better.

this is something to figure it out.
Eric proposal make sense to me;
another possibility would be use WebSocket when you have to tunneling 
data over HTTP/HTTPS.

Salvatore

-- 
Salvatore Loreto, PhD
www.sloreto.com