IETF Logo Mail Archive

Re: [rtcweb] RTCWEB Data Channel: message interleaving

"Makaraju, Maridi Raju (Raju)" <Raju.Makaraju@alcatel-lucent.com> Thu, 06 February 2014 12:08 UTC

Return-Path: <Raju.Makaraju@alcatel-lucent.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 719DB1A03A5 for <rtcweb@ietfa.amsl.com>; Thu, 6 Feb 2014 04:08:47 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.9
X-Spam-Level:
X-Spam-Status: No, score=-6.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5] 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 RcHVrYhOFEbE for <rtcweb@ietfa.amsl.com>; Thu, 6 Feb 2014 04:08:45 -0800 (PST)
Received: from ihemail1.lucent.com (ihemail1.lucent.com [135.245.0.33]) by ietfa.amsl.com (Postfix) with ESMTP id AF6771A03A3 for <rtcweb@ietf.org>; Thu, 6 Feb 2014 04:08:45 -0800 (PST)
Received: from us70tusmtp1.zam.alcatel-lucent.com (h135-5-2-63.lucent.com [135.5.2.63]) by ihemail1.lucent.com (8.13.8/IER-o) with ESMTP id s16C8gmK010321 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Thu, 6 Feb 2014 06:08:42 -0600 (CST)
Received: from US70UWXCHHUB01.zam.alcatel-lucent.com (us70uwxchhub01.zam.alcatel-lucent.com [135.5.2.48]) by us70tusmtp1.zam.alcatel-lucent.com (GMO) with ESMTP id s16C8feO011050 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Thu, 6 Feb 2014 07:08:42 -0500
Received: from US70UWXCHMBA02.zam.alcatel-lucent.com ([169.254.8.212]) by US70UWXCHHUB01.zam.alcatel-lucent.com ([135.5.2.48]) with mapi id 14.02.0247.003; Thu, 6 Feb 2014 07:08:41 -0500
From: "Makaraju, Maridi Raju (Raju)" <Raju.Makaraju@alcatel-lucent.com>
To: Michael Tuexen <Michael.Tuexen@lurchi.franken.de>, Christer Holmberg <christer.holmberg@ericsson.com>
Thread-Topic: [rtcweb] RTCWEB Data Channel: message interleaving
Thread-Index: AQHPIsaGtTtVxkBpl0uo4mWaQvx+DpqnSFawgADrMwCAAAhtgIAAA9AA///gvGA=
Date: Thu, 06 Feb 2014 12:08:41 +0000
Message-ID: <E1FE4C082A89A246A11D7F32A95A17826DFCF7E6@US70UWXCHMBA02.zam.alcatel-lucent.com>
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> <6A0518D4-D15D-4970-A56C-87FEDA60F978@lurchi.franken.de>
In-Reply-To: <6A0518D4-D15D-4970-A56C-87FEDA60F978@lurchi.franken.de>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
x-originating-ip: [135.5.27.17]
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
X-Scanned-By: MIMEDefang 2.57 on 135.245.2.33
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 12:08:47 -0000

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

[Raju] The key is "next revision of the SDP ID". It is understood that NDATA support indication is only avilable after both the peers talk. But then, the initial message sizes were already conveyed (to make them talk). Now, if the new message size per "no NDATA support"/"NDATA support" is lower/higher then another ound of end-to-end signaling is needed to update the peers. Not optimal, but I do not see any other better way other than "starting conservatively with lower values initially assuming no NDATA support; later when NDATA support becomes widespread default values can be higher".

Best Regards
Raju

v2.23.0 | Report a Bug | By Email