Re: [rtcweb] RTCWEB Data Channel: message interleaving
Michael Tuexen <Michael.Tuexen@lurchi.franken.de> Thu, 06 February 2014 08:08 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 8273C1A0091 for <rtcweb@ietfa.amsl.com>; Thu, 6 Feb 2014 00:08:42 -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 CtA5raihvyY8 for <rtcweb@ietfa.amsl.com>; Thu, 6 Feb 2014 00:08:39 -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 6CBEE1A0090 for <rtcweb@ietf.org>; Thu, 6 Feb 2014 00:08:39 -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 0591F1C0E979C; Thu, 6 Feb 2014 09:08:36 +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: <E1FE4C082A89A246A11D7F32A95A17826DFCDB0B@US70UWXCHMBA02.zam.alcatel-lucent.com>
Date: Thu, 06 Feb 2014 09:08:36 +0100
Content-Transfer-Encoding: quoted-printable
Message-Id: <D0E5C5FC-43FA-4BEF-941F-367573D9CBDA@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>
To: "Makaraju, Maridi Raju (Raju)" <Raju.Makaraju@alcatel-lucent.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:08:42 -0000
On Feb 6, 2014, at 12:33 AM, "Makaraju, Maridi Raju (Raju)" <Raju.Makaraju@alcatel-lucent.com> wrote: >> "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. draft-stewart-tsvwg-sctp-ndata has been adopted as a WG item in the TSVWG. We need to update and resubmit it. >> - 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. If NDATA is not supported, the message size is limited to avoid the monopolization. This limit will be signalled through SDP. Best regards Michael > You can apply this to even more sensitive gaming apps. > > -Raju > > _______________________________________________ > rtcweb mailing list > rtcweb@ietf.org > https://www.ietf.org/mailman/listinfo/rtcweb >
- [rtcweb] RTCWEB Data Channel: Usage of PPID for p… Christer Holmberg
- Re: [rtcweb] RTCWEB Data Channel: Usage of PPID f… Peter Thatcher
- Re: [rtcweb] RTCWEB Data Channel: Usage of PPID f… Makaraju, Maridi Raju (Raju)
- Re: [rtcweb] RTCWEB Data Channel: Usage of PPID f… Peter Thatcher
- Re: [rtcweb] RTCWEB Data Channel: Usage of PPID f… Michael Tuexen
- Re: [rtcweb] RTCWEB Data Channel: Usage of PPID f… Makaraju, Maridi Raju (Raju)
- Re: [rtcweb] RTCWEB Data Channel: Usage of PPID f… Michael Tuexen
- Re: [rtcweb] RTCWEB Data Channel: Usage of PPID f… Paul Kyzivat
- Re: [rtcweb] RTCWEB Data Channel: Usage of PPID f… Makaraju, Maridi Raju (Raju)
- Re: [rtcweb] RTCWEB Data Channel: Usage of PPID f… Makaraju, Maridi Raju (Raju)
- Re: [rtcweb] RTCWEB Data Channel: message interle… Paul Kyzivat
- Re: [rtcweb] RTCWEB Data Channel: message interle… Makaraju, Maridi Raju (Raju)
- Re: [rtcweb] RTCWEB Data Channel: Usage of PPID f… Christer Holmberg
- Re: [rtcweb] RTCWEB Data Channel: message interle… Michael Tuexen
- Re: [rtcweb] RTCWEB Data Channel: Usage of PPID f… Michael Tuexen
- Re: [rtcweb] RTCWEB Data Channel: Usage of PPID f… Christer Holmberg
- Re: [rtcweb] RTCWEB Data Channel: message interle… Christer Holmberg
- Re: [rtcweb] RTCWEB Data Channel: Usage of PPID f… Michael Tuexen
- Re: [rtcweb] RTCWEB Data Channel: message interle… Michael Tuexen
- Re: [rtcweb] RTCWEB Data Channel: Usage of PPID f… Makaraju, Maridi Raju (Raju)
- Re: [rtcweb] RTCWEB Data Channel: Usage of PPID f… Christer Holmberg
- Re: [rtcweb] RTCWEB Data Channel: message interle… Makaraju, Maridi Raju (Raju)
- Re: [rtcweb] RTCWEB Data Channel: message interle… Paul Kyzivat
- Re: [rtcweb] RTCWEB Data Channel: Usage of PPID f… Paul Kyzivat
- Re: [rtcweb] RTCWEB Data Channel: Usage of PPID f… Michael Tuexen
- Re: [rtcweb] RTCWEB Data Channel: Usage of PPID f… Michael Tuexen
- Re: [rtcweb] RTCWEB Data Channel: Usage of PPID f… Christer Holmberg
- Re: [rtcweb] RTCWEB Data Channel: Usage of PPID f… Christer Holmberg
- Re: [rtcweb] RTCWEB Data Channel: Usage of PPID f… Harald Alvestrand
- Re: [rtcweb] RTCWEB Data Channel: message interle… Makaraju, Maridi Raju (Raju)
- Re: [rtcweb] RTCWEB Data Channel: Usage of PPID f… Michael Tuexen
- Re: [rtcweb] RTCWEB Data Channel: Usage of PPID f… Christer Holmberg
- Re: [rtcweb] RTCWEB Data Channel: Usage of PPID f… Michael Tuexen
- [rtcweb] PPID, UTF-16 and DOMString (Re: RTCWEB D… Harald Alvestrand
- Re: [rtcweb] RTCWEB Data Channel: message interle… Justin Uberti
- Re: [rtcweb] RTCWEB Data Channel: Usage of PPID f… Christer Holmberg
- Re: [rtcweb] PPID, UTF-16 and DOMString (Re: RTCW… Makaraju, Maridi Raju (Raju)
- Re: [rtcweb] PPID, UTF-16 and DOMString (Re: RTCW… Martin Thomson
- Re: [rtcweb] PPID, UTF-16 and DOMString (Re: RTCW… Christer Holmberg
- Re: [rtcweb] PPID, UTF-16 and DOMString (Re: RTCW… Makaraju, Maridi Raju (Raju)
- Re: [rtcweb] PPID, UTF-16 and DOMString (Re: RTCW… Michael Tuexen
- Re: [rtcweb] PPID, UTF-16 and DOMString (Re: RTCW… Christer Holmberg
- Re: [rtcweb] PPID, UTF-16 and DOMString (Re: RTCW… Christer Holmberg
- Re: [rtcweb] PPID, UTF-16 and DOMString (Re: RTCW… Michael Tuexen
- Re: [rtcweb] PPID, UTF-16 and DOMString (Re: RTCW… Makaraju, Maridi Raju (Raju)
- Re: [rtcweb] PPID, UTF-16 and DOMString (Re: RTCW… Christer Holmberg
- Re: [rtcweb] PPID, UTF-16 and DOMString (Re: RTCW… Makaraju, Maridi Raju (Raju)
- Re: [rtcweb] PPID, UTF-16 and DOMString (Re: RTCW… Randell Jesup
- Re: [rtcweb] PPID, UTF-16 and DOMString (Re: RTCW… Michael Tuexen
- Re: [rtcweb] RTCWEB Data Channel: Usage of PPID f… Paul Kyzivat
- Re: [rtcweb] PPID, UTF-16 and DOMString (Re: RTCW… Harald Alvestrand
- Re: [rtcweb] PPID, UTF-16 and DOMString (Re: RTCW… Makaraju, Maridi Raju (Raju)