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

Michael Tuexen <> Thu, 30 October 2014 18:54 UTC

Return-Path: <>
Received: from localhost ( []) by (Postfix) with ESMTP id CAD841A1A8E for <>; Thu, 30 Oct 2014 11:54:52 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -1.561
X-Spam-Status: No, score=-1.561 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_DE=0.35, SPF_HELO_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=no
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id nXWmqtm0lsxJ for <>; Thu, 30 Oct 2014 11:54:50 -0700 (PDT)
Received: from ( [IPv6:2001:638:a02:a001:20e:cff:fe4a:feaa]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 60B4E1A1A1D for <>; Thu, 30 Oct 2014 11:54:01 -0700 (PDT)
Received: from [] ( []) (Authenticated sender: macmic) by (Postfix) with ESMTP id 47D171C104D94; Thu, 30 Oct 2014 19:53:58 +0100 (CET)
Content-Type: text/plain; charset="windows-1252"
Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.6\))
From: Michael Tuexen <>
In-Reply-To: <>
Date: Thu, 30 Oct 2014 19:53:56 +0100
Content-Transfer-Encoding: quoted-printable
Message-Id: <>
References: <> <> <> <> <> <> <> <> <> <> <> <> <> <> <> <> <8CA6F4DE-8978-458B-9C77-21CFA33C48CE@lurchi.franken. de> <>
To: "Mo Zanaty (mzanaty)" <>
X-Mailer: Apple Mail (2.1878.6)
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: Thu, 30 Oct 2014 18:54:53 -0000

On 29 Oct 2014, at 21:17, Mo Zanaty (mzanaty) <> wrote:

> Hi Michael,
> I moved to tsvwg as requested. See my reply to Karen, and one reply inline.
Great, thanks. I'll respond, but I'm really slow right now, since my day job
needs more time than I would like...
> For rtcweb, the main point is this. Will rtcweb apps care about blocking on potentially fragmented messages? I think they definitely will, if they care about blocking at all. Even simple JSON objects, which seem like natural message payloads, can easily exceed common MTUs. It doesn’t take huge file transfers to require fragmentation.
Can you be a bit more specific? My understanding is:
1. Messages sent on one data channel should not block messages sent on a different channel.
   I hope we agree on this and this goal can be reached with N-DATA.
2. If you send a larger message on an ordered data channel, it will block other
   messages sent on the same data channel. Since it is an ordered channel, this can't
   be avoided. I hope we also agree on this.
3. If you send a large message on an unordered data channel, and a small one after
   that, there is no statement made in which these messages would be delivered.
   Are you focussing on this and do you want to require some sort of reordering?

Best regards
> Cheers,
> Mo
> On 10/29/14, 6:05 AM, Michael Tuexen <> wrote:
> On 28 Oct 2014, at 23:28, Mo Zanaty (mzanaty) <> wrote:
>> 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
>> there...
>> 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.
> I don't understand how you can do it for ordered. The sender sends a large message on stream 0 and after that
> a small on stream zero. For both ordered delivery is request. So the receiver can't deliver the second before the
> first.
> Mo: Blocking sender transmission is very different from blocking receiver delivery to the app. It is wrong to assume all ordered protocols should block sender transmission out of order. Windows and SACK improve performance of ordered protocols despite the receiver blocking delivery to the app.
>>> 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).
> I don't understand the point when I look at the API for data channels... Only for sending messages
> on a data channel not requiring ordered delivery. However, the intention of NDATA is to mitigate
> the impact of one data channel on others belonging to the same peer connection. This goal is met.
> Best regards
> Michael
>> Best regards
>> Michael
>>> 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.