Re: [rtcweb] RTCWEB Data Channel: message interleaving

Michael Tuexen <Michael.Tuexen@lurchi.franken.de> Thu, 06 February 2014 08:52 UTC

Return-Path: <Michael.Tuexen@lurchi.franken.de>
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 96B4D1A01FB for <rtcweb@ietfa.amsl.com>; Thu, 6 Feb 2014 00:52:28 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.086
X-Spam-Level:
X-Spam-Status: No, score=-2.086 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_DE=0.35, RP_MATCHES_RCVD=-0.535, SPF_HELO_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 K7rxaKeOrv3h for <rtcweb@ietfa.amsl.com>; Thu, 6 Feb 2014 00:52:27 -0800 (PST)
Received: from mail-n.franken.de (drew.ipv6.franken.de [IPv6:2001:638:a02:a001:20e:cff:fe4a:feaa]) by ietfa.amsl.com (Postfix) with ESMTP id 29C131A018E for <rtcweb@ietf.org>; Thu, 6 Feb 2014 00:52:27 -0800 (PST)
Received: from [192.168.1.200] (p508F1F22.dip0.t-ipconnect.de [80.143.31.34]) (Authenticated sender: macmic) by mail-n.franken.de (Postfix) with ESMTP id 9391A1C0E97AA; Thu, 6 Feb 2014 09:52:25 +0100 (CET)
Content-Type: text/plain; charset="us-ascii"
Mime-Version: 1.0 (Mac OS X Mail 6.6 \(1510\))
From: Michael Tuexen <Michael.Tuexen@lurchi.franken.de>
In-Reply-To: <7594FB04B1934943A5C02806D1A2204B1D15EDA7@ESESSMB209.ericsson.se>
Date: Thu, 06 Feb 2014 09:52:24 +0100
Content-Transfer-Encoding: quoted-printable
Message-Id: <6A0518D4-D15D-4970-A56C-87FEDA60F978@lurchi.franken.de>
References: <7594FB04B1934943A5C02806D1A2204B1D15BD1A@ESESSMB209.ericsson.se> <CAJrXDUGJO1C-47PmU7nwgRaZu19XTvsgwyq=6m=-vsL6LYqqLA@mail.gmail.com> <E1FE4C082A89A246A11D7F32A95A17826DFCD56D@US70UWXCHMBA02.zam.alcatel-lucent.com> <CAJrXDUGtf4U_jhX1hmbPTtXQidR=oHL0cCrKCaZhnLsQd8NvLw@mail.gmail.com> <A9D7F81A-C0E6-44DF-AFC4-4AAB1E78DA19@lurchi.franken.de> <E1FE4C082A89A246A11D7F32A95A17826DFCD683@US70UWXCHMBA02.zam.alcatel-lucent.com> <CFF06852-E7C6-4A9D-A15B-D79F45D24834@lurchi.franken.de> <52F2B457.8040305@alum.mit.edu> <E1FE4C082A89A246A11D7F32A95A17826DFCD8A3@US70UWXCHMBA02.zam.alcatel-lucent.com> <52F2C347.7000304@alum.mit.edu> <E1FE4C082A89A246A11D7F32A95A17826DFCDB0B@US70UWXCHMBA02.zam.alcatel-lucent.com> <D0E5C5FC-43FA-4BEF-941F-367573D9CBDA@lurchi.franken.de> <7594FB04B1934943A5C02806D1A2204B1D15EDA7@ESESSMB209.ericsson.se>
To: Christer Holmberg <christer.holmberg@ericsson.com>
X-Mailer: Apple Mail (2.1510)
Cc: "rtcweb@ietf.org" <rtcweb@ietf.org>
Subject: Re: [rtcweb] RTCWEB Data Channel: message interleaving
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: Thu, 06 Feb 2014 08:52:28 -0000

On Feb 6, 2014, at 9:38 AM, Christer Holmberg <christer.holmberg@ericsson.com> wrote:

> Hi,
> 
>> If NDATA is not supported, the message size is limited to avoid the monopolization. This limit will be signalled through SDP.
> 
> What do you mean by "signaled through SDP"?
> 
> Will the browser inform the JS app, using SDP, if the local and/or remote peer doesn't support NDATA?
What will be signalled in SDP is the maximum message size the end-point can handle. This is needed
anyway... If you don't support NDATA, you can signal a smaller value of, let's say 16KB or so.

NDATA is negotiated via the SCTP setup and there is no need for another signalling channel.

After the association is up, both sides know if NDATA is supported and, if I remember correctly,
there is a JS way of making message size limits available to the application. So you can
limit the message size if NDATA is not supported by both peers. So that is the plan:
* If NDATA is supported by both peers, message size are only limited by reassembly
  memory and any limit is signalled via SDP. The corresponding support will be in the
  next revision of the SDP ID.
* If NDATA is not supported by both peers, a message size limit applies to avoid monopolisation.

Best regards
Michael
> 
> Regards,
> 
> Christer
> 
>