policing congestion response in an internetwork using re-feedback

1
policing congestion response in an internetwork
using re-feedback

• Bob Briscoe1,2
• Arnaud Jacquet1, Carla Di Cairano-Gilfedder1,
  Alessandro Salvatori1,3, Andrea Soppera1 Martin
  Koyabe1
• 1BT Research, 2UCL, 3Eurécom

2
the problem policing congestion response
intro

• host response to congestion voluntary
• short and long term congestion
• short policing TCP-friendliness (or any agreed
  response)
• long policing file-sharing (selfish), zombie
  hosts (malicious/careless)
• network policing users congestion response
  voluntary
• a network doesnt care if users cause congestion
  in other networks

access capacity
rate
inversepropnalresponse
pathcongestion,?
3
very serious problem
intro

• a few unresponsive (UDP) flows wasnt a problem
• converged IP network
• initially 30-50 of bits inelastic (mostly
  voice), for BT
• internetwork similar
• cant police required response to path
  congestion, if you dont know it
• each element only sees local congestion
• network cant reliably see e2e feedback (IPsec
  encryption, lying, route asymmetry)
• cant hope inelastic apps ask to be unresponsive
  (Diffserv/signalling)
• because those that dont ask can free-ride anyway
• due to lack of evidence of their crime
• capacity investment risk unacceptable if cant
  prevent free-riding
• uncontrollable demand dynamics and suppressed
  incentive to supply
• risk of repeated congestion collapse (alarmist?)

4
previous work
intro

• detect high absolute rate commercial boxes
• sampled rate response to local congestion RED
  sin bin
• transport control embedded in network ATM
• honest senders police feedback from rcvrs ECN
  nonce

5
wouldnt it be nice if...
intro
...we can our approach

• the big idea 1
• then 2 sub-ideas based on...
• network economics incentives
• rational networks (not users)
• no fiddling with user pricing
• challenge break and improve
• incremental deployment idea 4
• around unmodified IP routers
• BUT limited header bits slows attack detection
  considerably
• generalisations
• QoS
• DoS mitigation
• flow start incentives
• inter-domain traffic engineering
• non-IP internetworks

• source declared downstream path characteristics
  to network
• everyone was truthful
• endpoints and networks
• deployment could be incremental
• we could solve more general Internet Architecture
  problems
• capacity allocn accountability NewArch

6
path characterisation via data headersstate of
the art
TTL
255
the idea
ECN marking rate
0.7
105
resource indexalong path
0
0
resource indexalong path
NB
NA
R1
ND
S1
7
downstream knowledge upstream
242
S1
0
R1
N1
N2
1
5
7
N5
1
the idea
2
S2
N4
0
N3
1
3
R2
245
before re-feedback after re-feedback
target at destination standardised to 16, say
242
255 16
S1
0
R1
1
N1
N2
5
7
N5
1
S2
2
0
N4
2
N3
3
255 16
R2
245
26
8
downstream path characterisation
TTL
255
the idea
ECN rate
152
0.7
0.5
105
resource indexalong path
0.1
0
0
resource indexalong path
re-TTL
NB
NA
166
R1
ND
S1
119
re-ECN
16
0
0
-0.5
-0.6
-0.7
9
incentives preamble

• so far, policing relies on self-incrimination?...
• focus initially on congestion
• header processing not just additive/subtractive
• generalises to monotonic functions (eg
  combinatorial probability of ECN marking)
• downstream unloaded delay (TTL/2) has identical
  incentive properties
• to aid understanding
• solely graphical visualisation (see paper for
  maths)
• imagine that header carries a real number
• normalise monotonically decreasing to target at
  zero

incentives
downstreampath metric?i
0
resource indexalong path, i
10
incentive framework user-network
policer incentivises understatementdropper
incentivises overstatement
downstreampath metric,?i
incentives
i
policer
dropper
Snd
Rcv
11
egress dropper
incentives
naïvedropper
downstream congestionprobability distribution
downstreampath metricat rcvr, ?n
0
12
penalising uncertain misbehaviouridea 2
incentives
1
systematiccheating, ??nc
adaptivedropprobability
??nc
stateless dropper
downstream congestionprobability distribution
truncated/dropped
downstreampath metricat rcvr, ?n
if signature prevalent in discards spawn focused
dropper(s)
0
13
if everyone honest minimise false positives
incentives
no systematiccheating, ??nc 0
stateless dropper
downstream congestionprobability distribution
adaptivedropprobability
??nc
downstreampath metricat rcvr, ?n
0
14
typical dropper simulation (note log scale)
75
false positives
incentives
false negatives
25
15
flowpolicereg. TCPidea 3
each packet header carriesprediction of its own
downstream path
flowpolicer
TCP-friendly
incentives
downstreamcongestion,?i
check/enforce agreedcongestion response
16
ingress TCP policer stateful implementation
also bounded flow state policer implemented -
using sampling
unloaded delay, ?1,1congestion, ?2,1packet
size, s
downstream metricsin packet headers at
internetwork ingress
?t
path congestion ? downstr congestion p ?
?2,1 path RTT ? upstr RTT 2 downstr
delay T ? T0 2 ?1,1
incentives

x s/?t
17
incentive compatibility hosts
??0c
net value to both end-points,?U
0
dominant strategy
scheduler/policer
incentives
dropper push-back
dropper
ideal
overstatement of downstream path metric at
source ??0c

• incentivise
• responsible actions
• honest words

practical
0
18
incentive framework
downstreampath metric,?i
incentives
congestionpricing
i
routing
policer
dropper
Snd
Rcv
19
incentives for networks to police their users

• ?i is size of each packet factored by its
  downstream congestion metric
