Research Summary for PERC

1
Research Summary for PERC

• Jennifer C. Hou
• Department of Computer Science
• University of Illinois at Urbana Champaign
• Urbana, IL 61801
• Jhou_at_cs.uiuc.edu

2
Project Overview

• QoS framework for QoS-driven shared tree
  multicast routing
• Exploitation of long range dependency on Internet
  resource/traffic control
• JavaSim Large-scale network simulation and
  emulation
• Software architecture for communication
  middleware
• Protocol development for data-centric sensor
  networks

3
QoS-driven shared tree multicast routing
4
Multicast-Related Research

• QoS-Driven Multicast Routing
• QoS extension (in member join/leave and state
  update/refresh procedures) to core-based
  multicast routing protocols to facilitate
  deployment of additive, multiplicative and
  concave QoS.
• Implementation in FreeBSD and Lunix for empirical
  studies.
• Reliable Multicast
• Design and implementation of a repair-based
  reliable multicast framework for core-based
  multicast trees with the objectives of
• Avoidance of NACK explosion and duplicate replies
• Reduction in recovery latency
• Recovery isolation
• Adaptability to dynamic topology/membership
  changes.

• Multicast Congestion Control
• Use of robust, feedback control theory to design
  and implement a rate based congestion control
  framework for multicast w.r.t.
• Scalability.
• Capability to adjust source sending rates to
  achieve TCP-friendliness and fairness in an
  analytically provable manner.
• Capability to handle dynamic membership/traffic
  changes.
• Minimum router support.

5
QoS-Driven Multicast Routing

• QoS considered
• Additive QoS For any path (u,j,k,l,v), the
  end-to-end delay is
• d(u,v) d(u,j)d(j,k)d(l,v).
• Multiplicative QoS Path loss probability,
  p(u,v), satisfies
• 1-p(u,v) (1-p(u,j)) x (1-p(j,k)) x x
  (1-p(l,v)).
• Concave QoS Bandwidth available along a path
• b(u,v) min b(u,j), b(j,k),., b(l,v) .
• A QoS requirement may be specified as
• an upper/lower bound on a QoS parameter
  (end-to-end delay bound).
• an upper bound on the inter-receiver difference
  of a QoS parameter along the paths from a source
  to any two receivers (inter-receiver delay jitter
  bound).

• We devise eligibility tests to verify whether or
  not a new member can join a multicast tree at
  adequate QoS, without violating existing QoS.
• We determine the set of states kept at each
  router in order to conduct eligibility tests.
• We devise a soft-state based state update/refresh
  procedure that can be readily integrated with
  existing routing protocols.
• Based on the CBT daemon developed by British
  Telecom, we implement and empirically evaluate
  the performance.

6
Eligibility Tests
7
Implementation

• We have implemented the QoS extension on FreeBDS
  3.3 UNIX operating system, based on the CBT code
  developed by British Telecom and are currently
  conducting experiments on Internet 2.
• Changes made
• Each interface keeps a linked list of VifGroupQoS
  structures, each element of which associates with
  a multicast group.

• The VifGroupQoS structure keeps the state (e.g.,
  dmax(u,), dmin(u,) ).
• A set of functions are defined and implemented to
  facilitate QoS management
• get_incoming_delay(vifi,group),
  get_outgoing_delay(vifi,group)
• add_qos(vifi, group, dbound, duv, dvu),
  del_qos(vifi, group)
• eligibility_test(vifi, group, duv, dvu, dbound)

8
Empirical Results on a Lab Testbed
of Message Overhead Increased
of Join Requests Being Rejected
9
Exploitation of LRD for Resource/Traffic Control
10
Exploitation of LRD in Internet Resource/Traffic
Control

• Motivation
• Internet traffic is observed to exhibit long
  range dependency characteristics.
• The existence of nontrivial correlation structure
  at larger time scales can be judiciously
  exploited for better congestion and resource
  control.
