Subject: [hybi] Mux back pressure

From: Greg Wilkins <[email-masked]>
Date: Mon, 1 Aug 2011 09:45:10 +1000

The thread about the max message size has made me think about the back
pressure mechanism proposed in the x-google-mux extension.   Each
channel has a maximum number of bytes that can be sent without
receiving an explicit flow control message allowing more bytes to be
sent.   I'm now wondering if byte count is the right flow control, and
perhaps message count would be better?

With stream based mechanisms like HTTP, byte counts work fine because
with the server receives a message it typically will have (or start)
an application thread blocked reading for the content.  The server
reads the content only as fast as it can give it to the waiting
application thread.  If the application consumer is running slowing
that the producer+network, then data is not read from the connection,
back pressure is generated and eventually the producer in the client
will block as it tries to write data.

But with message based mechanism, the data is not passed to the
application until an entire message is received.  Thus the
server/client will buffer the data until the end of the message is
received.   Thus if we use bytes as the measure of websocket mux back
pressure,  the OK to send more will be based on the bytes being placed
in a buffer and not passed to the application.   The problem with this
is that it does not measure the capability of the real consumer - only
the capability of the buffers.    This is somewhat akin to the buffer
bloat problem that is currently being seen in TCP/IP networks.  A
producer might send many thousands of small websocket messages,
thinking that the consumer is receiving them because flow control
messages are being received, when in reality those messages are just
being buffered in the receiver and the consumer might be many hundreds
or thousands of messages behind.

Note that without Mux, the backpressure will depend somewhat on the
implementation, but I think many implementations will not begin
reading/parsing the next ws message until the previous has been
processed by the application.  Thus a slow consumer will also
eventually result in TCP/IP back pressure to the producer.   So I'm
wondering if we want Mux connections to mimic this, then the back
pressure measure for mux should be number of messages instead of
number of bytes - or perhaps both?

cheers

---

From: Wenbo Zhu <[email-masked]>
Date: Sun, 31 Jul 2011 17:11:24 -0700

On Sun, Jul 31, 2011 at 4:45 PM, Greg Wilkins <[email-masked]> wrote:

> an application thread blocked reading for the content.

This is a bit of simplification (for Java servlet based servers maybe).
Regardless, TCP based flow-control serves HTTP pretty well because what's
exposed to the application (i.e. RPC) and the underlying transport (i.e. TCP
connection) have a 1:1 mapping. Still, things may start to break when the
application tries to stream data asynchronously over a long-lived
connection. The mux protocol for websocket will likely have to deal with
end-to-end flow-control in a more complicated way. I tend to agree that
message-based flow-control is necessary, given the nature of the messaging
semantics that gets exposed to the application.

 The server
> _______________________________________________
> hybi mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/hybi
>