Fwd: Unofficial BoF on "re-ECN architectural intent"

Bob Briscoe <rbriscoe@xxxxxxxxxxxxxxx> · Wed, 21 Mar 2007 13:57:14 +0000

Folks,

Unofficial BoF (starting in 12mins).

Wed 21 March 1510-1640 (90mins) in Karlin I.

I've arranged with Marcia for cookies & drinks to be left outside the room 
part-way through, so I've scheduled a 10min break to go hunting and gathering.

Slides are here
<http://www.cs.ucl.ac.uk/staff/B.Briscoe/projects/refb/#Presentations>
Loads of spare slides for whatever questions you fire at me.

Agenda is below (unchanged from previous announcement). Aaron Falk will 
kindly be chairing this.

Cheers

Bob

Date: Tue, 20 Mar 2007 14:19:04 +0000
To: DCCP mailing list <dccp@xxxxxxxx>
From: Bob Briscoe <rbriscoe@xxxxxxxxxxxxxxx>
Subject: Unofficial BoF on "re-ECN architectural intent"

DCCPers,

"The architectural intent of the re-ECN protocol"
In Prague we'll be doing an unofficial 'Bar' BoF on this (see 
<http://www.ietf.org/tao.html> for what that is)

Wed 21 March 1510-1640 in Karlin I.

A number of people have asked for this, as they've found the short slots 
in IETF w-gs aren't really suitable to discuss and challenge the intent of 
what is effectively a proposal for major architectural change, albeit in 
one bit.

It's v relevant to DCCP, as it provides the environment for evolution of 
"responsible" new congestion controls, but it gives much more freedom than 
TCP-friendliness (I've explained why that's a broken concept anyway in ).

Proposed Bar BoF agenda:
Start 15:10
1. [ 5mins] Administrivia
2. [30mins] Architectural intent of re-ECN
            (including a simple abstraction of how it works)
3. [20mins] Questions & Answers
4. [10mins] Is there community interest in working in this problem space?
            IETF or IRTF?
            How best to go about architectural change.
            Next Steps.
5. [10mins] I'll try to get cookies & drinks in the room.
6. [15mins (squeezable/stretchable)] More questions & discussion.
End 16:40

Brief background and further links below...

============================================================================
The re-ECN protocol aims to make IP senders (including forwarders) 
accountable for the pain they inflict on others (congestion). The re-ECN 
protocol claims to allow different forms of congestion control to be 
policed in different ways, or not policed at all, depending on policy.

Embodied in re-ECN's design are implicit answers or deliberate non-answers 
to many subtle architectural and policy issues:
- who should decide on fairness?
- how do we expect networks as a whole to police traffic from other networks?
- what fairness policies might ISPs or groups of users want between them?
- not just provider networks, but self-provided (incl. ad hoc) networks?
- re-ECN claims to allow evolvability of congestion control. Assumptions?
- it claims to mitigate DDoS and provide the right incentives to fix it. How?
- it claims to do QoS more simply? Sure?
- how does re-ECN relate to routing?
- what about cheating?
- should we control the sender or the receiver or both?
- doesn't this just move the policing problem up a layer?
- what about layered networks (IP over MPLS, ethernet, IP in IP etc)?
- what likely outcome will we see for the Internet with this?
- what if we do nothing?
- why doesn't it solve world hunger?

Re-ECN: Adding Accountability for Causing Congestion to TCP/IP
<http://www.ietf.org/internet-drafts/draft-briscoe-tsvwg-re-ecn-tcp-03.txt>

Full list of supporting documentation and papers:
<http://www.cs.ucl.ac.uk/staff/B.Briscoe/projects/refb/>

Bob

____________________________________________________________________________
Notice: This contribution is the personal view of the author and does not 
necessarily reflect the technical nor commercial direction of BT plc.
____________________________________________________________________________
Bob Briscoe,                           Networks Research Centre, BT Research
B54/77 Adastral Park,Martlesham Heath,Ipswich,IP5 3RE,UK.    +44 1473 645196