IETF Logo Mail Archive

Re: [hybi] Frame size

"Thomson, Martin" <Martin.Thomson@andrew.com> Mon, 19 April 2010 01:05 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 2651F3A6A2F for <hybi@core3.amsl.com>; Sun, 18 Apr 2010 18:05:29 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.836
X-Spam-Level:
X-Spam-Status: No, score=-1.836 tagged_above=-999 required=5 tests=[AWL=0.763, BAYES_00=-2.599]
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 8Eh1I6erzujP for <hybi@core3.amsl.com>; Sun, 18 Apr 2010 18:05:28 -0700 (PDT)
Received: from csmailgw2.commscope.com (csmailgw2.commscope.com [198.135.207.242]) by core3.amsl.com (Postfix) with ESMTP id 4A6723A6822 for <hybi@ietf.org>; Sun, 18 Apr 2010 18:05:28 -0700 (PDT)
Received: from [10.86.20.103] ([10.86.20.103]:12512 "EHLO ACDCE7HC2.commscope.com") by csmailgw2.commscope.com with ESMTP id S219932Ab0DSBFU (ORCPT <rfc822; hybi@ietf.org>); Sun, 18 Apr 2010 20:05:20 -0500
Received: from SISPE7HC2.commscope.com (10.97.4.13) by ACDCE7HC2.commscope.com (10.86.20.103) with Microsoft SMTP Server (TLS) id 8.1.436.0; Sun, 18 Apr 2010 20:05:20 -0500
Received: from SISPE7MB1.commscope.com ([fe80::9d82:a492:85e3:a293]) by SISPE7HC2.commscope.com ([fe80::58c3:2447:f977:57c3%10]) with mapi; Mon, 19 Apr 2010 09:05:15 +0800
From: "Thomson, Martin" <Martin.Thomson@andrew.com>
To: Jamie Lokier <jamie@shareable.org>
Date: Mon, 19 Apr 2010 09:06:36 +0800
Thread-Topic: [hybi] Frame size
Thread-Index: AcrfWpHBnkL9Po8iRmKm3Q9NM5rNWgAAIsgA
Message-ID: <8B0A9FCBB9832F43971E38010638454F03E7D067BC@SISPE7MB1.commscope.com>
References: <8B0A9FCBB9832F43971E38010638454F03E3F313ED@SISPE7MB1.commscope.com> <v2m5c902b9e1004160043i7b5ccc79y2346e1b2b2c55cf5@mail.gmail.com> <8B0A9FCBB9832F43971E38010638454F03E7D06790@SISPE7MB1.commscope.com> <20100419005215.GD18876@shareable.org>
In-Reply-To: <20100419005215.GD18876@shareable.org>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
x-cr-puzzleid: {C7CF1C2C-C7D0-436E-B2D9-B71F6AD3E0C7}
x-cr-hashedpuzzle: ALzS DtGD FspR KMLI MW9/ Nv88 PaAw RX0g TcnJ UNYl Uk+v U06/ ZkzM cIay cxfM d4Cn; 3; aAB5AGIAaQBAAGkAZQB0AGYALgBvAHIAZwA7AGoAYQBtAGkAZQBAAHMAaABhAHIAZQBhAGIAbABlAC4AbwByAGcAOwBqAHUAcwB0AGkAbgBAAGUAcgBlAG4AawByAGEAbgB0AHoALgBjAG8AbQA=; Sosha1_v1; 7; {C7CF1C2C-C7D0-436E-B2D9-B71F6AD3E0C7}; bQBhAHIAdABpAG4ALgB0AGgAbwBtAHMAbwBuAEAAYQBuAGQAcgBlAHcALgBjAG8AbQA=; Mon, 19 Apr 2010 01:06:36 GMT; UgBFADoAIABbAGgAeQBiAGkAXQAgAEYAcgBhAG0AZQAgAHMAaQB6AGUA
acceptlanguage: en-US
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: base64
MIME-Version: 1.0
X-BCN: Meridius 1000 Version 3.4 on csmailgw2.commscope.com
X-BCN-Sender: Martin.Thomson@andrew.com
Cc: Hybi <hybi@ietf.org>
Subject: Re: [hybi] Frame size
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: Mon, 19 Apr 2010 01:05:29 -0000

Jamie writes:
> Alas, there are very good reasons to send non-final frames that aren't
> the full length.

From my perspective, the only very good reason you stop sending one thing is because you want to send something else (i.e. multiplexing).

Aligning with segments isn't a good argument for me.  How the WS layer is aware of layers below it and the way that it interacts with those is orthogonal to frame size.  TCP provides an abstraction of a stream.  If a particular implementation wants to optimize, it can, but that shouldn't affect layers above those key abstraction points.

Addressing shortcomings in the abstraction (graceful close, etc...) is another thing.  It's reasonable to say that the TCP abstraction does not provide graceful close, so providing it at a higher layer is OK.

--Martin

v2.23.0 | Report a Bug | By Email