Re: [rtcweb] Open data channel issues

"Makaraju, Maridi Raju (Raju)" <Raju.Makaraju@alcatel-lucent.com> Tue, 04 March 2014 11:18 UTC

Return-Path: <Raju.Makaraju@alcatel-lucent.com>
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 D640D1A0056 for <rtcweb@ietfa.amsl.com>; Tue, 4 Mar 2014 03:18:00 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.3
X-Spam-Level:
X-Spam-Status: No, score=-6.3 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, J_CHICKENPOX_35=0.6, RCVD_IN_DNSWL_HI=-5] 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 FEhQ9WLmGbRM for <rtcweb@ietfa.amsl.com>; Tue, 4 Mar 2014 03:17:58 -0800 (PST)
Received: from ihemail3.lucent.com (ihemail3.lucent.com [135.245.0.37]) by ietfa.amsl.com (Postfix) with ESMTP id D96751A0431 for <rtcweb@ietf.org>; Tue, 4 Mar 2014 03:17:57 -0800 (PST)
Received: from us70uusmtp4.zam.alcatel-lucent.com (h135-5-2-66.lucent.com [135.5.2.66]) by ihemail3.lucent.com (8.13.8/IER-o) with ESMTP id s24BHrsf010201 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Tue, 4 Mar 2014 05:17:53 -0600 (CST)
Received: from US70TWXCHHUB03.zam.alcatel-lucent.com (us70twxchhub03.zam.alcatel-lucent.com [135.5.2.35]) by us70uusmtp4.zam.alcatel-lucent.com (GMO) with ESMTP id s24BG6ss027834 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Tue, 4 Mar 2014 06:17:52 -0500
Received: from US70UWXCHMBA02.zam.alcatel-lucent.com ([169.254.8.212]) by US70TWXCHHUB03.zam.alcatel-lucent.com ([135.5.2.35]) with mapi id 14.02.0247.003; Tue, 4 Mar 2014 06:17:19 -0500
From: "Makaraju, Maridi Raju (Raju)" <Raju.Makaraju@alcatel-lucent.com>
To: Michael Tuexen <Michael.Tuexen@lurchi.franken.de>
Thread-Topic: [rtcweb] Open data channel issues
Thread-Index: AQHPNvTjdPPAuXGnm0CBoOmgEn8ul5rP+SYA///UOvCAAH0dAIAAd/Dw
Date: Tue, 4 Mar 2014 11:17:19 +0000
Message-ID: <E1FE4C082A89A246A11D7F32A95A17826E0067E0@US70UWXCHMBA02.zam.alcatel-lucent.com>
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> <7387F0E6-2DE0-4372-8559-B9DE9B9F365F@lurchi.franken.de>
In-Reply-To: <7387F0E6-2DE0-4372-8559-B9DE9B9F365F@lurchi.franken.de>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
x-originating-ip: [135.5.27.16]
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
Archived-At: http://mailarchive.ietf.org/arch/msg/rtcweb/BR1qe0LM8CCJrqScOTVh70Fjhe4
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: Tue, 04 Mar 2014 11:18:01 -0000

Please see inline comments.

> -----Original Message-----
> From: Michael Tuexen [mailto:Michael.Tuexen@lurchi.franken.de]
> Sent: Monday, March 03, 2014 4:46 PM
> To: Makaraju, Maridi Raju (Raju)
> Cc: Justin Uberti; Randell Jesup; rtcweb@ietf.org
> Subject: Re: [rtcweb] Open data channel issues
> 
> 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...

[Raju] 
Thanks for clarifying. Earlier it wasn't clear to me as EOR was referred to be EOR+NDATA. I was reading EOR as just EOR support without NDATA.
Yes, NDATA support is a must to avoid monopolization.
[/Raju]

> >
> > 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...

[Raju] 
Yes, I agree that NDATA is the final solution. But in the interim, application chunking per 16K size requires some chunking protocol at app.
Do we know the timeframe for NDATA support from browsers?
Until NDATA is available, to avoid monopolization one can use new PC as an alternative to application level chunking (which also require some kind of flow/congestion control).
Appreictae any comments on this approach.
[/Raju]

Best Regards
Raju