[hybi] multiplexing

Martin Sustrik <sustrik@250bpm.com> Thu, 01 September 2011 06:53 UTC

Return-Path: <sustrik@250bpm.com>
X-Original-To: hybi@ietfa.amsl.com
Delivered-To: hybi@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BA01A21F8AF6 for <hybi@ietfa.amsl.com>; Wed, 31 Aug 2011 23:53:00 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -0.392
X-Spam-Level:
X-Spam-Status: No, score=-0.392 tagged_above=-999 required=5 tests=[AWL=0.302, BAYES_00=-2.599, HELO_EQ_SK=1.35, HOST_EQ_SK=0.555]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 0v46YNUyZkVX for <hybi@ietfa.amsl.com>; Wed, 31 Aug 2011 23:53:00 -0700 (PDT)
Received: from mail.moloch.sk (chrocht.moloch.sk [62.176.169.44]) by ietfa.amsl.com (Postfix) with ESMTP id 32CB221F8785 for <hybi@ietf.org>; Wed, 31 Aug 2011 23:52:59 -0700 (PDT)
Received: from [10.9.1.2] (chello089173046084.chello.sk [89.173.46.84]) by mail.moloch.sk (Postfix) with ESMTPSA id 5D0221833E03 for <hybi@ietf.org>; Thu, 1 Sep 2011 08:54:29 +0200 (CEST)
Message-ID: <4E5F2C2D.5070907@250bpm.com>
Date: Thu, 01 Sep 2011 08:54:37 +0200
From: Martin Sustrik <sustrik@250bpm.com>
User-Agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.9.2.20) Gecko/20110805 Thunderbird/3.1.12
MIME-Version: 1.0
To: hybi@ietf.org
Content-Type: text/plain; charset="ISO-8859-1"; format="flowed"
Content-Transfer-Encoding: 7bit
X-Mailman-Approved-At: Thu, 01 Sep 2011 00:23:50 -0700
Subject: [hybi] multiplexing
X-BeenThere: hybi@ietf.org
X-Mailman-Version: 2.1.12
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: Thu, 01 Sep 2011 06:53:00 -0000
X-List-Received-Date: Thu, 01 Sep 2011 06:53:00 -0000

Hi,

Draft 13 says:

    "A secondary use-case for fragmentation is for multiplexing, where it
    is not desirable for a large message on one logical channel to
    monopolize the output channel, so the MUX needs to be free to split
    the message into smaller fragments to better share the output
    channel."

The above doesn't play well with TCP pushback. If there are two streams 
passed on top of single TCP connection, and the application doesn't keep 
up with reading one stream, the other stream gets stuck as well.

Is the intention not to use pushback as a means of flow control? In 
other words, if you can't process a message immediately, you must read 
it anyway so as not to block other streams? That sounds like a recipe 
for running out of memory.

Martin