Re: [rtcweb] Meaning of SHOULD support/use interleaving

"Mo Zanaty (mzanaty)" <> Tue, 28 October 2014 20:53 UTC

Return-Path: <>
Received: from localhost ( []) by (Postfix) with ESMTP id 3B3251A90AE for <>; Tue, 28 Oct 2014 13:53:01 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -14.51
X-Spam-Status: No, score=-14.51 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id V5a6vY_nMAKY for <>; Tue, 28 Oct 2014 13:52:58 -0700 (PDT)
Received: from ( []) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 319161A90A4 for <>; Tue, 28 Oct 2014 13:52:58 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple;;; l=3525; q=dns/txt; s=iport; t=1414529578; x=1415739178; h=from:to:cc:subject:date:message-id:references: in-reply-to:mime-version; bh=2BVewdouMsNgdq8QfU9a8uTzxV1BLrTQlOc9wj5bsls=; b=krEVzJMG9oDhVW28Zc3AdlW1izP4Co/2mhEskrwiCxAhNILLw8/CUIJc TCaIoynC+41k/RARh8ejkxGzu26A+7+DMN5i/zbMOpeDg7oimSOPoD+P6 IebvUGvD5sjIQluq+L1mHAr4CrILV55ClqaneXmaMmd4szlheFl3cDRxq o=;
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-AV: E=Sophos;i="5.04,804,1406592000"; d="scan'208,217";a="367267288"
Received: from ([]) by with ESMTP; 28 Oct 2014 20:52:57 +0000
Received: from ( []) by (8.14.5/8.14.5) with ESMTP id s9SKqvse005187 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Tue, 28 Oct 2014 20:52:57 GMT
Received: from ([]) by ([]) with mapi id 14.03.0195.001; Tue, 28 Oct 2014 15:52:57 -0500
From: "Mo Zanaty (mzanaty)" <>
To: Christer Holmberg <>, Eric Rescorla <>, Michael Tuexen <>, Harald Alvestrand <>
Thread-Topic: [rtcweb] Meaning of SHOULD support/use interleaving
Thread-Index: AQHP8vEmqS2/U13JNkqofeKaZ1Gl3g==
Date: Tue, 28 Oct 2014 20:52:56 +0000
Message-ID: <>
References: <> <> <> <> <> <> <> <> <> <> <> <> <>
In-Reply-To: <>
Accept-Language: en-US
Content-Language: en-US
user-agent: Microsoft-MacOutlook/
x-originating-ip: []
Content-Type: multipart/alternative; boundary="_000_D07572143D0B4mzanatyciscocom_"
MIME-Version: 1.0
Cc: "" <>
Subject: Re: [rtcweb] Meaning of SHOULD support/use interleaving
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: Real-Time Communication in WEB-browsers working group list <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Tue, 28 Oct 2014 20:53:01 -0000

> What resource is being conserved by not just requiring it?

8 bytes per packet (for MID+FSN).

Michael, the current NDATA draft requires it to be used for all messages if negotiated. Can’t this be relaxed / optimized to use it for all *fragmented* messages but use DATA for non-fragmented messages to avoid the 8 byte overhead for small messages (like game telemetry/control, an often cited use of data channels).

The current NDATA draft also says you can’t interleave fragmented messages in a stream, so head of line blocking remains for all fragmented messages, while only small non-fragmented messages can avoid it. This dilutes the utility of NDATA, perhaps enough to make apps that really care about head of line blocking to implement their own app layer fragmentation with messages well below common MTUs, hence defeating NDATA. Can’t this also be relaxed since MID is part of the NDATA extra header?

If those two issues are resolved, I see no argument against making NDATA a MUST in data channels.


PS. Some believe data channels will be more widely used than WebRTC media (webtorrent, etc.), so it does make sense to consider the desirable properties of a general peer-to-peer transport, and drop the WebRTC prefix when talking about data channels.