1. congestion exposure BoF candidate protocol: re-ECN Bob Briscoe Chief Researcher, BT Nov 2009 This work is partly funded by Trilogy, a research project supported by the European Community www.trilogy-project.org www.trilogy-project.org This work is investigative. It does not yet indicate the direction of BT’s production architecture.

2. goals network can measure contribution to congestion as easily as it measures volume today metric for neutral but sufficient capacity sharing Internet designed so endpoints deal with congestion endpoints expose congestion in packets to network purpose of this talk one protocol exists & implemented (x2) – concrete not asking BoF to bless this solution – a strong contender

3. 3 Feedback path Sender Receiver Networks congestion exposure uses drop or explicit congestion notification (ECN) [RFC3168] Switches & routers Data packet flow 1. Congested queue marks some packets (‘debits’) 2. Receiver feeds back marks 1 2 congestion signal without impairment then tiny queuing delay and tiny tiny loss for all traffic no need to avoid congestion to prevent impairment whether core, access or borders

4. 4 measuring contribution to congestion user’s contribution to congestion = bytes marked can transfer very high volume but keep congestion-volume very low similar trick for video streaming bit-rate time congestion time 10GB 0.01% marking 1MB 1% marking 1MB 300MB 100MB 3MB

5. Switches & routers Feedback path Sender Receiver +1+1 Networks 3. Sender re-inserts feedback (re-feedback) into the forward data flow as ‘credit’ marks 3 re-inserted feedback (re-feedback) = re-ECN sender exposes congestion to network important details bootstrap: send no less credit than likely debit in 1 RTT sender re-inserts feedback whether triggered by ECN or loss no changes required to IP or MPLS data forwarding Data packet flow 1. Congested queue marks some packets (‘debits’) 2. Receiver feeds back marks 1 2

6. 6 Switches & routers Data packet flow Sender Receivers +1+1 Networks packets expose congestion over rest of path from wherever you look at them +1+1 +1 0|0|2|7|6|0|50|0|0|9|4|2|1 - 0 0 1 8 1 8 4 whole path upstream (path so far) downstream (rest of path)

7. bulk congestion policing  example use of ConEx not proposing this for standardisation but need models like this to be possible bulk congestion policer Internet 0.3% congestion 0% 0.1% 2 Mb/s 0.3Mb/s 6 Mb/s Acceptable Use Policy 'congestion-volume' allowance: 35MB/day no other limits needed; no PIR, unlimited volume ~70GB data per day under typical conditions

8. 8 no time for other potential uses… see motivation draft & papers for… bulk congestion policing (or per flow) DDoS mitigation e2e QoS, all within best efforts, with no flow signalling relaxes unnecessary constraints on transport design self-admission control server / middlebox flow state exhaustion control wholesale & interconnect SLAs more speculative inter-domain traffic engineering? all-optical interconnects more feasible? replaces multiple access in shared access networks?

9. 9 Feedback path Data packet flow Sender Receiver +1+1 Routers Networks 3. Sender re-inserts feedback (re-feedback) into the forward data flow as credit marks 4. Sender has to reveal congestion it will cause Example use: end-points still do congestion control. But network limits overall congestion 5. Cheaters will be persistently in debt So network can discard their packets (In this diagram no-one is cheating) 3 5 4 why won’t sender under-expose congestion? 1. Congested queue marks some packets (‘debits’) 2. Receiver feeds back marks 1 2 (5) cheat detection: haven’t been able to avoid per-flow state but designed so flow state does not break shared fate principle agnostic to flow behaviour – just checks diff between 2 numbers per flow

10. 10 re-ECN status relatively stable draft of spec in IPv4&6 with TCP as transport – exemplar & full spec two independent prototype implementations (Linux) quick simple demo afterwards ns-2 implementation full security analysis resisted several perverse research community attacks Global Info Infrastructure Commission analysis public policy commercial technical feasibility TG Server Client VNC 10M 100M 10M 1G Intermediate Router

11. 11 goals network can measure contribution to congestion as easily as it measures volume today metric for neutral but sufficient capacity sharing purpose of this talk one protocol exists & implemented (x2) – concrete not asking BoF to bless this solution – a strong contender

12. 12 congestion exposure BoF candidate protocol: re-ECN re-ECN & re-feedback project page: draft-briscoe-tsvwg-re-ecn-tcpdraft-briscoe-tsvwg-re-ecn-tcp-motivationhttp://bobbriscoe.net/projects/refb/ Q&A