[hybi] Is it important to know frame length at the start of frame? (was: Re: Discontinuation of mux ...)

Takeshi Yoshino <tyoshino@google.com> Fri, 07 February 2014 07:30 UTC

Return-Path: <tyoshino@google.com>
X-Original-To: hybi@ietfa.amsl.com
Delivered-To: hybi@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B69701A05B7 for <hybi@ietfa.amsl.com>; Thu, 6 Feb 2014 23:30:24 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.613
X-Spam-Level:
X-Spam-Status: No, score=-1.613 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, MIME_8BIT_HEADER=0.3, RP_MATCHES_RCVD=-0.535, SPF_PASS=-0.001] autolearn=no
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 B-as5ymqlAuJ for <hybi@ietfa.amsl.com>; Thu, 6 Feb 2014 23:30:22 -0800 (PST)
Received: from mail-wg0-x229.google.com (mail-wg0-x229.google.com [IPv6:2a00:1450:400c:c00::229]) by ietfa.amsl.com (Postfix) with ESMTP id 833291A05AC for <hybi@ietf.org>; Thu, 6 Feb 2014 23:30:22 -0800 (PST)
Received: by mail-wg0-f41.google.com with SMTP id n12so501832wgh.4 for <hybi@ietf.org>; Thu, 06 Feb 2014 23:30:20 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:from:date:message-id:subject:to:cc:content-type; bh=mjiXlSM2CrWPP1DKhKwcg+XjK+JWMIRPDmcw3QX4alg=; b=KBfwWqI8esVwYJVOqdxkdMp/BeFEtmyidRCLK5Ne6yo5MPS84QJ0VVJMWtbHR/4EOY wOJmLgeTB0KVZvuFLk9ZiorL37E+Gc+1KHIyKOhbei2wAnn7wwZAkGn5LTcQZGa7g2Jm ncrRs+GyEMcw9j6kxoW7/GWeygBcD4Hqpvg8PFIUX71Edjsm1FRijhkegp1l9nLaXDnL hYOXRtW/aTu0C/uYqlDF7mG7ECH89FzG0+Q405P3gynmjFg1DaKP10jYH94N4Bclsp/K Rwcw9UcZHvd9Ri6HsWo2hnF5t5hOP4mSix0v3+Bj7P481kp/nI9oL0sp3EyhOuQH893j E4XQ==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:from:date:message-id:subject:to:cc :content-type; bh=mjiXlSM2CrWPP1DKhKwcg+XjK+JWMIRPDmcw3QX4alg=; b=l/3hnw3E3wZje0SciK7OepFopz/BdMcgfp4OdbEm/54ICeB1c6QB0dyIlrdHGPkQWz 6JYH0qULc+8WfUH7T8Bnne4lyFToXaaifONcc+iJgO5KKazvWohF0biTMQ9HuBEOtQs4 MWkE0VKTrlO0ayYMAgKUJ7J4CMH2WgtIkz2HJ1CMtzno6vHke1lfPaW4mwndW3UDN0HM 9oe6PuQJtDjByI2iHue9G9v7wVb+huDcZ09/w78lYFAGhvKS35nzIe2NxKo60tSJ6zQv 444lX6Kpcs3XLp1wrltvSJ7NYGN2x7Mq9299t26ov8jRnrghrQu3y03ViA1cZw+wllOJ 6P7Q==
X-Gm-Message-State: ALoCoQnDUuBUQl/BUpYIwipOkMbtVpFNi8/tQG0JXIN6OjLwfPB2IepYNC4GIaApT1oLixdmVGecDbE5ZcxIqQNRSxL+GNIXAUCgzTMwS51sY3UE4HkQB155/uRloTkHHIvpMr7UmXxg0UAi1otDjLzNQaHrG4ue26fjbuFb9pZsDtRWrCUsW2e9grAg4skhLB+lTYHi7pve
X-Received: by 10.180.10.105 with SMTP id h9mr2610624wib.11.1391758220712; Thu, 06 Feb 2014 23:30:20 -0800 (PST)
MIME-Version: 1.0
Received: by 10.194.8.231 with HTTP; Thu, 6 Feb 2014 23:30:00 -0800 (PST)
From: Takeshi Yoshino <tyoshino@google.com>
Date: Fri, 07 Feb 2014 16:30:00 +0900
Message-ID: <CAH9hSJbf_ABT7ECL9eS=_ADrncX8qBtxZv=uLcdu9_6GUv23Uw@mail.gmail.com>
To: "Martin J. Dürst" <duerst@it.aoyama.ac.jp>
Content-Type: multipart/alternative; boundary="001a11c263665c2cb104f1cbf6bc"
Cc: "hybi@ietf.org" <hybi@ietf.org>
Subject: [hybi] Is it important to know frame length at the start of frame? (was: Re: Discontinuation of mux ...)
X-BeenThere: hybi@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: Server-Initiated HTTP <hybi.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/hybi>, <mailto:hybi-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/hybi/>
List-Post: <mailto:hybi@ietf.org>
List-Help: <mailto:hybi-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/hybi>, <mailto:hybi-request@ietf.org?subject=subscribe>
X-List-Received-Date: Fri, 07 Feb 2014 07:30:24 -0000

I remember that in early days of the standardization, somebody was
proposing (*) that we should have a message length field in the first
fragment to allow for allocating buffer for full message at the beginning.

On Thu, Jan 16, 2014 at 3:27 PM, "Martin J. Dürst"
<duerst@it.aoyama.ac.jp>wrote:

> On 2014/01/16 15:05, Yutaka Hirano wrote:
>
>> Hi Joakim,
>>
>> Thanks for the comment.
>>
>> Knowing the size of a frame at the start of the frame, traditional
>>
>>> websocket behavior, is desired, as it allows us to fast fail for the 1009
>>> (message too big) use case.
>>>
>>
>> Do you know how effective it is?
>>
>> Having no prior knowledge of frame size is undesirable to us.
>>
>> On the other hand, the frame sender have more freedom because they don't
>> have to know the size of the frame in front.
>>
>
> My understanding of why messages are split into frames was that this would
> allow to start a message without knowing its length. But if you don't know
> the size of a frame before sending it, then the right solution is to make
> it smaller. Frames are just arbitrary pieces of a message.
>

We should be clear if we want to make it able to
(a) know the length of WebSocket frame on receiving the header of each
fragment
(b) know the length of WebSocket message on receiving the first fragment

As the proposal (*) has been rejected and not in the RFC6455 header, (b) is
not true even in RFC6455. What Joakim said should be to keep (a) which is
true now in RFC6455.

But if a message is fragmented into smaller frames, we cannot reject (and
send 1009) the message on receiving the first frame. "Whether we can
fast-reject a big message on receiving some non-final frame" depends on how
the peer fragments a message.

In some plans discussed in the main thread, it's planned to drop frame
length info for efficiency. But something else such as the length field of
HTTP/2.0 DATA frame tells how much data the fragment (when multiple DATAs
convey a WebSocket frame, each DATA would be called fragments of a frame)
contains. So, we won't be able to know the length of fragments
(original/encapsulated WebSocket frames) on receiving each of them, but
still be able to know the length of sub-fragments (e.g. HTTP/2.0 data
frames).

I think this change is acceptable and shouldn't be considered as breaking
of RFC6455 semantics. Even in the mux extension I was editing (
http://tools.ietf.org/html/draft-ietf-hybi-websocket-multiplexing-11), I
made the same change. The length of the encapsulated frame is unknown until
receiving all the fragments of the encapsulating message. No one was
objecting to that when we were discussing the spec, IIRC.