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

Eric Rescorla <ekr@networkresonance.com> Mon, 20 February 2006 16:43 UTC

Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FBE8H-0003Wn-PJ; Mon, 20 Feb 2006 11:43:29 -0500
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FBE8G-0003WO-8N; Mon, 20 Feb 2006 11:43:28 -0500
Received: from raman.networkresonance.com ([198.144.196.3]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FBE8F-0004u1-U2; Mon, 20 Feb 2006 11:43:28 -0500
Received: by raman.networkresonance.com (Postfix, from userid 1001) id 258B11E8C4C; Mon, 20 Feb 2006 08:43:27 -0800 (PST)
To: Keith Moore <moore@cs.utk.edu>
References: <20060219013238.779CC22241D@laser.networkresonance.com> <43F8FE0F.3060309@dcrocker.net> <24385.1140426803.565678@peirce.dave.cridland.net> <868xs6kqno.fsf@raman.networkresonance.com> <43F9E90E.9070802@cs.utk.edu>
From: Eric Rescorla <ekr@networkresonance.com>
Date: Mon, 20 Feb 2006 08:43:27 -0800
In-Reply-To: <43F9E90E.9070802@cs.utk.edu> (Keith Moore's message of "Mon, 20 Feb 2006 11:06:38 -0500")
Message-ID: <864q2ukmkw.fsf@raman.networkresonance.com>
User-Agent: Gnus/5.1007 (Gnus v5.10.7) XEmacs/21.4.18 (berkeley-unix)
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 21c69d3cfc2dd19218717dbe1d974352
Cc: iesg@ietf.org, Dave Crocker <dcrocker@bbiw.net>, IETF-Discussion <ietf@ietf.org>
Subject: Re: Is round-trip time no longer a concern?
X-BeenThere: ietf@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
Reply-To: EKR <ekr@networkresonance.com>
List-Id: IETF-Discussion <ietf.ietf.org>
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/ietf>, <mailto:ietf-request@ietf.org?subject=unsubscribe>
List-Post: <mailto:ietf@ietf.org>
List-Help: <mailto:ietf-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/ietf>, <mailto:ietf-request@ietf.org?subject=subscribe>
Errors-To: ietf-bounces@ietf.org

Keith Moore <moore@cs.utk.edu> writes:

>> 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.

TLS incorporates a "session resumption" feature that is specifically
designed to let you avoid a new handshake for each connection you
make (that's what the "not necessarily afterwards" above meant.)
So, the full TLS cost is only paid for the first connection to
a given server. 

-Ekr




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