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

[Mirja Kuehlewind <[e-mail]>]

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