Re-ECN: Adding Accountability for Causing Congestion to TCP/IP Bob Briscoe, BT & UCL Arnaud Jacquet, BT Alessandro Salvatori, BT IETF-65 tsvwg Mar 2006.

Slides:



Advertisements
Similar presentations
End-host Perspectives on Congestion Management Murari Sridharan CONEX BOF, IETF 76, Hiroshima.
Advertisements

Re-ECN: Adding Accountability for Causing Congestion to TCP/IP draft-briscoe-tsvwg-re-ecn-tcp-03 Bob Briscoe, BT & UCL Arnaud Jacquet, Alessandro Salvatori.
Re-ECN: Adding Accountability for Causing Congestion to TCP/IP draft-briscoe-tsvwg-re-ecn-tcp draft-briscoe-tsvwg-re-ecn-tcp Bob Briscoe, BT & UCL Arnaud.
Philip Eardley, Bob Briscoe, Dave Songhurst - BT Francois Le Faucheur, Anna Charny, Vassilis Liatsos – Cisco Kwok-Ho Chan, Joe Babiarz, Stephen Dudley.
Philip Eardley, Bob Briscoe, Dave Songhurst - BT Research Francois Le Faucheur, Anna Charny – Cisco Kwok-Ho Chan, Joe Babiarz - Nortel IETF-64 tsvwg Nov.
Policing congestion response in an internetwork using re-feedback Bob Briscoe 1,2 Arnaud Jacquet 1, Carla Di Cairano- Gilfedder 1, Alessandro Salvatori.
Usage cases for Congestion Accounting Bob Briscoe Chief Researcher, BT Oct 2009 This work is partly funded by Trilogy, a research project supported by.
RSVP/Diffserv Yoram Bernet - Microsoft Raj Yavatkar - Intel.
ConEx Abstract Protocol What’s the Credit marking for? draft-mathis-conex-abstract-mech-00.txt draft-mathis-conex-abstract-mech-00.txt apologies from Bob.
Explicit Congestion Notification (ECN) RFC 3168 Justin Yackoski DEGAS Networking Group CISC856 – TCP/IP Thanks to Namratha Hundigopal.
1 Internet Networking Spring 2003 Tutorial 11 Explicit Congestion Notification (RFC 3168) Limited Transmit (RFC 3042)
1 Internet Networking Spring 2003 Tutorial 11 Explicit Congestion Notification (RFC 3168)
DoS-resistant Internet - progress Bob Briscoe Jun 2005.
A Real-Time Video Multicast Architecture for Assured Forwarding Services Ashraf Matrawy, Ioannis Lambadaris IEEE TRANSACTIONS ON MULTIMEDIA, AUGUST 2005.
1 Spring Semester 2007, Dept. of Computer Science, Technion Internet Networking recitation #8 Explicit Congestion Notification (RFC 3168) Limited Transmit.
A broadband incentive solution re-feedback Bob Briscoe, BT Research Nov 2005 CFP broadband incentives w-g.
Whither Congestion Control? Sally Floyd E2ERG, July
Presentation on Osi & TCP/IP MODEL
Integrated Services (RFC 1633) r Architecture for providing QoS guarantees to individual application sessions r Call setup: a session requiring QoS guarantees.
Viability of Congestion Exposure. Framing the Discussion This discussion is about congestion exposure – not any specific solution Viability and tractability.
Rev PA Signaled Provisioning of the IP Network Resources Between the Media Gateways in Mobile Networks Leena Siivola
Tunnelling of Explicit Congestion Notification draft-briscoe-tsvwg-ecn-tunnel-08.txt draft-briscoe-tsvwg-ecn-tunnel-08.txt Bob Briscoe, BT IETF-77 tsvwg.
1 Guidelines for Adding Congestion Notification to Protocols that Encapsulate IP draft-briscoe-tsvwg-ecn-encap-guidelines-01 Bob Briscoe IETF-85 Nov 2012.
Quick-Start for TCP and IP A.Jain, S. Floyd, M. Allman, and P. Sarolahti ICSI, April 2006 This and earlier presentations::
Interconnect QoS business requirements Bob Briscoe BT Group CTO.
Datagram Congestion Control Protocol
PCN WG (Pre-Congestion Notification) – a brief status update Philip Eardley, BT TSVAREA, IETF-73 Minneapolis 18 Nov 08
6/1/991 Internetworking connectionless and connection-oriented networks Malathi Veeraraghavan Mark Karol Polytechnic UniversityBell Laboratories
Congestion marking for low delay (& admission control) Bob Briscoe BT Research Mar 2005.
Controlling Internet Quality with Price Market Managed Multiservice Internet Bob Briscoe BT Research, Edge Lab, University College London & M3I Technical.
Pushing Packet Processing to the Edge Scheduling in Optics is the Wrong Answer for Fine-Grained Resource Sharing Bob Briscoe Chief Researcher, BT Group.
1 Countering DoS Through Filtering Omar Bashir Communications Enabling Technologies
Byte and Packet Congestion Notification draft-briscoe-tsvwg-byte-pkt-mark-01.txt draft-briscoe-tsvwg-byte-pkt-mark-01.txt Bob Briscoe, BT & UCL IETF-70.
Re’Arch 2008 Policing Freedom… to use the Internet Resource Pool Arnaud.Jacquet, Bob.Briscoe, Toby.Moncaster December
Real-time Flow Management 2 BOF: Remote Packet Capture Extensions Jürgen Quittek NEC Europe Ltd, Heidelberg, Germany Georg Carle GMD.
Social & Economic Control of Networks Bob Briscoe Chief Researcher BT Networks Research Centre Jul 2007.
Congestion exposure BoF candidate protocol: re-ECN Bob Briscoe Chief Researcher, BT Nov 2009 This work is partly funded by Trilogy, a research project.
Tunnelling of Explicit Congestion Notification draft-briscoe-tsvwg-ecn-tunnel-03.txt draft-briscoe-tsvwg-ecn-tunnel-03.txt Bob Briscoe, BT IETF-75 saag.
Byte and Packet Congestion Notification draft-ietf-tsvwg-byte-pkt-congest-00.txt draft-ietf-tsvwg-byte-pkt-congest-00.txt Bob Briscoe, BT & UCL IETF-73.
Controlled Load (CL) Service using distributed measurement-based admission control (D-MBAC) Bob Briscoe, Gabriele Corliano, Phil Eardley, Peter Hovell,
Tunnelling of Explicit Congestion Notification draft-briscoe-tsvwg-ecn-tunnel-02.txt draft-briscoe-tsvwg-ecn-tunnel-02.txt Bob Briscoe, BT IETF-74 tsvwg.
Downstream knowledge upstream re-feedback Bob Briscoe Arnaud Jacquet, Carla Di Cairano- Gilfedder, Andrea Soppera & Martin Koyabe BT Research.
QoS interconnect best without effort Bob Briscoe Chief Researcher BT Sep 2009 This work is partly funded by Trilogy, a research project supported by the.
Guaranteed QoS Synthesiser (GQS) Bob Briscoe, Peter Hovell BT Research Jan 2005.
1 Note Well Any submission to the IETF intended by the Contributor for publication as all or part of an IETF Internet-Draft or RFC and any statement made.
Re-ECN: Adding Accountability for Causing Congestion to TCP/IP Bob Briscoe, BT & UCL Arnaud Jacquet, BT Alessandro Salvatori, BT CRN DoS w-g, Apr 2006.
CONEX BoF. Welcome to CONEX! Chairs: –Leslie Daigle –Philip Eardley Scribe Note well.
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.
Making stuff real re-feedback Bob Briscoe, BT Research Nov 2005 CRN DoS resistant Internet w-g.
Solving this Internet resource sharing problem... and the next, and the next Bob Briscoe Chief Researcher BT Group (& UCL) Lou Burness, Toby Moncaster,
Interconnect QoS settlements & impairments Bob Briscoe BT Group CTO.
Network Performance Isolation in Data Centres using Congestion Policing draft-briscoe-conex-data-centre-01.txt draft-briscoe-conex-data-centre-01.txt Bob.
1 Note Well Any submission to the IETF intended by the Contributor for publication as all or part of an IETF Internet-Draft or RFC and any statement made.
Support for ECN and PCN in MPLS networks draft-davie-ecn-mpls-00.txt Bruce Davie Cisco Systems Bob Briscoe June Tay BT Research.
Byte and Packet Congestion Notification draft-briscoe-tsvwg-byte-pkt-mark-02.txt draft-briscoe-tsvwg-byte-pkt-mark-02.txt Bob Briscoe, BT & UCL IETF-71.
Generic Aggregation of Resource Reservation Protocol (RSVP) for IPv4 and IPv6 Reservation over PCN domains Georgios Karagiannis, Anurag Bhargava draft-karagiannis-pcn-tsvwg-rsvp-pcn-01.
An End-to-End Service Architecture r Provide assured service, premium service, and best effort service (RFC 2638) Assured service: provide reliable service.
Congestion Notification Process for Real-Time Traffic draft-babiarz-tsvwg-rtecn-04.txt Jozef Babiarz Kwok Ho Chan
K. Salah1 Security Protocols in the Internet IPSec.
Philip Eardley, Bob Briscoe, Dave Songhurst - BT Francois Le Faucheur, Anna Charny, Vassilis Liatsos – Cisco Kwok-Ho Chan, Joe Babiarz, Stephen Dudley.
Layered Encapsulation of Congestion Notification draft-briscoe-tsvwg-ecn-tunnel-01.txt draft-briscoe-tsvwg-ecn-tunnel-01.txt Bob Briscoe, BT IETF-72 tsvwg.
Support for ECN and PCN in MPLS networks
Bob Briscoe, BT IETF-73 pcn Nov 2008
Internet Networking recitation #9
Inter domain signaling protocol
Bob Briscoe, BT Murari Sridharan, Microsoft IETF-84 ConEx Jul 2012
Bob Briscoe, BT IETF-72 tsvwg Jul 2008
CONEX BoF.
Internet Networking recitation #10
ECN Experimentation draft-black-ecn-experimentation
Presentation transcript:

