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

>> 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 mailing list
Ietf@ietf.org
https://www1.ietf.org/mailman/listinfo/ietf