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@xxxxxxxx https://www1.ietf.org/mailman/listinfo/ietf