Re: [rtcweb] RTCWEB Data Channel: message interleaving

"Makaraju, Maridi Raju (Raju)" <Raju.Makaraju@alcatel-lucent.com> Wed, 05 February 2014 23:33 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 D95E81A0141 for <rtcweb@ietfa.amsl.com>; Wed, 5 Feb 2014 15:33:18 -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 G9asBCCzfFGN for <rtcweb@ietfa.amsl.com>; Wed, 5 Feb 2014 15:33:16 -0800 (PST)
Received: from ihemail1.lucent.com (ihemail1.lucent.com [135.245.0.33]) by ietfa.amsl.com (Postfix) with ESMTP id CBB241A021A for <rtcweb@ietf.org>; Wed, 5 Feb 2014 15:33:15 -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 s15NXDOg008184 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Wed, 5 Feb 2014 17:33:14 -0600 (CST)
Received: from US70TWXCHHUB03.zam.alcatel-lucent.com (us70twxchhub03.zam.alcatel-lucent.com [135.5.2.35]) by us70tusmtp1.zam.alcatel-lucent.com (GMO) with ESMTP id s15NXDtW031927 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Wed, 5 Feb 2014 18:33:13 -0500
Received: from US70UWXCHMBA02.zam.alcatel-lucent.com ([169.254.8.212]) by US70TWXCHHUB03.zam.alcatel-lucent.com ([135.5.2.35]) with mapi id 14.02.0247.003; Wed, 5 Feb 2014 18:33:12 -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+DpqnSFaw
Date: Wed, 05 Feb 2014 23:33:12 +0000
Message-ID: <E1FE4C082A89A246A11D7F32A95A17826DFCDB0B@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>
In-Reply-To: <52F2C347.7000304@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.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
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: Wed, 05 Feb 2014 23:33:19 -0000

> "available" could mean:
> 
> - once it is defined in a published RFC
> - once it is defined in a WG draft or RFC
> - once it is defined in an individual draft
>    (e.g., draft-stewart-tsvwg-sctp-ndata-03)
[Raju] I believe this is the case.
> - once it it is implemented in the browser you are using
[Raju] Browser implementations probably be more proactive in adapting this draft similar to number of other drafts that are being adapted in individual draft state.
I think this is one way browsers can differentiate themselves from others.
So, in my opinion, the "SHOULD" below probably ok and does not have to be a "MUST" as this NDATA is not a MUST have to deliver data channel requirements. If it has to be a "MUST" then I believe it has to be part of the requirement section 4 of http://tools.ietf.org/html/draft-ietf-rtcweb-data-channel-06#section-4 and list it as "MUST".

> 
> "SHOULD be used" could apply to:
> - browser implementers
> - application implementers
> 
> And then there is the question of what "SHOULD" means. Specifically,
> what are the conditions where it would be acceptable to *not* follow this?
> 
> I *hope* this is intended to mean that browser implementers MUST
> *implement* it, and *use* it in their implementation of DataChannel once
> draft-stewart-tsvwg-sctp-ndata becomes an RFC. And SHOULD do so now
> based on draft-stewart-tsvwg-sctp-ndata-03.
[Raju] I am not sure if this NDATA is a deal breaker for webrtc 1.0?! Some implementations may support while others not as NDATA is negotiated during association setup; if one end does not support then it is disabled.

If you don't have NDATA then one data channel stream may monopolize the SCTP link and could affect scenarios like:
- You sent 1GB file using data channel stream 0 (all at once without using something like MSRP).
- Then immediately, you send a small "Hi, some important stuff!" chat message using data channel stream 1.
Without NDATA, the other end will receive the text msg ONLY AFTER receiving the 1GB file!! With NDATA chat msg gets equal share of the SCTP link and gets delivered much sooner.
You can apply this to even more sensitive gaming apps.

-Raju