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

["Arman Djusupov" <[e-mail]>]

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]] 
Sent: Thursday, April 19, 2012 8:41 AM
To: Takeshi Yoshino; John Tamplin
Cc: Arman Djusupov; [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]] 
Sent: Wednesday, 18 April, 2012 9:50
To: John Tamplin; Gabriel Montenegro
Cc: Arman Djusupov; [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]> wrote:

On Wed, Apr 18, 2012 at 4:15 AM, Takeshi Yoshino <[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?