Re: multiplexing -- don't do it

Might as well list all my complaints about SPDY in one spot:

   1. Inter-object dependency due to using a history based compression
   scheme where you need to receive every object in order it was sent to
   decode the last header. This guarantees HOL blocking even if the transport
   supports out of order messages.
   2. SPDY needs to allow headers to be readable by intermediaries. I don't
   mind the mostly binary approach proposed in Willy's document as parsers can
   be developed for wireshark and similar tools.
   3. HTTPS required -- to me that's a showstopper. Have to do this in two
   steps: deploy muxing, which removes the main performance penalty of HTTPS,
   and then go for security.

Other than those, I think it's great.

Peter

On Wed, Apr 4, 2012 at 4:58 PM, Peter Lepeska <bizzbyster@gmail.com> wrote:

> As long as SPDY is sent over TCP, it also suffers from HOL problems, just
> not as bad as pipelining.
>
> I think SPDY (or whatever the HTTP 2.0 muxing protocol is) should framed
> in such a way that if running over a protocol like SCTP, that solves the
> HOL problems, we should be able to take advantage of it. Due to gzip
> compression of headers, even if the transport allowed me to grab messages
> out of order, I'd still have to wait for all packets prior in order to
> decode the HTTP headers.
>
> Peter
>
>
> On Wed, Apr 4, 2012 at 9:07 AM, Patrick McManus <pmcmanus@mozilla.com>wrote:
>
>> On Wed, 2012-04-04 at 07:02 +0000, Poul-Henning Kamp wrote:
>> > In message <20120404054903.GA13883@1wt.eu>, Willy Tarreau writes:
>> >
>> > >> I'm starting to get data back, but not in a state that I'd reliably
>> > >> release. That said, there are very clear indicators of intermediaries
>> > >> causing problems, especially when the pipeline depth exceeds 3
>> requests.
>> >
>> > I always thought that the problem in HTTP/1.x is that you can never
>> > quite be sure if there is an un-warranted entity comming after at GET,
>>
>> its not uncommon to have the consumer RST the whole TCP session when
>> asked to recv too far beyond the current request it is processing. For
>> some devices "too far" appears to be defined as "any new packet". I
>> presume some variation of this is where Will's data point comes from.
>> (Often 3 uncompressed requests fit in 1 packet).
>>
>> That class of bug sounds absurd, but its really a pretty common pattern.
>> As an example: hosts that fail TLS False Start (for which I understand
>> second hand that Chrome needs to keep a black-list), react badly because
>> there is TCP data queued when they are in a state that the expect their
>> peer to be quiet. Same pattern.
>>
>> The lesson to me is that you want to define a tight set of functionality
>> that is reasonably testable up front - and that's what you can depend
>> widely on later. Using anything beyond that demands excessive levels of
>> pain, complexity, and cleverness.
>>
>> (and all this pipelining talk as if it were equivalent to spdy mux is
>> kind of silly. Pipelining's intrinsic HOL problems are at least as bad
>> of an issue as the interop bugs.)
>>
>> -Patrick
>>
>>
>>
>