Re-ECN: Adding Accountability for Causing Congestion to TCP/IP Bob Briscoe, BT & UCL Arnaud Jacquet, BT Alessandro Salvatori, BT IETF-65 tsvwg Mar 2006

2 context problem statement (§1) previous draft-00 focused on how to do policing problem solved is actually how to allow some networks to do policing conservative networks might want to throttle if unresponsive to congestion (VoIP, video, DDoS) middle ground might want to cap congestion caused per user (e.g. 24x7 heavy sources) liberal networks open access, no restrictions evolution of hi-speed/different congestion control,... new worms many believe Internet is broken not IETF role to pre-judge which is right answer to these socio-economic issues Internet needs all these answers – balance to be determined by natural selection ‘do-nothing’ doesn’t maintain liberal status quo, we just get more walls re-ECN goals just enough support for conservative policies without breaking ‘net neutrality’ manage evolution of new congestion control, even for liberal → conservative flows nets that allow their users to cause congestion in other nets, can be held accountable

...specific link & tunnel (non-)issues re-ECN in IP... border policing for admission control accountability/control/policing (e2e QoS, DDoS damping, cong’n ctrl policing) doc roadmap Re-ECN: Adding Accountability for Causing Congestion to TCP/IP draft-briscoe-tsvwg-re-ecn-tcp-01 intent §3: overview in TCP/IP §4: in TCP & othersstds §5: in IP §6: accountability appsinform’l Re-ECN: Adding Accountability for Causing Congestion to TCP/IP draft-briscoe-tsvwg-re-ecn-tcp-01 intent §3: overview in TCP/IP §4: in TCP & othersstds §5: in IP §6: accountability appsinform’l netwk host cc netwk cc link Emulating Border Flow Policing using Re-ECN on Bulk Data draft-briscoe-tsvwg-re-ecn-border-cheat-00 intent: informational Emulating Border Flow Policing using Re-ECN on Bulk Data draft-briscoe-tsvwg-re-ecn-border-cheat-00 intent: informational RSVP Extensions for Admission Control over Diffserv using Pre-congestion Notification draft-lefaucheur-rsvp-ecn-00 intent adds congestion f/b to RSVPstds RSVP Extensions for Admission Control over Diffserv using Pre-congestion Notification draft-lefaucheur-rsvp-ecn-00 intent adds congestion f/b to RSVPstds dynamicsluggish... QoS signalling (RSVP/NSLP) UDPTCPDCCP hi speed cc

