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

[<[e-mail]>]

Hi Rich,

Thanks for the extensive comments. This is just the sort of thing I am hoping to trigger by sending the draft in so early - always better to get significant structural comments before I have wasted too much time going down a blind alley...

More inline...

> -----Original Message-----
> From: Woundy, Richard [mailto:[e-mail]]
> Sent: 19 September 2009 00:47
> To: Moncaster,T,Toby,DER3 R
> Cc: [e-mail]
> Subject: RE: [re-ECN] preliminary draft of problem statement- authors
> wanted
> 
> 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 really wanted a title that conveyed a little more than just "existing work". But I agree "myopic" is the wrong word. Will add some of those other bits as well. Perhaps I should group them into categories (things the network does and things end-systems do?).


> 
> 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.)

This seems a good idea, but we need to try and not put the cart before the horse. This document is intended to stand independently of re-ECN and I actually want to write it in such a fashion that doesn't kill off other solutions... That means we can't tailor the list of use-cases to those ones that re-ECN covers! I reckon if we give the "core" use cases but hint that other things may be possible? How about "Incentive-based capacity sharing architecture"?


> 
> 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).

Definitely agree but as with the use-cases above I am keen to make the requirements general-enough to not just give re-ECN as the answer (even though that is the preferred answer at the moment). I would add "being transport-agnostic" to the list...

> 
> 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.

Will see if this is needed once there is a bit more text there...

Toby

> 
> -- 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]
> 
>