Re: [rtcweb] Open data channel issues

Justin Uberti <juberti@google.com> Mon, 03 March 2014 14:37 UTC

Return-Path: <juberti@google.com>
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 3250F1A01E1 for <rtcweb@ietfa.amsl.com>; Mon, 3 Mar 2014 06:37:44 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.925
X-Spam-Level:
X-Spam-Status: No, score=-1.925 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RP_MATCHES_RCVD=-0.547, SPF_PASS=-0.001] 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 65HAA4Cf2qtu for <rtcweb@ietfa.amsl.com>; Mon, 3 Mar 2014 06:37:38 -0800 (PST)
Received: from mail-vc0-x232.google.com (mail-vc0-x232.google.com [IPv6:2607:f8b0:400c:c03::232]) by ietfa.amsl.com (Postfix) with ESMTP id DB5CF1A01DD for <rtcweb@ietf.org>; Mon, 3 Mar 2014 06:37:36 -0800 (PST)
Received: by mail-vc0-f178.google.com with SMTP id ik5so3689161vcb.9 for <rtcweb@ietf.org>; Mon, 03 Mar 2014 06:37:33 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type; bh=MPs0x7JqZqSBsRcIjIcXSTwgRreanCax2HSDxqPt2jI=; b=WrUm/UgRQwVzG4AgNDwM0ebfvHOPQ5+NlxRbqpO59qoq4ds8x1DBYR7oGUygOIDKol A1sNFwYQKQYDHLqP1xOFO4ORIDGDKRUYAG/sNAJ2XS2vqdqc768qGhdSfj+JptoLZ0FJ j2VdUnuEYIF+/Y2CNb6Yq0TGWlamq4mtKjPClgmaIhVKe6/a33p4UXIJBcrDKUFsDFzR B03PqfGhfmmJPen7INjzORP2l6hig6v5yamfH2a82GPo74t/n5VJYiird3uM3Mee6CkQ ibq15aa7Uh4lkWW2L8YjOc7fL7F6UFOi7JSJFDizPBDSaK8gaKZzUXbB6Wn3Bq4o3O2H Wepg==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc:content-type; bh=MPs0x7JqZqSBsRcIjIcXSTwgRreanCax2HSDxqPt2jI=; b=Xc0gOWZY2YXW9pzeq789QreEhalPVVVQwSbtug17iDNz2RB+2cKQoUQuqS/8j8zu75 36L4voKl5rwEpRcMSx77eAVNZ2a/2sYh3kK2WsJs4P/PqN2k+unQ8CAqfICeRfsmb7zj J8KqRz+0pomXky5+7pJF/nipFwz7/R5oVHGAVTLYlzOUYWSqz4uzeKFEFcgb023iro8s dnCvLyyaFtBEegtEpHnGD0cjx7H249gGlPZPKUzOgmgtyHrkJtwachwS1JCA6LAP5vyr 4OpNT2k44FbKLz3eJq7oYG5K2KGdTgQkabJLS7MTlHdaU+Wu94H77a/DgwlZ9FFsg5Oq ePSg==
X-Gm-Message-State: ALoCoQmfwdMlA3m4cMLzSjKlu35w86gVwADoLhyx28OcB1eAQZ2fNepGu5g3CkrlzdHhn5Tbt9Vz2PCQh0YwEQ0v4NH9wlPU+oge363Eq9VMVhbeKr2SflTbw4OPdUm/5C25zzjjwK5//oXDuOgmUlszD9tzehJG/x+NGOOLP63pHeYPzutBz1SsJwDg51Oq0XbQUhjTxmXt
X-Received: by 10.52.29.209 with SMTP id m17mr120132vdh.72.1393857453734; Mon, 03 Mar 2014 06:37:33 -0800 (PST)
MIME-Version: 1.0
Received: by 10.52.89.170 with HTTP; Mon, 3 Mar 2014 06:37:13 -0800 (PST)
In-Reply-To: <531488F0.7090300@jesup.org>
References: <31B9253D-E826-4D07-A8A1-1B062B50F163@lurchi.franken.de> <530D9CC5.5080508@ericsson.com> <5312FBBC.5080006@jesup.org> <CAOJ7v-2GHt37u8raWDKquNFLCjSv-ptP0YGojPwuLv02da_m1Q@mail.gmail.com> <5313EC0D.9030808@jesup.org> <CAOJ7v-3L5_V2wuwVLKpz61VHey7yx3LnG_xrPLb5W+6DOLiEJw@mail.gmail.com> <53146B2C.8080008@jesup.org> <CAOJ7v-3q2TJnVFYLJFJ=mCjdOtOY9-0W1t6=m+_gNC8+Z65b9w@mail.gmail.com> <531488F0.7090300@jesup.org>
From: Justin Uberti <juberti@google.com>
Date: Mon, 3 Mar 2014 06:37:13 -0800
Message-ID: <CAOJ7v-15EZjPSjAPotCdnZEu4kgeLzBXJdFnYaccaN1ViBvyjQ@mail.gmail.com>
To: Randell Jesup <randell-ietf@jesup.org>
Content-Type: multipart/alternative; boundary=20cf307d054065d50604f3b4ba56
Archived-At: http://mailarchive.ietf.org/arch/msg/rtcweb/olF2JWfekk4BqRFZ_36ageVxGSo
Cc: "rtcweb@ietf.org" <rtcweb@ietf.org>
Subject: Re: [rtcweb] Open data channel issues
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, 03 Mar 2014 14:37:44 -0000

