Re: [hybi] Framing Take VI (a compromise proposal)

Takeshi Yoshino <tyoshino@google.com> Sat, 14 August 2010 05:47 UTC

Return-Path: <tyoshino@google.com>
X-Original-To: hybi@core3.amsl.com
Delivered-To: hybi@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 70F0C3A6AC6 for <hybi@core3.amsl.com>; Fri, 13 Aug 2010 22:47:24 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -102.734
X-Spam-Level:
X-Spam-Status: No, score=-102.734 tagged_above=-999 required=5 tests=[BAYES_05=-1.11, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, MIME_BASE64_TEXT=1.753, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id rzKtpBXowyQv for <hybi@core3.amsl.com>; Fri, 13 Aug 2010 22:47:22 -0700 (PDT)
Received: from smtp-out.google.com (smtp-out.google.com [74.125.121.35]) by core3.amsl.com (Postfix) with ESMTP id C21993A6AC0 for <hybi@ietf.org>; Fri, 13 Aug 2010 22:47:20 -0700 (PDT)
Received: from kpbe18.cbf.corp.google.com (kpbe18.cbf.corp.google.com [172.25.105.82]) by smtp-out.google.com with ESMTP id o7E5lYbH009044 for <hybi@ietf.org>; Fri, 13 Aug 2010 22:47:34 -0700
DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d=google.com; s=beta; t=1281764854; bh=cvGR+RvCHnqUPMd8zJeLRQrRY8U=; h=MIME-Version:In-Reply-To:References:From:Date:Message-ID:Subject: To:Cc:Content-Type; b=hobcJToTamXQj7FtA2yVkIvCRT4iZAED2gpZX8Otvyo0mBonJYlR2oE+8jxJtApLY pXY8Kn/Jaf0gWbpV3DHvw==
DomainKey-Signature: a=rsa-sha1; s=beta; d=google.com; c=nofws; q=dns; h=mime-version:in-reply-to:references:from:date:message-id: subject:to:cc:content-type:x-system-of-record; b=qw+y2ql/gNZVC1FySRv7EyzJhSsBgsYF0LX7BHUszLBhEGdzOhDfvu1E5jqAKQAqk rBQ6nkoNSfE9dkyVSqzOA==
Received: from gya1 (gya1.prod.google.com [10.243.49.1]) by kpbe18.cbf.corp.google.com with ESMTP id o7E5lWVo015948 for <hybi@ietf.org>; Fri, 13 Aug 2010 22:47:32 -0700
Received: by gya1 with SMTP id 1so1700869gya.24 for <hybi@ietf.org>; Fri, 13 Aug 2010 22:47:32 -0700 (PDT)
Received: by 10.231.77.155 with SMTP id g27mr2135304ibk.195.1281764851427; Fri, 13 Aug 2010 22:47:31 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.231.14.67 with HTTP; Fri, 13 Aug 2010 22:47:11 -0700 (PDT)
In-Reply-To: <AANLkTim5e0T3wLOnpFXpKtKtg1zAaHtzRUxgYhfCQNOe@mail.gmail.com>
References: <AANLkTi=TBXO_Cbb+P+e2BVfx69shkf8E1-9ywDh_Y+Kz@mail.gmail.com> <AANLkTimJOGWgV6rx5JJYSJMC26OzQzskzVtkYz0L_EAg@mail.gmail.com> <AANLkTim5e0T3wLOnpFXpKtKtg1zAaHtzRUxgYhfCQNOe@mail.gmail.com>
From: Takeshi Yoshino <tyoshino@google.com>
Date: Sat, 14 Aug 2010 14:47:11 +0900
Message-ID: <AANLkTim57GC5X0+wHHYZPzgwHo1PbD-8ELC2NMNx9v_T@mail.gmail.com>
To: ifette@google.com
Content-Type: multipart/alternative; boundary="000e0cd25414a7a94e048dc222e8"
X-System-Of-Record: true
Cc: hybi@ietf.org
Subject: Re: [hybi] Framing Take VI (a compromise proposal)
X-BeenThere: hybi@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: Server-Initiated HTTP <hybi.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/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: Sat, 14 Aug 2010 05:47:25 -0000

2010年8月14日6:20 Ian Fette (イアンフェッティ) <ifette@google.com>:

> On Fri, Aug 13, 2010 at 2:16 PM, Ian Hickson <ian@hixie.ch> wrote:
>
>> 2010/8/12 Ian Fette (イアンフェッティ) <ifette@google.com>:
>> >
>> > That said, here's the proposal:
>>
>> This seems overly complex. In particular:
>>
>>  - I don't see the need for explicit extension lengths.
>>
>>
> If you don't want to use any extensions, which I assume you don't, then set
> EXT=0 and you don't have to set any extension lengths. Given that you don't
> seem to want to use extensions, I'm not sure why you seem to have a
> preference for how extension data is stated.
>
>
>>  - I don't see what having both a short length and a long length gets
>> us. Saving 7 bytes seems like a very minimal gain, especially when
>> considered in the context of the rest of the header and the IP and TCP
>> overhead.
>>
>>
> An alternate would be to use a variable length. I really don't care that
> much.
>
>

I don't have strong preference on this point, too.

But let me provide some metric about this. As you said, people who mind
latency much would turn off NAGLE, so short packets containing, e.g. key
stroke of 1 octet would ultimately forms minimum_gap(8) + ethernet(18) +
ipv4(20) + tcp(20) + type(1) + len(1) + payload(1) = 69 octet on wire.
difference of 7 octets is just 10% increase on wire and 7/43=16% increase on
kernel level, and 3/9=33% increase on WebSocket level. Not much as 33%, 16%
and 10% still seems not so negligible amount.

If a user sends short messages and doesn't urge so much the messages to be
delivered, client can be implemented using some buffering so that they
(multiple WebSocket frames for multiple send() calls) can be combined into
one TCP packet. In such case, the difference of length header size would be
more significant. Actually, this can be also solved on application level by
combining e.g. several key stroke information into one send() call, so it's
not strong support for this choice.

Takeshi


>  - Supporting fragmentation today is premature. We have no experience
>> with how people use this protocol, we shouldn't be adding such
>> features yet. Six months from now, sure, once we can quantify what it
>> is people actually need.
>>
>>
> This point has been argued extensively enough on the list that I don't
> think anything I say here is going to be new.
>
>
>>  - I don't see why we would need to flag fragmentation frames using
>> reserved bits rather than just using the frame type byte mechanic.
>> Just define four frame types for text and four frame types for binary
>> when we add binary (not fragmented, fragment start, fragment middle,
>> fragment end).
>>
>> --
>> Ian Hickson
>>
>
>
> _______________________________________________
> hybi mailing list
> hybi@ietf.org
> https://www.ietf.org/mailman/listinfo/hybi
>
>