Geneva, 24 March 2011

Flow-based Traffic Accounting at SWITCH

Simon LeinenTeam Leader LAN, SWITCH

ITU-T Workshop onIP Traffic Flow Measurement

(Geneva, Switzerland, 24 March 2011)

Geneva, 24 March 2011 2

About SWITCH

National Research and Education Network (NREN) for Switzerland

Provide Internet(1+2) to universities

One of the first Swiss ISPs

Fiber-based since 2001

Operates C/DWDM, routers, peerings

Upstreams in Geneva and Zurich

Peerings in Geneva, Zurich, Amsterdam

Total ext. traffic levels: 10-20 Gb/s

Geneva, 24 March 2011 3

How SWITCH uses Netflow data

Volume-based chargingTraffic planning for peering & transitSecurity - early warnings, forensicsTo support research (ETHZ EE-CSG)

Geneva, 24 March 2011 4

Volume-based charging at SWITCH

Principle mandated by foundation: Costs recovery must distribute charges according to costs caused!

Implementation: Volume chargesIn addition to fee components based on:

Access capacityAccess type (redundant/non-redundant)HeadcountValue-added services

Volume Charges: First Attempt

Early model: count (using SNMP) bytes crossing SWITCHsite i/f

only in that direction - outbound is free!

Unwanted customer reactions:Reduce cheap local traffic (e.g. USENET)Build back-door connections between universitiesFear of new services such as multicast

Geneva, 24 March 2011

Geneva, 24 March 2011 6

New model (since 1998)

Only off-net traffic is chargedStill inbound-only, i.e. InternetsiteResearch traffic (e.g GÉANT) exemptTransit & commercial peerings charged

Initially: Only transatlantic traffic

Other intricaciesNights (20-08 local) and weekends freeIPv6 currently free to encourage use

Geneva, 24 March 2011 7

“Fluxoscope” Accounting System

Consume (unsampled) flows from border routersAggregate off-net flows online by:

Customer IDPeer ASApplication (guessed from ports etc.)

Write statistics to files every 5 minPost-process offline (bills, graphs, …)

Geneva, 24 March 2011 8

Why Unsampled?

Because our routers can do itHardware Netflow implementationAnd they are bad at sampling

Billing might work with samplingAs long as sampling is random/unbiasedWe charge large aggregates

Secondary applications are the problem! (security, research)

Geneva, 24 March 2011 9

Issue: Cost/Performance

Performance of the underlying measurement

even though our platform does Netflow "in hardware”too many flows occasional acct. lossrouter CPU overworked with flow export

Cost of processing dataServers, licenses, storage, operations

Accounting Load @~22Gb/s

Flows/s processed by Fluxoscope jobs

Geneva, 24 March 2011

Issue: Where does value accrue?

No idea who initiated a connectionAt SWITCH, we charge the receiver

Questionable because sender controls“Information creates value for receiver”Not applicable to e.g. commercial content providers

Geneva, 24 March 2011

Issue: Asymmetric Routing

On IXPs, not sure which neighbor AS traffic really came from

Netflow includes “source AS” (peer or origin), but these are derived from local router’s routing tables

Geneva, 24 March 2011