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

"Arman Djusupov" <arman@noemax.com> Wed, 25 April 2012 13:33 UTC

Return-Path: <arman@noemax.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 54FBA21F86B4 for <hybi@ietfa.amsl.com>; Wed, 25 Apr 2012 06:33:44 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.338
X-Spam-Level:
X-Spam-Status: No, score=-2.338 tagged_above=-999 required=5 tests=[AWL=0.260, BAYES_00=-2.599, HTML_MESSAGE=0.001]
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 n0wahngLTflr for <hybi@ietfa.amsl.com>; Wed, 25 Apr 2012 06:33:43 -0700 (PDT)
Received: from mail.noemax.com (mail.noemax.com [64.34.201.8]) by ietfa.amsl.com (Postfix) with ESMTP id 674E721F86B1 for <hybi@ietf.org>; Wed, 25 Apr 2012 06:33:43 -0700 (PDT)
Received: from ArmanPC1 by mail.noemax.com (IceWarp 9.4.1) with ASMTP (SSL) id JRG03141; Wed, 25 Apr 2012 16:33:41 +0300
From: Arman Djusupov <arman@noemax.com>
To: 'John Tamplin' <jat@google.com>
References: <CAH9hSJZP8FhAGANSwPfvdMCQPyfRhG7tqPT68e6VY5ZCAEROTw@mail.gmail.com> <CABLsOLBsHXsj_A2sWa+b8KaFJBEFMHk0W268RyKzh7J0Y+ZxVQ@mail.gmail.com> <CAH9hSJZMrqDLJLr6RNLk84o1B2i3AVezUeGF9mWZ2Yu2Uv-feA@mail.gmail.com> <CA566BAEAD6B3F4E8B5C5C4F61710C1147FA4EA0@TK5EX14MBXW602.wingroup.windeploy.ntdev.microsoft.com> <002501cd1e15$0c8d8480$25a88d80$@noemax.com> <CA566BAEAD6B3F4E8B5C5C4F61710C1147FA9596@TK5EX14MBXW602.wingroup.windeploy.ntdev.microsoft.com> <4F9494FD.5070106@ducksong.com> <CAH_y2NGJFpC500ut00a6jM=syF0Ljf4oSOh=uchqv1LOud7pKg@mail.gmail.com> <000301cd21f2$8ee30fa0$aca92ee0$@noemax.com> <CABLsOLDzVNx247sXx1+wL-c1T8-R67-BebOnhxJ=1+rBjqwJ5w@mail.gmail.com>
In-Reply-To: <CABLsOLDzVNx247sXx1+wL-c1T8-R67-BebOnhxJ=1+rBjqwJ5w@mail.gmail.com>
Date: Wed, 25 Apr 2012 16:33:02 +0300
Message-ID: <003f01cd22e7$f4a47220$dded5660$@noemax.com>
MIME-Version: 1.0
Content-Type: multipart/alternative; boundary="----=_NextPart_000_0040_01CD2301.19F330C0"
X-Mailer: Microsoft Outlook 14.0
Thread-Index: AQFDpAB3Ba5pDAvrAhMo3RFqWK7Q0QGeXeAIAYMcRbwA5LM+PwFTEQc0AU3uHbkBMBQUXgG+D031AQ8BDg8AtqCt+Zdjpurg
Content-Language: en-us
Cc: 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: Wed, 25 Apr 2012 13:33:44 -0000

The problem is that you are using up buffer space in the client to buffer any frames which might need to be re-sent if the logical connection is not successful.  So, having the server specify that seems backwards to me.  Since frames can be nearly arbitrarily large, that means that the client might have to buffer an arbitrarily large amount of data (even if it refragments it and sends only part of it, it has to hold onto the rest).

 

If the API permits a message to be sent while the socket is not yet connected, the implementation would have to buffer any amount of data being pushed into the Socket unless this amount is less than the default quota. Currently the default quota is 0, so it will have to buffer everything.  As you have pointed out, even if a quota is available, all data sent before the logical channel is established will have to be buffered in order to be resent if the connection fails. Note that if the API permits this than it would also have to buffer in cases when mux is not used since the API has no knowledge whether mux is present or not.

 

Ok, but who decides, and who bears the buffering cost of that decision?

 

So far I can imagine these options to determine the initial quota:

 

1)      Change spec so that, by default, 64k are granted as initial quota to all logical channels before receiving the AddChannelResponse. Spec decides, both bear cost, w/o RTT.

2)      Leave the default initial quota as is at zero. But then why permit the client to send data before the AddChannelResponse when we know that it doesn’t have any available quota. Nobody decides, nobody bears cost, w/ RTT.

3)      Let the server set the default quota for all logical channels during the first handshake. Server decides, cost depends on decision, w/o RTT.

4)      Let the client set a “self-granted” quota for every channel, so that the server either accepts it or refuses the logical channel. Client decides, cost depends on decision, w/o RTT.

5)      Let the client request a “desired” quota for all logical channels, and the server grant an equal or lower quota during the first handshake. Server decides, cost depends on decision, w/o RTT.

 

-- 
John A. Tamplin
Software Engineer (GWT), Google

 

With best regards,

Arman