• the correlation structure present in LRD traffic
  can be used to detected on-line and used to
  predict the future traffic.

• Exploitation of LRD in TCP Congestion Control
• Without traffic prediction, a TCP
• connection usually goes through several
  additive
• increase (AI) and multiplicative
  decrease (MD) phases.
• With traffic prediction, a TCP connection
• can infer the optimal operation point at
  which it
• should operate and reach the optimal
  point in
• one RTT, without commencing MD phases.
• We modify the AI phase of TCP congestion
• control to figure in traffic prediction.

• Exploitation of LRD in Active Queue Management
• Design objective
• Keep the queue length of a router at a stable
  level.
• Reduce the packet loss ratio while sustaining
  throughput.
• Approach used
• Predict the future traffic periodically with the
  use of LMMSE predictor.
• Figure in the prediction result in the
  calculation of the packet dropping probability
  used for the next interval.

11
Traffic Prediction

• f(t) is the time series representing the amount
  of traffic between two packet arrivals.
• A router keeps track of n aggregate series
  samples, fm(1), fm(2),, fm(n), where fm(k) is
  the aggregate sample taken in the (n1-k)th most
  recent interval.

Based on the aggregate series samples, the
predictor predicts fm(n1) and fm(n2).
12
Why Do We Use LMMSE Estimator

• The most important criterion in choosing a
  predictor is the accuracy.
• We depict the relative mean square errors versus
  H under the three prediction models.
• The three curves are close to one another when H
  lt 0.85.

• The actual traffic and the traffic estimated
  using LMMSE agree well under the following
  simulation scenario.
• Single bottleneck link of capacity of 20 Mbps,
  and a buffer size of 100 packets.
• Totally 60 connections are established.
• Attainable throughput of a TCP connection is
  measured.

13
Design of the Controller

• Objective
• with the constraint of
• u(k) amount of data that should be dropped in
  the kth interval
• Q(k) the queue length by the end of the kth
  interval.
• Given the output uopt, we set the drop
  probability as

14
Packet Dropping Probability
Simulation result
Analytical result
15
Experiments

• 50-100 TCP connections are established over a
  bottleneck link of capacity 20 Mbps and generate
  packets using the on-off traffic model.
• Maximum buffer size of each router is 100 packets
  (each of size 1000 bytes) under PAQM, RED, and
  AVQ, and 20 packets under SRED.

16
Performance
17
JavaSim
18
JavaSim Large-Scale Network Simulation/Emulation

• Composability
• Allow study of different networking problems in a
  unified, coherent framework.
• Extensibility
• Allow code reuse and insertion of new codes so as
  to accommodate new architectures and services.
• Level of abstraction
• Allow simulation conducted at different levels of
  abstraction and at different granularities.
• Diagnosis and monitoring
• Allow diagnosis and monitoring to be conducted at
  the component level in a time efficient manner.

virtual

• Heterogeneity in terms of
• Physical layer characteristics
• MAC through transport layer protocols
• Mobility models
• Network connectivity models
• Real vs. virtual environments

real

• JavaSim Two-tier Solution
• Component-based, Autonomous
• software architecture that realizes the
• notion of software ICs
• Generalized modeling framework that
• can be easily extended

19
The Modeling Framework in JavaSim

• The modeling framework
• Is decomposed based on the arbitrary and complex
  protocol graphs with simple protocols concept for
  better module reuse.
• Can be used to implement different network
  protocols at different levels of abstraction.

• Implementation supported in JavaSim
• Internet with best-effort, integrated services,
  and differentiated services architectures
• Wireless ad hoc networks with detailed antenna
  propagation models and IEEE 802.11b
• Sensor networks with power management and
  topology control

20
Class Organization in JavaSim
21
Components Supported in JavaSim
22
Components Supported in JavaSim
Differentiated Services Components
Allow real applications to be ported onto JavaSim.
23
Scalability Test

