Subject: Dynamic Network Architecture

From: Srijith K <[email-masked]>
Date: Thu, 21 Sep 2000 00:16:26 -0400 (EDT)

Hi,

I was going through the paper "A Dynamic Network Architecture" by Sean
O'Malley and Larry Peterson. In this paper they introduce a dynamic network
arch. in which the number of layers visited by each message/packet is
variable.

I find this a very interesting idea. What do you all say ?? Has any further
work been done on this??

Regards,
Srijith

______________________________________________
FREE Personalized Email at Mail.com
Sign up at http://www.mail.com/?sr=signup

---

From: Dave Hudson <[email-masked]>
Date: Thu, 21 Sep 2000 14:46:47 +0100

Hi,

> I find this a very interesting idea. What do you all say ?? Has any further

I believe that there's been quite a lot of further work done by the
(same?) team at the University of Arizona (I've got quite a few of their
papers in front of me). 

Having recently read their papers I've found that the system I've been
building for embedded networking (initially for 8 bit systems) is very
similar.  It's a very good concept for building systems when resources
are tight (my main target has 128 kBytes of flash for code and 32 kBytes
of SRAM for data).

Please note that the following comments are entirely based on my
experience (with my own code) with such small systems and I'm not sure
how well the implementation scales (although I should know fairly soon
as the code's being ported to the i386 now).  It's also worth noting
that the OS hosting this stack supports very fine grained priority
handling (it's an RTOS), and this does have an impact...

I'll start with the obvious downside: inter-layer transitions cost
time.  There is an upside that helps compensate this to an extent:
binding only those elements that are necessary avoids and wasted
conditional code sequences.  The net effect is, however, negative.

The number of threads required for its use is not dependent on the
number of services being handled.  In a trivial case, 1 thread per
datalink device is sufficient as the threads simply push packets through
the stack all the way to the end-application.  It looks like on higher
performance systems the thread count could be weighted, giving more
threads to faster devices.  By having a thread per message and avoiding
context switching is a big win - in my own case this far outweighs the
losses due to inter-layer transitions (very conservatively this is about
a 10:1 ratio).

By dynamically binding the layers at run-time, the linker can remove any
layers that can never be referenced (huge win for small systems) without
resorting to a lot of conditional compilation.  An example here is that
a device doesn't have to carry any SLIP-support code if running purely
on Ethernet, or conversely I don't carry any of the ARP, Ethernet
framing, etc, when only using SLIP. The downside is that there is some
additional overhead to manage the dynamically bound layers.  Dynamic
binding makes it easy to insert things such as packet filters so this
can be a run-time decision, but with no cost if the filter is not bound.

The fine-grained layers make it easier to separate policy and mechanism
- in my code, when a listening TCP port, receives a SYN, the service
bound to the port is upcalled and can decide whether or not to accept or
decline the connection.  More generally in the TCP case this means that
there are no resources being consumed by the stack without the agreement
of the applications (or at least the upper layers).

Avoiding context switching means that a lot of queuing can be avoided
too.  An earlier evolution of my stack was far more conventional and
used to have threads in the IP layer and each application service as
well as in the device drivers.  It was fairly trivial to crash the whole
system with buffer overflows (only 32k SRAM in the system) - flood
pinging would take almost no time to do this.  I originally added buffer
management and this simply resulted in no crashes but no work being done
either (total DoS)!  The new stack degrades gracefully - if I have a
debug compiled version of the code (does lots of sanity checks) a flood
ping may result in a 30% response rate, whilst a full-speed version
might yield a 45% response.

I was just about to note that one downside with this style of system is
that it doesn't support BSD sockets (to support existing code), but of
course these can be implemented as (almost) trivial layers on top the
"native" code.

One other nice feature of this style of system is that it makes it easy
to develop.  By dynamically binding each of the layers, it's extremely
easy to change one of them.  My main plan when I start to look at some
of the higher-performance TCP extensions will be to retain my existing
(slow but working) TCP code bound to my SLIP link for my debugging
services whilst binding the newer (faster but, initially at least,
probably not-working) TCP code to the Ethernet link.

Sorry if this is a bit rambling, but it's about the first time I've
tried to explain what I've been doing and I might have got a bit carried
away :-)

				Regards,
				Dave

PS. The code is available under LGPL, although this may move to a
slightly less restrictive licence soon to allow it to be used in
mask-ROM or OTP microcontrollers.  Please see
http://liquorice.sourceforge.net/