Re: Is round-trip time no longer a concern?

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 





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

[Index of Archives]     [IETF Annoucements]     [IETF]     [IP Storage]     [Yosemite News]     [Linux SCTP]     [Linux Newbies]     [Fedora Users]