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

The server might refuse the channel due to reaching the maximum number of
mux logical channels on the same connection. The issue is not only with the
cases when the channel is refused but also when the server can't allocate a
new channel fast, which would force the server to buffer frames of pending
logical channels until they get accepted in order to read from the wire the
subsequent frames belonging to already established channels. For this reason
the server needs a way to control a default quota. My suggestion was to let
the server define the default quota for the logical channel during the
physical channel handshake rather than hardcoding it into the spec.

As I already mentioned in a previous message, according to the current
specification (a) the client may send data prior to receiving an
AddChannelResponse, but (b) it doesn't have any flow control quota until an
AddChannelResponse with or without quota parameter is received. These two
obviously contradict each other. So if we want the client to be able to send
some data right after the AddChannelResponse is sent then we need to define
how the default quota is negotiated. In such a case we actually don't need
any quota parameter in the AddChannelResponse handshake. In other words the
part of the spec that describes the initial flow control quota negotiation
has to change anyway.

PS: I totally agree on the evilness of 'RTT', but there has to be a clean
way to control the amount of data that the client can send before the
channel is accepted, preferably not just a hardcoded default quota for all
clients in all cases.

With best regards,
Arman

-----Original Message-----
From: hybi-bounces@ietf.org [mailto:hybi-bounces@ietf.org] On Behalf Of Greg
Wilkins
Sent: Tuesday, April 24, 2012 9:05 AM
To: Patrick McManus
Cc: hybi@ietf.org
Subject: Re: [hybi] Send quota value before receiving AddChannelResponse
(was: Re: MUC: channel ID semantics)

In the case of MUX, the server has already accepted the main
connection from the client and agreed to the the MUX extensions.
Thus I would think that rejecting addChannel would be an
extraordinarily rare occurrence.    Perhaps it might be provoked by a
different channel extension, but if we don't expose the extension
choice to the application then I would expect the same extension and
settings for all channels anyway (hence the worth of the delta header
design).

So I think that a quick start for sending data can be another benefit
of using MUX.

cheers
_______________________________________________
hybi mailing list
hybi@ietf.org
https://www.ietf.org/mailman/listinfo/hybi