Edgebased Inference and Control in the Internet

1
Edge-based Inference and Control in the Internet
Ph.D. Thesis Proposal Aleksandar Kuzmanovic
Rice Networks Group http//www.ece.rice.edu/networ
ks
2
Motivation

• Applications and clients demand new services in
  the Internet
• Differentiation of performance
• Robustness
• IP and network core are not extensible and are
  slowly evolving
• IPv6 (10 years)
• IP Multicast (domain dependent)

Goal Achieve advanced functionality and services
via endpoint mechanisms and protocols
3
Approach

• Network as a black box

4
Thesis Objectives

• Infer network and server QoS elements from
  endpoints
• Infer static multi-class elements and their
  parameters
• Create service differentiation via endpoints
  (without network support)
• Infer and utilize available bandwidth to achieve
  low-priority service
• Prevent Denial of Service (DoS) attacks via
  robust endpoint protocol design
• Prevent malicious endpoint behavior

5
Outline
6
Background

• Network QoS elements and mechanisms
• Policing
• Ex. Dorm traffic is often rate limited
• Priority queues
• Ex. VoIP traffic has priority over other traffic

• Web Server/Cluster QoS policies
• CPU resource sharing
• Listen queue differentiation
• Load balancing
• Machine migration

Goal Develop tools for network clients to assess
the networks and servers QoS capabilities
7
Inverse QoS Problem

• Is a class rate limited?
• What is the inter-class relationship?
• Fair/weighted fair/strict priority
• Is resource borrowing fully allowed or not?
• Is the services upper bound identical to its
  lower bound?
• What are the services parameters?

8
Applications

• Service Level Agreement
• validation
• Is it fulfilled?
• Capacity planning
• What is the relationship
• among classes?
• Performance Monitoring and Resource Management
• Estimate a class net guaranteed rate

9
System Model and Problem Formulation

• Two stage server
• Non-work conserving elements
• Multi-class scheduler
• Observations
• Arrival and
• departure times
• Class ID
• Packet size

10
Off-Line Solution is Simple

• Consider a router with unknown QoS mechanisms

11
On-Line Case Operational Network

• Undesirable to disrupt on-going services
• High rate probes to detect inter-class
  relationships would degrade performance
• Impossible to force other classes to be idle
• to detect policers

12
Strategy

• Inter-class resource sharing
• theory QK99
• Key technique
• Passively monitor arrivals
• and services at edges
• Devise hypothesis tests to jointly
• Detect the most likely hypothesis
• Estimate unknown parameters

13
Empirical Service Distributions

• Theory (WFQ)
• Practice (WFQ and SP)

WFQ (400 ms) SP
(400 ms)
14
Parameter Estimation andScheduler Inference

• Determine MLE parameters
• for each scheduler
• Choose the most likely
• scheduler for each time scale
• Apply majority rule over all
• time scales

15
Detection and Estimation

• Detection
• Correctness ratio
• True EDF ? 100
• True WFQ ? 94
• Estimation
• WFQ weights
• Fluid vs. packet model
• Rate limiters
• Ex. FQ, r1Mb/s
• Probability decreases with time scale

Unified framework for incorporating phenomena
relevant at different time scales
16
Outline
17
Motivation

• Service differentiation is an important goal of
  the future Internet
• Our approach
• Low priority service
• End-point based solution
• Applications
• Low priority bulk
• data transfer
• Corporate networks
• Overlay networks
• Internet

18
Applications (contd)

• Peer-to-peer file
• sharing
• Often rate-limited
• Isolation vs. sharing
• Server Selection
• Find the best server

19
Problem Formulation
20
Problem Formulation
21
Problem Formulation
22
Algorithm Design Objectives

• TCP transparency
• Non-intrusiveness
• Aggressiveness
• Send at the excess/available capacity
• Fair-share of the available bandwidth
• Current techniques (e.g., Delphi, Pathload)
• Send in probes and interpret results
• TCP-LP
• Transmitting at the rate of available bandwidth
• Infer the fair-share vs. total available bandwidth

23
TCP-LP The Key Concepts

