IETF Logo Mail Archive

Re: [hybi] Send quota value before receiving AddChannelResponse (was: Re: MUC: channel ID semantics)

Gabriel Montenegro <Gabriel.Montenegro@microsoft.com> Thu, 19 April 2012 05:41 UTC

Return-Path: <Gabriel.Montenegro@microsoft.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 14BA721F84E1 for <hybi@ietfa.amsl.com>; Wed, 18 Apr 2012 22:41:38 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -5.098
X-Spam-Level:
X-Spam-Status: No, score=-5.098 tagged_above=-999 required=5 tests=[AWL=-1.500, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1]
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 Ld-7LjYDmTdH for <hybi@ietfa.amsl.com>; Wed, 18 Apr 2012 22:41:36 -0700 (PDT)
Received: from am1outboundpool.messaging.microsoft.com (am1ehsobe001.messaging.microsoft.com [213.199.154.204]) by ietfa.amsl.com (Postfix) with ESMTP id 803C921F84DF for <hybi@ietf.org>; Wed, 18 Apr 2012 22:41:35 -0700 (PDT)
Received: from mail25-am1-R.bigfish.com (10.3.201.235) by AM1EHSOBE004.bigfish.com (10.3.204.24) with Microsoft SMTP Server id 14.1.225.23; Thu, 19 Apr 2012 05:41:34 +0000
Received: from mail25-am1 (localhost [127.0.0.1]) by mail25-am1-R.bigfish.com (Postfix) with ESMTP id 360F9E03AB; Thu, 19 Apr 2012 05:41:34 +0000 (UTC)
X-SpamScore: -24
X-BigFish: VS-24(zz9371Ic85fh98dKzz1202hzz1033IL8275bh8275dhz2fh2a8h668h839hd25h)
X-Forefront-Antispam-Report: CIP:131.107.125.8; KIP:(null); UIP:(null); IPV:NLI; H:TK5EX14MLTC104.redmond.corp.microsoft.com; RD:none; EFVD:NLI
Received-SPF: pass (mail25-am1: domain of microsoft.com designates 131.107.125.8 as permitted sender) client-ip=131.107.125.8; envelope-from=Gabriel.Montenegro@microsoft.com; helo=TK5EX14MLTC104.redmond.corp.microsoft.com ; icrosoft.com ;
Received: from mail25-am1 (localhost.localdomain [127.0.0.1]) by mail25-am1 (MessageSwitch) id 1334814091727279_31609; Thu, 19 Apr 2012 05:41:31 +0000 (UTC)
Received: from AM1EHSMHS004.bigfish.com (unknown [10.3.201.232]) by mail25-am1.bigfish.com (Postfix) with ESMTP id ACF26A01BD; Thu, 19 Apr 2012 05:41:31 +0000 (UTC)
Received: from TK5EX14MLTC104.redmond.corp.microsoft.com (131.107.125.8) by AM1EHSMHS004.bigfish.com (10.3.207.104) with Microsoft SMTP Server (TLS) id 14.1.225.23; Thu, 19 Apr 2012 05:41:31 +0000
Received: from TK5EX14MLTW653.wingroup.windeploy.ntdev.microsoft.com (157.54.24.14) by TK5EX14MLTC104.redmond.corp.microsoft.com (157.54.79.159) with Microsoft SMTP Server (TLS) id 14.2.283.4; Thu, 19 Apr 2012 05:41:01 +0000
Received: from TK5EX14MBXW602.wingroup.windeploy.ntdev.microsoft.com ([169.254.2.247]) by TK5EX14MLTW653.wingroup.windeploy.ntdev.microsoft.com ([157.54.24.14]) with mapi id 14.02.0298.005; Wed, 18 Apr 2012 22:41:01 -0700
From: Gabriel Montenegro <Gabriel.Montenegro@microsoft.com>
To: Takeshi Yoshino <tyoshino@google.com>, John Tamplin <jat@google.com>
Thread-Topic: Send quota value before receiving AddChannelResponse (was: Re: [hybi] MUC: channel ID semantics)
Thread-Index: AQHNHYNZVNCvN/MkuEa7uhOfYIR9cZahobhQ
Date: Thu, 19 Apr 2012 05:41:00 +0000
Message-ID: <CA566BAEAD6B3F4E8B5C5C4F61710C1147FA4EA0@TK5EX14MBXW602.wingroup.windeploy.ntdev.microsoft.com>
References: <CAH9hSJZP8FhAGANSwPfvdMCQPyfRhG7tqPT68e6VY5ZCAEROTw@mail.gmail.com> <CABLsOLBsHXsj_A2sWa+b8KaFJBEFMHk0W268RyKzh7J0Y+ZxVQ@mail.gmail.com> <CAH9hSJZMrqDLJLr6RNLk84o1B2i3AVezUeGF9mWZ2Yu2Uv-feA@mail.gmail.com>
In-Reply-To: <CAH9hSJZMrqDLJLr6RNLk84o1B2i3AVezUeGF9mWZ2Yu2Uv-feA@mail.gmail.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
x-originating-ip: [157.54.51.90]
Content-Type: multipart/alternative; boundary="_000_CA566BAEAD6B3F4E8B5C5C4F61710C1147FA4EA0TK5EX14MBXW602w_"
MIME-Version: 1.0
X-OriginatorOrg: microsoft.com
Cc: "hybi@ietf.org" <hybi@ietf.org>
Subject: Re: [hybi] Send quota value before receiving AddChannelResponse (was: Re: MUC: channel ID semantics)
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, 19 Apr 2012 05:41:38 -0000