4 completely updated draft-01 Re-ECN: Adding Accountability for Causing Congestion to TCP/IP IETF-64 Vancouver Nov 05 initial draft, intent then: –hold ECN nonce (RFC3540) at experimentalRFC3540 –get you excited enough to read it, and break it thanks to reviewers (on and off-list); you broke it (co-author noticed flaw too) now updated draft: draft-briscoe-tsvwg-re-ecn-tcp-01.txtdraft-briscoe-tsvwg-re-ecn-tcp-01.txt ultimate intent: standards track immediate intent:re-ECN worth using last reserved bit in IP v4? context

5 propose Re-ECN Extension (RE) flag for IPv4: propose to use bit 48 (was reserved) set by sender, unchanged e2e once flow established sender re-inserts ECN feedback into forward data (“re-ECN”) as follows re-ECN sender always sets ECT(1) on every congestion event from transport (e.g. TCP) senderblanks RE elsesets RE conceptually, ‘ worth ’ of packet depends on 3 bit `codepoint ’ aim for zero balance of worth in flow changed re-ECN wire protocol in IPv4 (§3) protocol RE ECN ECT(1) 01 CE 11 sender (credit) [RFC3168] ECN markingRFC3168 router (debit) worth Diffserv ECN RE

6 flow bootstrap feedback not established ( FNE ) codepoint; RE=1, ECN=00 sent when don’t know which way to set RE flag, due to lack of feedback ‘worth’ +1, so builds up credit when sent at flow start after idle >1sec next packet MUST be FNE enables deterministic flow state mgmt (policers, droppers, firewalls, servers) FNE packets are ECN-capable routers MAY ECN mark, rather than drop strong condition on deployment (see draft) FNE also serves as state setup bit [Clark, Handley & Greenhalgh] protocol-independent identification of flow state set-up for servers, firewalls, tag switching, etc don’t create state if not set may drop packet if not set but matching state not found firewalls can permit protocol evolution without knowing semantics some validation of encrypted traffic, independent of transport can limit outgoing rate of state setup considering I-D [Handley & Greenhalgh] state-setup codepoint independent of, but compatible with, re-ECN FNE is ‘soft-state set-up codepoint’ (idempotent), to be precise protocol

7 extended ECN codepoints: summary and new Feedback-Established (FE) flag extra semantics backward compatible with previous ECN codepoint semantics ECN code- point ECN [RFC3168] codepointRFC3168 RE flag Extended ECN codepoint re-ECN meaning`worth’ 00not-ECT 0Not-RECT Not re-ECN capable transport 1FNE Feedback not established +1 01ECT(1) 0Re-Echo Re-echo congestion event +1 1RECT Re-ECN capable transport 0 10ECT(0) 0--- ‘Legacy’ ECN use 1--CU-- Currently unused 11CE 0CE(0) Congestion experienced with Re-Echo 0 1CE(-1) Congestion experienced protocol

