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

[Gabriel Montenegro <[e-mail]>]

I'm not sure "short RTT" is a valid expression any more. At any rate, I'm fine with adding safeguards, but ultimately, it would be a shame to preclude data from flowing along with the AddChannel request.

From: [e-mail] [mailto:[e-mail]] On Behalf Of Arman Djusupov
Sent: Thursday, 19 April, 2012 3:13
To: Gabriel Montenegro; 'Takeshi Yoshino'; 'John Tamplin'
Cc: [e-mail]
Subject: Re: [hybi] Send quota value before receiving AddChannelResponse (was: Re: MUC: channel ID semantics)

We are simply considering whether letting the client to send frames before the logical channel is accepted is worth it in order to remove this short RTT. This feature would also require that the sever buffers the frames of the logical channel until it is accepted. On the server side the procedure of adding logical channels is not certain to be fast. It may involve querying the database or establishing a new physical connection. For the duration of this operation the server would have to spend some amount of its resources despite it would be unclear whether the new logical channel is accepted or not.

The best solution would be to have the server control this by using a default value for the initial quota during the physical channel handshake. For example, the server could set the quota explicitly to "0" during the physical channel handshake, in which case all logical channels (including first one) would be prohibited from sending any data until the channel is accepted and so all clients would have to wait for the first flow control message to arrive from the server side. Note that this flow control message may arrive in the same frame as the AddChannelResponse without any additional RTT.

Practically we don't need to change much in the spec, we just need to be able to negotiate the default quotas during the physical channel handshake. Any additional quotas can be easily granted using the flow control messages that may arrive in the same frame as AddChannelRequest or AddChannelResponse.

With best regards,
Arman

From: Gabriel Montenegro [mailto:[e-mail]]<mailto:[mailto:[e-mail]]>
Sent: Thursday, April 19, 2012 8:41 AM
To: Takeshi Yoshino; John Tamplin
Cc: Arman Djusupov; [e-mail]<mailto:[e-mail]>
Subject: RE: Send quota value before receiving AddChannelResponse (was: Re: [hybi] MUC: channel ID semantics)

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:[e-mail]]<mailto:[mailto:[e-mail]]>
Sent: Wednesday, 18 April, 2012 9:50
To: John Tamplin; Gabriel Montenegro
Cc: Arman Djusupov; [e-mail]<mailto:[e-mail]>
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 <[e-mail]<mailto:[e-mail]>> wrote:
On Wed, Apr 18, 2012 at 4:15 AM, Takeshi Yoshino <[e-mail]<mailto:[e-mail]>> 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?