Usage cases for Congestion Accounting Bob Briscoe Chief Researcher, BT Oct 2009 This work is partly funded by Trilogy, a research project supported by the European Community

2 pre-requisites need for congestion accounting overcoming ISP resistance prepare the market for contribution to congestion metric

3 ECN design for partial deployment quick tutorial if host ECN enabled, tries to use for all connections if not, ignores ECN part of incoming connection requests IP header tells network whether endpoints talk ECN congested forwarding element will drop packets if it’s ECN-enabled, marks ECN-enabled packets instead dangerous to mark not drop if receiver won’t understand TCP header negotiates ECN support when ECN client sends TCP SYN (initialisation packet) ECN on in TCP header, off in IP header if server supports ECN, SYN-ACK has ECN on in both other TCP-derived e2e transports are similar (DCCP/SCTP) UDP-based protocols (e.g. RTP/RTCP used in VoIP) ECN negotiation is undefined (standardisation just starting)

4 main steps to deploy re-feedback / re-ECN network turn on explicit congestion notification in data forwarding –already standardised in IP & MPLS –standards required for meshed network technologies at layer 2 (ECN in IP sufficient for point to point links) deploy simple active policing functions at customer interfaces around participating networks passive metering functions at inter-domain borders terminal devices (minor) addition to TCP/IP stack of sending device –or sender proxy in network receiver needs to be ECN-enabled at minimum –more precise with re-ECN receiver as well (minor addition) [in progress] redefinition of re-ECN with drop-only receiver requires update to the IP standard (v4 & v6) started process in Autumn 2005 using last available bit in IPv4 header or IPv6 extension header

5 deployment bootstrap incentives deployment effectively involves architectural change 1.(minor) change to sender’s Internet stack 2.network deploys edge/border incentive functions preventing gridlock between these actors requires strong incentives

6 deployment bootstrap incentives re-feedback solves central cost control problem of ISPs third party services competing with ISP pay below network cost ISP has to compete while paying balance of competitor’s costs hits very big fear and button and greed button but keeps moral high ground –net neutral and doesn’t help lock-in or lock-out alliance deployment strategy 3GPP alliance has most to lose from not deploying, followed by NGNs controls vertically integrated network and mobile terminal market deployment by cross-infection nomadic, roaming devices inverse bundling can degrade a substitute product (legacy network service without re-feedback) generally useful model for security products – tend to restrict rather than enhance

7 unilateral actions OS & application developers LEDBAT & weighted congestion controls incentive: prioritise interactive against self-congestion incentive to distinguish self-congestion from shared ECN-enabled client disincentive: small risk of delay or home gateway crash ECN-enabled server incentive-neutral (widely happening now) re-ECN-enabled sender (with drop-only receiver) [TBA – may not be a feasible option] incentive: majority light users declare this to network disincentive: risk of delay due to re-ECN black holes re-ECN-enabled sender (with ECN or re-ECN receiver) incentive: majority light users declare this to network

8 unilateral actions network providers Volume over fine-grained durations (proxy for congestion) incentive: improve majority experience Monitor congestion in network elements and report to traffic management system disincentive: proprietary (why not just ask for ECN?) Artificially Centralise Bottleneck and monitor its Congestion Losses incentive: may match existing topology disincentive: may not – would require excess capacity deploy ECN disincentive: OSS costs incentive Sub-network ECN disincentive: complex Re-ECN proxy disincentive: complex contract modifications open description of internal traffic treatment handling of ECN

Usage cases for Congestion Accounting discuss... spare slides on DDoS as a motivating case

10 will re-feedback prevent DDoS? ≡ will it be deployed widely enough? deployment bootstrap incentives deployment closure incentives doesn’t have to finish the job itself can create right incentives to deploy complementary solutions once fully deployed, winning the war distinguishing genuine flash crowd from simultaneous attack deployment

11 deployment bootstrap incentives deployment effectively involves architectural change 1.(minor) change to sender’s Internet stack 2.network deploys edge/border incentive functions preventing gridlock between these actors requires strong incentives deployment

12 deployment deployment bootstrap incentives  bundling with itself re-feedback solves central cost control problem of ISPs –third party services competing with ISP pay below network cost –ISP has to compete while paying balance of competitor’s costs hits very big fear and button and greed button but keeps moral high ground –net neutral and doesn’t help lock-in or lock-out re-f/b as a solution to DDoS bundled with re-f/b as cost-control alliance deployment strategy 3GPP alliance has most to lose from not deploying, followed by NGNs controls vertically integrated network and mobile terminal market  deployment by cross-infection nomadic, roaming devices  inverse bundling can degrade a substitute product (legacy network service without re-feedback) generally useful model for security products – tend to restrict rather than enhance  novel deployment models wrt Ozment & Schechter

13 deployment deployment closure incentives assume 1 st mover (cellular industry?) has deployed 2 nd movers (NGNs?) didn’t because benefit lower than cost (if rational) but first mover removed costs (risks of unknown, R&D recovered) early adopters also change operational finances for non-adopters... money valve effect between adopters and non-adopters re-feedback controls congestion costs for adopters peaks in incoming traffic demand drive money inward outgoing traffic peaks only generate averaged money flow –costs of non-adopters depend on peak not average stronger effect, the more variance in demand DDoS is extreme variance in demand like alternating current through a diode/valve chain reaction adopters’ incoming border charges focus on non-adopters bots concentrate into smaller non-adopter space money valve effect surrounds more of non-adopters’ borders $ £ ¥ €

14 deployment winning the last battle (not just the next) distinguishing flash crowds from attacks incentives not to be too greedy a rate policer is effectively a revenue limiter if policer allows DDoS attacks, customer has to buy bigger quota why would operators try to distinguish the two? customers will switch to responsible operators distinguishing true demand form zombies is in operator’s interest fortunately society still civilised enough huge white market revenue not worth risking –just to capture marginal gains from black market strategic greed overcomes myopic greed