ip traffic management applications measurement, analysis, and optimization

IP Traffic Management Applications

Measurement, Analysis, and Optimization

Who We Are

• Josh Wepman, Ixia– Applications Engineer

• Andrew Lange, Exodus (C&W)– Principal Network Architect

• Matt Meyer, GBLX– Senior IP Traffic Engineer

• Joe Abley, MFN– Toolmaker/Engineer

If You Recall from Last Time…

• A process can be defined:1. Define Goals2. Measure3. Analyze4. Refine Goals5. Action6. GOTO 1

• Specifically addressing IDTE

Miami taught us a few things

• More detail on problem statements and measurement plans

• More real examples of problems and applied solutions

• Josh must talk…more…slowly…

So what is Josh Talking About?

• What broader sets of applications exist for Routing and Flow data?

– What are the problem statements?

– What are the issues and scale of measurement in providing solutions to the problem statements?

So what is Josh Talking About?

• Solutions to problems must:– Solve real business problems!!!– Cut costs or drive revenue– Proposed “Solutions” must be less expensive

than the “Problems” ******– Provide relevant engineering data

• Problem Statement Relevant

• Collect what is needed, not everything you can…

Applications List

• Inter-Domain Peering Optimization

• Inter-Domain Congestion Mitigation

• Customer Acquisition

• Network Policy Enforcement

• Intra-Domain Traffic Engineering

• Others (there are many…)

Applications

• Each Application follows the same model:

1. Define Goals2. Measure3. Analyze4. Refine Goals5. Action6. GOTO 1

Applications

• Focus for each application is on:

• Define Goals– Problem Statement

• Measure– Network Scenario

– Deployment Scenario

– Deployment Implications

Applications

• More collection specific technical detail can be found in Miami Tutorial slides on the NANOG website:

• www.nanog.org/mtg-0202/ppt/te/index.htm

Inter-Domain Peering Optimization

• Problem Statement– Reduce inter-domain transit costs while

increasing quality of connectivity• Cheaper

• Finer grain control (increases complexity)

• Closer to end consumers

• Clear cost savings

• This is NANOG – why am I preaching the value of peering…

• For more info:– See Bill Norton’s “The Art of Peering”

– See Sun Tzu’s “The Art of War”


• Network Scenario– Hierarchical network design– Core transit facilities– Edge Ingress/Egress facilities– Peers are not offered transit services– Outbound load is of primary concern****


AS100

AS1 AS2 AS3

BorderRouter

BorderRouter

TransitRouter

TransitRouter


• Deployment Scenario – Flow Export– Collection on Core “access” links– Sampling granularity - moderate (1:50|100)

• Can depend on link speed – platform

– Real link characteristics extrapolated based on “valid sampling data”

• Sampling for a longer period of time will not validate invalid sampled data

– Scale is moderate – one collection host per region or set of border routers


• Deployment Scenario – BGP– For OUTBOUND load only

• IBGP to edge box required

– For problem statements with edge links• Route-reflection is required from either edge box or

existing route-reflection servers (core boxes)

– Goal is to communicate BGP routes that correlate to traffic flows

• DST_IP needs to find a match in BGP in order to generate useful data


AS100

AS1AS2

AS3

BorderRouter

BorderRouter

TransitRouter

TransitRouter

Collector

Flow

BGP

Inter-Domain Peering Optimization• Deployment Implications

– Collection Nodes: Low/Moderate– Disk Usage: Low

• Metrics include:– Time (how long do you keep the data?)– Interfaces (generally linear multiplier)– Flow diversity (hard question to answer)– Flow-export version

– CPU: Low• Metrics include:

– Interfaces (n x streams of flow data)– Flow diversity (hard question to answer)– BGP model (route-reflection scaling issues)– Flow-export version (5 vs. 8)

Paths to the Source… (****)• Deployment Scenario – Paths to the source

– Mapping routing data to destination IP addresses has a very strong correlation to the forwarding path

– Mapping routing data to the source IP address has a very weak correlation to the forwarding path

– Origins and Peers can sometimes be known, the middle mile to the source is much harder…

• There is no way to state with reasonable confidence that the path announced to you for the source was followed to you (policy is complicated and not passed inter-domain)

Inter-Domain Congestion Mitigation

• Problem Statement– Save money by identifying and eliciting control

over discrete traffic segments that are causing congestion

• Congestion is “usually” bad

• Can cost providers money

• Finding the right size “fix” in order to consistently and persistently address problem

• Higher quality service

• Lower operational costs

Inter-Domain Congestion Mitigation

• Network and Deployment Scenarios– Very similar to Peering Optimization– Time domain much shorter

• Days and hours as opposed to months

– Goal is MUCH more specific• Offload at link (neighbor) level instead of abstracted

domain

• Requires retention of more detail to answer more specific questions

Inter-Domain Congestion Mitigation• Deployment Implications

– Collection Nodes: Low– Disk Usage: Moderate

• Metrics include:– Time (Added detail for more discrete time frames)– Flow diversity– Data Types (as, net, proto)

– CPU: Low• Metrics include:

– Interfaces– Flow diversity– BGP model– Flow-export Version

Customer Acquisition

• Problem Statement– Increase revenues by identifying and targeting

potential customers based on ~current traffic trends

• Publicly unpopular, privately VERY popular

• Is anyone not in need of more consumers in order to offset generally static network costs?

