1 / 12

congestion exposure BoF candidate protocol: re-ECN

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.

mari
Download Presentation

congestion exposure BoF candidate protocol: re-ECN

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript

  1. congestion exposure BoFcandidate protocol: re-ECN Bob BriscoeChief Researcher, BT Nov 2009 This work is partly funded by Trilogy, a research project supported by the European Communitywww.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 congestionas 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. -1 -1 congestion exposure uses drop or explicit congestion notification (ECN)[RFC3168] 1 1. Congested queue marks some packets (‘debits’) 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 2 2. Receiver feeds back marks Feedback path Networks Switches & routers Data packet flow Receiver Sender

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

  5. +1 +1 +1 -1 +1 -1 re-inserted feedback (re-feedback) = re-ECNsender exposes congestion to network 1 1. Congested queue marks some packets (‘debits’) • 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 3 3. Sender re-inserts feedback (re-feedback)into the forward data flow as ‘credit’ marks 2 2. Receiver feeds back marks Feedback path Networks Switches & routers Data packet flow Receiver Sender

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

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

  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. +1 +1 +1 -1 +1 -1 why won’t sender under-expose congestion? 1 1. Congested queue marks some packets (‘debits’) (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 3 3. Sender re-inserts feedback (re-feedback)into the forward data flow as credit marks 2 2. Receiver feeds back marks Feedback path Networks Routers Data packet flow Receiver Sender 4 4. Sender has to reveal congestion it will cause Example use: end-points still do congestion control.But network limits overall congestion 5 5. Cheaters will be persistently in debt So network can discard their packets (In this diagram no-one is cheating)

  10. TG VNC re-ECN status 10M 10M Server 1G 1G 1G 1G Intermediate Router 1G 1G • 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 100M 10M Client

  11. goals • network can measure contribution to congestionas 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. congestion exposure BoFcandidate protocol: re-ECN<draft-briscoe-tsvwg-re-ecn-tcp><draft-briscoe-tsvwg-re-ecn-tcp-motivation>re-ECN & re-feedback project page:<http://bobbriscoe.net/projects/refb/> Q&A

More Related