Re: [hybi] Multiplexing: Pre-AddChannelResponse quota

Takeshi Yoshino <tyoshino@google.com> Fri, 22 June 2012 06:18 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 B4B4021F85C9 for <hybi@ietfa.amsl.com>; Thu, 21 Jun 2012 23:18:51 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -102.976
X-Spam-Level:
X-Spam-Status: No, score=-102.976 tagged_above=-999 required=5 tests=[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 qdPtQgkAfyyk for <hybi@ietfa.amsl.com>; Thu, 21 Jun 2012 23:18:51 -0700 (PDT)
Received: from mail-gg0-f172.google.com (mail-gg0-f172.google.com [209.85.161.172]) by ietfa.amsl.com (Postfix) with ESMTP id B51D021F85C4 for <hybi@ietf.org>; Thu, 21 Jun 2012 23:18:50 -0700 (PDT)
Received: by ggnc4 with SMTP id c4so1378737ggn.31 for <hybi@ietf.org>; Thu, 21 Jun 2012 23:18:50 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type:x-system-of-record; bh=KFbuIu9MA1DZoqJP6zc06eBC8TFFxRAjVM4FDt+z6a4=; b=pN/i24Lb9ONODaOLx457bOCaDp7J6w/Jf2I3GhO4GqyAjum9/8w4b0c+2CKgAk14dE x/4TvPVEKfkqMpOUNDdeHRGkSO4Ehz/CpaAl1EAJbHLkmOuIx5Tu8nvCVN8Q1brfNxwT zHB5m+rBmHFfAkrHyt2FM3JFMpjj6NyheS9pk4CPeWkRypxe/O9T1eA18qR0kr344t9W DiAiLkaJUVORIvj1WCyXUweiET6liRrdIXSZPn9r/RsWbp1E+Taa3Qdl7yOPd61P+E5C a58MGc05lYEOp9d06AGhDivF2/UG2fXMJNgAoh+NWLhQsntVuwZZkt4W4I5aAHo3WfHq ZHyw==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type:x-system-of-record:x-gm-message-state; bh=KFbuIu9MA1DZoqJP6zc06eBC8TFFxRAjVM4FDt+z6a4=; b=O+Cd0L9lC+AJ+xqlGhSerPGQ2E1D5CJ/qCCAIh6HFthCdQcu6W3kJzHf88jUYF03M+ jB9gpYWcXeYKd1ogWCVmlJXksE8JoQLvpeelFN2B3mIQGJ7oC4jHONNxlf2yZb0RQm4k zzAsX0RzUbuj9tnzuHf/nW5h5W8cUCeuh6ZQNziBHoDylETtoaH8F9YbNqxjfxQgQk0J eyMpI2l/MevEL2AUeOpRxw0ZOdTe3BN4l4gmzArV2A56e1t1lTlQLEMXRZHPnSl1SV4i qnIXvh37WjxaL+otqneTINASxrFLAAAS7kcxsN7a47QOWO4WDr+ZEA5+gsvhpLCE9ViP nb+Q==
Received: by 10.50.187.228 with SMTP id fv4mr544969igc.10.1340345929703; Thu, 21 Jun 2012 23:18:49 -0700 (PDT)
Received: by 10.50.187.228 with SMTP id fv4mr544958igc.10.1340345929578; Thu, 21 Jun 2012 23:18:49 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.231.66.7 with HTTP; Thu, 21 Jun 2012 23:18:29 -0700 (PDT)
In-Reply-To: <000301cd503d$0aff8f00$20fead00$@noemax.com>
References: <CAH9hSJZUAHQzDm4ofq6onc620SNretLQDOcjSnr2eQ0YA9yFdQ@mail.gmail.com> <002f01cd3cc4$4791b380$d6b51a80$@noemax.com> <20120607034440.GD26406@jl-vm1.vm.bytemark.co.uk> <CAH9hSJZWMgvQMNLapZAg_CS0vri=jZbfPLpLhfninjzG+JxxmA@mail.gmail.com> <CAH9hSJbChf6NPUqraaeEeLnDO=YyYja4SkwZJsWRfM5VUwZ59Q@mail.gmail.com> <002001cd4a14$53eb66f0$fbc234d0$@noemax.com> <CAH9hSJbz9HQrN67=Jf6bEmJikTGEViNEqjDP8XbHKrPKhYD19Q@mail.gmail.com> <001301cd4acf$d8c5cda0$8a5168e0$@noemax.com> <CAH9hSJYzbfUKMjuV3J1-tdapV59N5aewO-nAMLMexzF2f6KosA@mail.gmail.com> <6A3569A8-C253-4363-B00C-F336B0CA3128@noemax.com> <CAH9hSJayEAqJEE7=KdYuq669HOaG76kS9AVwUMUYaPKLtO=zEw@mail.gmail.com> <000301cd503d$0aff8f00$20fead00$@noemax.com>
From: Takeshi Yoshino <tyoshino@google.com>
Date: Fri, 22 Jun 2012 15:18:29 +0900
Message-ID: <CAH9hSJaNpAV2WYqRr7Pf47=auvADPHusx9ipUDLvAZRhRp7iuA@mail.gmail.com>
To: Arman Djusupov <arman@noemax.com>
Content-Type: multipart/alternative; boundary="14dae9340a6b02380204c3099b30"
X-System-Of-Record: true
X-Gm-Message-State: ALoCoQnB3Hu+R8h6NupLZ8SkZHq2LGwBKW7bkjJdDhuK2skigh1fvbkHeJF2mkPZgiCJVM9nnsz0FmuqJIIKR3x6yJi/HzVyIZCiqOM6gvB85U1byTmztwuMcMAypDWvkaY6jQ3CGvEfiLYVmfjmTqY/A5MOADcvZyiuWgpytzoo0wTCd11kzq0=
Cc: hybi@ietf.org
Subject: Re: [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: Fri, 22 Jun 2012 06:18:51 -0000

As we're going to add, say, NewChannelQuotaUpdate command which replenishes
new channel quota, another idea is assigning a channel ID by the server on
NewChannelQuotaUpdate. This way, the server can give pre-handshake quota to
each potential channel slot by the same manner as post-handshake quota
assignment. Pre-handshake quota can be carried over seamlessly.

Takeshi


On Fri, Jun 22, 2012 at 3:05 PM, Arman Djusupov <arman@noemax.com> wrote:

> Hello Takeshi,****
>
> ** **
>
> This will result in the protocol having two different stages of
> communication. One stage before the handshake during which flow control
> should be based on the common quota, and a second stage after the
> end-of-pre-handshake-data frame is received during which flow control is
> based on the logical channel quota. I'm ok with this solution, but I have
> the impression that this is a bit of overkill.****
>
> ** **
>
> It will be difficult to implement in a high concurrency multithreaded
> environment. I can't say if there are any practical problems until I try
> implementing it. But there might be difficulties that are not evident now.
> In general it's becoming a bit more complex than simply working with a
> self-assigned initial quota. ****
>
> ** **
>
> With best regards,****
>
> Arman****
>
> ** **
>
> *From:* Takeshi Yoshino [mailto:tyoshino@google.com]
> *Sent:* Thursday, June 21, 2012 3:27 PM
>
> *To:* Arman Djusupov
> *Cc:* Jamie Lokier; hybi@ietf.org
> *Subject:* Re: [hybi] Multiplexing: Pre-AddChannelResponse quota****
>
> ** **
>
> On Tue, Jun 19, 2012 at 4:06 PM, Arman Djusupov <arman@noemax.com> wrote:*
> ***
>
> For reasons of simplicity and API limitations, browsers may simply always
> level the quota along the channels, or they might prefer to slightly delay
> sending the AddChannelRequest to check what is the size of the first
> message being sent so that the AddChannelRequest with IQ_X = message size
> is sent along with the first message, to avoid an extra roundtrip.****
>
> ** **
>
> Considering the concern Jamie showed, how about sending some FlowControl
> frame variant indicating the end of pre-handshake data after pre-handshake
> frames? The client consumes total pre-handshake data quota it has for the
> new channel as it like. And then, sends the end-of-pre-handshake-data
> frame. It can be after or before receiving AddChannelResponse for the
> request. The server knows how much pre-handshake data quota has been spent
> for the new channel attempt by summing the data size of frames before the
> end-of-pre-handshake-data frame. Delaying AddChannelRequest is fine but not
> so flexible enough to address the concern Jamie showed.****
>