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

[<[e-mail]>]

Hi all,

I agree with Bob that I had started to get into too much detail for an
abstract. What would people think about the following as an alternative:

"Today's Internet is a product of history.  TCP is largely responsible
for sharing out bandwidth and preventing congestion collapse while
packet drop is the primary signal of congestion at bottlenecks.  But TCP
isn't designed to take account of the duration of flows.  This allows
some users to have a disproportionate impact on the network experience
of others. This leads some ISPs to impose arbitrary controls on their
customers based on the limited information they can see or measure (the
contents of the packet headers and the rate of the traffic).  Such
controls don't improve matters since they fail to account for
congestion, the true measure of the impact of one user on another.

We propose congestion exposure as a possible solution.  This allows
packets to carry an accurate prediction of the congestion they expect to
cause downstream thus allowing it to be visible to ISPs and network
operators.  This memo sets out the motivations for congestion exposure
and introduces a strawman protocol designed to achieve congestion
exposure."


Obviously it's too late to send out a new version now but we can discuss
this ready for when the servers open again after Hiroshima...

Toby

> -----Original Message-----
> From: Briscoe,RJ,Bob,XVR9 BRISCORJ R
> Sent: 26 October 2009 21:36
> To: Moncaster,T,Toby,DEE1 R
> Cc: [e-mail]
> Subject: Re: [re-ECN] FW: New Version Notification for
draft-moncaster-
> congestion-exposure-problem-03
> 
> Toby,
> 
> I know you don't need constraints at this stage, but I think the
> middle sentence of the abstract really won't do (repeated below).
> 
> "Since packet drop
> (and increased delay) impacts all their customers negatively, network
> operators would like to be able to distinguish between overly
> aggressive congestion control and a confluence of many low-bandwidth,
> low-impact flows."
> 
> The abstract should get over one simple message. This isn't simple
> and it gives the opposite message to that intended - it sounds like
> network operators want to get involved in the nitty gritty of each
> flow's congestion control.
> 
> I agreed with some of John's criticisms of the -02 version, but they
> were only details that required clarifying precision (I agree the
> points made were rather vague).
> 
> Personally, I think the simplest point to get across about TCP is
> it's lack of a view over time. This is what the BoF announcement
> focuses on, which explains well why operators are imposing different
> regimes. It also allows us to say the sentence about "measuring
> volume of congestion as easily as volume is measured today". I think
> 'over time' is the key point that immediately makes people think
> "there's probably something in this".
> 
> I will now trust you can do the abstract justice without me
> interfering further.
> 
> Cheers
> 
> 
> 
> Bob
> 
> At 19:11 26/10/2009, [e-mail] wrote:
> >A new version. The main changes are:
> >* an altered abstract (trying to roughly follow suggestions from
> >John Leslie but with modification - note this still needs work!)
> >* An improved security considerations section
> >* The start of a proper Use Cases section
> >
> >I now I still have comments from a couple of people that will need
> >addressing but I needed to get this submitted before the deadline...
> >
> >Toby
> >
> >-----Original Message-----
> >From: IETF I-D Submission Tool [mailto:[e-mail]]
> >Sent: 26 October 2009 19:09
> >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-03
> >
> >
> >A new version of I-D,
> >draft-moncaster-congestion-exposure-problem-03.txt has been
> >successfuly submitted by T Moncaster and posted to the IETF
> repository.
> >
> >Filename:       draft-moncaster-congestion-exposure-problem
> >Revision:       03
> >Title:          The Need for Congestion Exposure in the Internet
> >Creation_date:  2009-10-26
> >WG ID:          Independent Submission
> >Number_of_pages: 22
> >
> >Abstract:
> >Today's Internet is a product of its history.  TCP is the main
> >transport protocol responsible for sharing out bandwidth and
> >preventing a recurrence of congestion collapse while packet drop is
> >the primary signal of congestion at bottlenecks.  Since packet drop
> >(and increased delay) impacts all their customers negatively, network
> >operators would like to be able to distinguish between overly
> >aggressive congestion control and a confluence of many low-bandwidth,
> >low-impact flows.  But they are unable to see the actual congestion
> >signal and thus, they have to implement bandwidth and/or usage limits
> >based on the only information they can see or measure (the contents
> >of the packet headers and the rate of the traffic).  Such measures
> >don't solve the packet-drop problems effectively and are leading to
> >calls for government regulation (which also won't solve the problem).
> >
> >We propose congestion exposure as a possible solution.  This allows
> >packets to carry an accurate prediction of the congestion they expect
> >to cause downstream thus allowing it to be visible to ISPs and
> >network operators.  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
> 
> ________________________________________________________________
> Bob Briscoe,                                BT Innovate & Design