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

From: <[email-masked]>
Date: Mon, 26 Oct 2009 19:11:38 -0000

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:[email-masked]] 
Sent: 26 October 2009 19:09
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-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.

---

From: Richard Bennett <[email-masked]>
Date: Mon, 26 Oct 2009 13:27:22 -0700

Are we clear about the language of the announcement? I'm seeing messages 
on non-IETF mailing lists about the BOF already.

RB

[email-masked] wrote:
> _______________________________________________
> re-ECN mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/re-ecn
>   

-- 
Richard Bennett
Research Fellow
Information Technology and Innovation Foundation
Washington, DC

---

From: Bob Briscoe <[email-masked]>
Date: Mon, 26 Oct 2009 21:36:23 +0000

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
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, [email-masked] wrote:
>* an altered abstract (trying to roughly follow suggestions from 
>John Leslie but with modification - note this still needs work!)
>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
>
>Cc: Krug,AL,Louise,DES3 R; [email-masked]; 
>[email-masked]; [email-masked]; 
>[email-masked]
>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.
>

________________________________________________________________
Bob Briscoe,                                BT Innovate & Design

---

From: <[email-masked]>
Date: Tue, 27 Oct 2009 09:48:06 -0000

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

> From: Briscoe,RJ,Bob,XVR9 BRISCORJ R
> Sent: 26 October 2009 21:36
> Cc: [email-masked]
> Subject: Re: [re-ECN] FW: New Version Notification for
draft-moncaster-
> congestion-exposure-problem-03
> 
> Toby,
>