Re-ECN: Adding Accountability for Causing Congestion to TCP/IP Bob Briscoe , BT & UCL Arnaud Jacquet, BT Alessandro Salvatori, BT IETF-64 tsvwg Nov 2005
context context context context initial draft protocol protocol protocol • IETF-63 Paris July 05 • new research results (SIGCOMM’05) using ECN nonce codepoints • TSVWG chair asked for our proposal by IETF-64 security apps security apps security apps • hold ECN nonce (RFC3540) at experimental status • re-ECN: adding accountability for causing congestion to TCP/IP initial draft: • draft-briscoe-tsvwg-re-ecn-tcp-00.txt * other formats: • www.cs.ucl.ac.uk/staff/B.Briscoe/pubs.html#retcp deployment deployment deployment ultimate intent: • standards track (hope for working group draft soon) intent today: • get you excited enough to read it, and break it status: • haven’t simulated this 2-bit IPv4/v6 proposal yet – our simulations based on a multibit ECN IPv6 extension header evaluation evaluation evaluation * changed 2 field names since draft-00 – new terminology in this presentation 2
context context context context the problem: accountability for causing congestion protocol protocol protocol • main concern • non-compliance with e2e congestion control (e.g. TCP-friendly)? • how can ingress netwk detect whole path congestion? police cc? security apps security apps security apps • not just per-flow congestion response smaller: per-packet • – single datagram ‘flows’ bigger: per-user deployment • deployment deployment – a congestion metric so users can be held accountable – 24x7 heavy sources of congestion, DDoS from zombie hosts even bigger: per-network • evaluation evaluation evaluation – a metric for holding upstream networks accountable if they allow their users to congest downstream networks 3
context context context context rate previous work cumulative inverse flows prop’nal protocol protocol protocol path response congestion e.g. TCP • detect high absolute rate [commercial boxes] security apps security apps security apps • but nothing wrong with high rate at low congestion • sampled rate response to local congestion [RED + sin bin] • but congestion typical at both ends (access networks) deployment • transport control embedded in networks [ATM] deployment deployment • but limits behaviours to those standardised by network operators • honest senders police feedback from rcvrs [ECN nonce] evaluation evaluation evaluation • but not all senders are community spirited (VoIP, video, p2p?, DoS) • per-packet, per-user & per-network congestion policing • minimal previous work 4
context context context basic idea (IP layer) • sender re-inserts congestion feedback into protocol protocol protocol protocol code- standard forward data: “re-feedback” point designation on every Echo-CE from transport (e.g. TCP) 00 not-ECT sender sets ECT(0) 10 ECT(0) security apps security apps security apps sets ECT(1) 01 ECT(1) else 11 CE deployment deployment deployment • and new Feedback-Established (FE) flag evaluation evaluation evaluation 5
context context context ECE in TCP code-point ECN rate 100% (recap) ECT(0) protocol protocol protocol protocol code- standard CE point designation 00 not-ECT 3% 0% 10 ECT(0) security apps security apps security apps resource 0 …i… n 01 ECT(1) index 11 CE N B R 1 S 1 N A N D deployment deployment deployment ECN rate 3% ECE CE evaluation evaluation evaluation 0% 6
context context context Echo-CE in TCP code-point re-ECN rate 3% 3% (sketch) ECT(0) protocol protocol protocol protocol 97% ECT(1) code- standard CE point designation 0.4% CE 00 not-ECT 3% 10 ECT(0) security apps security apps security apps resource 0 …i… n 01 ECT(1) index 11 CE N B R 1 S 1 N A N D on every Echo-CE from TCP, • deployment deployment sender sets ECT(0) , deployment else sets ECT(1) re-ECN rate, v i • at any point on path, 3% diff betw rates of ECT(0) & CE 2.6% is downstream congestion v i ≈ ≈ ECT(0) – CE ≈ ≈ • routers unchanged evaluation evaluation evaluation 0% 7
context context context code-point incentive rate 3% 3% framework ECT(0) protocol protocol protocol ECT(1) (user-network) CE • packets carry view of 3% downstream path security apps security aps security apps security apps congestion to each router • so ingress can police rate response N B R 1 – using path congestion S 1 N A N D declared by sender deployment deployment deployment policer • won’t snd or rcv just understate congestion? dropper re-ECN 3% • no – egress drops negative balance 2% evaluation evaluation evaluation 0% 8
context context context R 1 N B S 1 N A N D policer egress dropper (sketch) dropper cheating sender or receiver understates ECT(0) protocol protocol protocol egress code-point dropper rate = 2% 2% security apps security aps security apps security apps ECT(0) 98% ECT(1) 95% = CE 3% 0 …i… n deployment deployment deployment • drop enough traffic to make • simple per pkt algorithm rate of CE = ECT(0) – max 5 cmp’s, 5 adds, 1 shift • goodput best if rcv & snd • dropper treats traffic in bulk honest about feedback & re- • can spawn focused droppers evaluation evaluation evaluation feedback – misbehaving aggregates/flows prevalent in drop history 9
context context context R 1 N B S 1 N A N D policer ingress policer (sketch) dropper • packets arrive carrying view of downstream path congestion protocol protocol protocol • can police to any desired rate equation, eg TCP • token bucket implementation: drop whenever empties • bounded flow-state using sampling security apps security aps security apps security apps k √ ( 3 / 2 ) compliant rate s packet size ks x TCP ≈ T RTT T p p marking rate ∆ t inter-arrival time deployment deployment deployment actual rate x = s/ ∆ t • above equations are conceptual, in practice can re-arrange you get 1/p by counting bytes between ECT(0) marks • evaluation evaluation evaluation high perf. root extraction per ECT(0) mark challenging (like pulling teeth) • • for RTT need sister proposal for ‘ re-TTL ’ (tba) 10
context context context accountability for congestion other applications • congestion-history-based policer (congestion cap) protocol protocol protocol • throttles causes of past heavy congestion (zombies, 24x7 p2p) • DDoS mitigation security apps security aps security apps security apps • QoS & DCCP profile flexibility • ingress can unilaterally allow different rate responses to congestion • load sharing, traffic engineering deployment deployment deployment • multipath routers can compare downstream congestion R 1 N B S 1 N A N D • bulk metric for inter-domain SLAs or charges bulk volume of ECT(0) less bulk volume of CE • re-ECN, v i 3% evaluation evaluation evaluation • upstream networks that do £ £ nothing about policing, DoS, zombies etc 0% will break SLA or 11 get charged more
context context context flow start protocol protocol protocol protocol • re-ECN TCP capability handshake in draft • feedback established (FE) flag in IPv4 header or IPv6 extension • future-proofing if short flows or single datagrams dominate traffic mix security apps security apps security apps • FE flag only set by sender, only read by re-ECN security apps • leave FE=0 at flow start • if packet has FE=0, don ’ t include its ECN marking in bulk averages • sender incentive to be truthful about FE flag deployment deployment deployment • bit 48 (Currently Unused) flag in IPv4 header? • TCP flow start specifics in draft • guidelines for adding re-ECN to other transports in draft evaluation evaluation evaluation 12
context context context re-ECN incremental deployment protocol protocol protocol • only REQUIRED change is TCP sender behaviour • precision only if receiver is re-ECN capable too security apps security apps security apps • optional compatibility mode for ‘legacy’ ECN rcvrs • inclined to leave it out (so few Legacy-ECN hosts out there) • no change from ECN behaviour for • routers deployment deployment deployment deployment • tunnels • IPsec • middleboxes etc • add egress droppers and ingress policers over time evaluation evaluation evaluation • policers not necessary in front of trusted senders 13
context context context re-ECN deployment transition protocol protocol protocol • if legacy firewalls block FE=1, sender falls back to FE=0 • FE=0 on first packets anyway, so see connectivity before setting FE=1 • if sender has to wrongly clear FE=0, makes dropper over-strict for all security apps security apps security apps • sender (and receiver): re-ECN transport (from legacy ECN) • ingress policer (deliberately) thinks legacy ECN is highly congested – 50% for nonce senders, 100% for legacy ECN • policers should initially be configured permissively deployment deployment deployment deployment • over time, making them stricter encourages upgrade from ECN to re-ECN evaluation evaluation evaluation 14
Recommend
More recommend