• Famous single bottleneck scenario
• n TCP connections, 2n hosts, 2 routers and one
  bottleneck link with buffer 4n Kbytes
• n varied from 10 to 10,000

24
Scalability Test

• Stress test
• Size of the event queue is at least n
• Routing table size is (n1)
• Testees
• JavaSim v1.0 with Tcl, Python, or Java as the
  glue language, and with an event-driven
  simulation engine or with a real-time
  process-driven simulation engine.
• Ns-2 v2.1b8a
• SSFNEt v1.3
• JavaSim and SSFNET are tested on two JVMs IBM
  JDK1.3 and Blackdown 1.3.1
• Metrics
• Setup time time to create the scenario
• Time to complete 100/500/1000-second simulation

25
(No Transcript)
26
(No Transcript)
27
(No Transcript)
28
(No Transcript)
29
Communication Middleware
30
Block Diagram View
31
Session Creation
32
Sender Join
33
Receiver Join
34
Receiver Join (Cntd)
35
Callback Function
36
Plan for Future Work
37
Extension of QoS-Driven Multicast Routing to
Wireless Sensor Networks

• Develop multicast models of different levels of
  QoS in wireless networking environments.
• Develop multicast algorithms that take into
  account of node mobility, topology change, and
  MAC-level interference.

38
Data-Centric Sensor Networks

• Air dropped inexpensive acoustic sensors (some
  with PC boards) for vehicle tracking and homeland
  security.
• A few flying routers used to maintain
  connectivity.

• Environment
• Sensors
• Gather partial information
• Limited battery life
• Limited transmission power and
• computational capability
• Stationary (with limited mobility due to
• the environmental effects) and mobile
• Limited bandwidth
• Non-homogeneous in terms of processing
• capability and transmission power
• Adversary environment
• Poor spatial distribution
• Interference (wireless/acoustic)
• Malicious destruction

• Requirements
• Conserve energy
• Maintain network connectivity
• Provide bounded end-to-end latency
• Should be robust (i.e., can be self-healing)
• Should be scalable (i.e., no excessive
• control message overhead)

39
RD Roadmap for Data-Centric Sensor Networks

• Maximize information throughput but not data
  throughput

Data Aggregation/Computation
Application Layer

• Maintain connectivity using the minimum
  transmission power.
• Maintain connectivity by moving some router
  nodes to fill in thehole.
• Enable sensors to self-organize themselves into
  clusters.
• Load balance with power consideration

QoS Mapping (e.g. bounded delay)
Admission Control
Transport Layer
Error Control

• Realize Service Differentiation

Network Layer
Routing
Integrated real time scheduling and topology
control
Topology Control
Contention Resolution
Scheduling
MAC Layer
Channel Selection (frequency/code)
Power Adjustment
Physical Layer
Directional Beam-Forming
GPS Positioning Synchronizing
40
Exploitation of LRD for Resource Control

• We will take advantage of LRD characteristics and
  investigate three theoretically grounded methods
  prediction, reconstruction, and interpolation,
  for measuring corss traffic on the bottleneck
  link on an end-to-end path.
• Objectives
• Infer cross traffic as accurately as possible
• Should not inject a significant amount of probe
  packets into the network.
• Should be adaptive to the dynamic change of cross
  traffic.
• Should be robust in the presence of multiple
  bottleneck links.

41
JavaSim

• Extend Javasim to include components in other
  emerging network architectures, such as wireless
  sensor networks.
• Extend JavaSim to realize network emulation.
• Parallelize JavaSim
• Process-driven simulation (as opposed to
  event-driven simulation).
• Conservative synchronization approaches used in
  event-driven simulation can be applied?
• Investigate use of fluid models to expedite
  simulation.
• A cluster of closely spaced packets may be
  modeled as a single fluid chunk with a constant
  fluid rate.
• A set of fluid model-based equations is derived
  and used to characterize system evolution.
• The fluid rate changes are kept track of and
  treated as events.