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

From: <[email-masked]>
Date: Thu, 15 Oct 2009 17:08:29 +0100

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.  +44 7918 901170 

-----Original Message-----
From: IETF I-D Submission Tool [mailto:[email-masked]] 
Sent: 15 October 2009 17:00
To: Moncaster,T,Toby,DEE1 R
Cc: Krug,AL,Louise,DES3 R; [email-masked]; [email-masked]; [email-masked]; [email-masked]
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.

---

From: Mirja Kuehlewind <[email-masked]>
Date: Fri, 16 Oct 2009 17:57:41 +0200

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 [email-masked] 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.
>
> 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.
>
> Section 9 Security. This should concentrate on direct attacks on congestion
> exposure (DoS and dishonest declaration).
>
> 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
>
> Cc: Krug,AL,Louise,DES3 R; [email-masked];
> [email-masked]; [email-masked];
> [email-masked] 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.
>
> _______________________________________________
> re-ECN mailing list
> [email-masked]
> 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: [email-masked]
tel: +49(0)711/685-67973
-------------------------------------------------------------------

---

From: Bob Briscoe <[email-masked]>
Date: Tue, 20 Oct 2009 13:58:45 +0100

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:
> > B54/70 Adastral Park, Ipswich, IP53RE, UK.Â  +44 7918 901170
> >
> >
> >
>Dipl.-Ing. Mirja KÃ¼hlewind

________________________________________________________________
Bob Briscoe,                                BT Innovate & Design