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
- [re-ECN] FW: New Version Notification for draft-m… toby.moncaster
- Re: [re-ECN] FW: New Version Notification for dra… Richard Bennett
- Re: [re-ECN] FW: New Version Notification for dra… Bob Briscoe
- Re: [re-ECN] FW: New Version Notification for dra… toby.moncaster