[e2e] common interface: path or node?

[Micah Beck]

Recent discussions on this list bring out the fact that frustrations over
the
ability of the community to fashion transport layer solutions (TCP) that
meet the diversity of needs of the application community is hampered by
the need for a common, generic network layer.  This suggests a deeper
architectural issue that is not being discussed: whether the network layer
is still the best choice as the common interface.

I apologize in advance for summarizing with a couple of short
paragraphs a complex history that I was not part of: the
development of IP...

The Internet community has defined an interface, the network layer, whose
role is to move datagrams along a path of intermediate nodes originating at
a sender and terminating at a receiver.   The common implementation strategy
is to write a network layer forwarding program which runs at each
intermediate node and implements a fixed forwarding protocol.  The network
layer forwarding program can be changed only through an administrative
process, often manual; there may also be support in ROM or in hardware.

This implementation strategy leads to a situation in which a widely
implemented choice of forwarding protocol, in this case a particular flavor
of IPv4, becomes expensive and disruptive to change.  Cisco is often blamed,
but one might also blame the implementation strategy, which encourages
investment in hardware, software and procedures that makes the network layer
protocol difficult to change.

Various discussions on this list concern disagreements over what functions
should or should not be implemented at the intermediate node - "tussle" has
been suggested as a term for this kind of dispute.  There is an
architectural
argument that says that such conflicts can be resolved by allowing different
sets of endpoints to specify the behavior of the network layer as it
pertains
to their traffic according to their own needs.  As with diversity of
transport
layer protocols, such diversity of  network layer protocol would have to
operate within some bounds of "friendly behavior" which allowed sharing of
the underlying link layer infrastructure.

The difficulty lies with finding an implementation strategy that can
accomplish this level of flexibility, while still being efficient, ahciveing
high performance, and being scalable.  Here are some possibilities:

1. Pure source routing can move many decisions to the endpoints, but
forwarding decisions must be made in short timeframes and taking account of
changing conditions at the intermediate node.  Simply sending a fixed route
along with the datagram is not sufficient to allow the intermediate node to
take appropriate actions.

2. There are approaches that leverage a fixed routing algorithm at the
intermediate point, but add some coarse-grained direction from endpoints.
These include loose source routing, and the ability to choose between
alternative precomputed paths.  Such approaches have been implemented as
overlays, but putting them into the network layer presents a problem: these
strategies can be complex, and there are many alternatives, none of which is
adequate to all situations.  One can anticipate problems in reaching
consensus and in achieving widespread and correct deployment (as with IP
mulitcast).

3. There are Active Networking approaches that allow a network layer
forwarding program written at an endpoint to be run on intermediate nodes,
in order to allow the endpoint to have access to the full state of the
intermediate node and to direct its reactions in a short timeframe.
Interoperability requires that the program be written using a standard model
of execution, which must be implemented consistently at every intermediate
node.  There are many questions which one can raise about Active Networking
approaches, including whether a standard model of execution can also be
efficient and operate at the highest levels of performance and whether the
requirement of executing code at the intermediate node creates
specialization and complexity that is at odds with scalability.  I will not
go into those questions further.

In each of these cases, the use of the network layer as a means to hide the
existence of intermediate nodes from the endpoint is compromised in some
respect.  In the case of source routing, the indentity and order of
individual nodes on the path are exposed.  Even to choose between paths is a
way of taking account of the fact that they are comprised of different
nodes.  In the case of Active Networking, the functionality of the
intermediate node is exposed to endpoints in the form of a programming
interface.  These are all attempts to achieve flexibility by exposing what
the different options at the network layer have in common, namely that they
make use of the same basic store and forward capabilities of intermediate
nodes.

This analysis suggests the desirability of devising a *common programmable
model of the intermediate node* that allows endpoints to implement different
(yet compatible) network layer forwarding strategies.  If such a model could
be devised that was generic and simple enough to scale, there would still be
a question of whether it could be efficient and achieve high performance.
To the extent that this were possible, the result would be increased
heterogeneity at the network layer, and perhaps a decrease in the need to
accept common network layer signalling at that is inaequate to meet the
transport layer needs of paritcular application communities.

For some early ideas on the definition of such a programmable model of the
intermediate node, I would refer interested readers to this paper:

"An End-to-End Approach to Globally Scalable Programmable Networking"
Micah Beck, Terry Moore and James S. Plank
Future Directions in Network Architecture Workshop 2003
http://loci.cs.utk.edu/ibp/files/LoNC-FDNA03.pdf

The Network Functional Unit capability of the Internet Backplane Protocol
described in this paper is an overlay implementation of an interface that
exposes the intermediate node and which might be considered a prototype
for such a *common programmable model*.

Micah Beck
Associate Professor, Computer Science
University of Tennessee