Re: Is round-trip time no longer a concern? (was: Re: Last Call: 'TLS User ...)

"Steven M. Bellovin" <smb@cs.columbia.edu> Sun, 19 February 2006 23:48 UTC

Received: from [127.0.0.1] (helo=stiedprmman1-ext.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FAyIA-0005Zt-O4; Sun, 19 Feb 2006 18:48:38 -0500
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FAyI9-0005Zd-KA; Sun, 19 Feb 2006 18:48:37 -0500
Received: from machshav.com ([147.28.0.16]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FAyI8-0001QS-7B; Sun, 19 Feb 2006 18:48:37 -0500
Received: from berkshire.machshav.com (localhost [127.0.0.1]) by machshav.com (Postfix) with ESMTP id 3C17CFB28F; Sun, 19 Feb 2006 18:48:35 -0500 (EST)
Received: from cs.columbia.edu (localhost [127.0.0.1]) by berkshire.machshav.com (Postfix) with ESMTP id EEB323C0292; Sun, 19 Feb 2006 18:48:32 -0500 (EST)
X-Mailer: exmh version 2.6.3 04/04/2003 with nmh-1.0.4
From: "Steven M. Bellovin" <smb@cs.columbia.edu>
To: dcrocker@bbiw.net
In-Reply-To: (Your message of "Sun, 19 Feb 2006 15:23:59 PST.") <43F8FE0F.3060309@dcrocker.net>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Date: Sun, 19 Feb 2006 18:48:32 -0500
Message-Id: <20060219234832.EEB323C0292@berkshire.machshav.com>
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 538aad3a3c4f01d8b6a6477ca4248793
Cc: ietf@ietf.org, iesg@ietf.org
Subject: Re: Is round-trip time no longer a concern? (was: Re: Last Call: 'TLS User ...)
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

In message <43F8FE0F.3060309@dcrocker.net>, Dave Crocker writes:
>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.  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
> > a sensitive page.
>
>
>This raised a flag with me.  Within the Internet protocol context I have alway
>s 
>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 f
>or 
>this issue.)
>
>For all of the massive improvements in the Internet's infrastructure, my 
>impression is that round-trip delays can still be problematic.
>
>To this end, the high chatter rate of http seems less a basis for encouraging 
>other protocols to  chatter more, than a case of remarkable good luck... unles
>s 
>you happen to be on a path that has high latencies frequently, or experience t
>oo 
>many of these extra handshakes.
>
>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 lot depends on the expected operational environment.  All the massive 
improvements in Internet infrastructure haven't done much for the speed 
of light.

For protocols whose *usual* -- not exclusive -- operational environment 
is on a LAN or within an campus, round trips don't matter that much.  
For things that might be cross-US or intercontinental, things *can't* 
get too much better.

		--Steven M. Bellovin, http://www.cs.columbia.edu/~smb



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