• metered between domains by single bulk counter
• automagically shares congestion revenue across
  domains, and within domains to direct upgrades
• can approximate congestion pricing with SLAs

incentives
downstreampath metric,?i
ProfitA ProfitB ProfitD
?AB
?BD
resourcesequenceindex,i


NB
flat-pricedrevenue
NA
R1
ND
S1
20
congestion competition inter-domain routing

• if congestion ? profit for a network, why not
  fake it?
• upstream networks will route round more highly
  congested paths
• NA can see relative costs of paths to R1 thru NB
  NC
• the issue of monopoly paths
• incentivise new provision
• collusion issues require market regulation

incentives
down-stream routecost,Qi
faked congestion
?
resourcesequenceindex,i
routingchoice
21
re-ECN(sketch idea 4)
mechanism(approx)
standard EchoCE in TCP
code-pointrate
100
ECT(1)
97
ECT(0)
code-point standarddesignation
00 not-ECT
10 ECT(0)
01 ECT(1)
11 CE
CE
0.4CE
3
0
resourceindex
0 i n

• on every EchoCE from TCP, set ECT(0)
• at any point on path,diff between rates of
  ECT(0) CE is downstream congestion
• works with unchanged routers

deployment
re-ECN, ?i
0
?i ECT(0) - CE
-2.6
-3
22
deployment incentives

• re-ECN deployment by incremental sender upgrades
• re-TTL can be hacked for legacy receivers
• deploy policers and droppers permissively
  configd
• allows new legacy behaviours to co-exist
• incrementally increase strictness
• throttles legacy stacks upgrade incentive knob
• beware slow to catch cheaters with one bit
  re-ECN

deployment
23
edge QoS our original motivation
wxTCP
x

• once timely truthful path visible...
• ingress network can allow spectrum of responses
  to incipient congestion (w-weighted policer)
• equivalent to offering differentiated QoS
  (caveat see paper)
• like Kelly98 but without the need for
  congestion pricing of users
• purely by local (sender?ingress) arrangement
• no authorisation on any other network elements
  (equal marking)
• would need suitable back-pressure e.g. higher
  flat fee
• other networks reimbursed automagically
• by inter-domain congestion pricing (SLA model
  also possible)

generalise
24
no time for (see paper)

• long term per-user policing (complements
  per-flow)
• throttles down sources of persistent long term
  congestion
• encourages p2p file-sharing apps to avoid peaks
  fill troughs
• DDoS mitigation
• extreme downstream congestionprompts extreme
  policing at all ingresses
• long term per-user policing throttles out zombies
• not claiming we can discriminate intent
• flow-start incentives
• deliberate dilemma downstream metric during flow
  start?
• creates slow-start incentive

generalise
25
re-feedback summary

• reinsert feedback to align path characterisations
  at receiver
• packets arrive at each router predicting
  downstream path
• arranged for dominant strategy of all parties to
  be honesty
• incremental deployment upgrade incentive knob
• hangs new capabilities on ECN deployment, not
  just performance
• a simple idea for the Internets accountability
  architecture
• democratises path information
• either network or source can control (control
  requires timely information)
• designed for tussle preserves e2e principle, but
  endpoint control optional

no info
info
no info
info
no info
latentcontrol
latent control
R1
latent control
S1
control
summary
info
info
info control
info control
R1
info control
S1
control
26
policing congestion response in an internetwork
using re-feedback

• QA

27
path congestion typically at both edges
intro
C ? 1 ?B
bandwidth cost, C /bps
0
0
aggregate pipe bandwidth, B /bps
NB
NA
R1
ND
S1

• congestion risk highest in access nets
• cost economics of fan-out
• but small risk in cores/backbones
• failures, anomalous demand

28
last hop dropper discrimination sensitivity
true positivestruncation rate of dishonest
traffic
incentives
cheating level of dishonest sources
false positivestruncation rate of honest traffic
fraction of dishonest arrivals
29
spawning focused droppers

• use sin-bin technique Floyd99
• examine (candidate) discards for any signature
• spawn child dropper to focus on subset that
  matches signature
• kill child dropper if no longer dropping (after
  random wait)
• push back
• send hint upstream defining signature(s)
• if (any) upstream node has idle processing
  resource
• test hint by spawning dropper focused on
  signature as above
• cannot DoS with hints, as optional testable
• no need for crypto authentication no additional
  DoS vulnerability

incentives
30
long term congestion incentives
per-user policer

• effectively throttles out zombie hosts
• incentivises owners to fix them
• incentivises file-sharing in congestion troughs

cumulative multiple flows
incentive framework
downstreamcongestion,?i
downstreamcongestion,?i
congestionpricing
rate
policer/scheduler
policer/scheduler
generalise
Snd
31
distributed denial of service

• merely enforcing congestion response
• honest sources
• increase initial metric reduce rate
• malicious sources
• if do increase initial metric
• policer at attackers ingress forces rate
  response
• have to space out packets even at flow start
• if dont increase initial metric
• negative either at the point of attack or before
• distinguished from honest traffic and discarded
• push back kicks in if persistent

downstreamcongestion,?i
i
generalise
32
slow-enough-start

• initial value of metric(s)for new flows?
• undefined deliberately creates dilemma
• if too low, may be dropped at egress
• if too high, may be deprioritised at ingress
• without re-feedback (today)
• if congested all other flows share cost equally
  with new flow
• if not congested new flow rewarded with full
  rate
• with re-feedback
• risk from lack of path knowledge carried solely
  by new flow
• creates slow-start incentive
• once path characterised, can rise directly to
  appropriate rate
• also creates incentive to share path knowledge
• can insure against the risk (see differentiated
  service)

generalise