[e2e] Jon Crowcroft's thought questions...

[Dave Crocker]

Lloyd,

>>  Network-based protocols that operate well in resource-constrained
>>  environments will usually do pretty well in resource-rich ones.

LW> ...and this is why WAP, morse code and Gopher have been amazing
LW> successes on the wired Internet.

I thought this was a technical forum, rather than a political,
social, or business one. So perhaps I've missed the nature of your
posting.

Gopher worked quite well in modest environments, including across the
global Internet.  Working well as a protocol does not guarantee
long-term usage, any more than technical superiority assures any other
success in the real world.

Morse Code is a... code... not a protocol. On the other hand, it is
pretty good for poor communications environments, as has been nicely
demonstrated for rather a long time. For that matter, Telex is still in
serious use, because it works.

But somehow I can't see how any of this is relevant to the technical
point I was making about the use of chatty and inefficient protocols in
resource-constrained environments.


LW> Could we please have some actual examples of adoption into rich
LW> environments that don't involve citing Moore's law and waiting for
LW> the environment to scale up?

TCP.  Designed for resource constrained WAN environments; adapted into
low-latency/high-speed LANs nicely (albeit after considerable debate
over whether to "tune" it for LANs.

By contrast, the 80s saw any number of protocols designed for LANs
typically do very poorly over high-latency, lossy WANs, nevermind the
lovely satellite channels you have worked around.


>>  The fact that most net developers work in environments with very high
>>  bandwidth and very low delay means that we have essentially raised a
>>  generation of techies who are entirely insensitive to vast portions of
>>  the operational world.

LW> that used to explain the defaults in the Solaris TCP stack.

and, for example, the fact that SunOS UDP check-sums used to be turned
off by default was pretty much ok for old-time Sun workstation use on
LANs. NFS didn't mind all that much.

When NFS was used more over long-haul, Internet links, the data
corruption folly of that default became clear. Luckily, this was a
problem that only required a configuration change to remedy. Protocols
designed with short, fixed timers are not so lucky.


d/
--
 Dave Crocker <mailto:dcrocker at brandenburg.com>
 Brandenburg InternetWorking <http://www.brandenburg.com>
 Sunnyvale, CA  USA <tel:+1.408.246.8253>, <fax:+1.866.358.5301>