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

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

Return-Path: <>
Received: from localhost ( []) by (Postfix) with ESMTP id 358B81A0081 for <>; Tue, 28 Oct 2014 15:28:56 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -14.511
X-Spam-Status: No, score=-14.511 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, 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 sHYhUK60rCpt for <>; Tue, 28 Oct 2014 15:28:54 -0700 (PDT)
Received: from ( []) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id E583D1A0022 for <>; Tue, 28 Oct 2014 15:28:53 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple;;; l=2576; q=dns/txt; s=iport; t=1414535334; x=1415744934; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-transfer-encoding:mime-version; bh=xEWXVZ/4sJpgIWUTnKgzyAMJ+b3iFLYbKwqNvwgrWwM=; b=CF894BZuigw2PiVBF1bHVbse5w9/2/+AJsimfMOY0Gu0gORnpUzXD4iW 8Ka7dDvI1MnkljimHSHgTh9mMqSm0ISsVh3dNtdSX0Z9h6B8nfUSMFufi hhiqGQ3ajCojUDtKyjR8zNTdmRxvqaR9GS8sgYpePl3AxCjF/TZXYtQ50 0=;
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-AV: E=Sophos;i="5.04,805,1406592000"; d="scan'208";a="91184238"
Received: from ([]) by with ESMTP; 28 Oct 2014 22:28:54 +0000
Received: from ( []) by (8.14.5/8.14.5) with ESMTP id s9SMSrJT015174 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Tue, 28 Oct 2014 22:28:53 GMT
Received: from ([]) by ([]) with mapi id 14.03.0195.001; Tue, 28 Oct 2014 17:28:53 -0500
From: "Mo Zanaty (mzanaty)" <>
To: Michael Tuexen <>
Thread-Topic: [rtcweb] Meaning of SHOULD support/use interleaving
Thread-Index: AQHP8vEmqS2/U13JNkqofeKaZ1Gl3pxGVXUA///BxDI=
Date: Tue, 28 Oct 2014 22:28:52 +0000
Message-ID: <>
References: <> <> <> <> <> <> <> <> <> <> <> <> <> <>, <>
In-Reply-To: <>
Accept-Language: en-US
Content-Language: en-US
Content-Type: text/plain; charset="Windows-1252"
Content-Transfer-Encoding: quoted-printable
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 22:28:56 -0000

On Oct 28, 2014, at 5:11 PM, "Michael Tuexen" <> wrote:

On 28 Oct 2014, at 21:52, Mo Zanaty (mzanaty) <> wrote:

>> 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).
You can bring this up at the tsvwg mailing list.

Mo: Will do.

However, we normally do not optimize for byte saving... Mixing
both makes the processing harder... Maybe we can use a bit in the flags to indicate if the additional fields are

Mo: Type should already be enough without flags.

> 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?
This would only make sense for messages marked as unordered... For ordered it doesn't make sense.

Mo: The restriction applies to unordered as well as ordered. Even for ordered, it does make sense to avoid head of line blocking at the sender. 
> If those two issues are resolved, I see no argument against making NDATA a MUST in data channels.
Please let us discuss NDATA issues on the tsvwg mailing list...

Mo: Agreed, will do. But I think rtcweb MUST use NDATA only if its benefits outweigh its costs. The current draft does not pass that bar for me. If my app cares about HOL blocking, NDATA is not very useful, so my app must internally fragment, hence NDATA actually becomes harmful (8 bytes closer to exceeding MTU, forcing SCTP fragments and hence risking HOL blocking).

Best regards
> Mo
> 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.