ADAPTIVE

ADAPTIVE
A Flexible and Adaptive Transport System Architecture to Support Lightweight
Protocols for Multimedia Applications on High-Performance Networks

Douglas C. Schmidt, Donald F. Box, and Tatsuya Suda
Department of Information and Computer Science
University of California, Irvine, California 92717 1

Abstract memory latency, CPU speed, interrupt and context switch-
ing overhead, process architecture, and message buffering).
Transport systems integrate operating system services such Application performance bottlenecks are shifting from the
as memory and process management together with commu- network factors to the transport system factors due to (1)
nication protocols that utilize these OS services to support advances in fiber optics and VLSI technology that have in-
distributed applications running on local and wide area net- creased network channel speed by several orders of magni-
works. Existing transport systems do not customize their tude and (2) the increased diversity and dynamism in appli-
services to meet the quality-of-service requirements of dis- cation requirements and network characteristics.
tributed applications. This often forces developers into the To handle these changes, transport systems must become
procrustean framework offered by transport systems and pro- more flexible, lightweight, and adaptive [1]. However, ex-
tocols that were designed before the advent of multime- isting transport systems typically offer only a small number
dia applications and high-performance networks. Flexible of “monolithic” protocols. Moreover, these protocols do not
and adaptive transport systems, on the other hand, dynam- adequately meet the communication requirements of next-
ically configure lightweight protocols that meet application generation distributed applications [2]. We are developing
requirements more precisely. the ADAPTIVE system to provide a flexible architecture for
This paper describes a high-performance transport system developing and experimenting with lightweight and adaptive
architecture called ADAPTIVE, “A Dynamically Assembled transport system protocols.
Protocol Transformation, Integration, and Validation Envi- The paper is organized as follows: Section 2 describes
ronment.” We are developing ADAPTIVE to support multi- the research background, Section 3 introduces the ADAP-
media applications running on high-performance networks. TIVE system, Section 4 outlines ADAPTIVE’s architectural
ADAPTIVE is a transformational system that provides poli- design, and Section 5 summarizes the paper and describes
cies and mechanisms to automatically specify and synthesize our future work.
a flexible, lightweight, and adaptive transport system con-
figuration. In addition, it provides a controlled prototyping
environment for monitoring, analyzing, and experimenting
with the performance effects of alternative transport system
2 Background
designs and implementations.
This section defines three important research problems in-
volving transport systems, describes how existing systems do
not adequately solve these problems, and compares ADAP-
1 Introduction TIVE with other related work.
The performance of distributed applications such as remote
terminal access, network file servers, distributed databases, 2.1 Research Problems
bulk data transfer, computer imaging, tele-conferencing,
full-motion video, scientific computation and visualization is Our research is investigating solutions to the following three
influenced by both network factors and transport system fac- problems involving transport systems:
tors. Several key network factors include channel speed, bit- (A) The Throughput Preservation Problem: As noted
error rate, and congestion levels at the intermediate switch- by [3, 4], only a limited amount of the available band-
ing nodes. Transport system factors include both proto- width in high-performance networks is being delivered to
col processing activities (such as connection management, applications. This situation results both from poorly lay-
transmission control, and reliability management) and gen- ered architectures [5] and from transport system overhead
eral operating system hardware and software factors (such as such as memory-to-memory copying and process manage-
1 An earlier version of this paper appeared in the proceedings of the first ment operations like process/context switching and schedul-
symposium on High-Performance Distributed Computing in Syracuse, New ing. Moreover, this overhead is not decreasing as rapidly
York, September 1992. as the network channel-speed is increasing, due in part to

Transport Service Class Example Applications Average Burst Delay Jitter Order Loss Priority Multi-
Thruput Factor Sens Sens Sens Tolerance Delivery cast
Interactive Voice Conversation low low high high low high no no
Isochronous Tele-Conferencing mod mod high high low mod yes yes
Distributional Full-Motion Video (comp) high high high mod low mod yes yes
Isochronous Full-Motion Video (raw) very-high low high high low mod yes yes
Real-Time Non-Isochronous Manufacturing Control mod mod high var high low yes yes
File Transfer mod low low N/D high none no no
Non-Real-Time TELNET very-low high high low high none yes no
Non-Isochronous On-Line Transaction Processing low high high low var none no no
Remote File Service low high high low var none no yes

Table 1: Application Transport Service Classes (TSC)

the widespread use of traditional transport system infrastruc- multicast, and broadcast), media access control scheme
tures such as UNIX, which are ill-suited for asynchronous, (CSMA/CD, token passing, and switch based), maximum
interrupt-driven network communication. Transport system transmission unit (48 bytes for ATM and DQDB cells,
overhead also affects other network characteristics such as 1,500 bytes for Ethernet packets, 4,500 bytes for an FDDI
delay and jitter. frame, and 9,188 bytes for SMDS) and network services
(synchronous, asynchronous, and isochronous delivery and
(B) The Application and Network Diversity and Dy-
bounded-delay guarantees).
namism Problem: Another challenge facing transport sys-
tem developers and researchers is how to effectively sup- Moreover, given the large installed network base, many
port the diverse quality-of-service requirements of next- applications will continue to interoperate across several en-
generation distributed multimedia applications (we will refer vironments in the foreseeable future. These environments in-
to these as simply “application requirements” from now on) clude (1) low-utilization, low-latency LANs (e.g., Ethernet),
running over diverse, high-performance networks. (2) congestion-prone, high latency WANs (e.g., the current
Internet), and (3) high-bandwidth, high latency WANs (e.g.,
Multimedia Applications: Multimedia application re- ATM-based B-ISDN public access networks) [2]. Handling
quirements are more demanding and dynamic than those this diversity and dynamism requires determining appro-
found in traditional applications like remote terminal access, priate end-to-end congestion and error protection schemes.
file transfer, and electronic mail. For example, multimedia These schemes must effectively utilize the high bandwidth
applications involve combinations of quality-of-service re- channels and adapt quickly to dynamically changing network
quirements such as extremely high throughput (full-motion conditions such as congestion or routing updates.
video), strict real-time delivery (manufacturing control sys-
tems), low latency (on-line transaction processing), low de- (C) The Communication Software Development Com-
lay jitter (voice conversation), capabilities for multicast (col- plexity Problem: Communication software has tradition-
laborative work activities) and broadcast (distributed name ally been difficult to develop, due to the complexity of trying
resolution), high-reliability (transfer of medical images), to simultaneously maximize performance, functionality, cor-
temporal synchronization (tele-conferencing), and some de- rectness, extensibility, and portability across heterogeneous
gree of loss tolerance (hierarchically-coded video). operating environments. This heterogeneity is reflected in
Multimedia applications also impose different network complex software architectures that must support diverse ap-
traffic patterns. For instance, some applications generate plications written in diverse languages, communicating via
highly bursty traffic (variable bit-rate video), some generate diverse transport systems running on diverse computer ar-
continuous traffic (constant bit-rate video), and others gener- chitectures, which interoperate over diverse internetworked
ate short, interactive, “request-response” traffic (network file environments. To effectively support this heterogeneity, it is
systems using remote procedure calls (RPC)). In addition, increasingly important to structure communication software
application requirements may change dynamically during a using modular designs that enhance maintainability, flexibil-
session (e.g., a tele-conferencing application may switch be- ity, and efficiency. In particular, complicated communication
tween unicast and multicast as participants join and leave the software increases the difficulty of migrating selected trans-
conversation). Table 1 illustrates the diversity of transport port system operations into more efficient VLSI hardware
requirements for several representative classes of distributed implementations.
applications [6].
High-Performance Networks: Network diversity in-
volves both the static architecture and dynamic state of the 2.2 Inadequacy of Existing Transport System
underlying network. A diverse collection of networks now Solutions
exists, possessing differences in diameter (LANs, MANs,
and WANs), channel speeds (4/16 Mbps Token Ring, 10 Existing transport systems do not provide effective solutions
Mbps Ethernet, 100 Mbps FDDI, and 155/622 Mbps ATM), for all three problems described above. This section de-
channel bit-error rate (approximately 10,4 for copper and scribes several reasons for the inadequacy of existing sys-
10,9 for fiber), network type (datagram, virtual circuit, tems.

(A) High Transport System Overhead: Effectively sup- figurations in response to dynamically changing application
porting application requirements involves suitable perfor- requirements and network characteristics:
mance and services from both the network and the transport
system. However, most general-purpose operating systems Static Transport Systems: are completely configured
do not provide adequate support for transport system activi- at operating system boot time. In this case, the transport sys-
ties such as real-time process scheduling, interrupt handling tem often provides protocol support based only upon gen-
and context switching, message buffer management, layer- eral usage assumptions such as unreliable datagram service
to-layer flow control, and multiplexing and demultiplexing (e.g., UDP) versus reliable byte stream service (e.g., TCP).
[7]. Moreover, many protocol suites are implemented with Many well-known transport systems belong to this category
improperly layered process architectures that increase proto- [12, 13, 14, 15, 16].
col processing overhead [8]. Dynamic Transport Systems: postpone complete
Due to this overhead, the bandwidth available in a high- configuration until either connection establishment time or
performance network is reduced by 1 to 2 orders of magni- during data transfer. In both cases, these transport systems
tude by the time it is actually delivered to applications [4]. may be configured by negotiating with (1) local and remote
Moreover, this throughput preservation problem persists de- hosts and (2) intermediate switching nodes in the network.
spite an increase in CPU speeds. There are several explana- This negotiation process customizes transport system ses-
tions for this behavior: (1) networks have increased by 5 or sions to account for the application requirements and the
6 orders of magnitude (from kbps to Gbps), whereas CPU available host and network resources. These resources in-
speeds have only increased by 2 or 3 orders of magnitude clude available buffer space, CPU load, available commu-
(from 1 MIP up to 100 MIPS) [3], (2) existing transport sys- nication ports and virtual circuits, and network congestion
tems are written largely in software, (3) network host inter- level.
faces typically generate interrupts for every transmitted and Only a handful of transport systems provide any support
received packet, leading to increased CPU context/process for configuration of their protocol suites at connection estab-
switching overhead [3, 9], and (4) despite increasing to- lishment time [2, 17, 18]. Furthermore, this support typically
tal MIPS, RISC architectures often penalize interrupt-driven involves activities on only the local hosts, i.e., network and
network communication by exhibiting high context/process remote host characteristics and conditions are typically not
switching overhead. This overhead results from the cost of considered during the configuration process.
flushing instruction and data caches and pipelines, as well as An even more dynamic approach permits reconfiguration
from storing and retrieving register windows and invalidat- during the data-transfer phase, thereby accommodating dy-
ing translation-lookaside buffers. namic changes in application requirements, transport system
resources, and network characteristics. Very few transport
(B) Inflexible and Non-Adaptive Transport System Ar- systems provide support for adaptive reconfiguration, and
chitectures: Existing transport systems are also unable to those that do are experimental research projects [6, 19].
meet the diverse and dynamic demands of applications and Given the increasing diversity of application requirements
networks since they typically provide only a fixed, statically and network characteristics (combined with the fact that both
configured suite of protocol services [2]. For instance, most may change dynamically), it appears that dynamically con-
general-purpose protocols are not capable of dynamically figured transport systems may support a wider range of ap-
tailoring their services to take advantage of specific appli- plication/network pairings more effectively than statically
cation requirements or network characteristics [10]. More- configured systems. Therefore, we are designing ADAP-
over, communication software tends to be inflexible and dif- TIVE’s architecture to support transport systems that exe-
ficult to modify [2], and is often tightly coupled to a partic- cute lightweight and adaptive communication protocols that
ular transport system environment such as TCP/IP on BSD are configured flexibly.
UNIX [7, 11]. All these factors increase the difficulty of
maintaining, extending, and adapting the software to support (C) No Explicit Support for Multimedia Applications
the increased diversity in networks and applications. and High-Performance Networks: Many popular trans-
For example, it is difficult to select an existing transport port systems were designed and implemented before the new
system configuration that is neither too overweight nor too generation of multimedia applications and high-performance
underweight to satisfy the QoS requirements. An example of networks became widely available. For example, the BSD
an overweight configuration is one where a protocol (such as 4.3 UNIX TCP/IP implementation was originally designed
TP4) provides retransmission support for loss-tolerant, con- for traditional data applications that required 100 percent
strained latency applications such as interactive voice. In this error-free transmission over low-bandwidth, high-error net-
case the extra mechanisms required to provide retransmis- work links such as ARPANET.
sion simply slow down the protocol processing. An exam- Therefore, TCP/IP (and in many cases the ISO TP[0-4]
ple of an underweight configuration is one where a protocol transport protocols) may prove inadequate for modern mul-
(such as TCP) does not provide a service (such as reliable timedia applications, since they do not incorporate (1) effi-
multicast support) for applications that require it (such as in- cient control formats,2 (2) fast connection establishment, (3)
teractive teleconferencing applications). 2 For example, neither TCP nor TP4 place their checksum in the packet
To illustrate the range in the design space, transport sys- trailer, thereby precluding simultaneous transmission and checksum compu-
tems are distinguished below by how they adapt their con- tation [20]. Moreover, many fields in the TCP header are not word-aligned

multicast support, (4) security, (5) synchronized multimedia TIVE, on the other hand, focuses on flexible and adaptive
streams or (6) quality-of-service parameters such as priori- transport systems that support multimedia applications run-
tized real-time guarantees involving bounded delay/jitter and ning on high-performance networks.
application-selectable levels of loss-tolerance [1, 21]. More- The Function-based Communication SubSystem (F-CSS)
over, most existing transport systems do not export multi- is a transport system architecture that supports dynamic re-
media services like isochronous and synchronous delivery configuration of protocol stacks based on explicitly-specified
guarantees from the underlying network to the application. application requirements. F-CSS utilizes a special-purpose
In addition, standard protocol suites were designed for environment based upon transputers, whereas ADAPTIVE
low-speed, unreliable, congestion-prone datagram networks, resides in a general-purpose OS.
rather than high-speed, congestion-controlled virtual-circuit The Multi-Stream Protocol (MSP) is a “feature-rich”
networks such as ATM [22]. For example, the TCP/IP suite transport protocol designed to execute on parallel proces-
does not provide (1) explicit access control (although TCP’s sors. In addition, MSP permits protocol configurations to
slow start and multiplicative decrease algorithms are used change their mechanisms “on-the-fly” without loss of data
to simulate access control), (2) rate control and selective (e.g., switching the retransmission scheme from go-back-n
retransmission to handle congestion, or (3) long-delay link to selective repeat within an active connection). Like the x-
support such as large flow-control windows, non-wrapping kernel, MSP focuses more on mechanisms (e.g., how to im-
sequence numbers, and precise round-trip timer calculations. plement the changes on-the-fly) rather than on policies that
Although extensions to TCP and IP have been proposed that orchestrate the mechanisms (e.g., when to make the changes
address these limitations [23], these proposals are not yet and what changes should occur). ADAPTIVE, on the other
been integrated into the base standards requirements. hand, focuses on both policies and mechanisms (as described
in Section 3).
2.3 Related Work
A growing number of projects address high-performance 3 Overview of the ADAPTIVE Sys-
transport systems that are constructed out of flexible compo-
nents that support lightweight and adaptive protocols. In ad-
tem
dition to the research described in this section, other projects
ADAPTIVE is “A Dynamically Assembled Protocol Trans-
focusing on various aspects of flexible, lightweight, and
formation, Integration, and Validation Environment.” It is
adaptive transport systems and protocols include [3, 18, 20,
used to specify, configure, experiment with, analyze, and im-
21, 24, 25, 26, 27]. The ADAPTIVE system is influenced
prove alternative transport system designs and implementa-
by the Programmable Network Prototyping System (PNPS)
tions. In particular, we are developing ADAPTIVE to help
[28], the x-kernel/Avoca projects [2, 7], the Function-based
ameliorate the inadequacies of existing systems described in
Communication SubSystem (F-CSS) [6], and the Multi-
Section 2.2 above. This section briefly describes the flexible
Stream Protocol (MSP) [19]. PNPS is an environment for
and adaptive aspects of ADAPTIVE.
prototyping and experimenting with hardware implementa-
tions of MAC-layer protocols. ADAPTIVE, on the other ADAPTIVE provides services that flexibly configure and
hand, focuses on prototyping and experimenting with soft- reconfigure lightweight and adaptive transport system ses-
ware architectures for middle- and higher-layer protocols. sions. Its flexibility is derived from a repository of reusable
mechanisms used to synthesize sessions that are customized
The x-kernel is a communications-oriented environment
to adapt to application requirements and network character-
that supports protocol development and experimentation. It
istics. These mechanisms include buffer and event managers,
provides a “protocol backplane” consisting of uniform in-
connection management, transmission control, and reliabil-
terfaces for reusable, “medium-granularity” communication
ity management. A flexible transport system architectural
service components such as message handling, multiplex-
design is essential for supporting prototyping, experimenta-
ing and demultiplexing, and event management. Protocol
tion, and diversity.
interrelationships are described and implemented via modu-
lar, highly-layered protocol graphs composed from virtual- Experience indicates that it is very difficult to specify
and micro-protocols. Whereas the x-kernel focuses on OS one protocol that is optimal for all application/transport sys-
support for medium-grain protocol activities, ADAPTIVE tem/network combinations [29]. Therefore, instead of devel-
supports finer-grain protocol session functionality such as oping a single highly-complex, all-encompassing protocol,
connection management, reliability management, and end- ADAPTIVE provides a transport system architecture that
to-end transmission control. permits fine-grain selection and configuration of precisely
specified protocol mechanisms [2].
Avoca uses the x-kernel as a run-time environment to sup-
port middle-layer protocol implementation and experimenta- ADAPTIVE also supports run-time adaptive reconfigura-
tion. Its primary emphasis is on flexible implementations of tion that adapts to feedback from changes in applications re-
protocols like RPC, UDP, and TCP, which support traditional quirements, transport system resources, and network char-
data applications running on traditional networks. ADAP- acteristics. Adaptivity is important since applications and
networks are dynamically changing entities, which are not
and the option formats are not fixed-sized, which increases header parsing necessarily served most effectively by static solutions. Sec-
overhead. tion 4 describes the ADAPTIVE architecture in detail.

ADAPTIVE is distinguished by its flexible architecture retransmission, and timer schemes) that dictate how to con-
that supports (A) application and network diversity and dy- figure and reconfigure the transport system. For example,
namism, (B) reduction in transport system overhead, (C) [19] describes several adaptive mechanisms that support “on-
dual focus on both policies and mechanisms, and (D) the-fly” protocol reconfigurations. However, most existing
feedback-guided monitoring and measurement. The follow- research places less emphasis on the policies that deter-
ing paragraphs discuss these points in detail: mine when to adaptively reconfigure transport system mech-
(A) Support for Both Multimedia Application Require- anisms and what mechanisms the subsequent reconfigura-
ments and Network Characteristics: ADAPTIVE con- tions should contain. Conversely, related work that does
figures transport system sessions based upon the network address policies [6, 25, 30] is less specific with respect to
characteristics and the QoS requirements of applications. the mechanisms that actually enforce these policies. For
Other related work on transport systems typically empha- example, adequately supporting QoS requirements such as
sizes either diverse application requirements [6, 25, 30] or bounded delay and jitter involves complicated interactions
network characteristics [3, 19]. Moreover, existing imple- between the network and the transport systems on both local
mentations of transport systems tend to focus more on (1) and remote hosts.
traditional data applications such as bulk text file transfer The ADAPTIVE transport system architecture, on the
and/or (2) traditional local area network environments such other hand, specifically addresses both policies and mecha-
as Ethernet or Token Ring. nisms. The following two examples illustrate the distinction
between policies and mechanisms:
(B) Reduction in Transport System Overhead: A large Transport system policies may switch a session’s re-
body of research exists on both network protocols (see [31] transmission mechanism from go-back-n to selective re-
for a survey) and the transport systems that support them (see peat in the event that (1) the application’s requirements
[8] for our survey). Techniques for reducing transport system change from multicast to unicast or (2) the congestion
overhead involve various combinations of the following: in the network increases beyond a specified threshold
1. Utilize faster hardware for CPUs, busses, network con- (resulting in greater packet loss due to queue overflows
trollers, and memory hierarchies. at intermediate switching nodes) [1, 3]. Note that it may
2. Implement selected functions (e.g., checksum calcu- be feasible to restore the go-back-n scheme when con-
lations, message buffering, and demultiplexing) in gestion subsides, thereby reducing buffering require-
special-purpose hardware. ments at the receiver(s).
3. Migrate some or all of the protocol processing activi- The transport system may also contain policies
ties to “off-board” processors [9, 20, 32] to reduce CPU that cause the reliability management mechanism to
interrupts and operating system context/process switch- switch from “retransmission-based” to “forward error
ing on the host computer. correction-based” when the round-trip delay time in-
creases beyond some threshold (e.g., when a route
4. Implement existing protocols more efficiently by (1) switches from a terrestrial link to a satellite link).
shortening the instruction paths executed for each
Note that in each of these cases, it is as important to under-
packet and (2) improving the implementation of stan-
stand the policies that dictate when to switch mechanisms
dard transport system support services such as message
and what to switch them to, as it is to know how to imple-
management and demultiplexing [10, 11, 33].
ment the mechanisms efficiently.
5. Design new lightweight and adaptive protocols that are
tailored for high-speed, low error, and low delay net- (D) Support for Controlled, Empirical Experimentation
work environments [19, 20, 34, 35, 36]. via Performance Monitoring and Measurement: It is
difficult to empirically evaluate the advantages and disad-
6. Develop alternative transport system architectures vantages of different transport system designs without (1) a
based on (a) vertical process architectures [7, 37], (b) controlled implementation environment and (2) systematic
parallel processing of protocol functions [3, 4, 19], (c) methods for monitoring and measuring distributed applica-
flexible protocol stacks that require fewer layers and/or tion performance [10]. However, most transport systems are
are dynamically assembled [6, 25, 26, 30], and (d) mod- designed for performance rather than for experimentation.
ular and extensible transport system software that sup- This makes it difficult to replace selected mechanisms (e.g.,
ports these flexible protocol stacks [2, 18, 38]. acknowledgment or retransmission schemes) and measure
The ADAPTIVE architecture we are developing extends the performance impact precisely. The ADAPTIVE proto-
prior research on flexible transport system architectures. In col development process, on the other hand, explicitly em-
particular, ADAPTIVE employs techniques from categories ploys measurement as part of its iterative, feedback-driven
4 (efficient implementations), 5 (lightweight and adaptive methodology, which consists of: (1) transport system ses-
protocol designs), and 6 (alternative transport system archi- sion specification and configuration, (2) experimentation, (3)
tectures), with particular emphasis on flexible and modular analysis of the results, and (4) using feedback from (3) to re-
software. fine (1).
(C) Focus on Both Policies and Mechanisms: Related Monitoring and measuring the performance of different
work on transport systems typically focuses on providing in- transport system configurations provides feedback on the
frastructure mechanisms (e.g., buffering, acknowledgment, consequences of selecting between alternative policies and

Host Operating System

UNITES Metric Data (UMD)
UNITES Interface (UI)
TMC
ACD
UMD
MANTTS-API
A
UI Application
UMD TSA
D
U M
N
Notification
A A
I
T UMD
TSA Data N
T
P
E UI TKO MANTTS-TSI T T
S S
UMD
SCS
I
V

Application Data

Application Data
UMD
NSE
E
Network
UI Interface MANTTS-NMI
UMD Remote
MANTTS
Data

Network
other hosts

Figure 1: ADAPTIVE Architecture

mechanisms [28]. In addition, certain metric information anisms to form an executable session object representation
(e.g., packet loss and round-trip delay, CPU load, and mem- that guides the actions of an interpreter that performs pro-
ory utilization) may be used at run-time to determine when tocol processing activities on PDUs flowing throughout the
to reconfigure the transport system mechanisms. Other met- transport system. Section 4.2 further describes TKO.
rics for monitoring and measuring transport systems include
throughput, response time, jitter, connection establishment UNITES (“UNIform Transport Evaluation Subsys-
time, and number of packet retransmissions [39]. Section 4.3 tem”): UNITES supports network traffic monitoring, met-
describes measurement issues in greater detail. ric selection/collection/analysis/presentation, and perfor-
mance measurement. In addition to enabling meaning-
ful comparisons between different session configurations,
4 Design of the ADAPTIVE System UNITES provides feedback that assists MANTTS and TKO
in determining when and how to dynamically alter certain
This section describes the architecture of the ADAPTIVE mechanisms in a session. Section 4.3 further describes
system and examines its major subsystems in detail. As UNITES.
shown by the shaded rectangles in Figure 1, ADAPTIVE’s
three main subsystems are: ADAPTIVE’s architecture is decomposed into these three
subsystems to facilitate the development of fine-grain, “plug-
MANTTS (“Map Applications and Networks To Trans- compatible” components that precisely meet the communi-
port Systems”): MANTTS is responsible for choosing the cation requirements of distributed applications. The follow-
appropriate set of policies and mechanisms to meet an appli- ing sections describe each ADAPTIVE subsystem in detail.
cation’s quality-of-service (QoS) requirements (quality-of- Details of the interface to the native transport/operating sys-
service requirements involve both “qualitative” and “quan- tem are excluded for clarity.
titative” factors). MANTTS negotiates with remote hosts
and intermediate switching nodes, taking into account the
dynamically changing network environment. It transforms 4.1 MANTTS
the QoS requirements into a specification of the policies and
MANTTS (“Map Applications and Networks To Transport
mechanisms that comprise a transport system session config-
Systems”) manages various resources (e.g., message buffers,
uration. Section 4.1 further describes MANTTS.
control blocks for open sessions, and available communi-
TKO (“Transport Kernel Objects”): TKO synthesizes cation ports) and services (e.g., protocol mechanisms pro-
a customized lightweight transport system session configura- viding session configuration and reconfiguration support)
tion composed of reusable components selected from a pro- on ADAPTIVE host systems and intermediate switching
tocol mechanisms repository. TKO instantiates these mech- nodes. For instance, MANTTS coordinates multiple re-

lated communication sessions (e.g., determining the schedul- a “blueprint” that specifies a set of protocol mecha-
ing priorities of synchronized multimedia streams), guides nisms that implement the selected TSC policies. The
the “requirement-driven” transformation process that synthe- SCS is based upon information regarding static and dy-
sizes transport system session configurations, and monitors namic network characteristics, along with information
the network to detect and respond to dynamic changes in obtained from negotiating with remote application and
traffic conditions. MANTTS entities and intermediate switching nodes.
MANTTS is involved in several phases of communication Stage III: The mechanisms specified by the SCS
including: (1) the connection negotiation and configuration are automatically synthesized by the Transport Ker-
phase (where it coordinates the initial session configuration), nel Objects (TKO) subsystem. TKO dynamically com-
(2) the data transfer phase (where it coordinates the reconfig- poses and instantiates customized session configura-
uration process), and (3) the connection termination phase tions. When executed on incoming and outgoing PDUs,
(where it releases resources and recalculates transport sys- these configurations are designed to deliver the re-
tem load information). The activities undertaken during each quested communication service to applications.
phase are discussed below. The remainder of this section describes each stage of the
transformation process in greater detail.
4.1.1 The Connection Negotiation and Configuration Stage I – Transport Service Class Selection: During
Phase the first transformation stage, MANTTS selects a trans-
port service class (TSC) that corresponds to the application-
MANTTS is responsible for interactively negotiating the re-
specified communication requirements. As shown in Table 1,
quested QoS requirements when an application initiates a
TSCs represent general classes of application requirements
connection. Negotiation occurs between the local and re-
such as interactive isochronous traffic (e.g., voice conver-
mote application and MANTTS entities, as well as the inter-
sation), distributional isochronous traffic (e.g., full-motion
mediate switching nodes. The negotiation phase determines
HDTV), non-isochronous real-time traffic (e.g., robotics and
the QoS that the transport system is capable of providing at
manufacturing control), and non-isochronous, non-real-time
the current time. Negotiation may be necessary if the QoS
traffic (e.g., file transfer, remote login, and RPC) [6]. Each
requested by the application is not available. However, nego-
TSC embodies a set of related policy decisions that satisfy
tiation need not determine an optimal configuration, as long
the application’s QoS requests.
as it produces one that meets the application’s requirements
Applications may explicitly select a TSC to help simplify
(which may have a range of tolerance). If the negotiation
the subsequent transport system session configuration pro-
is satisfactory to the participating applications and transport
cess. TSCs embody a set of default parameters, mecha-
systems, the local and remote session configurations are in-
nisms, and/or representations, thereby requiring the negotia-
stantiated (as described in Stage III below). If the negotia-
tion of only a subset of these entities. Simplifying and reduc-
tion/transformation is unsuccessful, on the other hand, (e.g.,
ing the configuration delay is important, since the benefits
due to resource limitations or network partitioning), there are
of a dynamically configured architecture are reduced if the
two alternatives: (1) refuse the connection and (2) allow the
configuration and/or reconfiguration process is overly time-
application to re-negotiate at a lower quality of service.
consuming.
In general, the negotiation process is based upon factors
The MANTTS Application Programmatic Interface
like the current network state and traffic volume, interme-
(MANTTS-API) provides the user interface for the ADAP-
diate switching node queue lengths, host processing loads,
TIVE system. For example, when an application initi-
and services available at the remote hosts. Local and remote
ates a connection it passes application communication de-
MANTTS entities negotiate three basic categories: (1) pa-
scriptor (ACD) via the MANTTS-API. As shown in Ta-
rameters (e.g., buffer space, initial window advertisements
ble 2, ACDs specify several types of information including
and scaling factors [40], segment size and maximum trans-
the remote session participant address(es), qualitative and
mission unit (MTU) size, priorities for message delivery and
quantitative quality-of-service parameters, and metric col-
scheduling, and timer settings for delayed acknowledgments
lection and reconfiguration requests. Multiple remote ad-
and retransmissions), (2) mechanisms (e.g., reliability man-
dresses are necessary if multicast service is requested. Par-
agement and transmission management mechanisms), and
ticipant addresses indicate certain characteristics of interme-
(3) representations (e.g., fixed-size vs. variable-sized buffer
diate switching nodes and remote end systems such as avail-
management).
able bandwidth, MTU, latency, and bit error rates. Knowl-
As shown in Figure 2, MANTTS configures a transport
edge of these characteristics enables MANTTS to determine
system session on behalf of the application via the following
more appropriate policies and mechanisms. Duration is an
three-stage transformation process:
important quantitative QoS parameter for digital continuous
Stage I: MANTTS transforms the QoS requirements media (DCM) sessions [41]. It is an essential configuration
into an appropriate set of policies known as a Trans- parameter for ADAPTIVE, since it is not generally useful to
port Service Class (TSC) (TSCs are described further dynamically reconfigure sessions that have very low dura-
below). tion.
Stage II: MANTTS then transforms the TSC into a Stage II – Session Configuration Specification: During
Session Configuration Specification (SCS). The SCS is the second stage of configuration, MANTTS transforms the

MANTTS Application
Address(es), Sequencing ,
Datum Size, Delay, MANTTS-API
Throughput, Jitter, Reliability
Application
Communication Error Detection,
Descriptor Error Recovery, TKO
TK_ChecksumA,
(ACD) Transmission Control
TK_Selective_Repeat
TK_Block_Rate_Control

Transport Transport System Transport
Service Configuration Kernel
Class MANTTS-TSI
Specification Object
(TSC) (TSCS) Instantiation

Network CBR Video, VBR Video,
Characteristic Terminal IO, Voice,
Descriptor Bulk Data Transfer
(NCD) Network
MTU Size, Latency, MANTTS-NMI Interface
BER, Packet Loss Rate

Figure 2: MANTTS Transformation Model

Parameter Name Description Example Specifiers
Remote Session
Specifies addresses of remote end-systems
Participant Address(es) that comprise the communication association.
Quantitative Specifies the performance criteria Peak and average throughput, minimum and maximum latency and jitter
QoS Parameters requested by the application. error-rate probabilities, duration, etc.
Qualitative Specifies the functionality of behavior Sequenced/non-sequenced delivery, duplicate sensitivity, explicit/implicit
QoS Parameters requested by the application. connection management, (byte/packet/block)-based transmission and acknowledgment.
Transport Service Actions to perform when changes occur in condition, action pairs that indicate the actions to perform when certain
Adjustment (TSA) local or remote hosts or the network. conditions are true.
Transport Measurement Specifies performance metrics to collect Parameter selection, sampling rate, presentation format, etc.
Component (TMC) for this particular communication session.

Table 2: The ADAPTIVE Communication Descriptor Format

selected TSC into a corresponding session configuration 2. Explicit Negotiation: When an application requests
specification (SCS). The resulting SCS represents a set of either explicit connection management and/or peer-to-peer
protocol mechanisms that implement the policies embod- negotiation, the initiating local MANTTS entity uses an out-
ied in the TSC. MANTTS produces the SCS by reconcil- of-band signaling channel to exchange and negotiate config-
ing the TSC with the network characteristics associated with uration parameters with remote MANTTS entities. Out-of-
the indicated remote addresses. A network state descrip- band signaling helps to optimize the main data transfer path,
tor maintained by the MANTTS Network Monitor Interface since this path does not interpret packets containing control
(MANTTS-NMI) samples, records, and estimates the cur- information [31].
rent state of dynamic network characteristics. Figure 3 illustrates the separate control and data paths used
The initial configuration of a transport system session in by signaling and data units during the negotiation process
an ADAPTIVE host may choose between one of two alter- and subsequent data transfer. The additional time spent ne-
natives: gotiating QoS should improve the overall performance for
longer-duration, high-bandwidth connections, since the re-
1. Implicit Negotiation: MANTTS supports implicit sulting configurations more accurately reflect the application
connection management, where configuration information is requirements and network characteristics [31]. Moreover,
piggybacked along with the application’s first PDU. This the negotiation process may be combined with explicit con-
is useful for latency-sensitive applications (e.g., “request- nection management that occurs during the initial 2-way or
response”-style network file servers) that must not incur any 3-way handshake. This allows local configuration activities
QoS negotiation delay. To support implicit negotiation, re- to proceed in parallel with remote negotiation activities.
mote MANTTS entities must supply reasonable values for
default configurations. Stage III – Transport System Synthesis: In the third
Longer-duration applications may also choose implicit ne- stage of configuration, MANTTS submits the session con-
gotiation, since eliminating the multiple round-trip “hand- figuration specification (SCS) to the Transport Kernel Ob-
shake” overhead is beneficial for sessions running over long- ject (TKO) subsystem via the MANTTS Transport System
delay links [1]. If necessary, it is possible to reconfigure an Interface (MANTTS-TSI). TKO transforms the SCS into a
active session dynamically at a later point, using the renego- transport system session configuration, which is customized
tiation mechanisms described in Section 4.1.2 below. for the particular applications and networks involved. This

long-duration connection switches to a high-delay path (e.g.,
HOST OS A HOST OS B if intermediate node failures cause routes to change from a
UNITES Interface (UI) UNITES Interface (UI) terrestrial link to a satellite link), it may become necessary to
UI Application MANTTS MANTTS Application UI
reconfigure certain mechanisms such as the retransmission
API
A A
API
scheme or window scaling options.
U M D D M U
N A A A A N During reconfiguration, one of the following actions oc-
I N P P N I
T UI TKO MANTTS
TSI
T T T T MANTTS
TSI
TKO UI T curs:
E T I I T E
S S V V S S
E E Adjust the TSC: change the Transport Service Class
UI
Network
Subsystem
MANTTS
NMI
MANTTS
NMI
Network
Subsystem
UI to provide a QoS that is more suitable to the new conditions
(e.g., benefitting an application that has changed video cod-
ing schemes and now requires isochronous service). This
MANTTS Configuration/Negotiation Signaling
change potentially generates a completely new or partially
Application Data
NETWORK
modified SCS.
Adjust the SCS: replace or adjust one or more param-
Figure 3: Connection Configuration eters or mechanisms used by the transport system to compen-
sate for the indicated change (e.g., increase the inter-PDU
gap used by the rate control mechanism in response to per-
final transformation stage involves (1) synthesizing the spec- ceived network congestion). In this case, no change occurs
ified protocol mechanisms (e.g., buffer management, trans- in the corresponding TSC.
mission control, and reliability management) from the TKO
Application-Specific: notify the application when
class repository, (2) instantiating an executable representa-
changes occur in operating conditions (e.g., a reduction in re-
tion that is used by a protocol interpreter to invoke opera-
ceiver’s buffer space) via a call-back mechanism that allows
tions on PDUs in the appropriate order, and (3) instrumenting
it to react appropriately (e.g., begin transmitting data using
the dynamically synthesized mechanisms using the UNITES
an application-specific compression or component coding
measurement facilities to satisfy the application’s metric col-
scheme).
lection requests. Instrumentation is based on both applica-
tion requests and global UNITES metric collection requests.
Section 4.2 describes the TKO subsystem in detail; Sec- 4.1.3 Connection Termination Phase
tion 4.3 describes the UNITES subsystem in detail.
There are several different types of connection termination
semantics supported by ADAPTIVE, including graceful (i.e.,
4.1.2 Data Transfer and Reconfiguration Phase no loss of buffered data) and non-graceful (i.e., potential loss
The ADAPTIVE architecture adapts to dynamic changes in of buffered data). In addition to shutting down the commu-
application requirements and network characteristics by ex- nication channel, the termination phase provides an opportu-
plicitly and/or implicitly reconfiguring transport system ses- nity for MANTTS to release allocated resources and recal-
sions. The reconfiguration process is similar to the initial culate transport system load information. Both explicit and
configuration process, and may involve decreasing or in- implicit connection termination is supported.
creasing the QoS.
Explicit reconfiguration is initiated by a local or remote 4.2 TKO
application request such as changing from unicast to multi-
cast communication or requesting a higher or lower quality The TKO (“Transport Kernel Objects”) subsystem provides
of service. Remote MANTTS entities are notified if a new a modular and extensible framework for configuring and re-
SCS must be generated to satisfy the request, and the cor- configuring transport systems sessions. Modularity enhances
responding transport system session configurations are up- transport system flexibility by providing uniform interfaces
dated. Explicit reconfiguration requests are sent via the same for “plug-compatible” protocol and session processing com-
out-of-band signaling channel used for connection negotia- ponents. Extensibility enhances transport system adaptivity
tion. by permitting the addition of new and/or alternative services
MANTTS automatically detects situations where implicit at run-time. Flexibility and adaptivity, in turn, help support
reconfiguration is necessary. These situations typically occur the diversity and dynamism of applications and networks.
when parameters monitored by MANTTS exceed thresholds As shown in Figure 4, the TKO subsystem consists of
specified by transport system policies. For example, local the two distinct levels of abstraction described below: (1)
or remote MANTTS entities may initiate renegotiation in TKO protocol architecture and (2) TKO session architec-
response to increases or decreases in buffer space, round- ture. Each level performs a well-defined set of services for
trip delay, or changes in processor load. Similarly, changes the transport system. TKO is implemented in C++ since (1)
in network conditions may be detected by the MANTTS C++ integrates context information together with operations
Network Monitor. These conditions include intermediate to support object-oriented design and programming and (2)
switching node failure, lower throughput due to increased C++ directly supports flexibility and adaptivity via inheri-
network congestion, or routing changes. For example, if a tance and dynamic binding. Inheritance is a particularly use-

MANTTS-API Application UI

TK_Context
MANTTS
UI
TSI

Connection Management Remote Context Management Reliability Management Transmission Management
M Mechanism Family Mechanism Family Mechanism Family Mechanism Family U
A N
N I
T T
T E
S S

Application Data
Error
Error Recovery Error
Detection Reporting
Implicit Transmission Stop
Explicit Rate
Timer Periodic Based Sliding and
Hand Based
Based Window Wait
Shake Control

Bit-Error
Detection
Gap/Duplicate Forward
Go
Detection Error
Back Selective
Correct Ignore Selective
Damaged N Repeat
NACK
PDUs
Selective
Cumulative ACK
TKO Manager Abstract Base Classes ACK
TKO Manager Composite Components
TKO Manager Concrete Derived Classes
TKO
MANTTS-NMI Network Subsystem UI

Figure 4: TKO Protocol and Session Architectures

ful technique for maximizing sharing, reuse, and extensibil- copying when (1) moving messages between protocol lay-
ity of TKO components. ers and (2) when adding or deleting message headers
and trailers. The TKO Message class provides uniform
interfaces for services that create, copy, prepend, and
4.2.1 TKO OS Protocol Architecture: split messages. TKO Message objects are logically di-
The TKO protocol architecture is a repository of “medium- vided into two distinct regions: the header and the data.
granularity” C++ classes that insulate the transport sys- The data region efficiently supports “lazy copying” op-
tem from the underlying operating system environment. erations, as well as handling message fragmentation and
The ADAPTIVE TKO protocol architecture design is in- reassembly. Likewise, the header region allows opera-
fluenced by the x-kernel [7] and Conduit [18] communi- tions that efficiently prepend header information onto a
cation systems. The TKO protocol architecture classes message (TKO Message::push) and later strip it off
provide uniform interfaces for accessing protocol support (TKO Message::pop).
services such as timers, message buffering, and protocol TKO Protocol: Conventional protocol suites are spec-
graph operations that insert, delete, and/or alter protocol ob- ified as a hierarchy of layers, where each layer performs
jects. There are four fundamental TKO protocol architecture well-defined services for layers above it, while making use
classes: TKO Event, TKO Message, TKO Protocol of services from layers below it. The TKO Protocol class
and TKO Session: provides uniform interfaces for protocol objects used to com-
pose protocol suites like TCP/IP, OSI, and XNS. The service
TKO Event: Many protocols must respond to tem- interface for TKO Protocol objects provides (1) manage-
poral events such as retransmission timer expiration ment operations for manipulating “protocol graphs” (which
or periodic update requests [42]. The TKO Event express the relationships between various protocol objects)
class provides event management operations such as and (2) operations that create, destroy, and demultiplex
TKO Event::schedule, TKO Event::expire, and and multiplex messages to TKO Session objects. Each
TKO Event::cancel. TKO Event objects schedule TKO Protocol object contains 0 or more TKO Session
themselves to expire one or more times (i.e., they are “one- objects.
shot” or periodic), they may be cancelled, and they are trig-
gered to expire asynchronously by the operating system’s TKO Session: The TKO Session class forms the
timer facility. junction between the TKO protocol architecture and TKO
session architecture services (as shown in Figure 4).
TKO Message: Performance measurements indicate TKO Session objects encapsulate certain context informa-
that memory-to-memory copying is a significant source of tion (e.g., local and remote addresses) needed to correctly
transport system overhead [43]. Therefore, some form and efficiently process a session’s incoming and outgoing
of buffer management is required to avoid unnecessary messages. Associated with this context information are oper-

ations used for (1) sending and receiving TKO Message ob-
jects that flow through TKO Session objects, (2) dynamic Application UI
MANTTS-API

session attachment (i.e., allocating and linking together new
TK_Context
sessions to form session graphs), and (3) dispatching sys- MANTTS
TSI
UI

tem calls that store and/or retrieve session control informa-
Connection Management Remote Context Management Reliability Management Transmission Management
tion (e.g., determining host and peer network addresses or M
A
Mechanism Family Mechanism Family Mechanism Family Mechanism Family U
N
N I
determining the MTU for a given network interface). T
T
T
E
S S

Application Data
Error
Error Recovery Error

These four fundamental classes provide the infrastructure Implicit
Explicit Transmission
Detection Reporting

Stop Rate
Timer Periodic Sliding
that supports the TKO session architecture services de- Based Hand
Shake
Based
Window
and
Wait
Based
Control

scribed below. Bit-Error
Detection
Gap/Duplicate Forward
Go
Detection Error
Back Selective
Correct Ignore Selective
Damaged N Repeat
NACK

4.2.2 TKO Session Architecture TKO Manager Abstract Base Classes
PDUs
Selective
Cumulative ACK
ACK

TKO Manager Composite Components
Like the TKO protocol architecture, the TKO session archi- TKO Manager Concrete Derived Classes
TKO
tecture is designed as a repository of reusable C++ trans-
MANTTS-NMI Network Subsystem UI

port system mechanisms. However, each component in
the TKO session architecture repository encapsulates “finer-
grain” mechanisms associated with session activities such as
connection management, transmission control, and reliabil- Figure 5: TKO Context
ity management. The remainder of this section describes the
organization of the primary TKO session architecture com-
ponents, explains how transport system sessions are synthe-
sized and discusses several performance optimization tech- basic session
niques. mechanisms (e.g., Sliding Window is derived from the
To support flexible configuration and reconfiguration, abstract base class Transmission Management). Like-
TKO session architecture is organized as a collection of C++ wise, composite components manage objects of several re-
inheritance hierarchies. As shown in Figure 5, these in- lated subcomponents that interoperate in well-defined ways.
heritance hierarchies are “rooted” at abstract base classes For example, the Reliability Management compos-
that provide uniform interfaces for session activities. Spe- ite component in Figure 5 performs error detection, error re-
cialized instances of these mechanisms are derived from porting, and error recovery. Composite components are ef-
an appropriate abstract base class and combined to form ficiently replaced and recombined in their entirety, thereby
complete session configurations. Two TKO SA compo- minimizing run-time overhead.
nents, TKO Context and TKO Synthesizer, manage
and maintain these mechanisms as described below: TKO Synthesizer: The TKO Synthesizer is respon-
TKO Context: Figure 4 depicts how each sible for overseeing the configuration and reconfiguration
TKO Session object points to one or more TKO Context of TKO Context objects. As shown in Figure 5, the
objects that are customized for the associated application’s synthesizer receives the session configuration specification
QoS requirements. As shown in Figure 5, TKO Context (SCS) from the MANTTS-TSI and transforms it into an ef-
objects possess several different types of components that (1) ficient, lightweight TKO Context session instantiation. A
provide functions to perform certain session activities (e.g., TKO Synthesizer is also responsible for instrumenting
connection management, reliability management, and trans- and monitoring the transport system session resources spec-
mission management) and (2) maintain context information ified in Transport Measurement Component.
(e.g., round-trip time estimates, sequence numbers, or flow The TKO Synthesizer permits fine-grain, per-session
control window advertisements) necessary to support these control over its associated TKO Context bindings by in-
functions. This encapsulation of context and functions facil- stantiating entries in the TKO Context table at either
itates rapid prototyping and incremental protocol develop- configuration-time or run-time. In the latter case, the
ment. TKO Synthesizer coordinates dynamic session recon-
Each TKO Context object contains a table of pointers to figuration by re-instantiating the updated session mecha-
C++ abstract base classes that define the session’s behavior. nism(s). For instance, each class object provides a means for
Table entries point to objects that are either concrete derived replacing itself with a different class object via the segue
subclasses or composite components. Complete session ob- mechanism supplied in all abstract base classes. Segue sup-
jects are synthesized by composing and instantiating con- ports reconfiguration by permitting certain class object bind-
crete derived subclasses and composite components that are ings to change dynamically. This approach differs from the
appropriate for the specified application requirements and BSD 4.3 UNIX network architecture, where protocol oper-
network characteristics. ators are statically bound to session control blocks through
Concrete derived subclasses are formed by selectively in- pointers to C functions. In the BSD scheme, all sessions as-
heriting certain context information and functions from ex- sociated with a particular protocol object use the same bind-
isting abstract base classes. These subclasses “specialize” ings, which are fixed at link-time and do not change.

4.3 UNITES
HOST A HOST B

UNITES Interface (UI) UNITES Interface (UI)
The UNITES (“Uniform Transport and Evaluation Subsys-
tem”) subsystem facilitates transport system protocol exper-
UNITES UNITES
MI Application
API API
Application MI imentation by coordinating metric specification, metric col-
M U U M lection, metric analysis, and metric presentation. A funda-
A N N A mental goal of ADAPTIVE is to provide a framework that
N I UNITES I N
UNITES UNITES
T MI TKO TSI T METRIC T TSI
TKO MI T supports controlled hypothesis testing of different transport
T E REPOSITORY E T
S S S S system session configurations. For example, we are cur-
rently experimenting with alternative protocol design config-
MI
Network
Subsystem
UNITES
NMI
UNITES
NMI
Network
Subsystem
MI urations to determine those that best serve particular pairings
of multimedia application requirements and underlying net-
work characteristics. Information collected by the UNITES
metrics quantifies trade-offs and interactions among differ-
NETWORK
ent configurations, thereby providing meaningful design and
implementation evaluations.
UNITES metrics are divided into two classes: blackbox
Figure 6: UNITES Architecture and whitebox. These classes differ depending on whether or
not the metric collection mechanisms require internal instru-
mentation of transport system session configurations. Both
TKO session architecture flexibility is supported by the blackbox and whitebox metrics assist the tuning of transport
C++ “virtual function” dynamic binding mechanism [44]. system configurations by quantifying the performance con-
Although dynamic binding enhances flexibility (and thereby sequences of certain design and implementations decisions.
facilitates prototyping and experimentation), it increases pro- Blackbox metrics are collected without knowledge of in-
cessing overhead somewhat due to the extra level of indi- ternal implementation details. They include throughput (de-
rection required to dispatch C++ virtual functions. To re- fined as the number of packets transmitted per second) and
duce this overhead, TKO employs a technique known as latency (defined as the packet round-trip time for interactive
customization [45], which generates non-dynamically bound traffic). Whitebox metrics, on the other hand, require in-
configurations for circumstances where performance is more ternal instrumentation of the session configurations. These
important than flexibility. Customization incurs a time- metrics include connection establishment and termination la-
space tradeoff, however, since inline expansion of many cus- tency, number of packet (re)transmissions, the number of in-
tomized kernel objects may lead to excessive “code bloat” structions required to execute a protocol function, interrupt
(see [46] for a discussion of a similar problem with the Syn- and scheduling overhead, the degree of jitter (defined as the
thesis Kernel). variance in
In addition, the TKO session architecture maintains a the delay), and packet loss. Collecting white-box metrics
cache of customized “TKO Templates” that further op- is very difficult without a development and testing environ-
timize the instantiation process. TKO Templates pro- ment like ADAPTIVE that supports controlled experimenta-
vide default transport system session configurations for com- tion.
monly requested SCSs. These templates reduce the com- As illustrated in Figure 6, the UNITES Metric Reposi-
plexity and duration of the connection negotiation phase. tory stores the collected metric information in a database. A
There are two general types of TKO Templates: repository is necessary when many active connections are in-
strumented and monitored, since too much data is generated
1. Static Templates are guaranteed not to change. This al- to collect and process in real-time [28]. Users can access this
lows more efficient implementation, since the mecha- information in various ways, including interactive graphic
nisms may be completely customized (e.g., inline ex- displays or standard network management protocols such as
panded rather than dynamically dispatched). Static tem- SNMP or CMIP. This metric data is presented in either a
plates are also used to implement backward compatibil- systemwide, per-host, or per-connection manner. UNITES
ity with existing protocols like TCP. monitors transport system sessions in two primary ways:
1. Application programs use the Transport Measurement
2. Reconfigurable Templates may change at some point Component parameter in the ADAPTIVE Communica-
during the communication session. Although this ap- tion Descriptor to indicate metrics they want UNITES
proach is generally more flexible, it is also less efficient to collect. The TKO subsystem then selectively instru-
since additional indirection is required (though not as ments the synthesized configurations and the metrics
much as is needed by a dynamically synthesized con- are automatically collected by UNITES at run-time.
figuration). 2. To support experimentation, metrics also may be re-
quested using either a graphics-based or language-
If a pre-assembled TKO Template does not exist to match based interface. Sjodin et al.’s work is an example of
an SCS request, TKO session architecture is responsible for a language-based approach [39]. They define a speci-
dynamically synthesizing one [46]. fication language that indicates what measurements to

collect and what traffic to generate. Figure 6 shows a [6] M. Zitterbart, B. Stiller, and A. Tantawy, “A Model for Flex-
graphical interface for specifying certain metrics to col- ible High-Performance Communication Subsystems,” Tech.
lect on a per-host basis. Rep. TC 17801 (78023), IBM Research Division, February
1992.
[7] N. C. Hutchinson and L. L. Peterson, “The x-kernel: An Ar-
5 Summary chitecture for Implementing Network Protocols,” IEEE Trans-
actions on Software Engineering, vol. 17, pp. 64–76, January
Adequately supporting next-generation multimedia applica- 1991.
tions necessitates transport systems that tailor their services
[8] D. C. Schmidt and T. Suda, “Transport System Architecture
to precisely meet the communication requirements of both
Services for High-Performance Communications Systems,”
applications and high-performance networks. ADAPTIVE
IEEE Journal on Selected Areas in Communication, vol. 11,
is a flexible and adaptive transport system architecture de- pp. 489–506, May 1993.
signed to provide these services.
ADAPTIVE provides (1) support for application and net- [9] H. Kanakia and D. R. Cheriton, “The VMP Network Adapter
work diversity and dynamism, (2) reduction in transport sys- Board (NAB): High-Performance Network Communication
tem overhead, (3) focus on both policies and mechanisms, for Multiprocessors,” in Proceedings of the Symposium on
and (4) feedback-guided monitoring and measurement. In Communications Architectures and Protocols (SIGCOMM),
particular, ADAPTIVE’s flexible software architecture fa- (Stanford, CA), pp. 175–187, ACM, Aug. 1988.
cilitates an “experimentation-based” protocol development [10] R. W. Watson and S. A. Mamrak, “Gaining Efficiency in
methodology. ADAPTIVE enables precise measurement Transport Services by Appropriate Design and Implemen-
of application and network performance changes that result tation Choices,” ACM Transactions on Computer Systems,
from selectively modifying certain transport system mecha- vol. 5, pp. 97–120, May 1987.
nisms (e.g., measuring the effect of switching from implicit [11] D. D. Clark, “Modularity and Efficiency in Protocol Imple-
to explicit connection management or from selective repeat mentation,” Network Information Center RFC 817, pp. 1–26,
to go-back-n retransmission). July 1982.
We are currently designing and implementing a prototype
[12] S. J. Leffler, M. McKusick, M. Karels, and J. Quarterman, The
implementation of ADAPTIVE. This prototype is written in
Design and Implementation of the 4.3BSD UNIX Operating
C++, and is hosted on both the x-kernel and System V release
System. Addison-Wesley, 1989.
4 STREAMS. We are using the prototype to experiment with
different transport system configurations that support multi- [13] D. R. Cheriton, “The V Distributed System,” Communications
media applications (e.g., network voice and video) running of the ACM, vol. 31, March 1988.
on several different networks (e.g., Ethernet, Tree Network [14] R. V. Renesse, H. V. Staveren, and A. S. Tanenbaum, “Perfor-
[47], DQDB, and FDDI). mance of the Amoeba Distributed Operating System,” Soft-
ware – Practice and Experience, vol. 19, pp. 223–234, March
1989.
Acknowledgments [15] M. N. Group, “Network Server Design,” Tech. Rep. CMS-CS-
89-31, Carnegie Mellon University, August 1989.
We would like to thank Hung Huang, Unmesh Rathi, and
Girish Kotmire for their help in designing the ADAPTIVE [16] B. B. Welch, “The Sprite Remote Procedure Call System,”
system and for proof-reading earlier drafts of this paper. Tech. Rep. UCB/CSD 86/302, Computer Science Division
(EECS), University of California, Berkeley, CA 94720, June
1986.
References [17] UNIX Software Operations, UNIX System V Release 4 Pro-
[1] T. F. L. Porta and M. Schwartz, “Architectures, Features, and grammer’s Guide: STREAMS. Prentice Hall, 1990.
Implementation of High-Speed Transport Protocols,” IEEE [18] J. M. Zweig, “The Conduit: a Communication Abstraction in
Network Magazine, pp. 14–22, May 1991. C++,” in Proceedings of the 2nd USENIX C++ Conference,
[2] S. W. O’Malley and L. L. Peterson, “A Dynamic Network Ar- pp. 191–203, USENIX Association, April 1990.
chitecture,” ACM Transactions on Computer Systems, vol. 10, [19] T. F. L. Porta and M. Schwartz, “Design, Verification, and
pp. 110–143, May 1992. Analysis of a High Speed Protocol Parallel Implementation
[3] Z. Haas, “A Protocol Structure for High-Speed Communi- Architecture,” in Proceedings of the First IEEE Workshop
cation Over Broadband ISDN,” IEEE Network Magazine, on the Architecture and Implementation of High Performance
pp. 64–70, January 1991. Communication Subsystems, Feb. 1992.
[4] M. Zitterbart, “High-Speed Protocol Implementations Based [20] G. Chesson, “XTP/PE Design Considerations,” in Proceed-
on a Multiprocessor-Architecture,” in Proceedings of the 1st ings of the 1st International Workshop on High-Speed Net-
International Workshop on High-Speed Networks, pp. 151– works, May 1989.
163, May 1989. [21] D. R. Cheriton, “VMTP: Versatile Message Transaction Pro-
[5] J. Crowcroft, I. Wakeman, Z. Wang, and D. Sirovica, “Is Lay- tocol Specification,” Network Information Center RFC 1045,
ering Harmful?,” IEEE Network Magazine, January 1992. pp. 1–123, Feb. 1988.

[22] D. F. Box, D. C. Schmidt, and T. Suda, “Alternative Ap- [38] D. D. Clark, “The Structuring of Systems Using Upcalls,”
proaches to ATM/Internet Interoperation,” (Tucson, Arizona), in Proceedings of the 10th Symposium on Operating System
pp. 1–5, IEEE, 1992. Principles, (Shark Is., WA), 1985.
[23] V. Jacobson, R. Braden, and L. Zhang, “TCP Extensions for [39] P. Gunningberg, M. Bjorkman, E. Nordmark, S. Pink,
High-Speed Paths,” Network Information Center RFC 1185, P. Sjodin, and J.-E. Stromquist, “Application Protocols and
pp. 1–21, October 1990. Performance Benchmarks,” IEEE Communications Maga-
[24] G. Blair, G. Coulson, F. Garcia, D. Hutchinson, and zine, vol. 27, pp. 30–36, June 1989.
D. Shepherd, “Towards New Transport Services to Support [40] V. Jacobson and R. Braden, “TCP Extensions for Long-Delay
Distributed Multimedia Applications,” in 4th IEEE Com- Paths,” Network Information Center RFC 1072, pp. 1–16, Oct.
Soc International Workshop on Multimedia Communications, 1988.
(Monterey, California), pp. 250–259, IEEE, 1992.
[41] J. C. Pasquale, G. C. Polyzos, E. W. Anderson, K. R. Fall, J. S.
[25] T. Plagemann, B. Plattner, M. Vogt, and T. Walter, “A Model Kay, V. P. Kompella, S. R. McMullan, and D. Ranganathan,
for Dynamic Conﬁguration of Light-Weight Protocols,” in “Network and Operating System Support for Multimedia Ap-
IEEE Third Workshop on Future Trends of Distributed Sys- plications,” Tech. Rep. CS-91-186, University of California,
tems, pp. 1–9, IEEE, 1992. San Diego, 1990.
[26] B. Heinrichs, “Versatile Protocol Processing for Multimedia [42] A. N. Netravali, W. D. Roome, and K. Sabnani, “Design and
Communications,” in 4th IEEE ComSoc International Work- Implementation of a High Speed Transport Protocol,” IEEE
shop on Multimedia Communications, (Monterey, California), Transactions on Communications, 1990.
pp. 160–169, IEEE, 1992.
[43] D. D. Clark and D. L. Tennenhouse, “Architectural Consid-
[27] G. Parulkar and J. Turner, “Towards a Framework for High
erations for a New Generation of Protocols,” in Proceedings
Speed Communication in a Heterogeneous Networking Envi-
of the Symposium on Communications Architectures and Pro-
ronment,” IEEE Network, March 1990.
tocols (SIGCOMM), (Philadelphia, PA), pp. 200–208, ACM,
[28] R. C. Albert Li, A. Fawaz, S. Sachs, P. Varaiya, and J. Wal- Sept. 1990.
rand, “The Programmable Network Prototyping System,”
IEEE Computer, vol. 22, pp. 67–76, May 1989. [44] Bjarne Stroustrup and Margret Ellis, The Annotated C++ Ref-
erence Manual. Addison-Wesley, 1990.
[29] L. Peterson and S. O’Malley, “TCP Extensions Considered
Harmful,” Network Information Center RFC 1263, pp. 1–19, [45] C. Chambers and D. Ungar, “Customization: optimizing
1991. compiler technology for SELF (a dynamically-typed object-
oriented language),” in Proc. SIGPLAN, ACM, 1989.
[30] C. Tschudin, “Flexible Protocol Stacks,” in Proceedings of
the Symposium on Communications Architectures and Proto- [46] C. Pu, H. Massalin, and J. Ioannidis, “The Synthesis kernel,”
cols (SIGCOMM), (Zurich Switzerland), pp. 197–205, ACM, Computing Systems, vol. 1, pp. 11–32, Winter 1988.
Sept. 1991. [47] H. K. Huang, T. Suda, and Y. Noguchi, “LAN With Collision
[31] W. Doeringer, D. Dykeman, M. Kaiserswerth, B. Meister, Avoidance: Switch Implementation and Simulation Study,”
H. Rudin, and R. Williamson, “A Survey of Light-Weight in Proceedings of the 15th Conference on Local Computer
Transport Protocols for High-Speed Networks,” IEEE Trans- Networks, 1990.
actions on Communication, vol. 38, pp. 2025–2039, Novem-
ber 1990.
[32] E. C. Cooper, P. A. Steenkiste, R. D. Sansom, and B. D. Zill,
“Protocol Implementation on the Nectar Communication Pro-
cessor,” in Proceedings of the Symposium on Communications
Architectures and Protocols (SIGCOMM), (Philadelphia, PA),
pp. 135–144, ACM, Sept. 1990.
[33] D. D. Clark, V. Jacobson, J. Romkey, and H. Salwen, “An
Analysis of TCP Processing Overhead,” IEEE Communica-
tions Magazine, vol. 27, pp. 23–29, June 1989.
[34] D. D. Clark, M. L. Lambert, and L. Zhang, “NETBLT: A Bulk
Data Transfer Protocol,” Network Information Center RFC
998, pp. 1–21, Mar. 1987.
[35] R. W. Watson, “The Delta-t Transport Protocol: Features and
Experience,” in Proceedings of the 1st International Work-
shop on High-Speed Networks, May 1989.
[36] D. R. Cheriton and C. L. Williamson, “VMTP as the Trans-
port Layer for High-Performance Distributed Systems,” IEEE
Communications Magazine, vol. 27, pp. 37–44, June 1989.
[37] J. Jain, M. Schwartz, and T. Bashkow, “Transport Protocol
Processing at GBPS Rates,” in Proceedings of the Sympo-
sium on Communications Architectures and Protocols (SIG-
COMM), (Philadelphia, PA), pp. 188–199, ACM, Sept. 1990.

ADAPTIVE

More Related Content

What's hot (18)

Viewers also liked (20)

Similar to ADAPTIVE (20)

More from Videoguy (20)

ADAPTIVE