W3C home > Mailing lists > Public > ietf-http-wg@w3.org > April to June 2012

Re: SPDY Review

From: Mike Belshe <mike@belshe.com>
Date: Sat, 9 Jun 2012 10:03:32 -0700
Message-ID: <CABaLYCtMbCcFMDzJxcHQs49f5iAtL7=hR-b51tvXx=nW=HBNFQ@mail.gmail.com>
To: Martin Nilsson <nilsson@opera.com>
Cc: Roberto Peon <grmocg@gmail.com>, ietf-http-wg@w3.org
On Fri, Jun 8, 2012 at 9:29 AM, Martin Nilsson <nilsson@opera.com> wrote:

> On Thu, 07 Jun 2012 21:57:38 +0200, Roberto Peon <grmocg@gmail.com> wrote:
>
>
>> Can you tell us more about your or Opera's operational experience with
>> equivalent features?
>> I'd be rapt at any such presentation!
>>
>>
> We have Opera Mini that uses several different protocols, both similar to
> HTTP as well as of the persistent TCP connection type. These are all binary
> protocols using different versions of request-response, RPC, push features,
> as well as compression of different sorts. We have Opera Turbo, which is
> essentially a modified HTTP with prioritized, out-of-order pipelining and
> some simple compression. Finally we have integrations with different 3rd
> party technologies, some of which are mentioned on the press release pages
> http://www.opera.com/press/**releases/2004/11/04/<http://www.opera.com/press/releases/2004/11/04/>
> http://www.opera.com/press/**releases/2007/02/06/<http://www.opera.com/press/releases/2007/02/06/>
>
> Not really an answer to your question though, I'm afraid. I would need
> more time (and meetings) to collect that...


I'd be interested to hear if Opera would ever open-source these protocols
and any reasons for why or why not that Opera would be willing to disclose.



>
>
>
>> I agree totally that better approaches on the compression side likely
>> exist.
>> I'm surprised at the numbers, though. Our experience in the past was that
>> headers were significantly more compressed than you're seeing here.
>>
>>
> I'm using the same data as the http://www.eecis.udel.edu/~**
> amer/PEL/poc/pdf/SPDY-Fan.pdf<http://www.eecis.udel.edu/~amer/PEL/poc/pdf/SPDY-Fan.pdf>and when using the evaluation set they use I actually get somewhat better
> compression values (probably due to better header normalization).


I feel like we're getting caught up in noise here; looking at single block
compression is uninteresting.  In real world cases, with repeated cookie
blocks, the algorithm does great, at over 85% compression.  We can do
incrementally better and I'm not opposed to that.  But the use of the
dictionary or not is trivial and doesn't matter in the overall picture.

Is there something else you wanted to propose?

Mike


>
>
> /Martin Nilsson
>
> --
> Using Opera's revolutionary email client: http://www.opera.com/mail/
>
>
Received on Saturday, 9 June 2012 17:04:53 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Saturday, 9 June 2012 17:05:12 GMT