Well, for those of us looking at Lemonade, etc, I think we're still
very concerned about every round-trip.
>
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.
Eric,
I did understand you meant start-up chatter, rather than data chatter.
But latency is latency. There are situations in which an isolated bad latency
effect is tolerable to a session, and others where it is not. When that chatter
is repeated for every session of a popular protocol, it usually raises a flag
about design choice. As your response notes, it might well have a small
statistical impact on the total session, but that does not automatically make it
acceptable.
By way of historical contrast, the addition of an options mechanism to SMTP was
very, very carefully designed to add no extra round-trips, due to the email
infrastructure experiences with this issue as a problem. And my note
acknowledged the obvious alternate view that http represents, since it just
chatters away, especially at startup.
That's why I raised the question.
I note a pattern of responses to my question; it show that there still IS a
concern. More interesting is that the concern applies to a variety of scenarios.
While the IETF list is not the right venue for considering this protocol design
point to its conclusion, I was looking for an indication of whether my concern
was out-dated or whether there was an inconsistent view within the protocol
design community.
Based on the brief set of responses, so far, my sense is that the latter holds.
Since this is a potentially fundamental protocol design point, it would be
good to develop some community consensus about it.
I'll add one specific comment, reacting to Steve Bellovin's noting LAN vs. WAN
"operational environment" distinction. It has been my experience and my
understanding that the IETF does not design upper-level (transport and above)
protocols to be sensitive to that LAN vs. WAN distinction.
As I understand it, when TCP/IP was first put over Ethernet, this was a point of
very significant debate. There was a strong lobby for optimizing things for the
faster, lower-latency Ethernet environment.
My own assessment of the decision to avoid the temptation to have protocols be
"tuned" in that way is that it was a spectacularly good decision. First, it
makes the protocol world vastly simpler. Second, it makes the operational world
vastly simpler.
Folks can study the OSI TP0, TP1, TP2, TP3, TP4 alternative approach, by way of
seeing the way things could have been. None of those transports interoperated
with each other.
d/
--
Dave Crocker
Brandenburg InternetWorking
<http://bbiw.net>
_______________________________________________
Ietf@xxxxxxxx
https://www1.ietf.org/mailman/listinfo/ietf