Re: [hybi] Multiplexing: Pre-AddChannelResponse quota

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

-- 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.

 

A more simple description would be that the client simply sets its quota to
the PQ-I value and continues using it until it gets an FC block from the
server that would increment it. The server keeps track of the number of
active slots on the client side so it knows the current PQ-I value and also
starts keeping track of the client quota based on the PQ-I value.

 

- 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? 

 

With best regards,

Arman

 

 

From: Takeshi Yoshino [mailto:[e-mail]] 
Sent: Thursday, June 14, 2012 11:56 AM
To: Jamie Lokier
Cc: Arman Djusupov; [e-mail]
Subject: Re: [hybi] Multiplexing: Pre-AddChannelResponse quota

 

On Wed, Jun 13, 2012 at 7:18 PM, Takeshi Yoshino <[e-mail]>
wrote:

On Thu, Jun 7, 2012 at 12:44 PM, Jamie Lokier <[e-mail]> wrote:

If there is a max_simultaneous_handshakes - why not recast that as

"initial new-channels window" - meaning a flow control grant, which is
updated by further grants from the server.  (Very similar to the flow
control per channel).

 

Good idea. I'll take it.

 

I'm designing algorithm to realize this. My current idea is as follows. Just
a first strawman. It's very complicated.

 

- New channel window is a set of slots for new channel creation attempts

-- Each slot corresponds to one future/in-flight AddChannelRequest

-- Each slot (Slot_k) has pre-handshake quota (PQ_k)

-- When received, say, NewChannelQuota block, add a new slot. The new slot
has pre-handshake quota of 0

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

- To issue an AddChannelRequest with channel ID X, the client picks oldest
unused slot (Slot_i) for it

- The client MAY send pre-handshake data for the channel X up to PQ_i

- When received the corresponding AddChannelResponse,

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

-- Slot_i is removed from the new channel window

 

Goals are:

 

- make it able to increase the pre-handshake send quota for already
allocated slots

- give pre-handshake quota equally to all active slots

- carry over remaining pre-handshake quota into post-handshake quota

- deterministic, not affected by timing