On Active Networking and Congestion
Samrat Bhattacharjee, Kenneth Calvert, Ellen Zegura, Georgia Tech
One-line summary: Active network packets can be operated on by
functions that do application-specific things (sort of), so the routers
can do things like intelligently drop application-level data units (ADU's)
to decrease congestion. Architecture is basically "active messages
- Approach: provide a well defined set of functions that can be run on
packets. Each packet optionally carries a set of labeled state variables
that can be used in specifying the function's operation.
- Interesting motivation: they foresee a large class of applications
that will reactively adapt to network rather than demanding QoS, because
they will have no choice or want to avoid $$ cost.
- Goal: ensure that congestion losses occur in a controlled, application-specific
- Packets without APCI (Active Processing Control Info) are routed normally;
packets with APCI are sent to an "active processor" before being
routed. Computation may require headers, checksums, etc to be recomputed.
- Applications: unit-level dropping (aggregate packets of a video frame,
then drop the frame; drop an MPEG Group-of-Pictures; or control how many
layers of a layered encoding are sent); transformation of ADU's; stream
synchronization with selective dropping; etc.
- "Bursty" network modeled as follows: for parameters p,
K, each network write is followed, with probability p, by a
"wait" of rK time units where r is a random number
in [0,1]. Don't know if this is a reasonable characterization of bursty
- Fast switch (eg ATM) and processors must be integrated; couldn't
do this in their experimental setup.
- Where to add the APCI info to packets? ATM cells are too small;
can add in ATM AAL layer (so processor must reassemble AAL data
units before it can parse the APCI); as a sublayer or optional header in
IPv4. Routers must know how to deal with this.
- If network layer causes data unit restructuring (eg IP fragmentation),
APCI may have to be adjusted.
- Who computes the original APCI? Should be the application, via an appropriateapp-specific
UI; sometimes transport layer may be able to do it (simple TCP packet dropping)
but this loses most benefits of ALF.
- The APCI info must be passed down thru the network layers until it
becomes part of some layer's payload.
A good application of the e2e argument to active networks; a realistic
middle ground between current networks and Clark's long term vision of
active networks; a way of accommodating applications that adapt to the
network rather than demanding it. Relevant if you believe (as I do) that
these apps will dominate future traffic for economic reasons.
- Not clear if the modeling of burstiness is mathematically sound.
- Simulation setup required routing APCI packets to a separate active-processor
via Ethernet! As such, no real indication of how much CPU load would
be required in the real world (e.g. multiport ATM switch operating at capacity).
There could be wide variability in the CPU demands of AP functions.
- How could system be extended? In "true" active networks,
the packet can carry the code (or specify it), in this system it only specifies
a function name, so not clear how the code gets into the routers in the
first place or how it would be updated. How would new apps define new functions?
This is more like active messages for routers.