Download WorldNet Data Warehouse Albert Greenberg albert

Computing Traffic Demands from
Flow-Level Measurements
Jennifer Rexford
IP Network Management and Performance
AT&T Labs – Research; Florham Park, NJ
http://www.research.att.com/~jrex
Outline
• Background
– Internet architecture
– Traffic engineering
• Traffic demands
– Traffic from ingress point to set of egress points
– Combing flow measurement and routing tables
– Analysis of demands on the AT&T IP Backbone
• Conclusions
– Lessons learned and avenues for future work
– Summary and ongoing work
Internet Architecture
• Divided into Autonomous Systems
– Distinct regions of administrative control (~12,000)
– Set of routers and links managed by a single “institution”
– Service provider, company, university, …
• Hierarchy of Autonomous Systems
– Large, tier-1 provider with a nationwide backbone
– Medium-sized regional provider with smaller backbone
– Small network run by a single company or university
• Interaction between Autonomous Systems
– Internal topology is not shared between ASes
– … but, neighboring ASes interact to coordinate routing
Internet Service Provider Backbone
neighboring providers
modem banks,
business customers,
web/e-mail servers
Backbone
routers
Gateway routers
Access routers
The Need for Traffic Engineering
• Traffic shifts
– Special events (e.g., Starr report, Olympics)
– Popular new applications (e.g., peer-to-peer)
– Distributed denial-of-service attacks
– Time-of-day/day-of-week traffic changes
– Failures/reconfigurations in other domains
• Topological changes
– Failure of link or router within the domain
– Deployment of new links and routers
– Addition or removal of customers or peers
Operators must adapt routing to the prevailing traffic.
Detecting a Problem: Link Utilization
Utilization: link color (high to low)
Fixing a Problem: Traffic Engineering
• Topology of the ISP backbone
– Connectivity and capacity of routers and links
• Traffic demands
– Offered load between points in the network
• Routing configuration
– Tunable rules for selecting paths for the traffic
• Performance objective
– Balanced load, low latency, customer agreements
• Optimization procedure
– Given the topology and traffic demands, tune
routes to optimize the performance objective
An Appealing Model: Traffic Matrix
Traffic matrix: V(in,out,t) for all pairs (in,out)
in
out
Problem: Multiple Egress Points
• ISP backbone is in the middle of the Internet
– Multiple connections to other autonomous systems
– Destination is reachable through multiple exit points
– Selection of egress point depends on intradomain routes
• Problem with traditional point-to-point models
– Want to predict impact of changing intradomain routing
– But, a change in routing may change the egress point!
2
4
1
3
Populating the Demand Model
• Distributed problem
– Requires traffic measurement at multiple locations
• Multiple types of data
– Traffic measurement and routing data
• Large scale
– Large number of routers and volume of traffic
• Our approach
– Measure traffic at each of the ingress points
– Associate destination with egress point(s)
– Aggregate the traffic over space and time
Measuring Flows Rather Than Packets
flow 1
flow 2
flow 3
flow 4
• IP flow abstraction
– Set of packets with “same” src and dest IP addresses
– Packets that are “close” together in time (a few seconds)
– The closest thing to a “call” in the Internet
• Cisco Netflow
– Measure all flows between AT&T and its peers
– Extremely large amount of data (~200 GB/day)
Netflow Data
• Source and destination information
– Source and destination IP addresses (hosts)
– Source and destination port numbers (application)
– Source and destination Autonomous System
• Routing information
– Source and destination IP address block
– Input and output links at this router
• Traffic information
– Start and finish time of flow (in seconds)
– Total number of bytes and packets in the flow
Identifying Where the Traffic Can Leave
• Traffic flows
– Each flow has a dest IP address (e.g., 12.34.156.5)
– Each address belongs to a prefix (e.g., 12.34.156.0/24)
• Forwarding tables
– Each router has a table to forward a packet to “next hop”
– Forwarding table maps a prefix to a “next hop” link
Prefix d: egress links {i, k}
i
k
d
Experimental Results: AT&T IP Backbone
• Measurement data
– Netflow data
– Forwarding tables
– Topology and routing configuration
• Traffic analysis
– Distribution of traffic volume across demands
• Small % of demands are responsible for most traffic
– Time-of-day fluctuations in traffic volumes
• U.S. business, U.S. residential, International
– Stability of traffic demands across hours and days
• Initial results suggest some stability, but need to study
Proportion of Traffic in Top Demands
Time-of-Day Effects (San Francisco)
Traffic Flow Through AT&T’s IP Backbone
Source node: public peering link (NAP) in New York
Destination nodes: AT&T access routers
Color/size of node: proportional to traffic to this router (high to low)
Color/size of link: proportional to traffic carried (high to low)
Lessons Learned
• Thinning the data
– The large volume of measurement data was unwieldy
– A small number of heavy hitters dominate the data
– Techniques like sampling and sketches should be effective
• Distributed solution
– Significant aggregation based on the ingress point
– Local reduction of the data should be effective
• Routing optimization
– Inaccuracies in the traffic demands are not a problem
– Trading off accuracy for efficiency is a promising idea
• Router support for measurement
– Measurement support is an afterthought, and inflexible
– Efficient, online data reduction schemes would be useful
Conclusions
• Traffic engineering for IP networks
– Point-to-multipoint model of traffic demands
– Methodology for computing demands
– Analysis of traffic demands in AT&T network
• Ongoing work
– Flexible router support for packet sampling
– Traffic engineering for traffic between domains
• To learn more
– http://www.research.att.com/~jrex/papers.html#ipte