Re: [hybi] SPDY protocol from google frame

[Jamie Lokier <[e-mail]>]

Thomson, Martin wrote:
>    I'm also increasingly of the view that channels-based protocols aren't
>    necessarily the right way to solve head-of-line blocking problems.
>    There are other methods that do not demand the same overheads.  For
>    instance, a simple request identifier can be used for request-response
>    correlation.

Fwiw, when I've talked about multiplexing on the HyBi list before,
I've always had in mind request-response correlation identifiers, not
opening long-lived channels.

In general, request-response is a bit limiting: Some applications just
want messages, without responses, because they correlate in other ways
unknown to the transport.  They may not be 1:1, as with pubsub
architectures for example.  So let's say request-response is good, but
it's better if the response is optional because redundant responses
are overhead.

I've advocated that multiplexing protocols should handle small and
large message sizes equally well, for the same reason as HTTP:
Separation of concerns, and robust good performance over a range of uses.

To send *large* messages without head-of-line blocking, you need a way
to split them (to allow others to go through), and a message identifier
to correlate the fragments.

One bit of baggage associated with channels is that they need to be
"setup" before using them.  BEEP does this, and it is way too high
overhead (latency).  It should not require a round trip before using
new channels: just start using them, allocated by the sender!  There
are receiver overflow issues, but that is best handled by flow control.

When you can use new channels immediately, that's technically *the
same thing* as request or message identifiers with ability to split
messages.  The difference is just terminology.

It's been argued that a basic transport protocol doesn't need to split
large messages, because applications (or shared middle layers) can do
it themselves, over a basic transport optimised for short messages
only.  The argument is if it can be done at a higher level, keep the
transport simple.

That probably is good protocol design, to keep the problems separate.

However, for *implementation* there are technical arguments in favour
of doing splitting and multiplexing together close to transport
framing: Network performance, latency, fairness among message sources,
and flow control to different sinks, are likely to perform better with
knowledge fed back from the transport.  Things like aligning with TCP
MSS boundaries to reduce average message latency.

(Perhaps some of the debates/conflict over this are due to it being
good to specify them as separate protocol layers, but good to
implement them in a slightly more unified way.)

I hope I've been able to explain why "channels" means different things
and can be a *low overhead, performance enhancing* concept which arise
naturally from robust, multiplexed message transport.

-- Jamie