Re: [hybi] Multiplexing: Pre-AddChannelResponse quota

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

Since we go that far in flexibility why not just give the client a quota and
let it distribute it in the channels any way the client likes. This way the
client will be able to give a higher or lower priority to newly established
channels. The client will need to state the amount of quota it assigned to a
channel slot when sending an AddChannelRequest. So when receiving a
PreHandshakeQuota the client does not level it between available slots, but
uses a share of this quota later when creating a new channel. This would be
a simplified common quota.

 

With best regards,

Arman

 

 

From: Takeshi Yoshino [mailto:[e-mail]] 
Sent: Friday, June 15, 2012 6:19 AM
To: Arman Djusupov
Cc: Jamie Lokier; [e-mail]
Subject: Re: [hybi] Multiplexing: Pre-AddChannelResponse quota

 

On Thu, Jun 14, 2012 at 6:58 PM, Arman Djusupov <[e-mail]> wrote:

-- send quota for X is set to (PQ_i) - (total pre-handshake data sent) +
(initial send quota assigned by the AddChannelResponse)

 

The quota header in AddChannelResponse is not needed, the server can
supplement the client quota using normal flow control frames. This would
simplify it a bit. If the server needs to grant additional quota right after
the AddChannelResponse, it can send an FC block in the same frame with the
AddChannelResponse. The FC block format is more efficient than the literal
format of the AddChannelResponse header.

 

OK

 

- When received, say, PreHandshakeQuota block, split it up and add to slots
so that PQ_k are leveled (older ones first) among all slots

 

Why to split up the quota? This leave room for strange cases when the quota
is not divisible by the number of channels. Why not simply set or add a
value to each already allocated slot?

 

I tried to make it able to gradually decrease PQ_i for new slots when the
server is overloaded.

 

If PreHandshakeQuota adds the same value to each allocated slot, PQ_i for a
new channel needs to be initialized to the same value as the other slots' on
NewChannelQuota. Otherwise, PQ_i values are in-balanced between the new one
and the others. Then, ... there's no way to  decrease PQ_i.

 

We may add a new channel with slightly smaller PQ_i to allow for
suppression. This works, but one of its cons is that we cannot level PQ_i of
allocated slots even when the server gets less loaded again because the
PreHandshakeQuota keeps high slots high and low slots low.