Re: [hybi] Framing and design philosophy

On Fri, Jul 30, 2010 at 4:23 PM, Patrick McManus <mcmanus@ducksong.com>wrote:

>
> Related to the syntax of framing and chunking, I also urge the group to
> tackle multiplexing in the first round of the draft. Connection
> management has long been a thorn in the side of HTTP - leading to
> arbitrary numbers of parallel connections and their assorted problems
> interacting poorly with buffering and TCP congestion control.
>
Or, without multiplexing, I'd argue that the plain-old HTTP would be
sufficient in itself - to be used as a transport protocol for the WebSocket
API.
We had use cases that involve 1) streaming-only transport; and 2) API
clients. Based on initial discussions over httpbis, full-duplex HTTP seems
to be a viable option:
http://lists.w3.org/Archives/Public/ietf-http-wg/2010AprJun/0111.html ,
http://tools.ietf.org/html/draft-zhu-http-fullduplex-01  ...

Not saying that we don't need a new protocol ... but its incompatibility
with HTTP, as cost, needs be justified.

- Wenbo

>
> Multiplexing multiple websocket messages simultaneously over a single
> TCP channel (using chunks as necessary) allows them to share a single
> TCP congestion control block as well as a single TCP handshake. Both of
> those things will be significant wins in terms of reliable efficient
> performance.
>
> There is a downside in terms of fate sharing across messages during loss
> recovery events, but frankly a single busy TCP session makes loss
> recovery much more efficient than if the same data is spread of
> unrelated TCP flows. More importantly the number of client induced
> losses due to inaccurate aggregate cwnd's across the large number of
> parallel connections is reduced. That's probably the most important
> thing.
>
> Not tackling it now basically makes repeating the mistakes of http
> forseeable, and I would not support the IETF endorsing such a
> specification.
>
>
>
> _______________________________________________
> hybi mailing list
> hybi@ietf.org
> https://www.ietf.org/mailman/listinfo/hybi
>