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 for routers".

Overview/Main Points

• 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 manner.
• 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 traffic.

Issues

• 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.

Relevance

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.

Flaws

• 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.