8 security apps other changes in draft (27pp → 65pp) easter egg added :) re-ECN in TCP fully spec’d (§4), including ECN-capable SYN network layer (§5) OPTIONAL router forwarding changes added –preferential drop: improves robustness against DDoS –ECN marking not drop of FNE control and management section added accountability/policing applications described (§6) incentive framework fully described –example ingress policers & egress dropper described –pseudo-code TBA DDoS mitigation explained why it enables simpler ways to do e2e QoS, traffic engineering, inter-domain SLAs (still ref’d out) incremental deployment added (§7) → next slide architectural rationale added (§8) security considerations added (§10) → next slide but one

9 added incremental deployment (§7: 5½pp) brings together reasoning for wire protocol choices added deployment scenarios & incentives everyone who needs to act, must have strong incentive to act and incentives must arise in the order of required deployment main new messages first step to break ECN deployment deadlock –edge-edge PCN for end-to-end controlled load (CL) QoS next step: greed and fear motivators –help TCP (naively friendly) against greedy (streaming) apps –probably vertically integrated (conservative) operators first –3GPP devices leak deployment to other networks by roaming unilateral deployment per network... deployment

10 deployment re-ECN incremental deployment on every congestion event from TCP, sender blanks RE, else sets RE at any point on path, diff betw fractions of RE & CE is downstream congestion routers unchanged Echo in TCP RE ECN ECT(1) 01 CE 11 worth 0% re-ECN fraction, v i 3% v i  RE – CE 0 …i… n resource index RE NANA NBNB R1R1 S1S1 2.6% 0.4% CE CE S2S2 dropper policer interconnect penalties unpoliced (liberal) network policed (conservative) network 3%

