Minutes from Active Network Architecture Meeting

Attendees

• GT: Bobby Bhattacharjee, Ken Calvert, Ellen Zegura, Youngsu Chae, Joe Dixon, Shashidhar Merugu
• ISI: Bob Braden
• MIT: John Guttag, David Wetherall
• Arizona: Larry Peterson

Caveat

MEETING GOALS/AGENDA BASHING (Ken)

Agenda

• Meeting goals, agenda bashing
• Architecture: assumptions, goals
• Architecture: viewpoints, discussion
• Lunch, tours
• Discussion of Group project/demo
• Technology exchange (AN-Sim, ...)
• Wrapup architecture discussion
• Action items, next meeting?

Meeting goals

• Get consensus on goals, assumptions, principles, and pieces of AN architecture:
  • Identify pieces to be common/standardized.
  • End up with outline of an architecture document.
• Discuss possible joint interoperability/application demo(s).
• Exchange technology.

ARCHITECTURE ASSUMPTIONS AND GOALS - PART 1 (Ken)

Assumptions

• The packet is the fundamental unit of service (not cells or circuits).
• Active Nodes are connected by a variety of different packet-forwarding technologies.
• The primary function of the Active Network is moving information (and not computation).
• All Active Nodes support a single "base functionality".
• Users access AN services via the base functionality.

More Assumptions

• There will be more than 1 higher-level service.
• Each Active Node is controlled by an administration.
• No administration controls all Active Network nodes.
• Administrations may or may not trust each other.
• Strong cryptographic mechanisms are available.
• Others?

Goals for the Architecture

