Re: [re-ECN] preliminary draft of problem statement- authors wanted

["Woundy, Richard" <[e-mail]>]

Toby,

Here are some ideas for the table of contents for the problem statement. I have stolen ideas for sections from problem statements from other WGs/BoFs, and stolen ideas for content from the existing re-ECN drafts, especially http://tools.ietf.org/html/draft-briscoe-tsvwg-re-ecn-tcp-motivation-00.

I would change "Myoptic Solutions" to "Existing Work". You have identified two existing ISP solutions: "rate limiting" and "volume limiting". I would add "simple best effort traffic and flow-rate fairness" (RFC5290), as well as ECN (RFC3168) with nonces (RFC3540). You can steal content from sections 3.1.2 and 4.7 of the motivation draft, of course.

I would add a section about use cases. The primary use case would seem to be an "incentive environment that ensures optimal sharing of capacity", although that could use a better title. Other use cases may include "DDoS mitigation", "end-to-end QoS", "traffic engineering", and "inter-provider service monitoring". (You can see I am stealing liberally from the motivation draft here. We'll have to see whether the other use cases are "core" to this group, or "freebies" that come along with re-ECN as a particular protocol.)

I would also add a section on requirements. Here are some initial ideas: enable a view of whole path congestion (both upstream and downstream congestion), enable policing of flows, and monitor the flow of congestion across ISP borders. Be responsive to real-time congestion in the network. Solve the problem at the IP layer; avoid making assumptions about the behavior of specific applications (e.g. be application agnostic). Enable a diversity of intra-domain and inter-domain congestion management practices. Don't force a "universal rate adaptable policy" such as TCP-friendliness. Enable incremental deployment and an evolution to new congestion responses. Support integrity of congestion notifications; that is, make it difficult to generate false positives and false negatives in congestion notifications. Be robust in the face of DoS attacks aimed at either congestion transparency itself (e.g. persistently negative flows for re-ECN), or at the network elements implementing congestion transparency (e.g. policers and droppers for re-ECN).

At some point, I would add a section for "definitions", but that content can wait until we see what terms have to be introduced into the other sections first.

-- Rich

-----Original Message-----
From: [e-mail] [mailto:[e-mail]] On Behalf Of [e-mail]
Sent: Friday, September 18, 2009 5:58 AM
To: [e-mail]
Subject: [re-ECN] preliminary draft of problem statement- authors wanted

 <<draft-moncaster-congestion-exposure-problem-00.txt>> Hi All,

Here is a very preliminary version of a Problem Statement for Congestion Exposure. It is mainly in note form and needs MAJOR bashing. I am hoping by posting it in this early form to persuade a few more people to volunteer as co-authors with me...

We need to have this in a reasonable shape by mid-October in order to make the initial submission deadline (which is scarily close - only 4 weeks and 4 days away).

Absolutely everything in the document is fair game for change including title, draft name, table of content, content, ...

Toby
___________________________________________________________________
Toby Moncaster, <[e-mail]> Networks Research Centre, BT B54/70 Adastral Park, Ipswich, IP53RE, UK.  [phone]