11 added re-ECN security considerations ( §10 ) egress dropper –robust against attack that plays-off against ingress policing –robust against state exhaustion attacks (by design of FNE ) –write-up of state aggregation implementation TBA –believe new protocol allows dropper to be robust against dynamic attacks working on preventing collateral damage where malicious source spoofs negative traffic like someone else’s flow see also limitations text added (§6.3) – presented in Vancouver tsvwg posting “traffic ticketing considered ineffective or harmful” (26 Jan ‘06) security of re-ECN deliberately designed not to rely on crypto provoking you to break re-ECN summary

12 summary enables ‘net neutral’ policing of causes of congestion liberal networks can choose not to police, but still accountable simple architectural fix generic accountability hook per datagram requires one bit in IP header ECN nonce of limited scope in comparison fixed vulnerabilities so far by making it simpler working on robustness to new attacks detailed incremental deployment story summary

13 plans in IETF split draft into two and fill some ‘TBAs’: protocol spec accountability/policing applications implementation/simulation next re-TTL draft planned (Appendix E gives exec summary) independent flow state setup draft (possibly) spec detail more than sufficient for intensive review ~20 controversial points highlighted strongly encourage review on the tsvwg list changing IPv4 header isn’t a task we’ve taken on lightly summary

Re-ECN: Adding Accountability for Causing Congestion to TCP/IP draft-briscoe-tsvwg-re-ecn-tcp-01.txt draft-briscoe-tsvwg-re-ecn-tcp-01.txt Q&A

Emulating Border Flow Policing using Re-ECN on Bulk Data Bob Briscoe, BT & UCL Arnaud Jacquet, BT Alessandro Salvatori, BT IETF-65 tsvwg Mar 2006

16 simple solution to a hard problem? Emulating Border Flow Policing using Re-ECN on Bulk Data initial draft: draft-briscoe-tsvwg-re-ecn-border-cheat-00draft-briscoe-tsvwg-re-ecn-border-cheat-00 ultimate intent: informational exec summary:claim we can now scale flow reservations to any size internetwork and prevent cheating context

