Re: [rtcweb] Open data channel issues

Michael Tuexen <tuexen@fh-muenster.de> Mon, 03 March 2014 07:01 UTC

Return-Path: <tuexen@fh-muenster.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 3BFF91A0D41 for <rtcweb@ietfa.amsl.com>; Sun, 2 Mar 2014 23:01:38 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.551
X-Spam-Level:
X-Spam-Status: No, score=-1.551 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_DE=0.35, SPF_HELO_PASS=-0.001] autolearn=no
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 3Kdjlpaev2CG for <rtcweb@ietfa.amsl.com>; Sun, 2 Mar 2014 23:01:34 -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 955661A0D42 for <rtcweb@ietf.org>; Sun, 2 Mar 2014 23:01:33 -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 4C9A01C103E6D; Mon, 3 Mar 2014 08:01:30 +0100 (CET)
Content-Type: text/plain; charset=us-ascii
Mime-Version: 1.0 (Mac OS X Mail 7.2 \(1874\))
From: Michael Tuexen <tuexen@fh-muenster.de>
In-Reply-To: <CABkgnnVRAfnrmMY57UD-0o=1Oz3==ZA8Q42mqCaxoQ27+X-orQ@mail.gmail.com>
Date: Mon, 3 Mar 2014 07:01:28 +0000
Content-Transfer-Encoding: quoted-printable
Message-Id: <24066065-DD25-4037-B476-5FA7C9809DDE@fh-muenster.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> <CABkgnnVRAfnrmMY57UD-0o=1Oz3==ZA8Q42mqCaxoQ27+X-orQ@mail.gmail.com>
To: Martin Thomson <martin.thomson@gmail.com>
X-Mailer: Apple Mail (2.1874)
Archived-At: http://mailarchive.ietf.org/arch/msg/rtcweb/9FE923z-lUAjvTgBKfVZHiTz6o4
X-Mailman-Approved-At: Sun, 02 Mar 2014 23:42:08 -0800
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 07:01:38 -0000

On 03 Mar 2014, at 06:56, Martin Thomson <martin.thomson@gmail.com> wrote:

> On 2 March 2014 18:42, Randell Jesup <randell-ietf@jesup.org> wrote:
>> ndata solves the monopolization issue between streams, allowing packets for
>> different streams to be interleaved on the wire.  It does not (so far as I
>> know) relax the usrsctp library's returning 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).
>> 
>> 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 min(SCTP_BUFFER_SIZE - N,
>> other-sides-max-receive-size).  It does not allow us to expand the size to
>> any useful Blob size.
> 
> Sounds like the complaint would be best addressed by fixing the SCTP
> implementations.  I would hope that ndata would allow for transmission
> of messages far in excess of what the implementation is willing to
> buffer, that seems arbitrarily restrictive.
As said in my previous mail: Using NDATA will allow to have on each
stream a single ordered or unordered message being sent in explicit
EOR mode. The send calls can be interleaved.

Best regards
Michael
> 
> (A streaming API wounds like a good idea too.)
> 
> _______________________________________________
> rtcweb mailing list
> rtcweb@ietf.org
> https://www.ietf.org/mailman/listinfo/rtcweb
>