Subject: [hybi] Finalize flow control metric

From: Takeshi Yoshino <[email-masked]>
Date: Thu, 16 Aug 2012 16:34:09 +0900

In WebSocket multiplexing, each stream transports not only message payload
but message boundary information which also spends octets on wire. I'd like
to make flow control mechanism consider this point.

I've talked about this on the thread about -03 update and f2f meeting in
Vancouver. Thanks for feedback. I want to finalize this point on -05 update.

Requirements:
a) reflect each stream's processing power, size of buffer, etc. (receiver
can control amount of incoming data to some extent)
b) receiver can compute the amount of quota the sender spent for the
received data without ambiguity by looking at it
c) quota consumption is (almost) proportional to bandwidth for fairness
d) fragmentation made by multiplexer's matter should not affect quota
consumption

Current flow control almost satisfies (c) but cannot prevent flooding by
zero-sized messages. So, I want to have each encapsulated message consume
extra quota. I thought just counting in header overhead is fine, and was
going to suggest +1 octet for each frame (Encapsulation overhead is also
not negligible but it seems good enough once we have 1 octet penalty).

Each stream can also try to use more octets on wire by flushing data byte
by byte. But as we required in the spec that each logical stream cannot use
frame-wise signal, we can skip forwarding zero-sized frame (NOT zero-sized
message). So, at least 1 octet will be consumed from quota for each
flushing. It's enough I think.

However, we should also satisfy (d). Fragmentation made before mux and one
made by mux are not distinguishable. So, I think we shouldn't consume quota
headers of second and later encapsulated frame. Encapsulation overhead
(length representation and masking belong to this layer) also shouldn't be
counted in.

(Note: if many control frames are injected on one message before mux,
there'll be a lot of non-unfragmentable points. But each control frames
themselves also consume quota, we can prevent flooding.)

===

So, I suggested 1 octet (the size of encapsulated FIN, RSV1-3, opcode of
the first fragment) per message (NOT per frame) extra quota consumption in
addition to consumption equal to the length of payload. This satisfies
(a)-(d).

Alternatives
- count in second and later fragment's header but giving up satisfying (d)
- count in encapsulation overhead
- allocate RSV2 as MUX FIN bit, encapsulate one frame into multiple
encapsulating messages
- ...