Re: [rtcweb] Data channel comments and questions

Eric Rescorla <ekr@rtfm.com> Thu, 29 March 2012 20:28 UTC

Return-Path: <ekr@rtfm.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 DC20821E80EF for <rtcweb@ietfa.amsl.com>; Thu, 29 Mar 2012 13:28:26 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -102.977
X-Spam-Level:
X-Spam-Status: No, score=-102.977 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_LOW=-1, 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 kvjSFHkAl412 for <rtcweb@ietfa.amsl.com>; Thu, 29 Mar 2012 13:28:26 -0700 (PDT)
Received: from mail-vx0-f172.google.com (mail-vx0-f172.google.com [209.85.220.172]) by ietfa.amsl.com (Postfix) with ESMTP id C149721E80CD for <rtcweb@ietf.org>; Thu, 29 Mar 2012 13:28:24 -0700 (PDT)
Received: by vcbfk13 with SMTP id fk13so2091137vcb.31 for <rtcweb@ietf.org>; Thu, 29 Mar 2012 13:28:24 -0700 (PDT)
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:x-originating-ip:in-reply-to:references:from:date :message-id:subject:to:cc:content-type:content-transfer-encoding :x-gm-message-state; bh=yv6tk8c80t0xw+OCpV/D2mAItJlGg/J40pb9KM2AVtQ=; b=iiBkkK3fUoEhXeKb07dFKogbCLoyg/KdJN2eQhWxSpNtIt8C+eNXCK12jc18BVejIi NMGwv5g+yxni+p9P+UUdb1fHKhj28n7qJ3GnmSvfcvWrMBGCySS+e3zPBtgEj6ZyxGoo PwgrlYTOCutB5cSqFwItuK6QD6TmT4ehNoA8N0H94IIk8yYmV2XuVZMELrhKl/MM9Ou2 VjAU26YN8WAXiAzkYFPtrecxxsoqcfLHv1ukJ93wePwEXDJPzpoThZw7FKNtTm6vRZYI zstBLurFuHzlfS8bugXFPICuwmB7FRr0snqyatdMBtztXFjEzq4mqnF1/vOdc4MHpuWP LuQg==
Received: by 10.52.173.38 with SMTP id bh6mr13733022vdc.43.1333052904331; Thu, 29 Mar 2012 13:28:24 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.52.22.195 with HTTP; Thu, 29 Mar 2012 13:27:44 -0700 (PDT)
X-Originating-IP: [2001:df8:0:80:5a55:caff:fef1:5a11]
In-Reply-To: <E44893DD4E290745BB608EB23FDDB7621B12D4@008-AM1MPN1-042.mgdnok.nokia.com>
References: <E44893DD4E290745BB608EB23FDDB7621B12D4@008-AM1MPN1-042.mgdnok.nokia.com>
From: Eric Rescorla <ekr@rtfm.com>
Date: Thu, 29 Mar 2012 22:27:44 +0200
Message-ID: <CABcZeBNF2UFdinTDWJy1Tet5yh1=CsiMt3YHZYAXWJLDvPgNSg@mail.gmail.com>
To: Markus.Isomaki@nokia.com
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable
X-Gm-Message-State: ALoCoQngVF+nyL0qtjw6u6bdX9tTJn3J/pre7N8IySmofUyuUUfTlR0hVl3RcwWmyftEai1wH7yn
Cc: rtcweb@ietf.org
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: Thu, 29 Mar 2012 20:28:27 -0000

On Thu, Mar 29, 2012 at 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 :-)
>
> 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.
>
> 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.

I don't think I understand point 3. Why would we need HTTP tunneling?
If we can bring
up a bidirectional UDP channel, then why would we need to run HTTP over it?

-Ekr