Re: [rtcweb] Sending of zero-length messages over data channels

"Makaraju, Maridi Raju (Raju)" <Raju.Makaraju@alcatel-lucent.com> Wed, 23 July 2014 12:00 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 8ADAF1A0AC4 for <rtcweb@ietfa.amsl.com>; Wed, 23 Jul 2014 05:00:33 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.299
X-Spam-Level:
X-Spam-Status: No, score=-6.299 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, J_CHICKENPOX_44=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 qiGFky0dBEqk for <rtcweb@ietfa.amsl.com>; Wed, 23 Jul 2014 05:00:30 -0700 (PDT)
Received: from ihemail3.lucent.com (ihemail3.lucent.com [135.245.0.37]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A160F1A0AC1 for <rtcweb@ietf.org>; Wed, 23 Jul 2014 05:00:29 -0700 (PDT)
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 s6NC0Nh4003104 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Wed, 23 Jul 2014 07:00:23 -0500 (CDT)
Received: from US70UWXCHHUB02.zam.alcatel-lucent.com (us70uwxchhub02.zam.alcatel-lucent.com [135.5.2.49]) by us70uusmtp4.zam.alcatel-lucent.com (GMO) with ESMTP id s6NC0NXS020781 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Wed, 23 Jul 2014 08:00:23 -0400
Received: from US70UWXCHMBA02.zam.alcatel-lucent.com ([169.254.8.175]) by US70UWXCHHUB02.zam.alcatel-lucent.com ([135.5.2.49]) with mapi id 14.02.0247.003; Wed, 23 Jul 2014 08:00:22 -0400
From: "Makaraju, Maridi Raju (Raju)" <Raju.Makaraju@alcatel-lucent.com>
To: Justin Uberti <juberti@google.com>, "rtcweb@ietf.org" <rtcweb@ietf.org>
Thread-Topic: [rtcweb] Sending of zero-length messages over data channels
Thread-Index: AQHPpipfEWtPO6jXOES6Y6R7CwNaxJutiTxg
Date: Wed, 23 Jul 2014 12:00:22 +0000
Deferred-Delivery: Wed, 23 Jul 2014 12:00:00 +0000
Message-ID: <E1FE4C082A89A246A11D7F32A95A17828E4BCC13@US70UWXCHMBA02.zam.alcatel-lucent.com>
References: <CAOJ7v-0F9pysYLehjTVDv1Sxz3TKaxi2y6J7RrpGqMdA=tiR_g@mail.gmail.com>
In-Reply-To: <CAOJ7v-0F9pysYLehjTVDv1Sxz3TKaxi2y6J7RrpGqMdA=tiR_g@mail.gmail.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
x-originating-ip: [135.5.27.18]
Content-Type: multipart/alternative; boundary="_000_E1FE4C082A89A246A11D7F32A95A17828E4BCC13US70UWXCHMBA02z_"
MIME-Version: 1.0
Archived-At: http://mailarchive.ietf.org/arch/msg/rtcweb/xFNm-NvcFAuXjQ3XhZvkJaPL9Jk
Subject: Re: [rtcweb] Sending of zero-length messages over data channels
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: Wed, 23 Jul 2014 12:00:34 -0000

In the existing data channel protocol, it's not possible to send zero-length messages, because SCTP prohibits it.

While this may seem to be an academic point, it does represent a divergence from WebSockets, and this difference could be meaningful to applications who use empty messages for keepalives. Or maybe the Yo app.

Since we can't send a zero-length SCTP message, I propose we add a PPID_EMPTY value or something similar to indicate a message with empty content.
[Raju] There is a genuine need for this and the proposal is good.
However, I am thinking of an alternate proposal to achieve the same but in a generic way.
Define a PPID_OOB (out of band) or something similar.
Apps can use this to send a message of non-zero length. For the “Yo” kind of app or empty stream-level heartbeat purpose, app can send a 1 byte length message, which other end’s app ignores.
This approach involves bit more API work for webrtc to have a variation of send(data, oobFlag) and new data type in onmessage(). IMHO, this approach allows more possibilities in future and also the same approach can be used by other SCTP use cases not involving webrtc.

BR
raju