On Flow Concurrency in the Internet and its Implications for - - PowerPoint PPT Presentation

On Flow Concurrency in the Internet and its Implications for Capacity Sharing

Brian Trammell and Dominik Schatzmann Communications Systems Group, ETH Zürich

What’s a measurement guy doing at a capacity-sharing workshop?

§ Concern about flow state requirements in audit

§ Capacity sharing verification at network interconnection points necessary for algorithms requiring trust between policing and audit

§ expensive à large links, higher concurrency

§ Current capacity-sharing approaches don’t need this property

§ independent edge-policing architecture § and as long as they don’t, remain scalable à small links, lower concurrency

§ But it’s always nice to have data to back up these assumptions

§ however… § increasing use of flow-state-keeping devices in the network

§ Proliferation of protocols requiring middleboxes. (CGN scares me.)

§ Is flow state a new resource requiring fair allocation?

10 Dec 2012 2 Flow Concurrency - CSWS - Nice

Flow concurrency distribution characteristics

10 Dec 2012 3 Flow Concurrency - CSWS - Nice

Total Flow Concurrency

§ Flow concurrency highly dependent on network type

§ In general, less variable at higher levels of aggregation

§ Rule of thumb: ~20k peak per /16

§ adjusted for host type / popularity

10 Dec 2012 4 Flow Concurrency - CSWS - Nice

network median 95th peak all (/11) 148k 322k 436k university (5x /18) 3.2k 4.3k 22.9k

Flow Concurrency per Active Host

Host type median 95th peak clients (13.7k) 5.8 11.8 53.8 servers (13.4k) 10.3 13.4 23.0 CDN (1.25k) 16.5 43.3 49.8 all (2.4M) 5.2 7.7 9.7

§ Flow concurrency per active host much more stable per host type § (with some noise: 53.8 peak à outbound scan activity) § 5th percentile client flow concurrency is 3.8 à web client behavior § Client concurrency a function of behavior § Server concurrency a function of popularity § Large-scale rule of thumb: 10 peak per active host.

10 Dec 2012 5 Flow Concurrency - CSWS - Nice

Dominance of short flows

§ Flow concurrency is an issue because most flows are short. § Median flow is ~250ms long § 23% single-packet flows § very short flows account for 8%

• f packets and 5% of bytes…

§ …but 52% of flows.

0.0 0.2 0.4 0.6 0.8 1.0 10 20 30 40 50 60

Flow duration (s) Cumulative distribution of flow count

10 Dec 2012 6 Flow Concurrency - CSWS - Nice

Use aggressive timeouts!

§ Dominance of short flows indicates short timeouts can significantly decrease required flow state § Idle timeouts longer than 15s merely add to state requirements

0e+00 1e+06 2e+06 3e+06

• 5

10 15 30 60 120

Timeout (s) flows

10 Dec 2012 7 Flow Concurrency - CSWS - Nice

Development of flow concurrency over time

§ Flow concurrency increases with traffic volume. § Large flows contribute far more to traffic volume than to flow count:

§ Correlation: 0.668

0e+00 1e+05 2e+05 3e+05 4e+05 5e+05

• 2003

2005 2007 2009 2011

year flows

10 Dec 2012 8 Flow Concurrency - CSWS - Nice

Guidance for edge-policing in capacity sharing

§ ~10 peak concurrent flows per active host § ~12 peak concurrent flows per active client (excl. scanning) § à 200kB per /24 assuming 64B/flow § Server concurrency depends on popularity § Even with 100x concurrency, 20MB per /24 § à there does not appear to be a problem here

§ (but make sure you don’t need to police the interconnect)

10 Dec 2012 9 Flow Concurrency - CSWS - Nice

Toward flow-state fairness

10 Dec 2012 10 Flow Concurrency - CSWS - Nice

Decreasing the brittleness of in-network state

§ Two solutions to increasing flow concurrency for flow-state keeping devices:

§ Graceful degradation (audit and policing, measurement, etc.) § Massive overprovisioning

§ Use of devices that must be overprovisioned is increasing in the network

§ Anything with NAT in the name.

§ Can capacity-sharing approaches be of use here?

10 Dec 2012 11 Flow Concurrency - CSWS - Nice

Potential flow-state control schemes

§ Temporal offload: delay SYN before forward

§ Most peaks are transient à delay can help ride them out § Too much delay leads to retransmit / timeout § (Much less delay than this can impact perceived latency)

§ Lower-concurrency transport

§ e.g. SPDY: reduce concurrency by opening fewer flows

§ Discouragement of flow-state overload

§ Declare flow length in advance, and incentivize longer flows § Machinery here looks parallel to conex

10 Dec 2012 12 Flow Concurrency - CSWS - Nice

Acknowledgements

§ Thanks to SWITCH for network flow data examined § mPlane — http://www.ict-mplane.eu/

10 Dec 2012 13 Flow Concurrency - CSWS - Nice