In message <43F9EE52.7020007@xxxxxxxxxxxx>, Dave Crocker writes: >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. Dave, I tried to phrase my comment carefully. I wrote: For protocols whose *usual* -- not exclusive -- operational environment because I'm very well aware that there is no hard and fast boundary. Indeed, I occasionally refer to what I call "Bellovin's Laws of Networking": 1. Networks interconnect 2. Networks *always* interconnect, even if you don't think they will 3. Networks interconnect at the edges, not the center That said, there are protocols whose usual patterns are in one camp or the other, sometimes for fundamental reasons. X11 and NFS will always be better-used locally, because the people and applications are expecting low-latency responses. HTTP is generally a WAN protocol, because statistically most of the Web isn't at your site. It's acceptable, to me, to make an *engineering tradeoff* about how a protocol design is balanced, if there's a natural operational environment. What's not acceptable is to design it so that it *only* runs in one environment or the other. It's also worth noting that the counterexamples you cite are transport protocols. When something tends to live underneath many disparate protocols, you're less free to make such choices, because you don't know what the upper layers will be. This obviously applies to TCP; less obviously, it applies to TLS and (unfortunately) HTTP. _______________________________________________ Ietf@xxxxxxxx https://www1.ietf.org/mailman/listinfo/ietf