Re: [rtcweb] Open data channel issues

Michael Tuexen <Michael.Tuexen@lurchi.franken.de> Mon, 03 March 2014 22:45 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 2C8281A01E8 for <rtcweb@ietfa.amsl.com>; Mon, 3 Mar 2014 14:45:47 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.098
X-Spam-Level:
X-Spam-Status: No, score=-2.098 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_DE=0.35, RP_MATCHES_RCVD=-0.547, 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 QvZ6hQOOAqL6 for <rtcweb@ietfa.amsl.com>; Mon, 3 Mar 2014 14:45:43 -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 DF7A81A00DD for <rtcweb@ietf.org>; Mon, 3 Mar 2014 14:45:42 -0800 (PST)
Received: from [130.129.15.249] (unknown [130.129.15.249]) (Authenticated sender: macmic) by mail-n.franken.de (Postfix) with ESMTP id A61571C103E6D; Mon, 3 Mar 2014 23:45:38 +0100 (CET)
Content-Type: text/plain; charset=windows-1252
Mime-Version: 1.0 (Mac OS X Mail 7.2 \(1874\))
From: Michael Tuexen <Michael.Tuexen@lurchi.franken.de>
In-Reply-To: <E1FE4C082A89A246A11D7F32A95A17826E006069@US70UWXCHMBA02.zam.alcatel-lucent.com>
Date: Mon, 3 Mar 2014 22:45:36 +0000
Content-Transfer-Encoding: quoted-printable
Message-Id: <7387F0E6-2DE0-4372-8559-B9DE9B9F365F@lurchi.franken.de>
References: <31B9253D-E826-4D07-A8A1-1B062B50F163@lurchi.franken.de> <530D9CC5.5080508@ericsson.com> <5312FBBC.5080006@jesup.org> <CAOJ7v-2GHt37u8raWDKquNFLCjSv-ptP0YGojPwuLv02da_m1Q@mail.gmail.com> <5313EC0D.9030808@jesup.org> <CAOJ7v-3L5_V2wuwVLKpz61VHey7yx3LnG_xrPLb5W+6DOLiEJw@mail.gmail.com> <53146B2C.8080008@jesup.org> <CABkgnnV1BdAMvFqGq8xiL0Zu28aZBCAdPwZB8whpMeXrCD7AHQ@mail.gmail.com> <53149F0C.6070001@jesup.org> <CAOJ7v-0xSq2xvF_5Do-R4SG6yAVNdqELwRvt_VBU69ir6nHhGQ@mail.gmail.com> <E1FE4C082A89A246A11D7F32A95A17826E006069@US70UWXCHMBA02.zam.alcatel-lucent.com>
To: "Makaraju, Maridi Raju (Raju)" <Raju.Makaraju@alcatel-lucent.com>
X-Mailer: Apple Mail (2.1874)
Archived-At: http://mailarchive.ietf.org/arch/msg/rtcweb/g0ELk6ERtYL9RWof1PQAI8FLgMQ
Cc: Randell Jesup <randell-ietf@jesup.org>, "rtcweb@ietf.org" <rtcweb@ietf.org>
Subject: Re: [rtcweb] Open data channel issues
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: Mon, 03 Mar 2014 22:45:47 -0000

On 03 Mar 2014, at 22:19, Makaraju, Maridi Raju (Raju) <Raju.Makaraju@alcatel-lucent.com> wrote:

