Re: [re-ECN] FW: New Version Notification for draft-moncaster-congestion-exposure-problem-01

[Bob Briscoe <[e-mail]>]

Toby, Mirja & fellow co-authors,

Thank you for this nice fairly succinct statement of the problem.

I've given it a careful review. I've used MS WOrd 
annotations (the one thing it's good at) which 
are shown in the pdf I've uploaded here:
<http://bobbriscoe.net/projects/refb/draft-moncaster-congestion-exposure-problem-01_rvw_rjb.pdf> 
(.doc for source file)

It looks like a lot of annotation (it is), but I 
want to emphasise that the basic document is 
really sound. The large majority of my annotation 
is editorial, not changing the message.

I'm afraid I've worked through this problem for a 
number of years now, so I have found efficient 
ways to explain the problem to different 
audiences - hence my comments all over it.

1/ My main point of disagreement is to avoid 
describing the problem as too much congestion. 
The amount of congestion isn't the problem. 
Saying it is won't help, as people rightly won't 
believe us. The problem is capacity sharing. 
Congestion (exposure) is the solution to that problem. It's not the problem.

Yes, capacity sharing only becomes a problem when 
there is congestion, so there won't be too much 
of a problem when there's little congestion. But 
a problem statement needs to be clear about stating the problem precisely.

Framing the top level problem as capacity 
sharing, allows us to lead into the problem 
really being about accountability for congestion and hence congestion exposure.

You'll see I've tried to replace the first part 
of section 2 "The problem" on this basis. I also 
thought we should start by addressing those who 
would throw capacity at the problem. You'll see 
text that says that a data network with no 
congestion just means the transport protocols are 
broken. It would contradict this to say 
congestion is a problem - it's not - it's healthy 
and natural in a data network.

2/ I also suggested a near complete re-write of 
"4. Why now?" I didn't find that the given 
argument rang true. I believe the suggested 
replacement text gives good strong reasoning for "Why now?".

I've suggested adding more paras here, but I've 
removed plenty of paras from elsewhere, some of 
which are re-introduced here. So the length 
overall shouldn't be too much greater if you choose to use my suggestions.

____
Finally, of course, these are only suggestions - 
up to the editor what to take or leave.

Cheers



Bob

At 16:57 16/10/2009, Mirja Kuehlewind wrote:
>Hi,
>
>I think it's better now to not have that much about economic aspects in the
>problem statement. Even though I would like to add some comments:
>
>I'm missing the point that honest exposure of rest-of-path congestion and
>(ingress) policing can lead to an incentive (framework) for users to share
>the bandwidth fairly with other user (with respect to individual current
>needs of every user). And it's just barely mentioned that the fair share
>between users will give one single user more capacity when it is actually
>needed. And this is the reason that this system might be deployed in future.
>I could imagine to address this point at the end 
>of the introduction and maybe
>also as an use case...?
>
>Regarding the security considerations one point 
>is that depending on the usage
>one's can take advantage of over- or understating congestion in the
>sender/receiver/network-node/border-router.
>
>Mirja
>
>
>On Thursday 15 October 2009 18:08:29 [e-mail] wrote:
> > As promised a new version of the problem statement. There have been
> > extensive changes in this version trying to take into account comments from
> > a number of people. The structure has changed slightly and I have removed
> > an awful lot of the text about economics. I am possibly tempted to put some
> > of that back in as an appendix but only if people think it actually adds
> > significantly to the problem statement.
> >
> > Overall I hope this is now clearer at identifying the problem (lack of
> > congestion information) an effect of this problem (ISPs unable to tell
> > which traffic is a problem) and then shows how congestion exposure might be
> > the solution.
> >
> > One glaring omission is a change log between this and version 00...
> >
> > I have uploaded the XML version for those of you that use xml2rfc. In
> > theory it should be in the same directory as the txt version. I have
> > included any non-standard references "inline" in the xml which makes it
> > messy but self-contained.
> >
> > Big gaps still needing work are:
> >
> > Section 7 on Use Cases. I would like to concentrate on just 1 or 2 here as
> > examples...
> >
> > Section 9 Security. This should concentrate on direct attacks on congestion
> > exposure (DoS and dishonest declaration).
> >
> > Section 4 is also a little weak.
> >
> > I am going to have to concentrate on other things now at least until late
> > next week so any volunteers to take the editing token?
> >
> > Toby
> >
> > ____________________________________________________________________
> > Toby Moncaster, Senior Researcher, Network Infrastructure Practice
> > B54/70 Adastral Park, Ipswich, IP53RE, UK.  [phone]
> >
> >
> >
> > -----Original Message-----
> > From: IETF I-D Submission Tool [mailto:[e-mail]]
> > Sent: 15 October 2009 17:00
> > To: Moncaster,T,Toby,DEE1 R
> > Cc: Krug,AL,Louise,DES3 R; [e-mail];
> > [e-mail]; [e-mail];
> > [e-mail] Subject: New Version Notification for
> > draft-moncaster-congestion-exposure-problem-01
> >
> >
> > A new version of I-D, draft-moncaster-congestion-exposure-problem-01.txt
> > has been successfuly submitted by T Moncaster and posted to the IETF
> > repository.
> >
> > Filename:     draft-moncaster-congestion-exposure-problem
> > Revision:     01
> > Title:                The Need for Congestion Exposure in the Internet
> > Creation_date:        2009-10-15
> > WG ID:                Independent Submission
> > Number_of_pages: 15
> >
> > Abstract:
> > The success of the Internet is largely down to the elegant manner in
> > which it shares capacity amongst all users while avoiding congestion
> > collapse.  However this relies on the cooperation of all end users to
> > work efficiently.  Increasingly a small minority of users are able to
> > grab larger and larger shares of the network leading ISPs to impose
> > arbitrary controls on traffic.  These controls set ISPs on a direct
> > collision course with their customers and the regulators.
> >
> > The root of the problem lies in the fact the ISPs are unable to see
> > the most important information about the traffic - namely the amount
> > of congestion that traffic is going to cause in the network.  We
> > propose congestion exposure as a possible solution.  Every packet
> > will carry an accurate prediction of the congestion it expects to
> > cause downstream.  This memo sets out the motivations for congestion
> > exposure and introduces a strawman protocol designed to achieve
> > congestion exposure.
> >
> >
> >
> > The IETF Secretariat.
> >
> >
> > _______________________________________________
> > re-ECN mailing list
> > [e-mail]
> > https://www.ietf.org/mailman/listinfo/re-ecn
>
>
>
>--
>-------------------------------------------------------------------
>Dipl.-Ing. Mirja Kühlewind
>Institute of Communication Networks and Computer Engineering (IKR)
>University of Stuttgart, Germany
>Pfaffenwaldring 47, D-70569 Stuttgart
>
>web: www.ikr.uni-stuttgart.de
>email: [e-mail]
>tel: [phone]
>-------------------------------------------------------------------
>_______________________________________________
>re-ECN mailing list
>[e-mail]
>https://www.ietf.org/mailman/listinfo/re-ecn

________________________________________________________________
Bob Briscoe,                                BT Innovate & Design