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
>