> Sorry to jump in from middle of nowhere in this interesting conversation. I couldn’t resist providing this feedback and I hope it is useful.
>  
> First, on “EOR solving monopolization issue”:
> I could be wrong, but I am not sure how EOR based approach avoids SCTP link monopolization?! Per my understanding EOR is a local send () utility rather than receive side utility and it is implemented on top of base SCTP RFC (so no indication of special EOR in SCTP headers other than base SCTP RFC B/E fragment indication bits). Once a send () with EOR set to false is called, on a stream id, the SCTP link is monopolized until send () on same stream id with EOR set to true is called; so same limitation exist.  EOR allows sending side to start sending chunks without waiting for complete data. EOR has no impact on receiving side, the SCTP stack waits for last chunk (which is the result of sending side setting EOR=true) and delivers entire message to app.
You are right, if you consider RFC 4960. But using
http://tools.ietf.org/html/draft-ietf-tsvwg-sctp-ndata-00
overcomes this limitation. You can have on each stream a message being sent in explicit EOR mode.
Using an interleaving scheduler, they get interleaved on the wire. So you need the NDATA extension...
>  
> New PC approach:
> If an application is sensitive to SCTP link monopolisation then there is another option it can consider – use of separate new PeerConnection (PC) for the data channel(s) which may monopolize the link.
> Depending on how an application is designed, using a new PC could be simpler than having an application level chunking protocol (fragmentation and reassembly).  If app needs such “heavy” data channel infrequently then it can create new PC as needed; if it is needed frequently then a dedicated PC can be allocated and keep it open all the time.
>  
> One disadvantage with application level chunking protocol is both the peers need to use it; so it may not work between clients of different types or same clients with different versions. New PC based approach obviously does not have this issue as no chunking is involved.
>  
> At first, new PC approach may appear heavy weight wrt # of PCs in use (which I don’t think an issue on browsers), ICE overhead for new PC etc. But in comparision to application level chunking new PC approach may not be that bad.
I think the large message support with NDATA is sufficient to do whatever RTCWeb wants...
>  
> Please see additional comments inline.
>  
> -Raju
>  
> From: rtcweb [mailto:rtcweb-bounces@ietf.org] On Behalf Of Justin Uberti
> Sent: Monday, March 03, 2014 11:54 AM
> To: Randell Jesup
> Cc: rtcweb@ietf.org
> Subject: Re: [rtcweb] Open data channel issues
>  
>  
>  
> 
> On Mon, Mar 3, 2014 at 7:26 AM, Randell Jesup <randell-ietf@jesup.org> wrote:
> On 3/3/2014 8:53 AM, Martin Thomson wrote:
> On 3 March 2014 03:44, Randell Jesup <randell-ietf@jesup.org> wrote:
> Hopefully so, though I hate forcing apps to include a bunch of code for
> backwards compat for a year or two (and many won't, or won't test it, etc).
> That hurts the feature.  And today no one has ndata.
> Since WebRTC is behind a flag, I don't find this particularly
> convincing.  We can implement ndata.
>  
> I don't understand the "behind a flag" comment; an app using DataChannels for anything variable-length (unless with low bounds) must care until all old implementations are gone.  Since we already have DataChannel impls in  ESR releases, there's no avoiding this if we rely on that (even worse, since this undefined property doesn't exist yet (let alone in ESR), the app has to handle that case as well).  Or add browser and version sniffing to all the apps...
>  
> 
> I think that we could even remove our temporary length restriction.
>  
> Sure, we can.  This will reduce or eliminate source changes for apps that don't care about interleaving, which is a plus.  It will cause total stall of all other DataChannels during  transmission of one large message, which some applications would be ok with, and others would not, and so those that would not would have to somehow deal with it.
> 
> So, applications that are ok with blocking other channels with large sends could be allowed to send arbitrary-sized messages, and receivers would be required to receive them (without chunking). Applications that do care about other channels would need to restrict their sending size when ndata isn't available at both ends.  We really only need to know if ndata is available and expose that fact to the application, not a receive size from the receiver.
> 
> So this plan would be:
> 1) We expose ndata being agreed to (currently == false);
> 2) We turn off the PPID chunking in Firefox (and live with ESR24 and current revs of Firefox not being compatible; see 2a)
> 2a) we make sure the app can detect if the local client has the ndata property at all (supports this solution).
> 3) We make sure Chrome and Firefox both implement both EOR sending and EOR reception and unlimited (or virtually) send/receive sizes.
> [Raju] This requires PeerConnection API to indicate EOR during send(). Right? Which may be useful in some cases where app wants to send partial data as it is available/ready. But as explained above, in my opinion EOR won’t solve SCTP link monopolization and unncessarily introduces overhead at application.
At the API to the SCTP stack you need EOR support. But this API is not exposed to the JS user.
The JS user can just call send(bigmessage) and it works...
> 
> For bonus points, on EOR reception of a blob, spool it to disk in the browser (if over some limit perhaps), and on EOR send of a blob, optimize it to avoid send-side memory hits and performance issues.
> 
> This will break large send/receive between Chrome and current/older Firefox - but those are broken today by Chrome not implement PPID chunking and Firefox doing so.  Firefox can still fall back on PPID chunking if it knows it's talking to another Firefox until we decide that this no longer matters.  I could be wrong, but I think Chrome doesn't support EOR sending currently; I know Firefox doesn't since we were using PPID chunking, so we'd need to add that.
> 
> Once ndata is supported, all will work well, and applications that didn't care about interleaving don't have to change, and those that do will trigger on ndata and switch (and they can test ndata==true mode reasonably well by forcing it in the app, since send(large) will work).
>  
> While I agree with the final outcome of #3, I don't think going down the 1/2/2a path makes
> sense, since it leads to an additional intermediate state over the current situation. i.e. we end up with 3 states:
> a) today: max safe send is 16 KB
> b) soon: ndata exists, but large sends lock out other sends
> c) final: ndata exists, and large sends work OK
>  
> I would rather maintain a) or similar for now (using the max-message-size param) and jump to c) when we have the right stuff in SCTP.
> [Raju] With 16KB safe size won’t applications have to have their own chunking protocol? as per my understanding EOR won’t solve the monopolization issue, so it adds no value.
>  
> To avoid applications coming up with their own chunking protocol, an attractive alternative would be to use the PPID chunking that’s already mentioned abovr and implemented by Firefox. Then the issue of interworking pushed down to browser from application area. But this obviously requires browsers on both the ends to support this PPID based chunking.
... correct. And at the last RTCWeb session it was decided to avoid this intermediate step and
just use NDATA...

Best regards
Michael
>  
> -Raju
>  
> 
> 
> -- 
> Randell Jesup -- rjesup a t mozilla d o t com
> 
> _______________________________________________
> rtcweb mailing list
> rtcweb@ietf.org
> https://www.ietf.org/mailman/listinfo/rtcweb
>  
> _______________________________________________
> rtcweb mailing list
> rtcweb@ietf.org
> https://www.ietf.org/mailman/listinfo/rtcweb