• A generic model that admits all existing approaches.
• Support fast-path optimizations (at least don't hinder them).
• Support customization of almost any aspect of node processing, including global policies that are part of base functionality.
• Functions affecting security of the system are not left entirely to the higher-level services.

Questions

• How many higher-level services (like ANTS, PLAN) have to be supported?
• What goes in the base functionality?
• What low-level abstractions are supported by each active node?
  • Interface: to send/receive packets, establish per-flow queues, reserve BW, etc. (Also to applications.)
  • Routing Table: Maps Addrs to Interfaces
  • Addrs: Key for Routing Tables
• What are the differences between End Systems and Intermediate Systems?

STATUS UPDATES

ANTS (Wetherall)

• currently using JDK 1.0.2
• working on moving to JDK 1.1.1
• adding services - e.g., reliable transport service

Other MIT activity (Guttag)

• two thrusts: performance, applications
• starting to work with theory group (Tom Leighton et al.)
• new work on specifying security constraints
• new work on instrumenting ANTS for measurements/demos

Scout (Peterson)

• wrote JIT compiler running on Linux/Pentium
• Java Virtual machine + JIT running on Scout/Pentium
• ANTS running on both Linux and Scout
• ping-pong measurements with 1 msec rtt
• Scout platform requirements: PCI bus, particular graphics and Ethernet cards
• desired features in ANTS:
  • timeout
  • separation of forwarding from control (NetTV application)
• why Scout for AN?
  • partly performance, though not expected to be big win
  • vehicle to experiment with scheduling

ISI (Braden)

• (somewhat) FreeBSD contrained due to CAIRN involvement, but mostly using Solaris
• re-writing RSVP in Java
• not clear whether ANTS can be used for RSVP implementation
• Aside:
  • Java OS on a chip, including TCP/IP stack
  • might be possible to get several machines
• interested in practical implications/reality of AN
• thinking about how to support reservation customization by modifying/customizing Java code

GT

• installed ANTS
• working on AN simulator (AN-Sim) to be discussed later
• working on applications (e.g., network caching)
• Bobby: Control-on-demand project this summer at AT&T

ASSUMPTIONS AND GOALS - PART 2

ISI (Braden)

Points of significant discussion:

• whether problems to solve are more clear for distributed computation or communication (later agreed that primary function of active network is communication not computation)
• options for organization of ANEP and IP
  • ANEP strictly above IP (-> IP is wire format)
  • IP as "link" layer option for ANEP (-> ANEP is wire format)
  • two-faced bearer service (i.e., ANEP=IPv10) that looks like IP to IP community and ANEP to AN community
• initial discussion on number of execution environments, during development and as eventual goal

MIT - ANTS Architecture (Wetherall)

Points of significant discussion:

• ANTS details (terminology, definitions, code loading, etc.)
• protection model: currently by protocol; thinking about more ambitious (file-system-like) protection models; interesting question about what is a good protection model
• composition; no composition currently supported by ANTS other than incorporating desired code into new protocol; discussion of types of composition (stackable, control/data)
• "reliability model" of ANTS

GT (Zegura/Bhattacharjee)

Points of significant discussion:

• multiple environments
• how much effort to spend on supporting/interoperating multiple environments

DETAILED DISCUSSIONS

Resource Control at Base Layer

• how to specify requirements (link bandwidth, cpu cycles, memory-time)
• how to divide resource limit when multicast (don't know how many receivers will be reached over given interface)
• who decrements resource limit (node or environment)?
• Larry suggested sending code to interpret resource field
• Bob suggested 2 ANEP resource options
  • strict hop count
  • generalized resource usage

Roles

• users
• programmers (e.g., of ANTS protocols)
• environment developers
• providers of base functionality
• O/S vendors

Lower Layer Interface

• send(pkt, line)
• set-resource-limits(cpu,link-buffer,mem-pool,link)
• multiple threads of control (fork, timeout,exception throwing,sync)
• query node (address, avail resources)
• map (e.g., for routing table)

Things that might belong in base layer:

• code distribution mechanism (from ANTS?)
• memory management, including garbage collection (or does each environment get a static partition and do their own management?)
• synchronized clocks
• install new environment capability

• DNS names as only addresses (can a reasonable routing protocol be built using these?)
• IPv6 addresses
• should addresses be assigned to systems or interfaces?

GROUP EXPERIMENT (suggested by Wetherall/Guttag)

Idea: Stock quote service

Characteristics:

• performance critical
• hard to solve by caching alone, due to timing and granularity
• real-time

• cache prices of individual stocks in network
• assemble responses by putting together set of desired stocks
• support different policies (e.g., fast response but not necessarily up to date, slower response but current prices)

• source of content (PC Quote satellite service?)
• connecting non-AN-capable hosts
• next steps: coordinate with Ulana at MIT

OUTLINE OF ARCHITECTURE DOCUMENT

• Objectives of AN
• Assumptions
• Design Principles
• Architectural Requirements
• Evolution Strategy
• Terminology/Objects of Discourse
• Interfaces

THINGS WE AGREED UPON

• 2 architecture pictures from GT presentation
• Design strategy:
  • minimal ANEP + base
  • include functions needed for global correctness
  • extend with functions that are common or needed for efficiency
• Purpose is communication services, not computation.
• Arch should not preclude fast paths, scalability.
• Execution environments are heavyweight, few, change slowly.
• No distinction is made between ES and IS.
• Resource management is coarse-grained at node level and refined at environment level.
• Resource usage bound is enforced by base layer with at least one option in ANEP header.
• Global namespace is needed for protocols to allow sharing. Allocation of names must not require coordination.
• Node have unique IDs.

THINGS WE DON'T KNOW/DON'T AGREE

• Do context switches between environments need to be uniformly fast?
• Should ANTS (or any) code-loading mechanism go in base layer?
• Should fast path pass-through be exposed in architecture?
• Should synchronized clocks be in base layer?
• What should be the form of global node IDs?
  • DNS?
  • IPv6 address?
• Should composition mechanisms go in base layer?
• What interaction should be allowed between environments?

LEFT UNRESOLVED/NOT DISCUSSED MUCH

• agreeing on common machine and O/S platform
• administrations/trust boundaries
• meeting in January