Re: [rtcweb] Data channel comments and questions

Randell Jesup <randell-ietf@jesup.org> Fri, 30 March 2012 20:46 UTC

Return-Path: <randell-ietf@jesup.org>
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 CB0E721F86C7 for <rtcweb@ietfa.amsl.com>; Fri, 30 Mar 2012 13:46:55 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.814
X-Spam-Level:
X-Spam-Status: No, score=-1.814 tagged_above=-999 required=5 tests=[AWL=-0.215, BAYES_00=-2.599, J_BACKHAIR_24=1]
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 mhzj22cSz8ep for <rtcweb@ietfa.amsl.com>; Fri, 30 Mar 2012 13:46:55 -0700 (PDT)
Received: from r2-chicago.webserversystems.com (r2-chicago.webserversystems.com [173.236.101.58]) by ietfa.amsl.com (Postfix) with ESMTP id 34C1A21F85F9 for <rtcweb@ietf.org>; Fri, 30 Mar 2012 13:46:54 -0700 (PDT)
Received: from pool-108-16-41-249.phlapa.fios.verizon.net ([108.16.41.249] helo=[192.168.1.12]) by r2-chicago.webserversystems.com with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.69) (envelope-from <randell-ietf@jesup.org>) id 1SDiij-0003AH-KH for rtcweb@ietf.org; Fri, 30 Mar 2012 15:46:53 -0500
Message-ID: <4F761AFC.5090503@jesup.org>
Date: Fri, 30 Mar 2012 16:43:40 -0400
From: Randell Jesup <randell-ietf@jesup.org>
User-Agent: Mozilla/5.0 (Windows NT 5.1; rv:11.0) Gecko/20120312 Thunderbird/11.0
MIME-Version: 1.0
To: rtcweb@ietf.org
References: <E44893DD4E290745BB608EB23FDDB7621B12D4@008-AM1MPN1-042.mgdnok.nokia.com> <4F760634.207@ericsson.com>
In-Reply-To: <4F760634.207@ericsson.com>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 8bit
X-AntiAbuse: This header was added to track abuse, please include it with any abuse report
X-AntiAbuse: Primary Hostname - r2-chicago.webserversystems.com
X-AntiAbuse: Original Domain - ietf.org
X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12]
X-AntiAbuse: Sender Address Domain - jesup.org
X-Source:
X-Source-Args:
X-Source-Dir:
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 20:46:55 -0000

On 3/30/2012 3:15 PM, Salvatore Loreto wrote:
> On 3/29/12 10:23 PM, Markus.Isomaki@nokia.com wrote:
>> 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)...

Correct; please also see the presentation from the rtcweb Interim 
meeting in February that I gave; one issue it covered was congestion 
control.

We definitely want to both be able to balance bandwidth used by data 
channels versus media and to avoid data channels causing congestion that 
forces the media channels to degrade.

This could be done by:

a) developing a 'merged' congestion control regime for the media 
channels and the data channels.  As we're already getting a "total 
bandwidth" notification from the receiver, that calculation could 
include data channels, and let the sender allocate bits to media and the 
data channels according to that information.  In this scenario, the data 
channel code itself would be slaved to a wider congestion control.

b) run separate congestion control for the data channels based on a 
low-delay variant of classic TCP, such as Cx-TCP.  It so happens that 
the FreeBSD SCTP implementation includes a low-delay congestion 
algorithm based on an ancestor of the current Cx-TCP work.

Cx-TCP (for links see the Interim slides) runs in a low-delay fashion 
unless it's fighting with long-lived/saturating TCP flows, where it will 
transition into a loss-based behavior (with longer delay), and 
transition back if the TCP flows drop below bottleneck bandwidth.

c) run classic loss-based congestion control (the default), but put an 
external bandwidth limiter on it controlled by the main application and 
congestion code, limiting the data channels to a specified amount or 
fraction of the media channels.

d) run classic loss-based congestion control and let it compete with 
media; don't send large amounts of data, or pace it in the application. 
  Or live with the data channel killing your media.

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

Correct, though we could fix that - and we could give the JS control and 
let the app decide, since data channels are largely within-app 
proprietary connections.


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

Correct, though there was some in-room discussion of running it over 
multiple DTLS connections to support smooth handoff across interfaces 
(think mobile and 4g<->WiFi switchover).


-- 
Randell Jesup
randell-ietf@jesup.org