Re: [hybi] Requirement: extensions and sub protocols

Jamie Lokier <jamie@shareable.org> Fri, 05 March 2010 00:57 UTC

Return-Path: <jamie@shareable.org>
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 0B4EF28C0F5 for <hybi@core3.amsl.com>; Thu, 4 Mar 2010 16:57:16 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.44
X-Spam-Level:
X-Spam-Status: No, score=-2.44 tagged_above=-999 required=5 tests=[AWL=0.159, 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 wn5UagKO2uRV for <hybi@core3.amsl.com>; Thu, 4 Mar 2010 16:57:15 -0800 (PST)
Received: from mail2.shareable.org (mail2.shareable.org [80.68.89.115]) by core3.amsl.com (Postfix) with ESMTP id 312FB28C0E8 for <hybi@ietf.org>; Thu, 4 Mar 2010 16:57:15 -0800 (PST)
Received: from jamie by mail2.shareable.org with local (Exim 4.63) (envelope-from <jamie@shareable.org>) id 1NnLqu-0002uI-1Y; Fri, 05 Mar 2010 00:57:16 +0000
Date: Fri, 05 Mar 2010 00:57:16 +0000
From: Jamie Lokier <jamie@shareable.org>
To: KOMATSU Kensaku <kensaku.komatsu@gmail.com>
Message-ID: <20100305005716.GB9244@shareable.org>
References: <4B8ECA2D.4050303@ericsson.com> <8e7c686d1003031732wa39f448k1d9286585517c0d8@mail.gmail.com>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Disposition: inline
In-Reply-To: <8e7c686d1003031732wa39f448k1d9286585517c0d8@mail.gmail.com>
User-Agent: Mutt/1.5.13 (2006-08-11)
Cc: Hybi <hybi@ietf.org>
Subject: Re: [hybi] Requirement: extensions and sub protocols
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: Fri, 05 Mar 2010 00:57:16 -0000

KOMATSU Kensaku wrote:
> RTT measurements between client and server will be required for some
> extensions or sub-protocol. For example, TCP flow-control is so
> sensitive both content-size and RTT, so these two-parameters will be
> useful for some application's negotiation-phase which is better to use
> multiplexing frames in one channel or to use independent channels for
> each frames.

When you say "use independent channels", do you mean independent TCP
connections?

Because "channel" is often used to mean the individual flows that are
carried inside a multiplexed connection.

Assuming you do mean independent TCP connections:

Can you say a bit more about the circumstances when an endpoint would
choose to use them instead of multiplexing?  What kind of parameter values
are needed for multiple TCPs to be better?

I have not heard of this before, although I appreciate that multiple
TCPs can be faster than a single shared TCP in some scenarios.  (I'm
thinking of bonded-ADSL where each TCP is confined to exactly one of
the links).

Sometimes 4 TCPs is better than 1, but worse than 100, when you have
100 individual flows to transport.  But I'm not sure how to decide
what to use automatically.

Note that full end-to-end RTT, including processing latency, can be
measured by applications sending each other messages.

-- Jamie