Re: [TLS] Request for review: Next Protocol Negotiation Extension

[Marsh Ray <[e-mail]>]

On 08/19/2010 10:58 AM, Martin Rex wrote:
> Adam Langley wrote:
>>
>> However, as evidence of how important latency is, witness the amount
>> of work that we are putting into it. (SPDY, Google DNS, Snap Start,
>> False Start, NPN, ...)
>
> On my personal scorecard, management focus doesn't count as evidence
> of much besides Hypes and succesful marketing.

I would go farther than that. I believe there have been cases of large 
companies adding complexity to interfaces in an attempt to put others at 
a relative disadvantage or even to kill an open standard by making it 
unimplementable.

However, I believe the authors of this proposal are sincere in their 
attempt to reduce overall latency by eliminating round trips.

> TLS False Start has always been an obvious potential for optimization.
> I haven't looked at Snap start yet, but I doubt that I would like it
> after figuring out how it works.

It appears to be quite complex and only usable in very specific 
scenarios, probably with API changes requiring extra logic in the 
application code. However, these narrow scenarios could account for 50% 
of TLS handshakes on the web.

As a developer though, it raises the question of if it's keeping with 
the spirit of a general "secure socket layer" communications primitive 
if it requires significantly more complex semantics than the traditional 
socket. Which implies that small-time apps don't compete on an equal 
footing. Especially if, say, Chrome and Android were the only clients 
that implemented it and Google were to arrange for such traffic to 
receive preferential treatment on certain networks.

> To me it seemed that some mount of the
> "apparent latency" is caused by TCP congestion control (TCP slow start
> and delayed TCP ACK) and the original initial TLS roundtrip actually
> improves opening of the transmit window.

There are other benefits to reducing round trips too.

Consider a network with bad statistical packet loss. The probability of 
failure of an overall transaction can increase exponentially with the 
number of packets required to complete it. Sure, TCP is supposed to 
retransmit, but we've all been on that bad wifi where you have to hit 
the reload button a few times before the web page comes up.

- Marsh