17 context...specific link & tunnel (non-)issues re-ECN in IP... border policing for admission control accountability/control/policing (e2e QoS, DDoS damping, cong’n ctrl policing) doc roadmap Re-ECN: Adding Accountability for Causing Congestion to TCP/IP draft-briscoe-tsvwg-re-ecn-tcp-01 intent §3: overview in TCP/IP §4: in TCP & othersstds §5: in IP §6: accountability appsinform’l Re-ECN: Adding Accountability for Causing Congestion to TCP/IP draft-briscoe-tsvwg-re-ecn-tcp-01 intent §3: overview in TCP/IP §4: in TCP & othersstds §5: in IP §6: accountability appsinform’l netwk host cc netwk cc link Emulating Border Flow Policing using Re-ECN on Bulk Data draft-briscoe-tsvwg-re-ecn-border-cheat-00 intent: informational Emulating Border Flow Policing using Re-ECN on Bulk Data draft-briscoe-tsvwg-re-ecn-border-cheat-00 intent: informational RSVP Extensions for Admission Control over Diffserv using Pre-congestion Notification draft-lefaucheur-rsvp-ecn-00 intent adds congestion f/b to RSVPstds RSVP Extensions for Admission Control over Diffserv using Pre-congestion Notification draft-lefaucheur-rsvp-ecn-00 intent adds congestion f/b to RSVPstds dynamicsluggish... QoS signalling (RSVP/NSLP) UDPTCPDCCP hi speed cc

18 context problem statement flow admission control a network cannot trust its neighbours not to act selfishly if it asks them to deny admission to a flow –it has to check the neighbour actually has blocked the data if it accepts a reservation –it has to check for itself that the data fits within the reservation traditional solution flow rate policing at borders can pre-congestion-based admission control span the Internet? without per-flow processing at borders? why should I block flows? N D (CL) N A (CL) N C (CL) (N) reserved congested

19 solution: use re-ECN ingress gateway blanks RE, in same proportion as fraction of CE arriving at egress at any point on path, bulk diff betw fractions of RE & CE is downstream congestion routers unchanged 3% Congestion Level Estimate in RSVP extension protocol RE ECN ECT(1) 01 CE 11 worth 0% downstream congestion 3% v i  RE – CE resource index RE NANA NBNB NDND EG 1 IG 1 2.6% 0.4% CE CE bulk marking monitor 3% Re-Echo (black) into data 3%

20 £ $ inter-domain accountability for congestion metric for inter-domain SLAs or usage charges N B applies penalty to N A in proportion to bulk volume of RE less bulk volume of CE over, say, a month could be tiered penalties, directly proportionate usage charge, etc. flows and f’back de-aggregate precisely to responsible networks see draft for fail-safes against misconfigs etc. 0% downstream congestion 3% NANA NBNB NDND EG 1 IG 1 2.6% 2.1% security aps

21 security aps note well: not standardising contracts want to avoid protocols that depend on particular business models only standardise the protocol then networks can choose to use the metric in various ways the contractual arrangement was an example to prove a solution exists networks can choose other, broadly similar arrangements or choose not to use it, and to do per-flow processing instead only concerns interconnection within Diffserv region

22 security aps why should ingress re-echo honestly? if N D detects persistent imbalance between RE and CE, triggers sanctions probably not drop –raise mgmt alarm –sanction out of band 0% 2% downstream congestion  RE – CE resource index RE CE 3% NANA NBNB NDND EG 1 IG 1 3% 2% Re-Echo (black) into data (understatement)

23 summary claim we can now scale flow reservations to any size internetwork and prevent cheating without per-flow processing in Internet-wide Diffserv region just bulk passive counting of packet marking over, say, a month see draft for why this is a sufficient emulation of per-flow policing results of security analysis, considering collusions etc. protocol details (aggregate & flow bootstrap, etc) border metering algorithms, etc comments solicited, now or on list

