[hybi] Multiplexing: Pre-AddChannelResponse quota

Takeshi Yoshino <tyoshino@google.com> Mon, 28 May 2012 08:29 UTC

Return-Path: <tyoshino@google.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 3EE3D21F8454 for <hybi@ietfa.amsl.com>; Mon, 28 May 2012 01:29:15 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -102.814
X-Spam-Level:
X-Spam-Status: No, score=-102.814 tagged_above=-999 required=5 tests=[AWL=0.161, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100]
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 6uG6x4JWGSCF for <hybi@ietfa.amsl.com>; Mon, 28 May 2012 01:29:14 -0700 (PDT)
Received: from mail-yx0-f172.google.com (mail-yx0-f172.google.com [209.85.213.172]) by ietfa.amsl.com (Postfix) with ESMTP id 8280921F8456 for <hybi@ietf.org>; Mon, 28 May 2012 01:29:14 -0700 (PDT)
Received: by yenq13 with SMTP id q13so1442082yen.31 for <hybi@ietf.org>; Mon, 28 May 2012 01:29:14 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:from:date:message-id:subject:to:content-type :x-system-of-record; bh=CLjnMLa+qe+6Oai5856YeEdQbxXRwLWzSPoYMkaJDTw=; b=SaawrQEDhhUfF/bdDtJ8wfCACiar3chY8hv+7/thdVCffA+lF0X3ye9sPiLH5lOk5M Jd/FWwP5wuRgqvNHVVTlaj0lSeGok+0zjYvdj2nQWn43yY76GGIn/kOHurq0/BIJkl9X fO6/UEKwrkN9hbgkWw61Y9oSKhTDalBbBj8330FCuxy4jWUCjtdDqwU7qsYavwWcb6ut 07zHbKWN1UFjQj/yVLJZgiO3vgKrgnaWtISWIksMZtWuivtgI2KevqB3G5+/cADQmovi W3QzbIv6IluHFpXqnjBaDOfOYzErRjmwen1vZQx1+bTAMStdcOdNQqQiGwAaXtpzYtho 1jMw==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:from:date:message-id:subject:to:content-type :x-system-of-record:x-gm-message-state; bh=CLjnMLa+qe+6Oai5856YeEdQbxXRwLWzSPoYMkaJDTw=; b=d/8JoTLnBoAYPJRc+yLBxOx4OiJU2EA+N/0OmTWEWmm1Rmytb4iNKk+gylTUgqk+pi df69mptdiaLb0I37eRVAm5LEbNgZubh4qVV76e14nIa7RfPEGZG3JeyF1I7a62UfvXHX 0MP8NPgml9au+LobqoiR7QCrfJXjnWx59RMUuA5p6TJUWEb/vZyVXsEC5uFW4OcFxbq0 pTRDQExoHJIAzKoJpDf239b9aqGyusyx5RuvmcpGdmgVofZHG6xpDrw2wbBSKUyp9tsb TaXzWKPsbpDqoCh6IGMSYd4K7owx0Cy/CYfDqhYZ4m67bARgh+cJaynHHgPNBJxwfehp kSCA==
Received: by 10.50.46.228 with SMTP id y4mr3921658igm.10.1338193753558; Mon, 28 May 2012 01:29:13 -0700 (PDT)
Received: by 10.50.46.228 with SMTP id y4mr3921650igm.10.1338193753437; Mon, 28 May 2012 01:29:13 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.231.66.7 with HTTP; Mon, 28 May 2012 01:28:53 -0700 (PDT)
From: Takeshi Yoshino <tyoshino@google.com>
Date: Mon, 28 May 2012 17:28:53 +0900
Message-ID: <CAH9hSJZUAHQzDm4ofq6onc620SNretLQDOcjSnr2eQ0YA9yFdQ@mail.gmail.com>
To: hybi@ietf.org
Content-Type: multipart/alternative; boundary="14dae93410415076d804c11483b8"
X-System-Of-Record: true
X-Gm-Message-State: ALoCoQn8+3kZxoxzLGPKkqc5FKOtXffxJIuJgZCdNfYu1iOn4M72aWNmFaf+A/pda2nSw9jl7MNba2/AkuyGLsLfkXZcUKjtjCzK2X7CB9LXzESOxSFt1islyDAqBOux8xF4WS/xBkCJ
Subject: [hybi] Multiplexing: Pre-AddChannelResponse quota
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: Mon, 28 May 2012 08:29:15 -0000

Hi all,

Sorry for delay on the decision making on the pre-response quota feature of
the multiplexing extension. Based on input on the list, I'm going to add
two extension parameters for use in the server's opening handshake of the
physical channel.

One is pre_handshake_quota. It indicates the number of bytes allowed to be
sent by the client before receiving an AddChannelResponse for each logical
channel.

The second one I want to introduce is max_simultaneous_handshakes that
limits the number of in-flight AddChannelRequests the client may issue not
to run out the server's buffer for pre-handshake data.

Servers may send these extension parameter based on their buffering
capacity.

I also considered limiting total pre-handshake bytes summed for all
channels. This doesn't increase complexity so much as it introduces only
one extension parameter. But not to run out buffer for each channel, this
would be practically limited up to the minimum value of quota for all
logical channel. So, the pre-handshake quota won't be utilized well if many
AddChannelRequests are issued simultaneously.

As John said in the thread, if we allow the WebSocket API to send data
before receiving AddChannelResponse, the JS application should be
responsible for re-sending. Otherwise, the WebSocket stack would need to
buffer much data in case re-sending is necessary.

That said, in the first place, we haven't discussed for what case
re-sending would happen. We need to clarify this and have a way to allow JS
to know what to do.

Takeshi