• Find your competitors customers and target the ones that use your bandwidth already

• Increase revenue and potentially decrease peering traffic


• Network Scenario– Applies to most any network model– Works well in the same hierarchical model– Collection inbound on peer links users want to

target for customer acquisition– Abstraction of “N” links to see big picture– Order competitor’s customers based on load:

• Source• Sink• Total (source + sink)

– Send in the jackals…


AS1AS2

AS3

BorderRouter

BorderRouter

TransitRouter

TransitRouter

AS100


• Deployment Scenario – Flow– Collection inbound on peering links– Sampling granularity can be generally coarse– Same data normalization procedure as Peering

Optimization


• Deployment Scenario – BGP– Requires BGP Route-reflection from exporter

or representative router• Could collect route data from the same router that

reflects routes to edge peering router

– The routes available to the BGP collector must represent the flows that are being tracked

• Otherwise “bucket 0” gets very big!


AS1AS2

AS3

BorderRouter

BorderRouter

TransitRouter

TransitRouter

AS100

Collector

Flow

BGP


• Deployment Implications– Collection Nodes: Low/Moderate– Disk Usage: Moderate

• Metrics include:– Time– Interfaces (larger set)– Flow diversity– Traffic types

– CPU: Moderate• Metrics include:

– Interfaces (larger set than core links)– Flow diversity– BGP model – N x route reflection > N x IBGP

Network Policy Enforcement

• Problem Statement– Reduce operations costs and outage times

by identifying routing and flow issues proactively• Catch little problems before they become

BIG• Catch problems the FIRST time, not the Nth


• Problem Statement (details)• Identify traffic that should not be there

– Peers dumping traffic on you

– Are your “mostly intra-Europe customers” actually sending most of their traffic to the US over those expensive STM-16s?

• Identify routes that violate BGP policy– Peer A propagating routes from Peer B

– Default route from the wrong (any) place


• Network Scenario– Large scale IBGP deployment– Complex network policy– Multiple exit points for routes– Transit and non-transit relationships


• Deployment Scenario - BGP– Full-mesh IBGP collection

• Allows evaluation of all installed routes in core

– Ideally, all core candidate routes could be evaluated in order to catch “snakes in the grass”

• Some IETF work being done to help:• draft-walton-bgp-add-paths-00.txt• draft-jabley-bgp-measurement-00.txt

– Evaluate every route transaction in real time to evaluate “goodness”

– Requires general concept of what is and is not valid in local BGP implementation (policy definition)


• Deployment Scenario – Flow Export– Collect flow data at network ingresses

– Should interface X, send traffic flow Y

– Are peers sending traffic for routes you did not announce?

– Sampling granularity can often be very low

– Question tend to be binary (YES/NO) as opposed to quantified (how much)

– V5 preferable here for many things


• Deployment Implications (large scale)– Collection Nodes: Moderate/High– Disk Usage: High

• Metrics include:– Flow Version (trade off in resources)

– Interfaces

– nodes

– Traffic types (raw)

– CPU: High• Metrics include:

– Large number interfaces

– Large amount of raw flows

– Large amount of processing of flows and BGP events

Intra-Domain Traffic Engineering

• Problem Statement– Maximize traffic mapping onto existing

internal capacity without using all sorts of “expensive” MPLS technology

• Can obviate costly technology migrations

• Able to address many offered load concerns

• MPLS is good too, This is not a replacement, simply an alternative in many scenarios

– With only three hours, we cannot possibly have an MPLS debate…


• Network Scenario– Some arbitrary set of IGP links– BGP selects exit point of network– Derive traffic load per BgpNextHop in order

to derive inter-node and inter-pop traffic demands over time

– Works in most any conventional network paradigm where IGPs carry intra-domain traffic to BgpNextHop exit point


• Deployment Scenario - Flow Export– Collect flow data from edge ingress links of

substance• Don’t sweat the small stuff

• Can be done at edge/core aggregation point to reduce #links in a hierarchical network environment

– Sampling rate can be moderate• This is not billing, this is longish term capacity

planning

• Same concepts apply to normalization


• Deployment Scenario - BGP– Route-reflection is required similar to

customer acquisition scheme– Traffic mapped onto backbone generally relies

on routes propagated from IBGP peers. In order for collectors to see the IBGP installed routes, route-reflection is your friend


• Deployment Implications (large scale)– Collection Nodes: High– Disk Usage: Moderate

• Tabular data reduces disk needs• No raw data required• Disk usage balloons in proportion to #links• Aggregate edges where possible

– CPU: Moderate• Long term trending reduces “real-time” load• Route-reflection does not scale as well as IBGP

Other Applications

• Usage Based Billing

• Billing Verification

• DDOS

• Security

• Per Service Network Design

Things it does not do…

• Print Money

• Correct Accounting Practices

• Speak in the HAL-9000 voice

• Make a decent omelet

Summary

• There are a host of applications that can solve business relevant problems by collecting and analyzing routing and flow data

• Most work on standard network designs• Disk and CPU loads very significantly

based on scale, application, and problem statement

More Information

• Josh Wepman– Ixia NetOps– [email protected]– 734-222-5460

• Thanks for listening!

ip traffic management applications measurement, analysis, and optimization

Documents

optimization slide

idte slide

interdomain transit

art of war slide

mfn toolmakerengineer

problem statements

art of peering

value of peering