NodeOS questions

[Bob Lindell <lindell@ISI.EDU>]

A couple of us at ISI have been looking at the Janos/ANSTR code
(janos-20000214) and have some questions about it.  We thought that it
would be constructive to email our questions not only to the Flux group,
but also to the wider active-network community to promote discussion and
consensus of programming interfaces.  Our knowledge of the Janos code is
somewhat limited as we have not actually used the code, but we have been
studying it with the intent to port the ASP EE to the Janos interface.

1) Flow management

Our plan is to assign flows to both the EE and the AAs to gain NodeOS
support for the resource management of these entities.  The NodeOS
interface provides a streamlined capability to move packets from the
network to the target flows and InChannels.  For simple protocols, it
should be possible to classify packets and move them to the appropriate
AAs with no additional processing in the EE.

Our question involves the implementation of more complex protocols,
such as reliable transport, in the EE.  In this case, a flow of packets
for a given AA will contain some packets that will be processed by the
AA and others that will only be processed by the EE.  The later includes
packets such as SYN, ACKS, and retransmissions.

Such an implementation will require that the EE first acquire the
packets, perform the protocol processing, and deliver the results to
the application.  When the packets are first received, they will placed
in the NodeOS flow/mempool for the EE.  To hand of the packet to the AA,
the EE will need to move the resources (memory and possibly the thread)
to the target AA flow/mempool.  How is this accomplished using the
NodeOS interface?

Rather than moving the thread from one pool to another, we could
rendezvous with a thread from the other pool and hand off the processing.
This solution does not seem to be desirable for efficient protocol
stack implementations.  It inserts a large and unnecessary context switch
overhead into the protocol processing path.  To move the memory we could
use the map and unmap functionality.  How do we express the later in
the Java NodeOS bindings?  Should there be placeholder functions that
we reference which might be filled in later by resource managed JVM
implementations?

2) Is porting to the Janos Java bindings the right goal?

Our goal is to port our EE to the NodeOS interface.  This should
make it easier for others to experiment with our EE on a real NodeOS
implementation.  Does a port using the Janos Java bindings achieve this
goal?  Do most NodeOS developers plan to use the Janos Java bindings
and port the backend to their respective NodeOS implementations?  If the
answer is no, what Java bindings should we be using.

3) Implementation details with the Janos Java bindings

The current Janos interface *excludes* the protocol specification
from the channel constructors and implicitly assumes "ip/udp".
We say "excludes" because the protocol specification is included in the
NodeOS interface when constructing a channel.  In the ASP EE we would like 
the protocol specification to be exposed by the Janos interface so that AAs 
can can specify the interception of both UDP and raw IP packets.  
If an EE is running over the NodeOS, there is no reason why AAs might
not request the capture of raw IP packets, even when using a Java (ie. Janos) 
interface.  Currently, the ASP EE can be run using native methods that allow
the capture of protocol 46 packets (RSVP) and we would like the same 
functionality when running ASP over Janos.  We therefore propose that the 
Janos interface include the protocol spec as a parameter when constructing
channels (as specified by the NodeOS spec).

When specifying packet intercept from the Janos Java interface, it
is unclear to us why the udp port is not part of a demux key.  See for
example the call to startMsgLoop() in tests/UdpTest.Java.  It seems that
this structure is inconsistent with the NodeOS model of protocols specs
and demux keys.  For the Java implementation of UDP InChannels, the Janos
implementation could create a UDP pseudo-header, with knowledge of src/dst
addresses and length, and provide mask and match keys for the header.

--Graham Phillips and Bob Lindell