Re: Is round-trip time no longer a concern?

> Well, I'm not claiming that latency isn't a factor in protocol
> performance. What I'm claiming is that it's not clear that latency
> in the initial connection setup handshake (in this case the TLS
> one) is a major factor in protocol performance. Recall that the
> way that TLS works is that you do an initial handshake to establish
> the keys and then you send data of the negotiated channel. What
> we're discussing is whether it's OK for this to take a few extra
> round-trips at the setup of the first connection (and not necessarily
> afterwards because of TLS session caching). So, we're not talking
> about adding messages to every activity of the higher level protocol.

True, but this presumes a lot about how TLS is used.  For instance, if 
you're using it with HTTP to load a web page that downloads not only a 
root HTML file but lots of other files for frames, images, applets, 
etc., then you're going to incur that connection setup overhead for 
every one of those objects.  And because (partially for this reason) 
with HTTP it's fairly normal for a browser to open multiple connections 
to a server site, all of those delays won't be serialized, but they'll 
still impact the total time to download the page.

Now maybe this specific example illustrates a flaw in the design of HTTP 
and/or HTML, but the extra setup overhead of TLS (and this new 
extension) does impact its versatility.

Also I chose HTTP/HTML because most people are familiar with it.  There 
are other, more obscure, applications involving lots of hosts that need 
to open up secure and sometimes brief connections with one another.

So while the extra setup delays of TLS might not matter much in some 
applications, they definitely matter in others.

Keith

_______________________________________________
Ietf mailing list
Ietf@ietf.org
https://www1.ietf.org/mailman/listinfo/ietf