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

"Thomson, Martin" <Martin.Thomson@andrew.com> Wed, 18 August 2010 00:21 UTC

Return-Path: <Martin.Thomson@andrew.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 3833A3A67E2 for <hybi@core3.amsl.com>; Tue, 17 Aug 2010 17:21:55 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.039
X-Spam-Level:
X-Spam-Status: No, score=-3.039 tagged_above=-999 required=5 tests=[AWL=-0.441, BAYES_00=-2.599, HTML_MESSAGE=0.001]
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 qGLtMCFII3UC for <hybi@core3.amsl.com>; Tue, 17 Aug 2010 17:21:54 -0700 (PDT)
Received: from csmailgw1.commscope.com (csmailgw1.commscope.com [198.135.207.244]) by core3.amsl.com (Postfix) with ESMTP id ADA163A6765 for <hybi@ietf.org>; Tue, 17 Aug 2010 17:21:53 -0700 (PDT)
Received: from [10.86.20.103] ([10.86.20.103]:141 "EHLO ACDCE7HC2.commscope.com") by csmailgw1.commscope.com with ESMTP id S30600204Ab0HRAW3 (ORCPT <rfc822; hybi@ietf.org>); Tue, 17 Aug 2010 19:22:29 -0500
Received: from SISPE7HC1.commscope.com (10.97.4.12) by ACDCE7HC2.commscope.com (10.86.20.103) with Microsoft SMTP Server (TLS) id 8.1.436.0; Tue, 17 Aug 2010 19:22:28 -0500
Received: from SISPE7MB1.commscope.com ([fe80::9d82:a492:85e3:a293]) by SISPE7HC1.commscope.com ([fe80::8a9:4724:f6bb:3cdf%10]) with mapi; Wed, 18 Aug 2010 08:22:24 +0800
From: "Thomson, Martin" <Martin.Thomson@andrew.com>
To: John Tamplin <jat@google.com>
Date: Wed, 18 Aug 2010 08:24:44 +0800
Thread-Topic: [hybi] Framing Take VI (a compromise proposal)
Thread-Index: Acs+af1ynBn68Y+oQDWja3j+U7YmHwAALRqg
Message-ID: <8B0A9FCBB9832F43971E38010638454F03ED35AB65@SISPE7MB1.commscope.com>
References: <AANLkTi=TBXO_Cbb+P+e2BVfx69shkf8E1-9ywDh_Y+Kz@mail.gmail.com> <AANLkTimJOGWgV6rx5JJYSJMC26OzQzskzVtkYz0L_EAg@mail.gmail.com> <op.vhe7qtmu64w2qv@anne-van-kesterens-macbook-pro.local> <8B0A9FCBB9832F43971E38010638454F03ED35AB3F@SISPE7MB1.commscope.com> <AANLkTimQoy1Z_oTWc4Z3cYnQz0MOb6q_u1mtz0PxMXz0@mail.gmail.com> <AANLkTimAo9bD3dwVhmDn9FuypdS5j4zG4yrHs3x2NxpP@mail.gmail.com> <8B0A9FCBB9832F43971E38010638454F03ED35AB54@SISPE7MB1.commscope.com> <AANLkTin3oti7f4F8kP0t4iWciCmTTkT2OrC31_MV_244@mail.gmail.com>
In-Reply-To: <AANLkTin3oti7f4F8kP0t4iWciCmTTkT2OrC31_MV_244@mail.gmail.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
acceptlanguage: en-US
Content-Type: multipart/alternative; boundary="_000_8B0A9FCBB9832F43971E38010638454F03ED35AB65SISPE7MB1comm_"
MIME-Version: 1.0
X-BCN: Meridius 1000 Version 3.4 on csmailgw1.commscope.com
X-BCN-Sender: Martin.Thomson@andrew.com
Cc: "hybi@ietf.org" <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: Wed, 18 Aug 2010 00:21:55 -0000

I think that you’ve misunderstood my suggestion as well.  I’m not suggesting that we avoid fragmentation (even if there is consensus, and I’ll defer to the chairs on this point).  What I’m suggesting is that fragmentation can be accommodated as an extension.

I am absolutely NOT suggesting that we avoid the topic of extensibility in the base - to do so would be foolish.

Repeating Jamie’s suggestion:

  <length> <opcode>

Define opcodes for fragmented messages (start, middle, end), then you have five opcodes:

  0 - this is a complete message, and it contains binary data
  1 - this is a complete message, and it contains UTF-8 text data
  2 - this is the start of a fragmented message
  3 - this is the middle of a fragmented message
  4 - this is the end of a fragmented message

For 2, 3 and 4, you follow that with another opcode - 0 or 1.

<length> <fragmentation opcode> <opcode>

You might practice a little judicious optimization, but fundamentally, opcodes 2-4 are simply extensions.  An intermediary that doesn’t understand just passes these on unmodified (that’s the extensibility bit you have to include).

--Martin

From: John Tamplin [mailto:jat@google.com]
Sent: Wednesday, 18 August 2010 10:05 AM
To: Thomson, Martin
Cc: ifette@google.com; gustav trede; hybi@ietf.org
Subject: Re: [hybi] Framing Take VI (a compromise proposal)

On Tue, Aug 17, 2010 at 7:50 PM, Thomson, Martin <Martin.Thomson@andrew.com<mailto:Martin.Thomson@andrew.com>> wrote:
That wasn’t the suggestion at all.  Binary/text was included.  The proposal was length + opcode.  Two opcodes only…for now.

The other stuff (fragmentation, channels, etc) are well enough understood now to say that they can be built in later. Hence, we reserve the bits and plan to build them later (or not at all).

I think we do know that we have a use-case for fragmentation, as it has been accepted as a requirement for this protocol.  As previously mentioned, the inclusion of a total message length was required to remove objections to fragmentation.  So, other than having two options for the frame length to preserve efficient encoding of small messages, I think the current proposal is about as minimal as it can get.

I think if we leave out fragmentation and planned extensibility from the base protocol, we haven't really accomplished anything and we will either wind up having to make incompatible changes later or having suboptimal framing once we do define some extensions.

Let's say we did strip out fragmentation, and even defined the INI/FIN bits as proposed, but required that they be 1 in the initial version.  Then, any intermediaries and receivers that are written now will break when fragmentation is added later, and experience shows that those intermediaries will be very slowly upgraded.  I think that would add years to when fragmentation could usefully be used, so I think it is entirely appropriate that fragmentation support be in the base protocol.

--
John A. Tamplin
Software Engineer (GWT), Google