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. now next future intro goals & non-goals, approach • goals & non-goals • goal: fix Internet’s 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 Communications Innovation Institute

3. rate cumulativeTCPs RTT,T intro the problem: rate policing • 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 shouldn’t 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,ρ Communications Innovation Institute

4. pre-requisite knowledge: explicit congestion notification (ECN) IETF proposed std: RFC3168 Sep 2001 most recent change to IPv4&6 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) DSCP ECN 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 Communications Innovation Institute

6. info control info control& info control control control control& info 7 before... ...after re-feedback 0 8 R1 8 13 3 0 7 control& info receiver aligned 2 9 S1 control& info control& info 0 control& info R2 S2 control& info -2 -7 -2 -5 -1 -5 -7 -1 control& info re-inserted downstream knowledge upstream: the idea 10 16 propg’n timecongestionhop countetc 7 11 3 16 16 16 11 11 11 14 R1 10 10 16 8 S1 R2 S2

7. intro downstream knowledge upstream — re-feedback metric,h h0(t+T) 3 nodesequenceindex,i h0(t) m1 1 hz 0 1 2 ... i ... n he(t) hn 2 sequence of relays on a network path receiver sender Communications Innovation Institute

8. incentive framework incentives downstreampath metric,ρi congestionpricing routing i policer/scheduler dropper Snd Rcv Communications Innovation Institute

9. downstream path metric at receiver downstreampath metricat rcvr, ρn naïvedropper incentiveframework 0 downstreamcongestionprobability distribution i dropper Rcv

10. penalising uncertain misbehaviour downstreampath metricat rcvr, ρn stateless dropper incentiveframework systematiccheating, ρc 0 1 i ρc dropper dropper adaptivedropprobability downstreamcongestionprobability distribution Rcv

11. downstream path metric at receiver downstreampath metricat rcvr, ρn statelessdropper incentiveframework no systematiccheating, ρc = 0 0 downstreamcongestionprobability distribution i dropper Rcv Communications Innovation Institute

12. 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 Communications Innovation Institute

13. 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

14. R1 S1 incentive compatibility – hosts Δρc incentives 0 net value to end-points,ΔU • incentivise: • responsible actions • honest words dominant strategy scheduler/policer dropper push-back dropper ideal overstatement of downstream path metric at sourceΔρc practical 0 Communications Innovation Institute

15. inter-domain policing incentives • 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, TaisQ = ΣTa ρi+ • ρi metered by single bulk counter on each interface • note: negative ρi worthless – creates incentive to deploy droppers downstreampath metric, ρi ρAB ρBD i N2 congestion profit, Π:Π1 = – (λρ)12 Π2 = +(λρ)12 – (λρ)24Π4 = + (λρ)24per packet N1 R1 N4 S1 Capacity price,ηsigndepends on relative connectivity Communications Innovation Institute

16. 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 Communications Innovation Institute

17. distributed denial of service • merely enforcing congestion response • honest sources • increase initial metric & reduce rate • malicious sources • if do increase initial metric • policer at attacker’s ingress forces rate response • have to space out packets even at flow start • if don’t 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 Communications Innovation Institute

18. classic origin migration unchanged unchanged • 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 re-f/b origin deployment Communications Innovation Institute

19. 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 dropper dropper ρc so just sample packetsto check/enforce the agreedcongestion response adaptivedropprobability Snd downstreamcongestionprobability distribution Rcv discussion Communications Innovation Institute