Re: [rtcweb] Open data channel issues

Randell Jesup <randell-ietf@jesup.org> Tue, 04 March 2014 07:31 UTC

Return-Path: <randell-ietf@jesup.org>
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 0C6641A03C8 for <rtcweb@ietfa.amsl.com>; Mon, 3 Mar 2014 23:31:43 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.9
X-Spam-Level:
X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001] 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 FeGSi6PZksF2 for <rtcweb@ietfa.amsl.com>; Mon, 3 Mar 2014 23:31:41 -0800 (PST)
Received: from r2-chicago.webserversystems.com (r2-chicago.webserversystems.com [173.236.101.58]) by ietfa.amsl.com (Postfix) with ESMTP id 9747C1A03C3 for <rtcweb@ietf.org>; Mon, 3 Mar 2014 23:31:41 -0800 (PST)
Received: from pool-71-175-4-197.phlapa.fios.verizon.net ([71.175.4.197]:4066 helo=[192.168.1.12]) by r2-chicago.webserversystems.com with esmtpsa (TLSv1:DHE-RSA-AES128-SHA:128) (Exim 4.82) (envelope-from <randell-ietf@jesup.org>) id 1WKjpC-0002HX-4q for rtcweb@ietf.org; Tue, 04 Mar 2014 01:31:38 -0600
Message-ID: <53158103.4000809@jesup.org>
Date: Tue, 04 Mar 2014 02:30:11 -0500
From: Randell Jesup <randell-ietf@jesup.org>
User-Agent: Mozilla/5.0 (Windows NT 5.1; rv:24.0) Gecko/20100101 Thunderbird/24.3.0
MIME-Version: 1.0
To: rtcweb@ietf.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> <CABkgnnV1BdAMvFqGq8xiL0Zu28aZBCAdPwZB8whpMeXrCD7AHQ@mail.gmail.com> <53149F0C.6070001@jesup.org> <CAOJ7v-0xSq2xvF_5Do-R4SG6yAVNdqELwRvt_VBU69ir6nHhGQ@mail.gmail.com> <53154AA8.4000202@jesup.org> <CABkgnnVWESeVgrPjYnxuhB5w1QTjbXNW+zBLfYRwUL059Q0_hw@mail.gmail.com>
In-Reply-To: <CABkgnnVWESeVgrPjYnxuhB5w1QTjbXNW+zBLfYRwUL059Q0_hw@mail.gmail.com>
Content-Type: text/plain; charset="ISO-8859-1"; format="flowed"
Content-Transfer-Encoding: 7bit
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-Get-Message-Sender-Via: r2-chicago.webserversystems.com: authenticated_id: randell@jesup.org
Archived-At: http://mailarchive.ietf.org/arch/msg/rtcweb/M5juK2miXJA_69FHiExo1zmPqxw
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: Tue, 04 Mar 2014 07:31:43 -0000

On 3/4/2014 2:00 AM, Martin Thomson wrote:
> On 4 March 2014 03:38, Randell Jesup <randell-ietf@jesup.org> wrote:
>> To take your suggestion:
>> a) applications assume 16KB if ndata wasn't negotiated (per the current
>> suggestion)
>> b) implement ndata and EOR support in the browsers, and drop the 16KB limit
>> when ndata is negotiated.
>> All this needs is "is ndata supported by this association" exposed to the
>> app; no sdp changes needed.  (One less dependency!)
>
> Or, to avoid vestigal crap in the API in the end state, when you
> install the 16K limitation, add an indicator that applications can
> check.  Once you remove the cap, remove the indicator.
>
> if (dataChannel.isNotVeryGood) {
>    chunkMessage(message);
> } else {
>    dataChannel.send(message);
> }

Yup, that works for me.  dataChannel.requiresFragmentation would be the 
wordy version or mustFragmentAt16K for self-documentation.

-- 
Randell Jesup -- rjesup a t mozilla d o t com