From: craig@sics.se (Craig Partridge)
Newsgroups: comp.os.research
Subject: taking the AST challenge
Date: 15 Apr 92 18:15:37 GMT
Article-I.D.: darkstar.33001
Organization: Swedish Institute of Computer Science, Kista
Originator: osr@ftp


Replying to Andy Tanenbaum's second challenge, here's my list of the
big five achievements (actually, I only see three).  While I'm at it, I'll
also put down my favorite challenges for the next ten years.

What we've learned/proved in the past decade.

    1. Distributed systems are a good idea.  This achievement may sound
	odd to folks but I remember very vividly that in the early 80's
	that the idea that we needed to integrate the network more closely
	with the rest of a computer's system was very much a research
	question.  There were people who could argue with a straight face
	that a hodgepodge mix of network applications, each with its own
	protocols and interfaces, was all we needed.  I don't hear that
	argument very much any more...

    2. RPC is a great application interface.  Emphasis on *application*.
	Application writers find RPC intuitive -- they are used to changing
	context (albeit within a single address space) when they make a
	procedure call and the RPC notion nicely hides them from stuff
	they'd just as soon not see about the network.  At the same time,
	RPC hints enough about the network (i.e. like any procedure call
	an RPC may take some time to come back) that application writers
	have some notion of an RPC's cost.

	NOTE: I don't think we've come very far in figuring out the *right*
	protocol to run under an RPC system.  There's been some talk about
	how parallelism/asynchrony improves RPC performance.  Yes it does
	but by far less than we need it to.

    3. Multicasting is useful.  Dunno whether you want atomic, causal,
	or just best effort multicast, but clearly we need the ability to
	send to multiple receivers and broadcast is too messy.


Challenges:

    A. Minimizing silly use of the network.  The network is becoming
	a very fat (gigabit bandwidth) pipe which takes a long time
	to get started (latency is getting *very* long, measured in
	millions of instruction cycles).  So the network is rapidly
	become a peripheral which can deliver extraordinary amounts
	of data, but at the price of a long wait for the data to start
	coming.

	This challenge has two sub parts.  

	One is to devise protocols that allow us to make the minimum
	number of trips across the network.  (If I need a file from a
	file server, I shouldn't have to request it block by painful
	block, with one RTT incurred per block read.  In a fat pipe
	I should get the whole file in one RPC -- arguably I should get
	the whole *filesystem* in one RPC just so I never have to visit
	that file server again).

	The second challenge is to reduce the number of ways that
	systems restrict our ability to minimize network transits.
	For example, people typically think of processes as abstractions
	which, at best, are exportable amongst homogeneous machines.
	That's wrong -- if you interpret the code you can ship the
	interpretted representation around pretty easily.  (Witness
	REV, NICL, etc.)  Freeing ourself of the tyranny of machine
	homogeneity allows us to migrate our code more freely.
	Similarly, distributed synchronized clocks means we can compare
	file timestamps on different machines safely without messy
	coordination through a "home" system.

    B. Preparing for new types of data streams like video, voice, etc.
	My personal take on this problem is that it will turn out to
	be an OS problem far more than a network problem.  The network
	will deliver the data at your OS's interface and the OS will
	then be responsible for scheduling that data in a way that
	the application likes and managing all these time sensitive
	devices like the video codecs. Similarly the network is going to
	expect the OS to shape the traffic being put into the network
	a little (emphasis on "little") so the network can manage the
	various streams.

Craig Partridge
craig@bbn.com
Newsgroups: comp.os.research