Re: Is round-trip time no longer a concern?
Keith Moore <moore@cs.utk.edu> Mon, 20 February 2006 16:06 UTC
Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FBDYr-00082c-G1; Mon, 20 Feb 2006 11:06:53 -0500
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FBDYq-00082J-Gi; Mon, 20 Feb 2006 11:06:52 -0500
Received: from ka.cs.utk.edu ([160.36.56.221]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FBDYq-0003DK-8p; Mon, 20 Feb 2006 11:06:52 -0500
Received: from localhost (ka [127.0.0.1]) by ka.cs.utk.edu (Postfix) with ESMTP id 3D85123559; Mon, 20 Feb 2006 11:06:48 -0500 (EST)
Received: from ka.cs.utk.edu ([127.0.0.1]) by localhost (ka [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 21411-06; Mon, 20 Feb 2006 11:06:45 -0500 (EST)
Received: from [192.168.0.4] (user-119b1dm.biz.mindspring.com [66.149.133.182]) by ka.cs.utk.edu (Postfix) with ESMTP id 40A6B23569; Mon, 20 Feb 2006 11:06:42 -0500 (EST)
Message-ID: <43F9E90E.9070802@cs.utk.edu>
Date: Mon, 20 Feb 2006 11:06:38 -0500
From: Keith Moore <moore@cs.utk.edu>
User-Agent: Thunderbird 1.5 (Macintosh/20051201)
MIME-Version: 1.0
To: EKR <ekr@networkresonance.com>
References: <20060219013238.779CC22241D@laser.networkresonance.com> <43F8FE0F.3060309@dcrocker.net> <24385.1140426803.565678@peirce.dave.cridland.net> <868xs6kqno.fsf@raman.networkresonance.com>
In-Reply-To: <868xs6kqno.fsf@raman.networkresonance.com>
Content-Type: text/plain; charset="ISO-8859-1"; format="flowed"
Content-Transfer-Encoding: 7bit
X-Virus-Scanned: by amavisd-new with ClamAV and SpamAssasin at cs.utk.edu
X-Spam-Score: 0.0 (/)
X-Scan-Signature: b19722fc8d3865b147c75ae2495625f2
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
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
> 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
- Re: Last Call: 'TLS User Mapping Extension' to Pr… Eric Rescorla
- Re: Last Call: 'TLS User Mapping Extension' to Pr… Steven M. Bellovin
- Re: Last Call: 'TLS User Mapping Extension' to Pr… Bill Fenner
- Re: Last Call: 'TLS User Mapping Extension' to Pr… Russ Housley
- Re: Last Call: 'TLS User Mapping Extension' to Pr… Russ Housley
- Is round-trip time no longer a concern? (was: Re:… Dave Crocker
- Re: Is round-trip time no longer a concern? Russ Allbery
- Re: Is round-trip time no longer a concern? (was:… Steven M. Bellovin
- Re: Last Call: 'TLS User Mapping Extension' to Pr… Bill Strahm
- Re: Is round-trip time no longer a concern? (was:… Dave Cridland
- Re: Is round-trip time no longer a concern? Harald Tveit Alvestrand
- Re: Is round-trip time no longer a concern? Peter Dambier
- RE: Last Call: 'TLS User Mapping Extension' to Pr… Pasi.Eronen
- Re: Is round-trip time no longer a concern? Eric Rescorla
- Re: Is round-trip time no longer a concern? Keith Moore
- Re: Is round-trip time no longer a concern? Dave Cridland
- Re: Is round-trip time no longer a concern? Dave Crocker
- Re: Is round-trip time no longer a concern? Eric Rescorla
- Re: Is round-trip time no longer a concern? Tony Finch
- Re: Is round-trip time no longer a concern? Steven M. Bellovin
- Re: Is round-trip time no longer a concern? Dave Crocker
- RE: Last Call: 'TLS User Mapping Extension' to Pr… Gray, Eric
- RE: [TLS] Re: Last Call: 'TLS User Mapping Extens… Pasi.Eronen
- Re: Last Call: 'TLS User Mapping Extension' to Pr… Bernard Aboba
- RE: Last Call: 'TLS User Mapping Extension' to Pr… Russ Housley
- RE: [TLS] Re: Last Call: 'TLS User Mapping Extens… Russ Housley
- RE: [TLS] Re: Last Call: 'TLS User Mapping Extens… Stefan Santesson
- RE: Last Call: 'TLS User Mapping Extension' to Pr… Stefan Santesson
- RE: Last Call: 'TLS User Mapping Extension' to Pr… Stefan Santesson
- RE: Re: [TLS] Re: Last Call: 'TLS User Mapping Ex… Stefan Santesson
- RE: Re: [TLS] Re: Last Call: 'TLS User Mapping Ex… Stefan Santesson
- RE: Re: [TLS] Re: Last Call: 'TLS User Mapping Ex… Russ Housley
- Re: Last Call: 'TLS User Mapping Extension' to Pr… Simon Josefsson
- Re: Last Call: 'TLS User Mapping Extension' to Pr… Jeffrey Hutzelman
- RE: [TLS] Re: Last Call: 'TLS User Mapping Extens… Ari Medvinsky