On Mon, Mar 3, 2014 at 5:51 AM, Randell Jesup <randell-ietf@jesup.org>wrote;wrote:

>  On 3/3/2014 8:28 AM, Justin Uberti wrote:
>
> On Mon, Mar 3, 2014 at 3:44 AM, Randell Jesup <randell-ietf@jesup.org>wrote;wrote:
>
>>  On 3/3/2014 6:18 AM, Justin Uberti wrote:
>>
>>  On Sun, Mar 2, 2014 at 6:42 PM, Randell Jesup <randell-ietf@jesup.org>wrote;wrote:
>>
>>
>>  So I still think manual chunking seems like a reasonable thing to
>> support. I don't quite get the congestion control concerns; just because
>> there is a max chunk size doesn't mean the impl can't buffer multiple
>> chunks in bufferedAmount; the app could let that fill up to a degree to
>> avoid having to poll constantly to prevent underrun.
>>
>>
>>       On a slow link this will work if the browser isn't janky.  On a
>>> fast link GC pauses and other things may cause the buffer to drain out and
>>> go idle for significant periods.
>>>
>>
>>  Since the amount buffered is up to the app, the app can just increase
>> the buffer size to provide enough data to cover the next second or so of
>> transfer.
>>
>>
>>  How does the app increase the size of the internal SCTP buffers?  (And
>> that buffer is shared by all channels, of course).
>>
>
>  What I meant is the app can make multiple calls to send() at a time,
> each with a chunk, which will be buffered in the api layer and increase
> bufferedAmount.
>
>
> Aha - that explains "increase the buffer size".  Yes, that will work,
> modulo that the app will have to track the actual bandwidth by either
> monitoring how fast the bufferedAmount drains, or via a JS API to report
> bandwidth ala the bug I opened on JS interaction with congestion control.
> I still feel this pushes some level of congestion control into the JS app
> (and done like trying to thread needles with oven mitts on - ok, mild
> exaggeration) or the app will simply ignore this issue (likely) and get
> sub-optimal performance, perhaps significantly.  So I think more thought
> would be useful here, especially at the W3/JS level.
>
> If we have the bandwidth reporting, having the app choose a reasonable
> amount of buffering would be much easier/simpler.
>

In the simplest case, you could just have a medium-sized buffer of size
(max expected transfer rate * worst-case poll interval); 10 MB would be
plenty for almost all cases.

If you wanted to be smarter, you could start with 1MB buffer, poll every
100 ms, and then adjust the buffer size to be at least ((data sent since
last poll / time since last poll) * worst-case poll interval), where
worst-case poll interval, accounting for GC, is somewhere around 1 second.

I don't think this pushes CC onto apps, it just pushes spooling onto them,
which is the consequence of not having streams yet.


> --
> Randell Jesup -- rjesup a t mozilla d o t com
>
>
> _______________________________________________
> rtcweb mailing list
> rtcweb@ietf.org
> https://www.ietf.org/mailman/listinfo/rtcweb
>
>