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
|
