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

Bob Briscoe <rbriscoe@jungle.bt.co.uk> Mon, 26 October 2009 21:36 UTC

Return-Path: <rbriscoe@jungle.bt.co.uk>
X-Original-To: re-ecn@core3.amsl.com
Delivered-To: re-ecn@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id CB21528C159 for <re-ecn@core3.amsl.com>; Mon, 26 Oct 2009 14:36:22 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.242
X-Spam-Level:
X-Spam-Status: No, score=-1.242 tagged_above=-999 required=5 tests=[AWL=-0.325, BAYES_00=-2.599, DNS_FROM_RFC_BOGUSMX=1.482, J_CHICKENPOX_42=0.6, J_CHICKENPOX_91=0.6, RCVD_IN_DNSWL_LOW=-1]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 2ZK1PB0965yl for <re-ecn@core3.amsl.com>; Mon, 26 Oct 2009 14:36:15 -0700 (PDT)
Received: from smtp3.smtp.bt.com (smtp3.smtp.bt.com [217.32.164.138]) by core3.amsl.com (Postfix) with ESMTP id 8C43E3A67CC for <re-ecn@ietf.org>; Mon, 26 Oct 2009 14:36:15 -0700 (PDT)
Received: from i2kc08-ukbr.domain1.systemhost.net ([193.113.197.71]) by smtp3.smtp.bt.com with Microsoft SMTPSVC(6.0.3790.3959); Mon, 26 Oct 2009 21:36:28 +0000
Received: from cbibipnt08.iuser.iroot.adidom.com ([147.149.100.81]) by i2kc08-ukbr.domain1.systemhost.net with Microsoft SMTPSVC(6.0.3790.3959); Mon, 26 Oct 2009 21:36:28 +0000
Received: From bagheera.jungle.bt.co.uk ([132.146.168.158]) by cbibipnt08.iuser.iroot.adidom.com (WebShield SMTP v4.5 MR1a P0803.399); id 1256592987116; Mon, 26 Oct 2009 21:36:27 +0000
Received: from MUT.jungle.bt.co.uk ([10.73.146.30]) by bagheera.jungle.bt.co.uk (8.13.5/8.12.8) with ESMTP id n9QLaOo6011178; Mon, 26 Oct 2009 21:36:24 GMT
Message-Id: <200910262136.n9QLaOo6011178@bagheera.jungle.bt.co.uk>
X-Mailer: QUALCOMM Windows Eudora Version 7.1.0.9
Date: Mon, 26 Oct 2009 21:36:23 +0000
To: <toby.moncaster@bt.com>
From: Bob Briscoe <rbriscoe@jungle.bt.co.uk>
In-Reply-To: <AEDCAF87EEC94F49BA92EBDD49854CC70DAA28D0@E03MVZ1-UKDY.doma in1.systemhost.net>
References: <AEDCAF87EEC94F49BA92EBDD49854CC70DAA28D0@E03MVZ1-UKDY.domain1.systemhost.net>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"; format=flowed
X-Scanned-By: MIMEDefang 2.56 on 132.146.168.158
X-OriginalArrivalTime: 26 Oct 2009 21:36:28.0346 (UTC) FILETIME=[603861A0:01CA5684]
Cc: re-ecn@ietf.org
Subject: Re: [re-ECN] FW: New Version Notification for draft-moncaster-congestion-exposure-problem-03
X-BeenThere: re-ecn@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: re-inserted explicit congestion notification <re-ecn.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/re-ecn>, <mailto:re-ecn-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/re-ecn>
List-Post: <mailto:re-ecn@ietf.org>
List-Help: <mailto:re-ecn-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/re-ecn>, <mailto:re-ecn-request@ietf.org?subject=subscribe>
X-List-Received-Date: Mon, 26 Oct 2009 21:36:22 -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
(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, toby.moncaster@bt.com 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:idsubmission@ietf.org]
>Sent: 26 October 2009 19:09
>To: Moncaster,T,Toby,DEE1 R
>Cc: Krug,AL,Louise,DES3 R; menth@informatik.uni-wuerzburg.de; 
>j.araujo@ee.ucl.ac.uk.uk; sblake@extremenetworks.com; 
>richard_woundy@cable.comcast.com
>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
>re-ECN@ietf.org
>https://www.ietf.org/mailman/listinfo/re-ecn

________________________________________________________________
Bob Briscoe,                                BT Innovate & Design