Transcript 0910cfpWP-briscoe

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