[e2e] where end-to-end ends

[Micah Beck]

The work of Cerf et al on Interplanetary Internet recognizes that the delays
inherent in transmissions across vast distances makes end-to-end signaling
impractical.  Techniques such as forward error correction are used instead
to allow communication between sender and receiver to be asyncrhonous.  In
the interplanetary case, asychrony is unavoidable, but there is a case to be
made for asyncrhony in the terrestrial network.

I co-lead a project called the Internet Backplane Protocol (IBP).  The
objective of this project is to build network infrastructure that allows
end-to-end communication to be terminated in order to introduce asynchrony
between sender and reciever(s).  The sender can choose a location at which
to terminate end-to-end communication, and the data is buffered at that
location.  The server that does the buffering is called a IBP depot.  Data
can be moved between depots, and can be delivered to the ultimate receiver
using IBP.  However, while end-to-end communication is terminated at the
depot, control over the data need not be ceded to any intermediary - the
depots are passive elements that are under the control of the end-points.
We call this use of explicit buffer management Logistical Networking, where
our depots are thought of as being analogous to warehouses in the delivery
of physical materiel.

An argument could be made that IBP implements overall end-to-end
communication because control can be maintained at the end-points.  On the
other hand, end-to-end signalling terminates at the end-points of each
particular segment.  It is also possible to use IBP to implement systems in
which buffering is controlled by "middle-points" that are neither sender nor
reciever.  The purpose of Logistical Networking is to implement
buffering/storage functionality in a shared networking mechanism that today
is aviailable only in application-specific forms (active daemons and
middleboxes).  It is possible to implement many different Logistical
Networking strategies from caching to asynchronous multicast using IBP as a
distributed state management mechanism.  Some of these generic strategies
can be usefully implemented as a layer between IBP and the specific
application.

Defining a common abstraction of storage may allow it to be treated as a
shared network resource, much as bandwidth is a shared resource in the
Internet.  IBP defines a model of storage that is adapted to be sharable
within a network.  As in all distributed storage applications, issues arise
having to do with reliability and consistency, but IBP does not attempt to
solve these - it implements simple, unreliable buffering in a flexible way
that can be utilized by higher level protocols to obtain higher reliability.

Information about the Internet Backplane Protocol and implementations of the
client and server for various Unix and Windows-based platforms are available
at http://icl.cs.utk.edu/ibp.  A paper on archiectures for using IBP for
implementing active services appeared in the 2000 Workshop on Active
Middleware Services, and a paper on the design of higher level abstractions
built on top of IBP will appear in this year's workshop.

Micah Beck
Research Associate Professor
Computer Science Department
University of Tennessee

----- Original Message -----
From: "Christian Tschudin" <tschudin at docs.uu.se>
To: <end2end-interest at postel.org>
Sent: Tuesday, May 22, 2001 1:37 PM
Subject: [e2e] where end-to-end ends


> A new Internet-Draft on the "Interplanetary Internet" was recently
> published in which the authors (Cerf et al) predict where the end of
> end-to-end is:
>
>   "We have concluded that the standard Internet protocols should be
>    essentially "terminated" at the Interplanetary Gateways [...]"
>
> and not surprisingly they opt for an active networking approach ;-)
>
>   "But because of the enormous round-trip delays, such systems must work
>    very indirectly. For example, to steer the Mars Pathfinder rover, one
>    sends instructions about intermediate points that the robot must steer
>    past."
>
> Just some synectic readings.
> christian.
>
> Ref:
>   draft-irtf-ipnrg-arch-00.txt (May 2001)
>
> ---
> Christian Tschudin, Department of Computer Systems, Uppsala University,
Box 325
> S-75105 Uppsala, Sweden. <tschudin at docs.uu.se>,
http://www.docs.uu.se/~tschudin
>
>
>
>