• Early congestion indication
• TCP-LP uses a tight control loop
• One-way packet delays (RFC1323) vs. packet losses
• TCP-transparent
• congestion avoidance policy
• parameters

24
TCP-LP Sample Path
25
TCP vs. TCP-LP

• TCP alone 49.7
• TCP vs. TCP-LP 49.3 vs. 7.3

TCP-LP is invisible for TCP traffic!
26
Web Experiment

• TCP background bulk data
• transfer
• Web response times
• are normalized

27
Web Experiment

• TCP-LP background bulk data tr.
• FTP throughput
• TCP 58.2
• TCP-LP 55.1

28
Web Experiment

• No background bulk data
• transfer
• TCP-transparency!

29
Future Work

• Implement TCP-LP in Linux
• Validation
• Testbed
• CBR, square wave, and HTTP cross traffic
• The Internet
• What is the difference between pure excess
  network bandwidth utilized by TCP-LP and the
  available bandwidth utilized by TCP?
• Related work
• TCP Vegas Nice - developed in parallel

30
Outline
31
Denial of Service (DoS)

• DoS is a malicious way to consume resources in a
  network, a server cluster or in an end host,
  thereby denying service to other legitimate users
• Current folklore
• DoS flow is a high bit-rate flow
• Attackers generate these flows
• Researchers develop mechanisms to detect and
  throttle down these flows
• Internet is stable due to TCP and its congestion
  control mechanisms

32
Problem Formulation

• Send at minimum possible average rate (hard or
  impossible to detect) and be as intrusive as
  possible

33
Motivation

• Detect and isolate fragile network/protocol
  mechanisms that are used as tools of a possible
  DoS attack
• Detect and isolate network protocols that are
  able to generate such low bit-rate streams
• Suspects Pathload JD02, Audio/Video sources

34
Approach

• Homogeneity of cross-traffic
• More than 95 of the traffic in the Internet is
  TCP traffic
• Deterministic and predictable behavior of
  cross-traffic
• Challenges
• Heterogeneity of TCP variants
• Tahoe, Reno, New Reno, SACK...
• Roundtrip times
• from several ms to hundreds of ms

35
The Key Source of Determinism

• All TCP variants
• React in the same way on bursts of packet losses
  (wait for RTO)
• Use the same algorithm to compute the RTO value
  (RTOSRTT4RTTVAR)
• On Estimating End-to-End Network Path
  Properties, P. Allman and V. Paxson, In
  Proceedings of ACM SIGCOMM, Aug. 1999.
• To avoid spurious retransmissions, require
• minRTO 1 sec
• RFC2988, V. Paxson and M. Allman, Nov. 2000
• minRT0 1sec
• May 2001 default in ns-2

36
Scenario

• Outage all the TCP packets are lost
• If on the order of a flows RTT, then TCP always
  enters RTO mechanism
• Repeat outages on intervals of minRTOf(RTT)

37
The minRTO Parameter

• minRTO1sec means
• If RTT50ms gt monopolize resources for short
  periods (50ms/1050ms4.7) gt low bit-rate
• Deterministic response that overcomes
  heterogeneity of both TCP variations and
  roundtrip times
• Approximating outages

38
Single TCP Experiment

• Magnitude 2 Mbps
• ON length 70ms (max RTT 120ms)
• Resonant time scale 1sec RTT

39
Future Work

• TCP variants
• Reno is the most fragile, but what about Tahoe,
  NewReno, SACK
• TCP aggregates
• Filtering
• Short-RTT vs. long-RTT flows in a heterogeneous
  TCP aggregate
• Denial of local area traffic?
• Long vs. short TCP flows
• How short should a file be?
• Linux vs. Windows
• Incremental deployability?
• Linux does not have it yet
• Perform experiments in the Internet

40
Conclusions

• Efficient control and inference of the Internet
  from its edges
• Multi-class service inference KK01, KK02
• General multiple time-scale traffic and service
  model to characterize a broad set of behaviors
  within a unified framework
• TCP-LP End-point service prioritization protocol
  KK03
• Low priority bulk data transfers
• Future work
• Implementation and validation in the Internet
• TCP and DoS attacks
• Design and explore low bit-rate DoS streams and
  their relationship to TCP