Re: [rtcweb] Open data channel issues

Michael Tuexen <Michael.Tuexen@lurchi.franken.de> Mon, 03 March 2014 12:10 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 2D7D81A0079 for <rtcweb@ietfa.amsl.com>; Mon, 3 Mar 2014 04:10:46 -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 Xpkd0_cWPS_W for <rtcweb@ietfa.amsl.com>; Mon, 3 Mar 2014 04:10: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 D7D751A0069 for <rtcweb@ietf.org>; Mon, 3 Mar 2014 04:10:42 -0800 (PST)
Received: from dhcp-9fd9.meeting.ietf.org (dhcp-9fd9.meeting.ietf.org [31.133.159.217]) (Authenticated sender: macmic) by mail-n.franken.de (Postfix) with ESMTP id EB2731C0E97AE; Mon, 3 Mar 2014 13:10:38 +0100 (CET)
Content-Type: text/plain; charset=iso-8859-1
Mime-Version: 1.0 (Mac OS X Mail 7.2 \(1874\))
From: Michael Tuexen <Michael.Tuexen@lurchi.franken.de>
In-Reply-To: <5314669C.3090301@jesup.org>
Date: Mon, 3 Mar 2014 12:10:38 +0000
Content-Transfer-Encoding: quoted-printable
Message-Id: <BA4E7503-5E9E-48D0-AA6A-7AFF37122ECE@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> <6C3E8CBC-9EC4-4222-8073-7D7903FEC38A@fh-muenster.de> <5314669C.3090301@jesup.org>
To: Randell Jesup <randell-ietf@jesup.org>
X-Mailer: Apple Mail (2.1874)
Archived-At: http://mailarchive.ietf.org/arch/msg/rtcweb/VajrGMRrJU_s2GasO0YDnBPnJhQ
Cc: rtcweb@ietf.org, Randall Stewart <rrs@lakerest.net>
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 12:10:46 -0000

On 03 Mar 2014, at 11:25, Randell Jesup <randell-ietf@jesup.org> wrote:

> On 3/3/2014 1:53 AM, Michael Tuexen wrote:
>> On 03 Mar 2014, at 02:42, Randell Jesup <randell-ietf@jesup.org> wrote:
>> 
>> 
>>> EMSGSIZE if the sendto() is larger than available buffer space, and the alternative (EOR mode) doesn't allow for interleaving of messages when sending at all (and I'm not sure it allows interleaving on reception either, but I didn't check right now).
>> If you want to send messages larger than the socket send buffer, you must use the explicit
>> EOR more. This is independent from using NDATA or not.
> 
> right.
> 
>> If you use NDATA, you can have on each outgoing stream a single message (order or unordered)
>> being sent using explicit EOR mode and the calls can be interleaved. I don't think I have
>> tested this up to know, but this is how it should work.
>> 
>> rrs@: Just to double check: Am I right? Please note that RTCWeb doesn't use ordered and
>>       unordered on the same stream, and you don't need to send more than one message with
>>       explicit EOR on the same stream at the same time. Therefore the above simplification...
> 
> If this is the case, this should deal with the issue I believe, with one caveat for the W3 layer:
> 
> If we can only send one at a time, we get an issue where we call channel.send(blob1); channel.send(blob2);
> 
> the JS interface to send() is synchronous and can't block.  This implies that if send(blob1) hasn't completed, the send(blob2) can't start, and all following send()s must also be buffered in memory. For a blob, since a blob reference is read-only, this is likely ok (need to verify what happens if we haven't read the blob into memory - if this isn't the case, we have a problem).  For sending an ArrayBuffer (or string), we'll have to snapshot the buffer at send() time if it's queued since the referenced data may change.  However, this really isn't anything that new, since if the SCTP buffers are full you have to do something similar anyways, even without any messages using fragmentation.
> 
> I presume from your comment (since it wasn't entirely clear) that if I have channel.send(blob1); channel.send("foo") that "foo" can't be sent until blob1 has been fully transmitted (has hit EOR at the send side), even though "foo" doesn't require fragmentation, and so all send()s for a channel during a fragmented send() must be copied and queued.
Correct. And if you are on an ordered channel, there is no alternative, right? On an unordered,
you can't interleave messages on a single stream...
> 
>>> Now, this is an implementation/API issue which could be fixed with some work, but so far as I know no work has been done on it.  So ndata will allow us to expand the max-sending size to
>> This API work is part of getting NDATA implemented. Randall has implemented it, we do have
>> code, but it needs some testing and cleaning up in the API which supports the scheduling...
> 
> So the last issue would be backwards compatibility.  If today an app must be written to query (via an unspecified W3 property) the max size you can reliably send() to the other side, then it must buy into (and test!) that functionality now and until it's pretty certain that all non-compliant implementations are gone.  This can take a while, even if you assume people update promptly, due to things like Firefox "ESR" releases (Extended Support for businesses, schools, etc).  Thes are valid for most of a year, and if we land ndata support right after one is created it could be closer to 1-1.5 years before if even starts to reach clients - and it may take even more time for all ESR users to approve/test it and update.
> 
> The arguments about having all the apps be required to implement their own fragmentation, etc for a considerable period adds lots of complexity to the apps.  Implementing the PPID chunking as the stopgap (and retiring it once ndata is universal) means the API to the application remains stable and simple.  Since all DataChannel implementations must implement queuing of JS send()s (since the SCTP bufferspace may be full), it's easy to support PPID fragmentation if you don't worry about memory-use optimization).  ndata not being available yet highlights this issue.
> 
>>> min(SCTP_BUFFER_SIZE - N, other-sides-max-receive-size).  It does not allow us to expand the size to any useful Blob size.
>> Please note that you never have a limitation of the receive buffer send size, since SCTP
>> would use partial delivery. So other-sides-max-receive-size is only relevant if there are
>> buffering limits on top of SCTP.
> 
> I was referring to the SDP value for "minimum value I guarantee receiving".
Understood. My point was the following:

If NDATA is not yet supported, the sender can choose a message limit to avoid
monopolisation. It is a sender side thing.

So any limit the receiver is enforcing and communicating via SDP is for different
reasons. So if we agree on support for arbitrary size messages when we have
NDATA, then there is ne need to negotiate a message size limit. The sender just
enforces whatever he things is appropriate to mitigate monopolisation.
> 
> We would need to specify that if ndata is agreed to (I presume we know that) that the application would be told an "infinite" value for max-I-can-receive (since we can't use the value from the SDP, as that predates the two sides creating the association and negotiating ndata).  I don't want to renegotiate just to remove the max SCTP receive size.
Correct. See my above statement. Why negotiate at all if we agree on the receiver being
able to handle arbitrary size messages?

Best regards
Michael
> 
>  Randell
> 
> -- 
> Randell Jesup -- rjesup a t mozilla d o t com
> 
>