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

Re[6]: HTTP2 Expression of Interest

From: Adrien W. de Croy <adrien@qbik.com>
Date: Wed, 18 Jul 2012 03:50:07 +0000
To: "Mike Belshe" <mike@belshe.com>
Cc: "Rajeev Bector" <rbector@yahoo-inc.com>, "Martin Thomson" <martin.thomson@gmail.com>, Martin J. Dürst <duerst@it.aoyama.ac.jp>, "Doug Beaver" <doug@fb.com>, "Willy Tarreau" <w@1wt.eu>, "ietf-http-wg@w3.org" <ietf-http-wg@w3.org>
Message-Id: <emf87d2c40-2fc7-4272-873a-fdeee9ea590a@bombed>

------ Original Message ------
From: "Mike Belshe" mike@belshe.com
>On Tue, Jul 17, 2012 at 8:34 PM, Adrien W. de Croy <adrien@qbik.com> wrote:

> we can already transfer many objects over a single connection with 
> HTTP/1.1

> SPDY without SSL would be more speedy than with it.

> There may be only a couple R-Ts to get an SSL handshake, but sprinkle 
> on a CRL / OCSP check and you're left eating dust.

> So, let's just get this straight for the record.  SSL will not 
> improve latency.  It will make it worse, and for many people (on 
> already-high-latency links) a LOT worse.
 Of course, no-SSL is lower latency than SSL.  It's not 3 RTs all the 
 time, but yes, OSCP can add a lot, and SSL implementations vary.  But 
 SPDY gains a lot of this back with fewer connections, multiplexing, 
 and compression.  Don't forget to implement SSL False Start in your 
 client.  Obviously an un-optimized SSL stack will have a harder time 
 than an optimized one.
 But its not true that every bit of latency is more important than 
I'm just not convinced this would be a security win in the end.

How many CAs are there?  We may as well right now deprecate OCSP / CRL 
checks, because you have 200 million sites using a cert from one 
vendor, you take out their OCSP server(s), and you've taken down 200 
million sites.

Way to go amplifying DOS effectiveness.
Becoming a CA is non-trivial.  If we suddenly need a million more of 
them to cope with cert load, how do you anticipate that will improve 
security?  I think it will make for a disaster.

>Note that Google has reported overall latency of SPDY + SSL is faster 
>than HTTP without SSL or SPDY.  
you saying SPDY + SSL faster than SPDY (presumably without SSL)?  
Doesn't seem possible.

I have no problem accepting SPDY + SSL would be faster than HTTP.  But 
we're talking about adding a bunch of things to HTTP that would provide 
the same benefits that SPDY currently enjoys.


> ------ Original Message ------
> From: "Rajeev Bector" <rbector@yahoo-inc.com>
> To: "Adrien W. de Croy" <adrien@qbik.com>;"Martin Thomson" <martin.thomson@gmail.com>;"Martin J. Dürst" <duerst@it.aoyama.ac.jp>
> Cc: "Doug Beaver" <doug@fb.com>;"Willy Tarreau" <w@1wt.eu>;"ietf-http-wg@w3.org" <ietf-http-wg@w3.org>
> Sent: 18/07/2012 3:26:56 p.m.
> Subject: Re: Re[2]: HTTP2 Expression of Interest
> >Arguably, the cost of 3 Rts is amortized over many many objects that 
> >gets transferred over the session. That said, I am trying to imagine 
> >how to do crypto on my Arduino :-).   
> >
> >
> >From: "Adrien W. de Croy" <adrien@qbik.com>
> >Reply-To: "Adrien W. de Croy" <adrien@qbik.com>
> >Date: Tue, 17 Jul 2012 20:20:09 -0700
> >To: Martin Thomson <martin.thomson@gmail.com>, "Martin J. Dürst" <duerst@it.aoyama.ac.jp>
> >Cc: Doug Beaver <doug@fb.com>, Willy Tarreau <w@1wt.eu>, "ietf-http-wg@w3.org" <ietf-http-wg@w3.org>
> >Subject: Re[2]: HTTP2 Expression of Interest
> >
> >
> >------ Original Message ------
> >From: "Martin Thomson" <martin.thomson@gmail.com>
> > On 17 July 2012 19:35, "Martin J. Dürst" <duerst@it.aoyama.ac.jp> wrote:
> > 
> >  
> >  So why are we okay with 10-20% more processing costs for 
> >  everybody, but not
> >  with 10-20% more bandwidth? What's different between processing 
> >  costs and
> >  bandwidth?
> >  
 >  Personally, I thought that the first optimization was for latency,
>  How do you optimise latency by adding 3 RTs in a SSL setup?
>   with bandwidth as secondary and (obviously) consequential.  
>   Trade-offs
>   may have to be made.
Received on Wednesday, 18 July 2012 03:50:31 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 17:14:03 UTC