Re: multiplexing -- don't do it

On Sat, Mar 31, 2012 at 1:19 AM, Adrien W. de Croy <adrien@qbik.com> wrote:

>
> ------ Original Message ------
> From: "Alexey Melnikov" <alexey.melnikov@isode.com>
> To: "Adrien W. de Croy" <adrien@qbik.com>
> Cc: "Roberto Peon" <grmocg@gmail.com>;"ietf-http-wg@w3.org" <
> ietf-http-wg@w3.org>
> Sent: 31/03/2012 12:12:18 p.m.
> Subject: Re: multiplexing -- don't do it
>
> On 31/03/2012 00:52, Adrien W. de Croy wrote:
>
>
> ------ Original Message ------
> From: "Roberto Peon" <grmocg@gmail.com>grmocg@gmail.com
>
>     ·         SPDY compresses HTTP headers using an LZ history based
>>> algorithm, which means that previous bytes are used to compress subsequent
>>> bytes. So any packet capture that does not include all the traffic sent
>>> over that connection will be completely opaque -- no mathematical way to
>>> decode the HTTP. Even with all the traffic, a stream decoder will be a
>>> tricky thing to build b/c packets depend on each other.
>>>
>>
>> I know there's a SPDY decoder plugin for Wireshark, but I'll defer to
>> people more
>>
>  knowledgeable about packet analysis tools to cover that area.
>>
>
> The OP is right about this, btw. Technically it is possible that you've
> flushed the window after 2k of completely new data, but there is no
> guarantee and so interpreting a stream in the  middle may be extremely
> difficult.
>
> Seems like a fine tradeoff for the latency savings that we get on low-BW
> links, though.
>
>
> I think it basically means compression or any transport level transform
> needs to be able to be switched off when debugging.  Which means
> optional/negotiated.
>
> I think it should be mandatory to implement (so no discovery of the
> feature is needed), but optional to use.
>
> for something like TLS or gzip I've absolutely no problem with that.
>

Before thinking this way we should look at how well other mandatory but
optional to use features have turned out.

One such example is pipelining.  Mandatory for a decade, but optional to
implement. We still can't turn it on.

Another is chunked uploads.  Hugely valuable for data uploads from the
client, mandatory to implement, but completely broken and unusable by
browsers because of it.

Options simply don't work - we need to make this stuff mandatory from the
get-go or it  is very likely to have the same result that we've seen in the
past.

Finally, debugging is the wrong reason to make things optional at the
protocol level. If you are in a position to turn of f the flags, turn them
off via cmdline tricks or what not.  It's fine.  If you're running a
production trace, and we want the feature on (presumably the option to turn
off was not used, right?), you're still going to need real debugging tools.
 The right answer here is to invest in the tools - not to neuter the
protocol features.

BTW - check out chromes about:net-internals.  It's not perfect, but it
takes care of all this for you so that you can see the spdy frames fully
decoded.  It's not a panacea of tools - but this stuff is very
implementable.

Mike



>
>
>
>  I have to analyse packet dumps of HTTP most days, as I'm sure do many
> others on this list.  We haven't yet evolved as a species to the stage
> where we don't make mistakes.
>
> I think it's a vitally important facility for discovering implementation
> errors, which is required in many cases to resolve issues.
>
> Adrien
>
>
>
>
>
>