In message <[EMAIL PROTECTED]>, 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
[email protected]
https://www1.ietf.org/mailman/listinfo/ietf
