downstream knowledge upstream re-feedback

1
downstream knowledge upstream re-feedback

• Bob Briscoe
• Arnaud Jacquet, Carla Di Cairano-Gilfedder,
  Andrea Soppera Martin Koyabe
• BT Research

2
goals non-goals, approach
intro

• goals non-goals
• goal fix Internets resource allocation and
  accountability architecture
• non-goal solve the whole DoS problem
• non-goal solve app-layer/user-space flooding
• goal foundation for wider DoS solution(s)
• approach
• part of effort to determine new Internet
  architecture
• mechanism for non-co-operative end-game in case
  things get nasty
• network economics incentives, but no fiddling
  with retail pricing
• network operators (not users) assumed to be
  rational
• work in progress
• simulations in progress
• not even submitted yet

3
the problem rate policing
intro

• short long term congestion
• short e.g. policing TCP-friendliness (or any
  agreed response)
• long e.g. policing zombie hosts, p2p
  file-sharing (selfish not malicious)
• user congestion response voluntary
• why is TCP compliance stable? what shouldnt we
  do to keep it?
• TCP-friendly malware?? imagine a TCP virus
• network congestion response voluntary
• why care if my users cause congestion in
  downstream networks?

access capacity
rate
TCP-friendly
pathcongestion,?
4
pre-requisite knowledge explicit congestion
notification (ECN)
IETF proposed std RFC3168 Sep 2001 most recent
change to IPv46
packet headers
marked ACK
network transport data
ACKnowledgement packets
data
probability
1
probabilisticpacket marking algorithm on all
egress interfaces
drop
mark
marked packet
ave queue length
0 5 6 7
00 Not ECN Capable Transport (ECT) 01 or 10 ECN
Capable Transport - no Congestion Experienced
(sender initialises) 11 ECN Capable Transport -
and Congestion Experienced (CE)
ECN
DSCP
bits 6 7 of IP DS byte
5
path characterisationvia data headers
loss rate or explicit congestion notification
(ECN)
0
time to live (TTL)
255
6
downstream knowledge upstream the idea
10
16
propgn timecongestionhop countetc
7
11
3
16
16
16
11
11
11
14
R1
10
10
16
8
S1
R2
S2
7
downstream knowledge upstream re-feedback
intro
metric,h
h0(tT)
3
nodesequenceindex,i
h0(t)
m1
1
hz
0
1
2
i
n
...
...
he(t)
hn
2
sequence of relays on a network path
sender
receiver
8
congestion protocol terms
intro

• ECN Explicit Congestion Notification
• ECL Explicit Congestion Level (my term)
• re- receiver aligned (or re-inserted)

aligned at binary multi-bit
sender ECN ECL
receiver re-ECN re-ECL
9
incentive framework
incentives
downstreampath metric,?i
congestionpricing
i
routing
policer/scheduler
dropper
Snd
Rcv
10
downstream path metric at receiver
downstreampath metricat rcvr, ?n
naïvedropper
incentiveframework
0
downstreamcongestionprobability distribution
i
dropper
Rcv
11
penalising uncertain misbehaviour
downstreampath metricat rcvr, ?n
stateless dropper
incentiveframework
systematiccheating, ??c
0
1
i
??c
dropper
dropper
adaptivedropprobability
downstreamcongestionprobability distribution
Rcv
12
downstream path metric at receiver
downstreampath metricat rcvr, ?n
statelessdropper
incentiveframework
no systematiccheating, ??c 0
0
downstreamcongestionprobability distribution
i
dropper
Rcv
13
spawning focused droppers
incentives

• use penalty box 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

14
TCP policer no state for well-behaved flows
congestion,delay,
flowpolicer
each packet header carriesview of its own
downstream path
TCP-friendly
downstreamcongestion,?i
incentive framework
downstreamcongestion,?i
rate
policer/scheduler
policer/scheduler
sample packetsto check/enforce the
agreedcongestion response no per flow state for
honest flows
Snd
15
incentive compatibility hosts
??c
incentives
net value to end-points,?U
0
dominant strategy
scheduler/policer
dropper push-back
dropper
ideal
overstatement of downstream path metric at
source ??c

