Re: Is round-trip time no longer a concern?
Peter Dambier <peter@peter-dambier.de> Mon, 20 February 2006 11:28 UTC
Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FB9Dr-0002T0-Vc; Mon, 20 Feb 2006 06:28:55 -0500
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FB9Dp-0002Sn-P3 for ietf@ietf.org; Mon, 20 Feb 2006 06:28:53 -0500
Received: from mail.gmx.de ([213.165.64.20] helo=mail.gmx.net) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1FB9Dm-0003S7-0C for ietf@ietf.org; Mon, 20 Feb 2006 06:28:53 -0500
Received: (qmail invoked by alias); 20 Feb 2006 11:28:47 -0000
Received: from p54A7E923.dip.t-dialin.net (EHLO peter-dambier.de) [84.167.233.35] by mail.gmx.net (mp001) with SMTP; 20 Feb 2006 12:28:47 +0100
X-Authenticated: #8956597
Message-ID: <43F9A7E0.9040500@peter-dambier.de>
Date: Mon, 20 Feb 2006 12:28:32 +0100
From: Peter Dambier <peter@peter-dambier.de>
Organization: Peter and Karin Dambier
User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.4.2) Gecko/20040921
X-Accept-Language: en-us, en
MIME-Version: 1.0
To: iesg@ietf.org, IETF-Discussion <ietf@ietf.org>
References: <20060219013238.779CC22241D@laser.networkresonance.com> <43F8FE0F.3060309@dcrocker.net> <24385.1140426803.565678@peirce.dave.cridland.net>
In-Reply-To: <24385.1140426803.565678@peirce.dave.cridland.net>
X-Enigmail-Version: 0.76.8.0
X-Enigmail-Supports: pgp-inline, pgp-mime
Content-Type: text/plain; charset="us-ascii"; format="flowed"
Content-Transfer-Encoding: 7bit
X-Y-GMX-Trusted: 0
X-Spam-Score: 0.1 (/)
X-Scan-Signature: a87a9cdae4ac5d3fbeee75cd0026d632
Cc:
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: peter@peter-dambier.de
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
Dave Cridland wrote: > On Sun Feb 19 23:23:59 2006, Dave Crocker wrote: > >> Folks, >> >> Eric said: >> > 1. It is slower because it requires two handshakes. >> > 2. The client may have to authenticate twice (this is a special >> > case of (1)). >> > >> > The second case can be easily ameliorated by having the client send an >> > extension (empty UME?) in the first handshake as a signal that it wants >> > to do UMDL and that the server should hold off on demanding client >> > authentication until the rehandshake happens. >> > >> > The performance issue is quite modest with modern servers. as long as you are living in the same rack with them. If you are connected via UMTS it is a different thing. >> > Indeed, it's >> > quite common for web servers to do a first handshake without cert-based >> > client auth and then rehandshake with client auth if the client asks >> > for sensitive page. Indeed there are some webservers around that take so long until my browser times out. >> >> This raised a flag with me. Within the Internet protocol context I >> have always seen significant concern for reducing the number of >> exchanges, because additional exchanges (hand-shakes) can -- and often >> do -- have painful round-trip latencies. (Server capacity can be a >> concern, of course, but not for this issue.) >> >> > Well, for those of us looking at Lemonade, etc, I think we're still very > concerned about every round-trip. Server capacity, too, is a very real > problem, and, while I admit to not having looked at this specification > yet, given what I've read thus far, I'm assuming this has some > applicability to email protocols as well as HTTP, which would affect > Lemonade. > > >> For all of the massive improvements in the Internet's infrastructure, >> my impression is that round-trip delays can still be problematic. > > > Yes, I believe it has something to do with the difficulty of changing > the speed of light. Probably requires standards action on a bunch of > normative references, or there's a global upgrade problem. > > >> Is it true that we no longer need to worry about regularly adding >> extra round-trips to popular protocols that operate over the open >> Internet? > A typical traceroute for me and many, many, many customers of major german ISPs 1 echnaton.peter-dambier.de (192.168.48.228) 4.594 ms 5.464 ms 6.267 ms 2 DARX41-erx (217.0.116.49) 96.478 ms 101.004 ms 111.541 ms 3 sepia (217.0.67.102) 115.774 ms 123.485 ms 131.139 ms 4 62.154.15.2 147.919 ms 155.120 ms 162.845 ms 5 gb-10-0-0.saams.nl.easynet.net (195.69.144.137) 171.365 ms 178.635 ms 187.107 ms 6 213.201.252.10 267.804 ms 270.174 ms 272.507 ms 7 Scylla (213.201.229.65) 269.246 ms 272.058 ms 274.653 ms 8 Charybdis (84.22.96.250) 98.668 ms 107.666 ms 111.906 ms 9 Bifroest (84.22.96.246) 124.170 ms 128.057 ms 138.825 ms 10 tourelle (84.22.100.150) 148.487 ms 158.490 ms 163.288 ms Except for (192.168.48.228) 4.594 ms (my old 486-SLC/2 router, 66 MHz) all are fast modern machines. That DARX41-erx (217.0.116.49) 96.478 ms is a top model. So 300 msec forward + 300 msec backward will become 1.2 seconds. Vaja con dios VoIP. > > No. > > As far as I'm aware, there is no protocol in existence which somebody, > somewhere, does not actively use over a mobile phone link, or a slow > analogue modem, and this is especially true of TLS enabled protocols > such as HTTP, email protocols, etc. > > Dave. Peter -- Peter and Karin Dambier The Public-Root Consortium Graeffstrasse 14 D-64646 Heppenheim +49(6252)671-788 (Telekom) +49(179)108-3978 (O2 Genion) +49(6252)750-308 (VoIP: sipgate.de) mail: peter@peter-dambier.de mail: peter@echnaton.serveftp.com http://iason.site.voila.fr/ https://sourceforge.net/projects/iason/ _______________________________________________ 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