Emulating Border Flow Policing using Re-ECN on Bulk Data draft-briscoe-tsvwg-re-ecn-border- cheating-00.txt draft-briscoe-tsvwg-re-ecn-border- cheating-00.txt Q&A

25 intro path congestion typically at both edges congestion risk highest in access nets cost economics of fan-out but small risk in cores/backbones failures, anomalous demand 00 bandwidth cost, C £/bps aggregate pipe bandwidth, B /bps C  1  B NANA NBNB NDND R1R1 S1S1

26 context you MUST do this you may not do this logically consistent statements build-time compliance –usual standards compliance language (§2) run-time compliance –incentives, penalties (§6 throttling, dropping, charging) hook in datagram service for incentive mechanisms they can make run-time compliance advantageous to all

27 previous re-ECN protocol (IP layer) Feedback-Established (FE) flag sender re-inserts congestion feedback into forward data: “re-feedback” on every Echo-CE from transport (e.g. TCP) sendersets ECT(0) elsesets ECT(1) ECN code- point standard designation 00not-ECT 10ECT(0) 01ECT(1) 11CE protocol IPv4 control flags FEDFMF

28 re-ECN (sketch) on every congestion event from TCP, sender blanks RE, else sets RE at any point on path, diff betw fractions of RE & CE is downstream congestion routers unchanged Echo in TCP protocol RE ECN ECT(1) 01 CE 11 worth 0% re-ECN fraction, v i 3% v i  RE – CE 0 …i… n resource index RE NANA NBNB NDND R1R1 S1S1 2.6% 0.4% CE CE

29 re-ECN in TCP (§4) updated flow start now fully spec ’ d (incl. example session) goal: all packets can be ECN capable can now allow ECN capable SYN (and SYN ACK) –with a strong deployment condition (see draft) pure ACKs, re-transmissions, window probes: still Not-ECT re-ECN hosts don’t need ECN nonce [RFC3540] supportRFC3540 protocol

30 accountability for congestion other applications congestion-history-based policer (congestion cap) throttles causes of past heavy congestion (zombies, 24x7 p2p) DDoS mitigation QoS & DCCP profile flexibility ingress can unilaterally allow different rate responses to congestion load sharing, traffic engineering multipath routers can compare downstream congestion bulk metric for inter-domain SLAs or charges bulk volume of ECT(0) less bulk volume of CE upstream networks that do nothing about policing, DoS, zombies etc will break SLA or get charged more security aps £ £ 0% re-ECN, v i 3% NANA NBNB NDND R1R1 S1S1

31 security aps congestion competition – inter-domain routing if congestion → profit for a network, why not fake it? upstream networks will route round more highly congested paths N A can see relative costs of paths to R 1 thru N B & N C the issue of monopoly paths incentivise new provision collusion issues require market regulation NANA NBNB NCNC NDND R1R1 S1S1 ? down- stream route cost, Q i resource sequence index, i faked congestio n ? routin g choice

32 border anti-cheating solution (CL) (N) reserved % Re-Echo into data 3% CE feedback (RSVP)

33 BT IPR related to draft-briscoe-tsvwg-re-ecn-tcp-00.txt draft-briscoe-tsvwg-re-ecn-tcp-00.txt See IPR declaration at which overrides this slide if there is any conflict 1)WO 2005/ Mar 2004published 2)WO 2005/ Mar 2004published 3)PCT/GB 2005/ May )GB (EP )31 Jan )GB (EP )07 Feb 2005 BT hereby grants a royalty-free licence under any patent claims contained in the patent(s) or patent application(s) disclosed above that would necessarily be infringed by implementation of the technology required by the relevant IETF specification ("Necessary Patent Claims") for the purpose of implementing such specification or for making, using, selling, distributing or otherwise lawfully dealing in products or services that include an implementation of such specification provided that any party wishing to be licensed under BT’s patent claims grants a licence on reciprocal terms under its own Necessary Patent Claims. context