• incentivise
• responsible actions
• honest words

practical
0
16
inter-domain policing

• bulk congestion charging emulates policing
  passive simple
• capacity charge modulated by congestion charge
• sending domain pays C ?X ?Q to receiving
  domain (e.g. monthly)
• ?, ? are (relatively) fixed prices of capacity, X
  and congestion, Q resp.
• usage related price ? 0 (safe against denial
  of funds)
• any receiver contribution to usage settled
  through end to end clearinghouse
• congestion charge, Q over accounting period, Ta
  is Q STa ?i
• ?i metered by single bulk counter on each
  interface
• note negative ?i worthless creates incentive
  to deploy droppers

incentives
downstreampath metric, ?i
?AB
?BD
i
N2
congestion profit, ? ?1 (? ?)12 ?2
(? ?)12 (? ?)24 ?4 (? ?)24per packet
N1
R1
N4
S1
Capacity price, ? sign depends on relative
connectivity
17
incentive compatibility inter-domain routing
incentives

• why doesnt a network overstate congestion?
• msecs congestion response gives diminishing
  returns (for TCP ?? ? v??)
• minutes upstream networks will route round more
  highly congested paths
• by sampling data N1 can see relative costs of
  paths to R1 thru N2 N3
• months persistent overstatement of congestion
• artificially reduces traffic demand (thru
  congestion response)
• ultimately reduces capacity element of revenue
• also incentivises provision, to compete with
  monopoly paths

18
long term congestion incentives
per-user policer
incentives

• effectively shuts out zombie hosts
• incentivises owners to fix them
• (also incentivises off-peak file-sharing)

cumulative multiple flows
incentive framework
downstreamcongestion,?i
downstreamcongestion,?i
congestionpricing
rate
policer/scheduler
policer/scheduler
Snd
19
incentives for other metrics
incentives

• downstream unloaded delay (emulated by TTL)
• approximates to ½ feedback response time (near
  source) ? RTT
• each node can easily establish its local
  contribution
• identical incentive properties to congestion
• increasing response time increases social cost
• physically impossible to be truthfully negative
• incentive mechanism identical to that of
  congestion
• assess other metrics case-by-case

20
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)

apps
21
single datagram-dominated traffic mix

• current Internet would collapse
• not designed for all eventualities
• 1012 devices, 109 users, RPCs, sensor nets, event
  avalanches
• with re-feedback
• service protected against completely uncorrelated
  traffic mix
• demanding users can still insure against risk
• for brief flows, TCP slow start sets rate limit
• not technology performance advances
• with re-feedback, once characterised path, can
  hit full rate

apps
22
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

apps
downstreamcongestion,?i
i
23
migration
classic origin
unchanged
unchanged
re-f/b origin

• approach
• realign metrics by modifying sender and/or
  receiver stack only
• unchanged router path characterisation (protocol
  routers)
• re-ECN possible without contravening existing ECN
  code-points
• reason changing hosts incremental changing
  routers flag day
• deployment path
• network operators add incentive mechanisms to
  edge routers
• add policers droppers, but permissively
  configured
• increasing strictness incentivises incremental
  host upgrades

deployment
24
summaryre-feedback incentive framework
policer
congestion,delay,
each packet header carriesview of its own
downstream path
premium
TCP-friendly
incentive framework
downstreamcongestion,?i
downstreamcongestion,?i
stateless dropper
downstreampath metricat rcvr, ?n
systematiccheating, ??c
congestionpricing
i
rate
0
routing
policer/scheduler
policer/scheduler
1
??c
dropper
dropper
so just sample packetsto check/enforce the
agreedcongestion response
adaptivedropprobability
Snd
downstreamcongestionprobability distribution
Rcv
discussion