In all previous discussions in this WG there has been relentless push to optimize any RTTs out of the protocol. Consistent with this is being able to use the lightweight channel setup (as is possible in SPDY) in which data transmission is possible without requiring the ack. If I'm the only one asking about this, perhaps the WG is no longer interested in such optimizations, but I'd still be interested in understanding the change of heart.

From: Takeshi Yoshino [mailto:tyoshino@google.com]
Sent: Wednesday, 18 April, 2012 9:50
To: John Tamplin; Gabriel Montenegro
Cc: Arman Djusupov; hybi@ietf.org
Subject: Re: Send quota value before receiving AddChannelResponse (was: Re: [hybi] MUC: channel ID semantics)

On Wed, Apr 18, 2012 at 21:01, John Tamplin <jat@google.com<mailto:jat@google.com>> wrote:
On Wed, Apr 18, 2012 at 4:15 AM, Takeshi Yoshino <tyoshino@google.com<mailto:tyoshino@google.com>> wrote:
You're right. In the latest spec, it's not explicitly specified what the value of send quota is until AddChannelResponse is received.

There're several options we can take.

a) specify the fixed value of send quota before AddChannelResponse in the spec
b) add a new parameter "pre_handshake_quota" to multiplexing extension to negotiate the value of send quota before AddChannelResponse
c) drop the feature to configure initial quota for each logical channel, and redefine the quota parameter as pre-handshake send quota for all logical channels

Until we know the AddChannel was accepted, how can we send data anyway?  This seems just like the initial handshake on a new connection -- you wouldn't consider sending that data until you knew the connection was accepted.  Since we are avoiding TCP setup requirements, this will be much less latency than if the connection were created without multiplexing.

I suppose it would be possible to send the data while keeping it buffered as an optimization, but since adding a channel should be infrequent compared to sending data on it, I don't see it as that important to optimize for.

Yes. It's infrequent.

If the information the impatient client want to send is small, it can also be just embeded into URL or subprotocol to avoid the additional RTT.

If no one really needs this feature and has justification, I'm fine with keeping the same restriction (no transmission until AddChannelResponse) as no-mux connection.

IIRC, Gabriel was interested in this optimization. Gabriel, do you have any comment about this?

v2.23.0 | Report a Bug | By Email