IETF Logo Mail Archive

Re: [rtcweb] RTCWEB Data Channel: message interleaving

"Makaraju, Maridi Raju (Raju)" <Raju.Makaraju@alcatel-lucent.com> Thu, 06 February 2014 20:15 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 59CAE1A0463 for <rtcweb@ietfa.amsl.com>; Thu, 6 Feb 2014 12:15:21 -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 4EiFt7gxTx6V for <rtcweb@ietfa.amsl.com>; Thu, 6 Feb 2014 12:15:20 -0800 (PST)
Received: from ihemail3.lucent.com (ihemail3.lucent.com [135.245.0.37]) by ietfa.amsl.com (Postfix) with ESMTP id 079E11A0469 for <rtcweb@ietf.org>; Thu, 6 Feb 2014 12:15:19 -0800 (PST)
Received: from us70uusmtp3.zam.alcatel-lucent.com (h135-5-2-65.lucent.com [135.5.2.65]) by ihemail3.lucent.com (8.13.8/IER-o) with ESMTP id s16KFHAv010082 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Thu, 6 Feb 2014 14:15:17 -0600 (CST)
Received: from US70UWXCHHUB01.zam.alcatel-lucent.com (us70uwxchhub01.zam.alcatel-lucent.com [135.5.2.48]) by us70uusmtp3.zam.alcatel-lucent.com (GMO) with ESMTP id s16KFGs2002832 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Thu, 6 Feb 2014 15:15:16 -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 15:15:16 -0500
From: "Makaraju, Maridi Raju (Raju)" <Raju.Makaraju@alcatel-lucent.com>
To: Paul Kyzivat <pkyzivat@alum.mit.edu>, "rtcweb@ietf.org" <rtcweb@ietf.org>
Thread-Topic: [rtcweb] RTCWEB Data Channel: message interleaving
Thread-Index: AQHPIsaGtTtVxkBpl0uo4mWaQvx+DpqnSFawgADrMwCAAAhtgIAAOHlwgAA08KA=
Date: Thu, 06 Feb 2014 20:15:16 +0000
Message-ID: <E1FE4C082A89A246A11D7F32A95A17826DFD1A8F@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> <52F3B6E5.9040001@alum.mit.edu>
In-Reply-To: <52F3B6E5.9040001@alum.mit.edu>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
x-originating-ip: [135.5.27.18]
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.37
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 20:15:21 -0000

> > * If NDATA is not supported by both peers, a message size limit applies to
> avoid monopolisation.
> 
> I assume that in the RFC this will just be a MUST NOT. Will that apply
> to the SCTP implementation? Or to the SCTP user?
> 
> (In a practical sense, will this be implemented in the SCTP stack, in
> the DataChannel "stack", in the browser, or in javascript?)

[Raju] It has to be done exclusively by the application (Javascript for browser or some other language for native apps).
This is because per recent comments the browser/data-channel level fragmentation/reassembly, based on PPID, will be removed from data channel core spec.

-Raju

v2.23.0 | Report a Bug | By Email