Survey
* Your assessment is very important for improving the workof artificial intelligence, which forms the content of this project
* Your assessment is very important for improving the workof artificial intelligence, which forms the content of this project
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 www.trilogy-project.org pre-requisites • need for congestion accounting • overcoming ISP resistance • prepare the market • for contribution to congestion metric 2 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) 3 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 4 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 5 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 6 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 7 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 8 Usage cases for Congestion Accounting discuss... spare slides on DDoS as a motivating case culprit theintro congestion status charging deployment re-feedback deployment summary accountability effect solution 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 10 culprit theintro deployment re-feedback deployment summary accountability effect solution congestion status charging 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 11 culprit theintro deployment re-feedback deployment summary accountability effect solution congestion status charging 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 12 culprit theintro deployment re-feedback deployment summary accountability effect solution congestion status charging deployment closure incentives • assume 1st mover (cellular industry?) has deployed • 2nd 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 • • • 13 adopters’ incoming border charges focus on non-adopters bots concentrate into smaller non-adopter space money valve effect surrounds more of non-adopters’ borders £ ¥ $ € culprit theintro congestion status charging deployment re-feedback deployment summary accountability effect solution 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 14