From toby@moncaster.com Thu Jul 1 13:47:47 2010 Return-Path: X-Original-To: conex@core3.amsl.com Delivered-To: conex@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id CD8FD3A6944 for ; Thu, 1 Jul 2010 13:47:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.351 X-Spam-Level: X-Spam-Status: No, score=0.351 tagged_above=-999 required=5 tests=[BAYES_50=0.001, HELO_EQ_DE=0.35] 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 oe3S9ctRquSK for ; Thu, 1 Jul 2010 13:47:44 -0700 (PDT) Received: from moutng.kundenserver.de (moutng.kundenserver.de [212.227.126.186]) by core3.amsl.com (Postfix) with ESMTP id C40F43A691B for ; Thu, 1 Jul 2010 13:47:43 -0700 (PDT) Received: from TobysHP (host86-145-203-64.range86-145.btcentralplus.com [86.145.203.64]) by mrelayeu.kundenserver.de (node=mreu1) with ESMTP (Nemesis) id 0MGVBU-1OPygM2ZVo-00Du0s; Thu, 01 Jul 2010 22:47:54 +0200 From: "Toby Moncaster" To: Date: Thu, 1 Jul 2010 21:47:53 +0100 Message-ID: <002901cb195e$addca590$0995f0b0$@com> MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable X-Mailer: Microsoft Office Outlook 12.0 thread-index: AcsZXXSnlbhG30tISZyZ2MsDBmYUYgAAAyJg Content-Language: en-gb X-Provags-ID: V01U2FsdGVkX1+X4Ht/xCnE1i1FbSqUBr4vkq2EWutRyy5GNKT O0jeXppMS1nApau0nFLiWRYno8h2wuSMRKcjLqz89/OLB3iCxC zCYgeNjbV5Li13mp+ImarO6dUCsthZ/ Subject: [conex] FW: New Version Notification for draft-moncaster-conex-concepts-uses-00 X-BeenThere: conex@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Congestion Exposure working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 01 Jul 2010 20:47:47 -0000 All, I have just posted this revised document, addressing most of Marcelo's = comments. Notice the new filename and title... There is a changelog in = the draft and there is a link to the diff below... HTML at = http://www.moncaster.com/conex/draft-moncaster-conex-concepts-uses-00.htm= l DIFF at http://www.moncaster.com/conex/Diff0.htm I think this is now in a good enough state to be adopted as the first WG = document. The changes make this pretty close to what is requested in the = charter (namely a use cases document). There is a section on mechanisms = because to my mind a use cases document with no description of mechanism = is useless (as there would be no way for people to judge how realistic = the use cases are). So, to ask the question formally, does anyone else think this is ready = for WG adoption? What do the chairs think? Will the chairs propose this = for adoption or do you intend to wait until it has been discussed at = Maastricht? Toby PS Dirk, I saw your email (or skimmed it anyway), but it was too late to = incorporate your suggestions into this release. Hopefully I will have = time next week to do another revision and will probably incorporate the = majority of your suggestions > -----Original Message----- > From: IETF I-D Submission Tool [mailto:idsubmission@ietf.org] > Sent: 01 July 2010 21:39 > To: toby@moncaster.com > Cc: bob.briscoe@bt.com; richard_woundy@cable.comcast.com; john@jlc.net > Subject: New Version Notification for draft-moncaster-conex-concepts- > uses-00 >=20 >=20 > A new version of I-D, draft-moncaster-conex-concepts-uses-00.txt has > been successfully submitted by Toby Moncaster and posted to the IETF > repository. >=20 > Filename: draft-moncaster-conex-concepts-uses > Revision: 00 > Title: ConEx Concepts and Use Cases > Creation_date: 2010-07-01 > WG ID: Independent Submission > Number_of_pages: 20 >=20 > Abstract: > Internet Service Providers (ISPs) are facing problems where > congestion prevents full utilization of the path between sender and > receiver at today's "broadband" speeds. ISPs desire to control the > congestion, which often appears to be caused by a small number of > users consuming a large amount of bandwidth. Building out more > capacity along all of the path to handle this congestion can be > expensive; and network operators have sought other ways to manage > congestion. The current mechanisms all suffer from difficulty > measuring the congestion (as distinguished from the total traffic). >=20 > The ConEx Working Group is designing a mechanism to make congestion > along any path visible at the Internet Layer. This document > discusses this mechanism. >=20 >=20 >=20 > The IETF Secretariat. From acooper@cdt.org Fri Jul 2 04:24:47 2010 Return-Path: X-Original-To: conex@core3.amsl.com Delivered-To: conex@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id CFF183A67EE for ; Fri, 2 Jul 2010 04:24:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.083 X-Spam-Level: X-Spam-Status: No, score=-2.083 tagged_above=-999 required=5 tests=[AWL=0.516, BAYES_00=-2.599] 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 wC27F5oMYvbY for ; Fri, 2 Jul 2010 04:24:47 -0700 (PDT) Received: from mail.maclaboratory.net (mail.maclaboratory.net [209.190.215.232]) by core3.amsl.com (Postfix) with ESMTP id BC1803A67E2 for ; Fri, 2 Jul 2010 04:24:46 -0700 (PDT) Received: from localhost ([127.0.0.1]) by mail.maclaboratory.net (using TLSv1/SSLv3 with cipher AES128-SHA (128 bits)); Fri, 2 Jul 2010 07:24:56 -0400 Message-Id: <49B8AF43-14F5-466E-8B59-DE180B792146@cdt.org> From: Alissa Cooper To: Toby Moncaster In-Reply-To: <002901cb195e$addca590$0995f0b0$@com> Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v936) Date: Fri, 2 Jul 2010 12:24:55 +0100 References: <002901cb195e$addca590$0995f0b0$@com> X-Mailer: Apple Mail (2.936) Cc: conex@ietf.org Subject: Re: [conex] FW: New Version Notification for draft-moncaster-conex-concepts-uses-00 X-BeenThere: conex@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Congestion Exposure working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 02 Jul 2010 11:24:47 -0000 Hi Toby, Just a note on section 3, I think it would help to at least list current approaches to congestion management by name (as was done in both draft-moncaster-congestion-exposure-problem-03 and draft- tschofenig-conex-ps-02) so that readers of this document understand what they're supposed to be comparing conex-enabled mechanisms against. As it is the draft talks about "all of the current approaches" in several places, but it's not clear what that group is referring to. One question inline... On Jul 1, 2010, at 9:47 PM, Toby Moncaster wrote: > I think this is now in a good enough state to be adopted as the > first WG document. The changes make this pretty close to what is > requested in the charter (namely a use cases document). There is a > section on mechanisms because to my mind a use cases document with > no description of mechanism is useless (as there would be no way for > people to judge how realistic the use cases are). Are you thinking that what is explained in section 6 would be the abstract specification of the mechanism that the WG is chartered to do, or would that be specified in a separate document? Thanks, Alissa > > So, to ask the question formally, does anyone else think this is > ready for WG adoption? What do the chairs think? Will the chairs > propose this for adoption or do you intend to wait until it has been > discussed at Maastricht? > > Toby > > PS Dirk, I saw your email (or skimmed it anyway), but it was too > late to incorporate your suggestions into this release. Hopefully I > will have time next week to do another revision and will probably > incorporate the majority of your suggestions > >> -----Original Message----- >> From: IETF I-D Submission Tool [mailto:idsubmission@ietf.org] >> Sent: 01 July 2010 21:39 >> To: toby@moncaster.com >> Cc: bob.briscoe@bt.com; richard_woundy@cable.comcast.com; >> john@jlc.net >> Subject: New Version Notification for draft-moncaster-conex-concepts- >> uses-00 >> >> >> A new version of I-D, draft-moncaster-conex-concepts-uses-00.txt has >> been successfully submitted by Toby Moncaster and posted to the IETF >> repository. >> >> Filename: draft-moncaster-conex-concepts-uses >> Revision: 00 >> Title: ConEx Concepts and Use Cases >> Creation_date: 2010-07-01 >> WG ID: Independent Submission >> Number_of_pages: 20 >> >> Abstract: >> Internet Service Providers (ISPs) are facing problems where >> congestion prevents full utilization of the path between sender and >> receiver at today's "broadband" speeds. ISPs desire to control the >> congestion, which often appears to be caused by a small number of >> users consuming a large amount of bandwidth. Building out more >> capacity along all of the path to handle this congestion can be >> expensive; and network operators have sought other ways to manage >> congestion. The current mechanisms all suffer from difficulty >> measuring the congestion (as distinguished from the total traffic). >> >> The ConEx Working Group is designing a mechanism to make congestion >> along any path visible at the Internet Layer. This document >> discusses this mechanism. >> >> >> >> The IETF Secretariat. > > > _______________________________________________ > conex mailing list > conex@ietf.org > https://www.ietf.org/mailman/listinfo/conex > From toby@moncaster.com Fri Jul 2 05:06:50 2010 Return-Path: X-Original-To: conex@core3.amsl.com Delivered-To: conex@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id A31B63A6405 for ; Fri, 2 Jul 2010 05:06:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.949 X-Spam-Level: X-Spam-Status: No, score=-0.949 tagged_above=-999 required=5 tests=[AWL=1.300, BAYES_00=-2.599, HELO_EQ_DE=0.35] 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 c5JtgoW2HduX for ; Fri, 2 Jul 2010 05:06:49 -0700 (PDT) Received: from moutng.kundenserver.de (moutng.kundenserver.de [212.227.126.186]) by core3.amsl.com (Postfix) with ESMTP id 3541C3A6849 for ; Fri, 2 Jul 2010 05:06:42 -0700 (PDT) Received: from TobysHP (host86-145-203-64.range86-145.btcentralplus.com [86.145.203.64]) by mrelayeu.kundenserver.de (node=mrbap0) with ESMTP (Nemesis) id 0LbPxa-1OtJSa3wmw-00kvMS; Fri, 02 Jul 2010 14:06:35 +0200 From: "Toby Moncaster" To: "'Alissa Cooper'" References: <002901cb195e$addca590$0995f0b0$@com> <49B8AF43-14F5-466E-8B59-DE180B792146@cdt.org> In-Reply-To: <49B8AF43-14F5-466E-8B59-DE180B792146@cdt.org> Date: Fri, 2 Jul 2010 13:06:32 +0100 Message-ID: <003401cb19df$0300da20$09028e60$@com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 12.0 thread-index: AcsZ2TW3gGH6P1+HQTStc3V/4wYiZgABSzAA Content-Language: en-gb X-Provags-ID: V01U2FsdGVkX19zH8kQKNdNyj3tsZvIVC34eRgc+O85mJfOmnm zfslCl3sQBvgtTY++tyLpISWF3/Ga1NxfqazbvZvwmEkZ1QUan hyO8vUtOMwfL39i5HwIRVbtixNsofUq Cc: conex@ietf.org Subject: Re: [conex] FW: New Version Notification for draft-moncaster-conex-concepts-uses-00 X-BeenThere: conex@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Congestion Exposure working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 02 Jul 2010 12:06:50 -0000 Hi Alissa, Inline responses Toby > -----Original Message----- > From: Alissa Cooper [mailto:acooper@cdt.org] > Sent: 02 July 2010 12:25 > To: Toby Moncaster > Cc: conex@ietf.org > Subject: Re: [conex] FW: New Version Notification for draft-moncaster- > conex-concepts-uses-00 > > Hi Toby, > > Just a note on section 3, I think it would help to at least list > current approaches to congestion management by name (as was done in > both draft-moncaster-congestion-exposure-problem-03 and draft- > tschofenig-conex-ps-02) so that readers of this document understand > what they're supposed to be comparing conex-enabled mechanisms > against. As it is the draft talks about "all of the current > approaches" in several places, but it's not clear what that group is > referring to. That is a reasonable point. We (co-authors) were unsure how much detail to go into on current approaches. I will try and improve this section and remove ambiguities when the next version comes out > > One question inline... > > On Jul 1, 2010, at 9:47 PM, Toby Moncaster wrote: > > I think this is now in a good enough state to be adopted as the > > first WG document. The changes make this pretty close to what is > > requested in the charter (namely a use cases document). There is a > > section on mechanisms because to my mind a use cases document with > > no description of mechanism is useless (as there would be no way for > > people to judge how realistic the use cases are). > > Are you thinking that what is explained in section 6 would be the > abstract specification of the mechanism that the WG is chartered to > do, or would that be specified in a separate document? I am expecting there to be a separate document specifying the actual mechanism. This section is intended to give sufficient detail of a possible approach to allow people to see how realistic conex is. Currently re-ECN is the only mechanism that has been proposed, hence that is the mechanism I am assuming for these use cases... > > Thanks, > Alissa > > > > > > So, to ask the question formally, does anyone else think this is > > ready for WG adoption? What do the chairs think? Will the chairs > > propose this for adoption or do you intend to wait until it has been > > discussed at Maastricht? > > > > Toby > > > > PS Dirk, I saw your email (or skimmed it anyway), but it was too > > late to incorporate your suggestions into this release. Hopefully I > > will have time next week to do another revision and will probably > > incorporate the majority of your suggestions > > > >> -----Original Message----- > >> From: IETF I-D Submission Tool [mailto:idsubmission@ietf.org] > >> Sent: 01 July 2010 21:39 > >> To: toby@moncaster.com > >> Cc: bob.briscoe@bt.com; richard_woundy@cable.comcast.com; > >> john@jlc.net > >> Subject: New Version Notification for draft-moncaster-conex- > concepts- > >> uses-00 > >> > >> > >> A new version of I-D, draft-moncaster-conex-concepts-uses-00.txt has > >> been successfully submitted by Toby Moncaster and posted to the IETF > >> repository. > >> > >> Filename: draft-moncaster-conex-concepts-uses > >> Revision: 00 > >> Title: ConEx Concepts and Use Cases > >> Creation_date: 2010-07-01 > >> WG ID: Independent Submission > >> Number_of_pages: 20 > >> > >> Abstract: > >> Internet Service Providers (ISPs) are facing problems where > >> congestion prevents full utilization of the path between sender and > >> receiver at today's "broadband" speeds. ISPs desire to control the > >> congestion, which often appears to be caused by a small number of > >> users consuming a large amount of bandwidth. Building out more > >> capacity along all of the path to handle this congestion can be > >> expensive; and network operators have sought other ways to manage > >> congestion. The current mechanisms all suffer from difficulty > >> measuring the congestion (as distinguished from the total traffic). > >> > >> The ConEx Working Group is designing a mechanism to make congestion > >> along any path visible at the Internet Layer. This document > >> discusses this mechanism. > >> > >> > >> > >> The IETF Secretariat. > > > > > > _______________________________________________ > > conex mailing list > > conex@ietf.org > > https://www.ietf.org/mailman/listinfo/conex > > From marcelo@it.uc3m.es Mon Jul 5 00:15:01 2010 Return-Path: X-Original-To: conex@core3.amsl.com Delivered-To: conex@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 5DFE63A68E0 for ; Mon, 5 Jul 2010 00:15:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -104.74 X-Spam-Level: X-Spam-Status: No, score=-104.74 tagged_above=-999 required=5 tests=[BAYES_20=-0.74, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] 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 2X4I4-BebGB9 for ; Mon, 5 Jul 2010 00:15:00 -0700 (PDT) Received: from smtp03.uc3m.es (smtp03.uc3m.es [163.117.176.133]) by core3.amsl.com (Postfix) with ESMTP id 779373A687A for ; Mon, 5 Jul 2010 00:15:00 -0700 (PDT) X-uc3m-safe: yes Received: from marcelo-bagnulos-macbook-pro.local (169.30.18.95.dynamic.jazztel.es [95.18.30.169]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by smtp03.uc3m.es (Postfix) with ESMTP id 0AAF2836DCF for ; Mon, 5 Jul 2010 09:14:58 +0200 (CEST) Message-ID: <4C318671.307@it.uc3m.es> Date: Mon, 05 Jul 2010 09:14:57 +0200 From: marcelo bagnulo braun User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.5; es-ES; rv:1.9.1.10) Gecko/20100512 Thunderbird/3.0.5 MIME-Version: 1.0 To: conex@ietf.org Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-TM-AS-Product-Ver: IMSS-7.0.0.3116-6.0.0.1038-17486.003 Subject: [conex] call for agenda items X-BeenThere: conex@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Congestion Exposure working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 05 Jul 2010 07:15:01 -0000 Hi, CONEX WG will be meeting in the next ietf. If you want a slot please let us know. Regards, marcelo From lei.zhu@huawei.com Tue Jul 6 03:53:35 2010 Return-Path: X-Original-To: conex@core3.amsl.com Delivered-To: conex@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 11EA13A685A for ; Tue, 6 Jul 2010 03:53:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.92 X-Spam-Level: * X-Spam-Status: No, score=1.92 tagged_above=-999 required=5 tests=[BAYES_40=-0.185, FH_RELAY_NODNS=1.451, HELO_MISMATCH_COM=0.553, HTML_MESSAGE=0.001, RDNS_NONE=0.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 Cv6QDoXPsoMo for ; Tue, 6 Jul 2010 03:53:34 -0700 (PDT) Received: from szxga03-in.huawei.com (unknown [119.145.14.66]) by core3.amsl.com (Postfix) with ESMTP id 3D2C13A6823 for ; Tue, 6 Jul 2010 03:53:34 -0700 (PDT) Received: from huawei.com (szxga03-in [172.24.2.9]) by szxga03-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0L5400A0MU8XZQ@szxga03-in.huawei.com> for conex@ietf.org; Tue, 06 Jul 2010 18:53:22 +0800 (CST) Received: from huawei.com ([172.24.2.119]) by szxga03-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0L54003AVU8W21@szxga03-in.huawei.com> for conex@ietf.org; Tue, 06 Jul 2010 18:53:20 +0800 (CST) Received: from z41317 ([10.111.16.163]) by szxml04-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTPA id <0L5400A1BU8T4J@szxml04-in.huawei.com> for conex@ietf.org; Tue, 06 Jul 2010 18:53:20 +0800 (CST) Date: Tue, 06 Jul 2010 18:53:17 +0800 From: Zhu Lei To: conex@ietf.org Message-id: <006901cb1cf9$71e10d80$a3106f0a@china.huawei.com> MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2900.3350 X-Mailer: Microsoft Office Outlook 11 Content-type: multipart/alternative; boundary="Boundary_(ID_HgPwUmSuuVuaojOZb4AA/g)" Thread-index: Acsc+XC0Xyviv/XhQuia4j4eqagVpQ== Subject: [conex] An individual for your review X-BeenThere: conex@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Congestion Exposure working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 06 Jul 2010 10:53:35 -0000 This is a multi-part message in MIME format. --Boundary_(ID_HgPwUmSuuVuaojOZb4AA/g) Content-type: text/plain; charset=us-ascii Content-transfer-encoding: 7BIT Hi all, We already had some discussions which may allow wireless access networks to notify congestions in mail list. I personally think that Conex charter is asking some solutions by stating "However, the CONEX WG will initially focus on one use case, where the end hosts and the network that contains the destination end host are CONEX-enabled but other networks need not be." I have an individual draft which introduces some ideas for next f2f meeting. I'd like to ask you to review this short document and help identify the problems which could be resolved in Conex wg. Thank you! draft-lei-ecn-localised-congestion-notification-00 Hope have your feedback soon. Best regards, Lei Zhu --Boundary_(ID_HgPwUmSuuVuaojOZb4AA/g) Content-type: text/html; charset=us-ascii Content-transfer-encoding: 7BIT
Hi all,
 
We already had some discussions which may allow wireless access networks to notify congestions in mail list.
 
I personally think that Conex charter is asking some solutions by stating "However, the CONEX WG will initially focus on one use case, where the end hosts and the network that contains the destination end host are CONEX-enabled but other networks need not be."
 
I have an individual draft which introduces some ideas for next f2f meeting. I'd like to ask you to review this short document and help identify the problems which could be resolved in Conex wg. Thank you!
 
draft-lei-ecn-localised-congestion-notification-00
Hope have your feedback soon.
 
Best regards,
Lei Zhu

 
--Boundary_(ID_HgPwUmSuuVuaojOZb4AA/g)-- From mirja.kuehlewind@ikr.uni-stuttgart.de Thu Jul 8 02:27:49 2010 Return-Path: X-Original-To: conex@core3.amsl.com Delivered-To: conex@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id AB18C3A69F5 for ; Thu, 8 Jul 2010 02:27:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.651 X-Spam-Level: X-Spam-Status: No, score=0.651 tagged_above=-999 required=5 tests=[BAYES_50=0.001, HELO_EQ_DE=0.35, MIME_8BIT_HEADER=0.3] 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 1l+XfT76r2wW for ; Thu, 8 Jul 2010 02:27:49 -0700 (PDT) Received: from mailsrv.ikr.uni-stuttgart.de (mailsrv.ikr.uni-stuttgart.de [129.69.170.2]) by core3.amsl.com (Postfix) with ESMTP id CC1A53A67F3 for ; Thu, 8 Jul 2010 02:27:48 -0700 (PDT) Received: from netsrv1.ikr.uni-stuttgart.de (netsrv1-c [10.11.12.12]) by mailsrv.ikr.uni-stuttgart.de (Postfix) with ESMTP id DA932439F5; Thu, 8 Jul 2010 11:27:50 +0200 (CEST) Received: from vpn-1-cl02 (vpn-1-cl02 [10.88.11.12]) by netsrv1.ikr.uni-stuttgart.de (Postfix) with ESMTP id C36C9BC07E; Thu, 8 Jul 2010 11:27:50 +0200 (CEST) From: Mirja =?iso-8859-1?q?K=FChlewind?= To: conex@ietf.org Date: Thu, 8 Jul 2010 11:27:47 +0200 User-Agent: KMail/1.9.10 (enterprise35 0.20090731.1005176) References: <4C318671.307@it.uc3m.es> In-Reply-To: <4C318671.307@it.uc3m.es> X-KMail-QuotePrefix: > MIME-Version: 1.0 Content-Disposition: inline Content-Type: Text/Plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Message-Id: <201007081127.48068.mkuehle@ikr.uni-stuttgart.de> Subject: Re: [conex] call for agenda items X-BeenThere: conex@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Congestion Exposure working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 08 Jul 2010 09:27:49 -0000 Hi, I gone publish a paper about some investigations on the re-ECN Protocol: Mirja K=FChlewind, Michael Scharf: "Implementation and Performance Evaluati= on of=20 the re-ECN Protocol," In: Proc 3rd Workshop on Economic Traffic Management= =20 (ETM'10), Amsterdam (to appear September 2010) I would like to present some of the results mainly related to ECN and Slow= =20 Start effects. This goes in-line with the motivation for ConEx to enable =20 a more scalable congestion controls as previously explained by Bob. I figured out that a huge amount of congestion/ECN marks is caused by Slow= =20 Start overshoot. Whereelse with ECN-only, the total amount of markings is n= ot=20 that crucial (as the CWND is halved not more than once per RTT), this is=20 especially relevant for conex-based congestion management where very single= =20 mark counts. Moreover, flows, that send just enough data to excess the=20 Slow-Start overshoot, get a larger amount of marks and thus are somehow=20 discriminated. I would be happy to explain this further when showing the=20 related diagrams. Title: ECN and TCP Slow Start - A motivation for a more scalable congestion= =20 control Presenter: Mirja Kuehlewind Requested time: 10 mins. Mirja On Monday 05 July 2010 09:14:57 marcelo bagnulo braun wrote: > Hi, > > CONEX WG will be meeting in the next ietf. If you want a slot please let > us know. > > Regards, marcelo > > _______________________________________________ > conex mailing list > conex@ietf.org > https://www.ietf.org/mailman/listinfo/conex From lei.zhu@huawei.com Thu Jul 8 04:11:24 2010 Return-Path: X-Original-To: conex@core3.amsl.com Delivered-To: conex@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 5B1E53A6A6B for ; Thu, 8 Jul 2010 04:11:24 -0700 (PDT) X-Quarantine-ID: <7+WO2t0vUqdN> X-Virus-Scanned: amavisd-new at amsl.com X-Amavis-Alert: BANNED, message contains part: multipart/mixed | application/ms-tnef,.tnef,winmail.dat X-Spam-Flag: NO X-Spam-Score: 3.237 X-Spam-Level: *** X-Spam-Status: No, score=3.237 tagged_above=-999 required=5 tests=[AWL=-1.317, BAYES_50=0.001, FH_RELAY_NODNS=1.451, HELO_MISMATCH_COM=0.553, MIME_CHARSET_FARAWAY=2.45, RDNS_NONE=0.1] X-Amavis-Modified: Mail body modified (defanged) by core3.amsl.com 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 7+WO2t0vUqdN for ; Thu, 8 Jul 2010 04:11:19 -0700 (PDT) Content-Type: multipart/mixed; boundary="----------=_1278587484-29268-1" Content-Transfer-Encoding: binary MIME-Version: 1.0 Received: from szxga01-in.huawei.com (unknown [119.145.14.64]) by core3.amsl.com (Postfix) with ESMTP id 56C133A6A64 for ; Thu, 8 Jul 2010 04:11:18 -0700 (PDT) Received: from huawei.com (szxga01-in [172.24.2.3]) by szxga01-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0L58005PGKENVD@szxga01-in.huawei.com> for conex@ietf.org; Thu, 08 Jul 2010 19:11:12 +0800 (CST) Received: from huawei.com ([172.24.2.119]) by szxga01-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0L58003USKENZH@szxga01-in.huawei.com> for conex@ietf.org; Thu, 08 Jul 2010 19:11:11 +0800 (CST) Received: from z41317 ([10.111.16.163]) by szxml04-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTPA id <0L58009MCKEN2R@szxml04-in.huawei.com> for conex@ietf.org; Thu, 08 Jul 2010 19:11:11 +0800 (CST) Date: Thu, 08 Jul 2010 19:11:10 +0800 From: Zhu Lei In-reply-to: <006e01cb1cf9$72c37e40$a3106f0a@china.huawei.com> To: conex@ietf.org Message-id: <000001cb1e8e$45aee430$a3106f0a@china.huawei.com> X-Mailer: Microsoft Office Outlook 11 Subject: Re: [conex] call for agenda items X-BeenThere: conex@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Congestion Exposure working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 08 Jul 2010 11:11:24 -0000 This is a multi-part message in MIME format... ------------=_1278587484-29268-1 Content-Type: text/plain; charset="iso-8859-1" Content-Disposition: inline Content-Transfer-Encoding: 7bit WARNING: contains banned part ------------=_1278587484-29268-1 Content-Type: message/rfc822; x-spam-type=original; name="message" Content-Disposition: attachment; filename="message" Content-Transfer-Encoding: 7bit Content-Description: Original message Received: from szxga01-in.huawei.com (unknown [119.145.14.64]) by core3.amsl.com (Postfix) with ESMTP id 56C133A6A64 for ; Thu, 8 Jul 2010 04:11:18 -0700 (PDT) Received: from huawei.com (szxga01-in [172.24.2.3]) by szxga01-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0L58005PGKENVD@szxga01-in.huawei.com> for conex@ietf.org; Thu, 08 Jul 2010 19:11:12 +0800 (CST) Received: from huawei.com ([172.24.2.119]) by szxga01-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0L58003USKENZH@szxga01-in.huawei.com> for conex@ietf.org; Thu, 08 Jul 2010 19:11:11 +0800 (CST) Received: from z41317 ([10.111.16.163]) by szxml04-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTPA id <0L58009MCKEN2R@szxml04-in.huawei.com> for conex@ietf.org; Thu, 08 Jul 2010 19:11:11 +0800 (CST) Date: Thu, 08 Jul 2010 19:11:10 +0800 From: Zhu Lei Subject: Re: [conex] call for agenda items In-reply-to: <006e01cb1cf9$72c37e40$a3106f0a@china.huawei.com> To: conex@ietf.org Message-id: <000001cb1e8e$45aee430$a3106f0a@china.huawei.com> MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2900.3350 X-Mailer: Microsoft Office Outlook 11 Content-type: multipart/mixed; boundary="Boundary_(ID_km86FfhxJdFdZopFDmyrzg)" Thread-index: Acsc+XC0Xyviv/XhQuia4j4eqagVpQBk/KTQ X-MS-TNEF-Correlator: 00000000638BB1932978FA4FBC45644F2681FE85E4504A00 This is a multi-part message in MIME format. --Boundary_(ID_km86FfhxJdFdZopFDmyrzg) Content-type: text/plain; charset=gb2312 Content-transfer-encoding: quoted-printable Hi all, =20 I forwarded previous e-mail for asking a particular time slot in next meeting. I saw some discussions which intented to include "mobility" as = part of concept of Conex. The way forward may be some introductions and use = cases happened in wireless. =20 Hopefully, I may have some feedbacks or concerns during physical = meeting.=20 =20 Br, L. =20 _____ =20 =B7=A2=BC=FE=C8=CB: Zhu Lei [mailto:lei.zhu@huawei.com]=20 =B7=A2=CB=CD=CA=B1=BC=E4: 2010=C4=EA7=D4=C26=C8=D5 18:53 =CA=D5=BC=FE=C8=CB: conex@ietf.org =B3=AD=CB=CD: 'Zhu Lei' =D6=F7=CC=E2: [conex] An individual for your review Hi all, =20 We already had some discussions which may allow wireless access networks = to notify congestions in mail list.=20 =20 I personally think that Conex charter is asking some solutions by = stating "However, the CONEX WG will initially focus on one use case, where the = end hosts and the network that contains the destination end host are CONEX-enabled but other networks need not be."=20 =20 I have an individual draft which introduces some ideas for next f2f = meeting. I'd like to ask you to review this short document and help identify the problems which could be resolved in Conex wg. Thank you! =20 draft-lei-ecn-localised-congestion-notification-00 Hope have your feedback soon. =20 Best regards, Lei Zhu =20 --Boundary_(ID_km86FfhxJdFdZopFDmyrzg) Content-type: application/ms-tnef; name=winmail.dat Content-transfer-encoding: base64 Content-disposition: attachment; filename=winmail.dat eJ8+IgsLAQaQCAAEAAAAAAABAAEAAQeQBgAIAAAAqAMAAAAAAACrAAEIgAcAGAAAAElQTS5NaWNy b3NvZnQgTWFpbC5Ob3RlADEIAQOQBgDcEAAAJAAAAAsAAgABAAAAAwAmAAAAAAALACsAAAAAAAMA LgAAAAAAHgBwAAEAAAAiAAAAUmU6IFtjb25leF0gY2FsbCBmb3IgYWdlbmRhIGl0ZW1zAAAAAgFx AAEAAAAbAAAAAcsc+XC0Xyviv/XhQuia4j4eqagVpQBk/KTQAAsAAQ4AAAAAAgEKDgEAAAAYAAAA AAAAAGOLsZMpePpPvEVkTyaB/oXCgAAAAwAUDgEAAAAeACgOAQAAACwAAAAwMDAwMDAwMgFsZWku emh1QGh1YXdlaS5jb20BcG9wMy5odWF3ZWkuY29tAB4AKQ4BAAAALAAAADAwMDAwMDAyAWxlaS56 aHVAaHVhd2VpLmNvbQFwb3AzLmh1YXdlaS5jb20AAwDeP6gDAAADAAJZAAAWAAMACVkCAAAACwAT gAggBgAAAAAAwAAAAAAAAEYAAAAAA4UAAAAAAAADACeACCAGAAAAAADAAAAAAAAARgAAAAABhQAA AAAAAAMANIAIIAYAAAAAAMAAAAAAAABGAAAAABCFAAAAAAAACwBbgAggBgAAAAAAwAAAAAAAAEYA AAAABoUAAAAAAAALAF+ACCAGAAAAAADAAAAAAAAARgAAAAAOhQAAAAAAAAMAY4AIIAYAAAAAAMAA AAAAAABGAAAAABiFAAAAAAAACwB8gAggBgAAAAAAwAAAAAAAAEYAAAAAgoUAAAAAAAAeAH2ACCAG AAAAAADAAAAAAAAARgAAAACDhQAAAQAAABMAAAA0OTg1MTA0MTEtMDgwNzIwMTAAAAsAHw4BAAAA AgH4DwEAAAAQAAAAY4uxkyl4+k+8RWRPJoH+hQIB+g8BAAAAEAAAAGOLsZMpePpPvEVkTyaB/oUD AP4PBQAAAAIBCRABAAAAOA0AADQNAAC6OQAATFpGdYdZdCoDAAoAcmNwZzkzNsEDQ2h0bWwxAzAB A58B9wqAAqQD4wIAY2gKwEBzZXQxMzQDMCc2YwwwEaBlEZEA4CdlfjUCgA/zAFAEVxGvD/MyuwLj EMcyBgAGwxKVMwRGuRDHMCAIVQeyEpU0EF9fEW8SchKjCO8J9zscnzK+NRKAHc8e0hKhDGBjAFB/ CwkBZA4wGBALpRqAD/IqFlwOogGQZyKQMyA8ACFET0NUWVBFACBIVE1MIFBVAEJMSUMgIi0vEC9X M0MlUERUREkkZDQuGBBUcgBydA5pAiAHQCVQRU4iPp8SoyMHI7AKoye8MTkjwI8kcieuGoAqEEVB RCetLw7hKM8svymUNg7gPE1wRVRBIAWgAjAJ8HQsPSIF4CRzNiZgMC4MMjkxIQ4wNzYiIBMnIAeA PUcncEVSQahUT1InrTQvgS8rnxcjcS4vI2E1GBA8Qk+8RFknrSIRNY8OEDYjwABESVYgZGlyPccj UAXAB0BpZ246EAFx9yegIxMAISAAADohCrE7wvkZ8FxxAyE8ojs1GBAi6Zw2NDsaPScpHDQ4I8DA Rk9OVCBmANAyMOcari/xHDE9IzEgMSABIOogAJB6MjAyOwsZQAMwvmMVAAOyAdA9CSLLOCth0FNQ QU44JGMLYAQQgD00OTg1MTAz0OAxLTA4MAHBSIA7C8k9J0hpOlFsLDicFgBfNABHQjsJOxc/vjU5 cS//QPJMnz1uAcA7FwqiTUgKgP8pHEiQM/E5oU9vTa84Dzkf/zovOz88T1BvPm9Vj0CPQZ//Qq9D v0TPXh9G70f/SQ9dzz9Ln1SfaS9Oz2s/ZPwmbjhic3ACgGKqFvAnYf4wUB9RL1I/U09UX25/Vn// V49Yn1mvWr9xn1zfdr9e//9gD2EfYi9jP39PZV9mb2d/bX78SYEwBbB3CxEJgCAqcBygdicAdQQg ZS1PAMADEYrhelBzawuAZ896UItwCsAm8GN1C2AFwP8zDHglJvAHgINwHDAFQAuAeTHwZXgFQAeA GkCM8S7pirFzYQfgcwNwj4B54J8E8IvgAJACIAQgd2gN4M5oj+EwMotRdG+P4YfgrnUBAI3/eEMi BGBiAxCdJuB5MeCIAI1DIG97kH8wARQABTGWkQhQkCGQ4FR2aI+AixB5itaQYJgxYr+PgZFylB94 UpLRA2BkIKC/JvIEIABwi2CL4I+AY4gA8weRGgBwcAnwi1ELgG7/v3APcR8D8BygesAEEC5pb/9q f4WfbJ+in3Hvcv90D3Uf/6Wfdz94T3lfem97f3yPfZ//iZ9/v4DPgd+C74P/hQ+GH/+HL4g/iU+6 X6HPqs+j76T//8Fvnc+e36YPpx+oL6k/qk//xG+sb61/ro+vn7Cvx4+yz//Mr7Tvtf+3D7gfuS/V P7tPV7xfvW9J7W+c4GaNsGxceSyKsZjiGgB2mTVm6QngZGIA0GsEIAWxlsN/BKAEIJtABRCNAZmv zkJw/Gh5DdEHQJBov1/Ab9uP/8KP6B/H38jvyf/LD+sfzS//zj/PRt9f01/Ub/EP3Ojd3//e7/av 1h/XL9g/2UEKo9l//9qP+x/p7/Afvy/njwRfxS//xj/HT+x/7Y/un++vB0/xz//y3/pP9P/2Dw/v +C/5PxLPfxX//Gn+f/+P0YIBHxPxQv5ySywDLw9PBU8GXxOvC6//DL8NzyP/Ik8Q/xIPGX8UL/8t XxZPF18Yby9/Go8bnxyv+x2/AYtMoRwgnymPIr8jz/8t7yXvJv8oDz4vPH8rPy7F/ULgUDfJ3YJE oD7oM49Imf9BLz+4QuFHAUSvRb9Gzklf/0pvS39Mj02fLI8tny6vM///NQ/8//4P2T8AfwGPOj87 T/9e/wiPCZ9Wf0AvUP9CT2Dv/1avV79h/zWfNq83v15fX2+XYH9hj2gmMXKhQlJHGv/QYJAgSArk P1QCZW9mf2ePI89WMeRPdXSPsG9rhk2g4ZTAZUhlYYtAB9AwjcCNAD16aC1j35AAz9/Q7X5BcOA1 cJHRz0/S21L/VA/PUkhSk1BhjGJJm+CXoD0tMV0cxjHSwFtwcWpcjbDikPFwoH4gX4hyiDF2c3oz /3bPg65qj2ufbK9aH1spb093XcRwzzCtQm+riCFP2Cf0YjefoTKVoVtx4mBbQWo4j4I6PM8vlApz 2SAIWmh1OcBlaSBbJeGAaeTAbzp/wGkuyX6AdUCZ4GF3muHjMPxtXXd/hF91T3Zfkt+T79eU/5YC WuNkW0FhlaGHcPmWM2U0ly+YP5lHMyJbQSo0W4FhldFkqDFjMgo2lqRkW7AxODo1/jOdb55/n4+g n6GvlUakMn+pgJYvpS+mP5lW4zGGQEDSaeYwZi5cAGeqD6sf/6wvrT+uT5VHZGKkAqPDsT+vsk+Z R5wfnSInmdUntM9ftd+277f/uQ+VRmSpEWa7ldFbYzK7f7yPmUdbs+Odm/BBfsDCEH7gdmnjwOXl 4WbjAXlv49C+H50T5HJlylBld8APwR/CL/9x73L/z4/Nn86vZR95n3qv/2hP0a+KP50PVP+M79hv 2X//3n/bn9yv3b9qb+Rvwu8xe2I4qQA1NDQycTLQNr8zD+cPji+Qn2QxkhxImjD9f2BsH7/RD+Dv PR/xb9WP/9af16/fb/Rf4Y/in+Ov5L//5c/rH+fv6P/qD//f7C/tP//uTwTP8N/5z/L/9A8K72Lf /2Pv/i/2L/c/+E8Mzw3f+3///I/9n/6vA/8AzwHfAu8bf88FDwYfBy8aA1dlf1HMoPF94HkgaH3g IhCb0CRQUX7gc2N1MhBps/Bzo8tPF2N3aGmCECCaYEMk0O+xb3cgd37wZT9/wDIQf1BbYCjizyB0 dx3K0GsmIJqgKYBvdGnuZiTQs+F9oHMqcCYCzxDPJ+GagH4gJZB0LiY/F2//CU8VbwtvDH8ZzxHP Et8T7/8U/zAvFx8YLx+fGk87Pxxv/x1/Ho89XyCvIb8iz0JPLl//N08wfzGPSG8+3m7zP99A7/9B /0MPRB9FL0Y/R09LH0lv/1VvVn8O3w/vMv80DzUfNi//WF84TzlfOm87fzyPT49MD38/v05/Zw9Q n1GvUr9lkUlsIHB+ACUwbu+xJNB0CSegbmtwcWF0IEPfs/IsX2LTJ8Bi4HR+ASWQaX9Qc2vPEGcl JCUwbHt88CXzYiTQKxBxAHPCIm5IKGDMsH4ALHBxJFBD6Y7wRVgkMEcoge/AcY97YtPPEGkqcHAz ysAlsSD/s/B5oSRQJcAkUKQwejB2IG8nkH4AJFB2QmWGICTgb/8rECkBe3F2QimVcNR3b3Kj/7Pw YnDPECoBdlGGMCsRcCDfKyJ7V++gevF2gy17YIXw+5rQJRBidIB5oHZBTWAplx/PIIGxKlF9T2LT YmUu/iJT71T/YR9XH4a/XG9df/9ej1+fia9hv2LPY99k72X//2tPaB9pL2o/lS9sX21vbn//mh+G L48fiE+JX6A/Wi9bP/+Tf4t/jI+Nn6Ifoy+Qz5Hf/5Lvk/+ZT5Yfly+YP7DPml9/m2+cf29lJPB1 8HvxygpkOHJhZoOPJzrPEHRy/m/KcClBJSTKYCSgJiDKwvPJkXEQZjKq4CVQKaB1Ye0sQEnFwCvx a3sBKjBzkf/K8ioSzKS7P6yzcIG9gXugf6fAJXB5YSVQfsB783ZQbN5wveJ+wCqCdkJwvSCBkXxt c6NvpH+ljyeUKsB1/mwlEMGfhLTGD8cfyC+A0F90UXXwJRArgXE0d7+BVPck8HCxwLEhnd+e76sP oQ//0h+mX6dvqH+pj9UPq6+sv/+tz67fr++1P7IPsx+0L+CP/7ZPt1+4b52/0Y/af9Ov1L//65/M H80v3t/W39fv2P/tf//bH9wv3T/eT99f5K/hf+KP/+Of/C/lv+bC9/PnD+gfuuPKLSjQaYFQY24F gHlg1ygwJZCBsC0qyC0qUyewL3/T/2D0EfRqMeoRQlL9A3lcLAB58PcAAL/pn/W//wsf7M/VT/If 8y/0P/VPDX//92/4f/mPEI/7rxWv/c/+3///7xu/5k8Db+hqdbBv0Lmk68CxTWBmgyFiKSBwwMn/ 9xcSvaAq0C4LXwxvFV8Oj/8ojxCvEb8SzxPfK38V/xcP/xgfGS8aPx+PHF8dbx5/Nv//IJ8hryK/ Cz8n/zDvKh8rL/9CD+9v8H81Ty1PLl8vb0Pv/zGPMp8zrzS/Nc87HzfvOP+/Og9SnzwvPT8+T1Ei Qn+BFyVfTnOA0GdOgGRzLP8/n0CvTM9Cz17/SB9JL0o//0tPYe9Nb05/T49Qn1GvVv//U89U31Xv bW9YD1kfWi9oAMJMBaAgWmh1XX9ej/9nf2Cvd/9iz2PfZO9l/3rv72gfaS9ssX9gUAmagiEKmv9x P4UZfa98OH9hg4GBL4I//4NOhd+G74f/iQ+KH2o/a0//bF9xr3K/c8903z9/d2+AX/9Fb0Z/R498 T31ffm9/f5tPBcIENZZxL0JPRFkJj10yN6JxSFRNTBWPXTOQVX2okAMADTT9PwMAAwAPNP0/AwAC ARQ0AQAAABAAAABOSVRB+b+4AQCqADfZbgAAAgF/AAEAAAAxAAAAMDAwMDAwMDA2MzhCQjE5MzI5 NzhGQTRGQkM0NTY0NEYyNjgxRkU4NUU0NTA0QTAwAAAAAAMABhDtK0XOAwAHEMwDAAADABAQAAAA AAMAERAAAAAAHgAIEAEAAABlAAAASElBTEwsSUZPUldBUkRFRFBSRVZJT1VTRS1NQUlMRk9SQVNL SU5HQVBBUlRJQ1VMQVJUSU1FU0xPVElOTkVYVE1FRVRJTkdJU0FXU09NRURJU0NVU1NJT05TV0hJ Q0hJTlRFTgAAAAAZkQ== --Boundary_(ID_km86FfhxJdFdZopFDmyrzg)-- ------------=_1278587484-29268-1-- From lei.zhu@huawei.com Thu Jul 8 23:19:39 2010 Return-Path: X-Original-To: conex@core3.amsl.com Delivered-To: conex@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 070B43A683C for ; Thu, 8 Jul 2010 23:19:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 2.596 X-Spam-Level: ** X-Spam-Status: No, score=2.596 tagged_above=-999 required=5 tests=[AWL=0.641, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_COM=0.553, MIME_CHARSET_FARAWAY=2.45, RDNS_NONE=0.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 kAxIpkbQRLa3 for ; Thu, 8 Jul 2010 23:19:38 -0700 (PDT) Received: from szxga04-in.huawei.com (unknown [119.145.14.67]) by core3.amsl.com (Postfix) with ESMTP id 324B13A680C for ; Thu, 8 Jul 2010 23:19:38 -0700 (PDT) Received: from huawei.com (szxga04-in [172.24.2.12]) by szxga04-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0L5A009DP1KKOJ@szxga04-in.huawei.com> for conex@ietf.org; Fri, 09 Jul 2010 14:19:32 +0800 (CST) Received: from huawei.com ([172.24.2.119]) by szxga04-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0L5A0062L1KJ59@szxga04-in.huawei.com> for conex@ietf.org; Fri, 09 Jul 2010 14:19:32 +0800 (CST) Received: from z41317 ([10.111.16.163]) by szxml06-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTPA id <0L5A00M3S1KJ2M@szxml06-in.huawei.com> for conex@ietf.org; Fri, 09 Jul 2010 14:19:31 +0800 (CST) Date: Fri, 09 Jul 2010 14:19:06 +0800 From: Zhu Lei In-reply-to: <000001cb1e8e$45aee430$a3106f0a@china.huawei.com> To: 'Zhu Lei' , conex@ietf.org Message-id: <005701cb1f2e$a3857420$a3106f0a@china.huawei.com> MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2900.3350 X-Mailer: Microsoft Office Outlook 11 Content-type: text/plain; charset=gb2312 Content-transfer-encoding: quoted-printable Thread-index: AcsekO9aI2Qfesr6RBm3xAH+0ikcswAnYuCQ Subject: Re: [conex] call for agenda items X-BeenThere: conex@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Congestion Exposure working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 09 Jul 2010 06:19:39 -0000 Hi all, =20 I forwarded previous e-mail for asking a particular time slot in next meeting. I saw some discussions which intented to include "mobility" as = part of concept of Conex. The way forward may be some introductions and use = cases happened in wireless. =20 Hopefully, I may have some feedbacks or concerns during physical = meeting.=20 =20 Br, L. =20 -------------------------------------------------------------------------= --- ---- =B7=A2=BC=FE=C8=CB: Zhu Lei [mailto:lei.zhu@huawei.com]=20 =B7=A2=CB=CD=CA=B1=BC=E4: 2010=C4=EA7=D4=C26=C8=D5 18:53 =CA=D5=BC=FE=C8=CB: conex@ietf.org =B3=AD=CB=CD: 'Zhu Lei' =D6=F7=CC=E2: [conex] An individual for your review Hi all, =20 We already had some discussions which may allow wireless access networks = to notify congestions in mail list.=20 =20 I personally think that Conex charter is asking some solutions by = stating "However, the CONEX WG will initially focus on one use case, where the = end hosts and the network that contains the destination end host are CONEX-enabled but other networks need not be."=20 =20 I have an individual draft which introduces some ideas for next f2f = meeting. I'd like to ask you to review this short document and help identify the problems which could be resolved in Conex wg. Thank you! =20 draft-lei-ecn-localised-congestion-notification-00 Hope have your feedback soon. =20 Best regards, Lei Zhu =20 From rbriscoe@jungle.bt.co.uk Sun Jul 11 18:29:56 2010 Return-Path: X-Original-To: conex@core3.amsl.com Delivered-To: conex@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 0953928C114 for ; Sun, 11 Jul 2010 18:29:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.483 X-Spam-Level: X-Spam-Status: No, score=0.483 tagged_above=-999 required=5 tests=[BAYES_50=0.001, DNS_FROM_RFC_BOGUSMX=1.482, 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 VJPMtLTGz5rq for ; Sun, 11 Jul 2010 18:29:47 -0700 (PDT) Received: from smtp1.smtp.bt.com (smtp1.smtp.bt.com [217.32.164.137]) by core3.amsl.com (Postfix) with ESMTP id 5916B3A68B7 for ; Sun, 11 Jul 2010 18:29:44 -0700 (PDT) Received: from i2kc06-ukbr.domain1.systemhost.net ([193.113.197.70]) by smtp1.smtp.bt.com with Microsoft SMTPSVC(6.0.3790.4675); Mon, 12 Jul 2010 02:29:50 +0100 Received: from cbibipnt05.iuser.iroot.adidom.com ([147.149.196.177]) by i2kc06-ukbr.domain1.systemhost.net with Microsoft SMTPSVC(6.0.3790.4675); Mon, 12 Jul 2010 02:29:50 +0100 Received: From bagheera.jungle.bt.co.uk ([132.146.168.158]) by cbibipnt05.iuser.iroot.adidom.com (WebShield SMTP v4.5 MR1a P0803.399); id 1278898188914; Mon, 12 Jul 2010 02:29:48 +0100 Received: from MUT.jungle.bt.co.uk ([10.73.208.1]) by bagheera.jungle.bt.co.uk (8.13.5/8.12.8) with ESMTP id o6C1TkRe021669 for ; Mon, 12 Jul 2010 02:29:47 +0100 Message-Id: <201007120129.o6C1TkRe021669@bagheera.jungle.bt.co.uk> X-Mailer: QUALCOMM Windows Eudora Version 7.1.0.9 Date: Mon, 12 Jul 2010 02:29:42 +0100 To: conex@ietf.org From: Bob Briscoe 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: 12 Jul 2010 01:29:50.0157 (UTC) FILETIME=[B886AFD0:01CB2161] Subject: [conex] What's the problem: excessive congestion or capacity sharing? X-BeenThere: conex@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Congestion Exposure working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 12 Jul 2010 01:29:56 -0000 ConEx list, In trying to write draft-moncaster-conex-concepts-uses, the co-authors need wider consensus from the list on how best to characterise the problem we are trying to solve. * One view says the problem should be characterised as excessive congestion. * Another view says the problem is lack of a good metric for sharing capacity. The link between the two is that capacity sharing only becomes an issue during congestion, but the latter view says congestion doesn't have to be excessive for there to still be a capacity sharing problem. Thoughts anyone? Bob ________________________________________________________________ Bob Briscoe, BT Innovate & Design From lei.zhu@huawei.com Sun Jul 11 18:51:36 2010 Return-Path: X-Original-To: conex@core3.amsl.com Delivered-To: conex@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 3DC073A68BE for ; Sun, 11 Jul 2010 18:51:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 2.552 X-Spam-Level: ** X-Spam-Status: No, score=2.552 tagged_above=-999 required=5 tests=[AWL=0.258, BAYES_00=-2.599, CN_BODY_35=0.339, FH_RELAY_NODNS=1.451, HELO_MISMATCH_COM=0.553, MIME_CHARSET_FARAWAY=2.45, RDNS_NONE=0.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 YN1gXq6HXX-k for ; Sun, 11 Jul 2010 18:51:34 -0700 (PDT) Received: from szxga01-in.huawei.com (unknown [119.145.14.64]) by core3.amsl.com (Postfix) with ESMTP id 0B2683A67AE for ; Sun, 11 Jul 2010 18:51:34 -0700 (PDT) Received: from huawei.com (szxga01-in [172.24.2.3]) by szxga01-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0L5F00I4B95QEV@szxga01-in.huawei.com> for conex@ietf.org; Mon, 12 Jul 2010 09:51:26 +0800 (CST) Received: from huawei.com ([172.24.2.119]) by szxga01-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0L5F00BLH95Q0F@szxga01-in.huawei.com> for conex@ietf.org; Mon, 12 Jul 2010 09:51:26 +0800 (CST) Received: from z41317 ([10.111.16.163]) by szxml06-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTPA id <0L5F00F8C95PYL@szxml06-in.huawei.com> for conex@ietf.org; Mon, 12 Jul 2010 09:51:26 +0800 (CST) Date: Mon, 12 Jul 2010 09:51:22 +0800 From: Zhu Lei In-reply-to: <201007120129.o6C1TkRe021669@bagheera.jungle.bt.co.uk> To: 'Bob Briscoe' , conex@ietf.org Message-id: <005f01cb2164$bb8d31b0$a3106f0a@china.huawei.com> MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2900.3350 X-Mailer: Microsoft Office Outlook 11 Content-type: text/plain; charset=gb2312 Content-transfer-encoding: quoted-printable Thread-index: AcshYdbUPiZWsjoqQqSy03Jx+HXMDgAAZ1+Q Subject: Re: [conex] What's the problem: excessive congestion or capacity sharing? X-BeenThere: conex@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Congestion Exposure working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 12 Jul 2010 01:51:36 -0000 My view is that the TCP does not know if the earlier congestion or = capacity lack would impact the usage of application. It can impact in some cases. Those earlier congestion is better to be considered in the scope. Best regards, Zhu Lei -----=D3=CA=BC=FE=D4=AD=BC=FE----- =B7=A2=BC=FE=C8=CB: conex-bounces@ietf.org = [mailto:conex-bounces@ietf.org] =B4=FA=B1=ED Bob Briscoe =B7=A2=CB=CD=CA=B1=BC=E4: 2010=C4=EA7=D4=C212=C8=D5 9:30 =CA=D5=BC=FE=C8=CB: conex@ietf.org =D6=F7=CC=E2: [conex] What's the problem: excessive congestion or = capacity sharing? ConEx list, In trying to write draft-moncaster-conex-concepts-uses, the co-authors = need wider consensus from the list on how best to characterise the problem we = are trying to solve. * One view says the problem should be characterised as excessive = congestion. * Another view says the problem is lack of a good metric for sharing capacity. The link between the two is that capacity sharing only becomes an issue during congestion, but the latter view says congestion doesn't have to = be excessive for there to still be a capacity sharing problem. Thoughts anyone? Bob ________________________________________________________________ Bob Briscoe, BT Innovate & Design=20 _______________________________________________ conex mailing list conex@ietf.org https://www.ietf.org/mailman/listinfo/conex From marcelo@it.uc3m.es Mon Jul 12 01:16:38 2010 Return-Path: X-Original-To: conex@core3.amsl.com Delivered-To: conex@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 8C1CF3A6889 for ; Mon, 12 Jul 2010 01:16:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.599 X-Spam-Level: X-Spam-Status: No, score=-106.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] 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 1CbDVTfqBDak for ; Mon, 12 Jul 2010 01:16:37 -0700 (PDT) Received: from smtp01.uc3m.es (smtp01.uc3m.es [163.117.176.131]) by core3.amsl.com (Postfix) with ESMTP id 830A43A698D for ; Mon, 12 Jul 2010 01:16:37 -0700 (PDT) X-uc3m-safe: yes Received: from marcelo-bagnulos-macbook-pro.local (wlap005.it.uc3m.es [163.117.139.108]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by smtp01.uc3m.es (Postfix) with ESMTP id 30D91BE0596 for ; Mon, 12 Jul 2010 10:16:44 +0200 (CEST) Message-ID: <4C3ACF6B.4080405@it.uc3m.es> Date: Mon, 12 Jul 2010 10:16:43 +0200 From: marcelo bagnulo braun User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.5; es-ES; rv:1.9.1.10) Gecko/20100512 Thunderbird/3.0.5 MIME-Version: 1.0 To: conex@ietf.org References: <201007120129.o6C1TkRe021669@bagheera.jungle.bt.co.uk> In-Reply-To: <201007120129.o6C1TkRe021669@bagheera.jungle.bt.co.uk> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit X-TM-AS-Product-Ver: IMSS-7.0.0.3116-6.0.0.1038-17500.003 Subject: Re: [conex] What's the problem: excessive congestion or capacity sharing? X-BeenThere: conex@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Congestion Exposure working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 12 Jul 2010 08:16:38 -0000 mmm, i am not sure why excessive congestion as opposed to simply congestion? If we rephrase this removing the excessive, it results only in congestion, which doesn't seem to be very descriptive. OTOH, the concept of an alternative metric seems to match more my current understanding. So without further context of the discussion, i would go for the second. Regards, marcelo El 12/07/10 3:29, Bob Briscoe escribió: > ConEx list, > > In trying to write draft-moncaster-conex-concepts-uses, the co-authors > need wider consensus from the list on how best to characterise the > problem we are trying to solve. > > * One view says the problem should be characterised as excessive > congestion. > * Another view says the problem is lack of a good metric for sharing > capacity. > > The link between the two is that capacity sharing only becomes an > issue during congestion, but the latter view says congestion doesn't > have to be excessive for there to still be a capacity sharing problem. > > Thoughts anyone? > > > Bob > > > ________________________________________________________________ > Bob Briscoe, BT Innovate & Design > _______________________________________________ > conex mailing list > conex@ietf.org > https://www.ietf.org/mailman/listinfo/conex > From ford@isoc.org Mon Jul 12 01:36:16 2010 Return-Path: X-Original-To: conex@core3.amsl.com Delivered-To: conex@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id A28813A6774 for ; Mon, 12 Jul 2010 01:36:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.532 X-Spam-Level: X-Spam-Status: No, score=-101.532 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1, RCVD_NUMERIC_HELO=2.067, USER_IN_WHITELIST=-100] 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 6jxncREYeZ6l for ; Mon, 12 Jul 2010 01:36:16 -0700 (PDT) Received: from smtp131.iad.emailsrvr.com (smtp131.iad.emailsrvr.com [207.97.245.131]) by core3.amsl.com (Postfix) with ESMTP id CB0C63A680E for ; Mon, 12 Jul 2010 01:36:15 -0700 (PDT) Received: from localhost (localhost.localdomain [127.0.0.1]) by smtp33.relay.iad1a.emailsrvr.com (SMTP Server) with ESMTP id 7A15D304D6; Mon, 12 Jul 2010 04:36:23 -0400 (EDT) X-Virus-Scanned: OK Received: from 220.146.187.81.in-addr.arpa (220.146.187.81.in-addr.arpa [81.187.146.220]) (Authenticated sender: ford@isoc.org) by smtp33.relay.iad1a.emailsrvr.com (SMTP Server) with ESMTPSA id DB7DF304D0; Mon, 12 Jul 2010 04:36:22 -0400 (EDT) Mime-Version: 1.0 (Apple Message framework v1081) Content-Type: text/plain; charset=iso-8859-1 From: Matthew Ford In-Reply-To: <4C3ACF6B.4080405@it.uc3m.es> Date: Mon, 12 Jul 2010 09:36:20 +0100 Content-Transfer-Encoding: quoted-printable Message-Id: References: <201007120129.o6C1TkRe021669@bagheera.jungle.bt.co.uk> <4C3ACF6B.4080405@it.uc3m.es> To: marcelo bagnulo braun X-Mailer: Apple Mail (2.1081) Cc: conex@ietf.org Subject: Re: [conex] What's the problem: excessive congestion or capacity sharing? X-BeenThere: conex@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Congestion Exposure working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 12 Jul 2010 08:36:16 -0000 I agree with Marcelo. 'Excessive' is a pretty nebulous qualifier. = Congestion will come and go at various timescales depending on competing = traffic, upgrades, new paths becoming available etc. It's the new metric = that is interesting. Mat On 12 Jul 2010, at 09:16, marcelo bagnulo braun wrote: > mmm, i am not sure why excessive congestion as opposed to simply = congestion? > If we rephrase this removing the excessive, it results only in = congestion, which doesn't seem to be very descriptive. >=20 > OTOH, the concept of an alternative metric seems to match more my = current understanding. > So without further context of the discussion, i would go for the = second. >=20 > Regards, marcelo >=20 >=20 >=20 > El 12/07/10 3:29, Bob Briscoe escribi=F3: >> ConEx list, >>=20 >> In trying to write draft-moncaster-conex-concepts-uses, the = co-authors need wider consensus from the list on how best to = characterise the problem we are trying to solve. >>=20 >> * One view says the problem should be characterised as excessive = congestion. >> * Another view says the problem is lack of a good metric for sharing = capacity. >>=20 >> The link between the two is that capacity sharing only becomes an = issue during congestion, but the latter view says congestion doesn't = have to be excessive for there to still be a capacity sharing problem. >>=20 >> Thoughts anyone? >>=20 >>=20 >> Bob >>=20 >>=20 >> ________________________________________________________________ >> Bob Briscoe, BT Innovate & Design >> _______________________________________________ >> conex mailing list >> conex@ietf.org >> https://www.ietf.org/mailman/listinfo/conex >>=20 >=20 > _______________________________________________ > conex mailing list > conex@ietf.org > https://www.ietf.org/mailman/listinfo/conex From lists@syshex.com Mon Jul 12 01:43:58 2010 Return-Path: X-Original-To: conex@core3.amsl.com Delivered-To: conex@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 392FA3A6774 for ; Mon, 12 Jul 2010 01:43:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.115 X-Spam-Level: X-Spam-Status: No, score=0.115 tagged_above=-999 required=5 tests=[BAYES_40=-0.185, MIME_8BIT_HEADER=0.3] 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 E-v+B1aVv44T for ; Mon, 12 Jul 2010 01:43:57 -0700 (PDT) Received: from mail-ww0-f44.google.com (mail-ww0-f44.google.com [74.125.82.44]) by core3.amsl.com (Postfix) with ESMTP id 4C6213A67F2 for ; Mon, 12 Jul 2010 01:43:57 -0700 (PDT) Received: by wwi17 with SMTP id 17so386512wwi.13 for ; Mon, 12 Jul 2010 01:44:00 -0700 (PDT) Received: by 10.216.167.138 with SMTP id i10mr8255988wel.57.1278924240764; Mon, 12 Jul 2010 01:44:00 -0700 (PDT) Received: from dhcp-81-130.eduroam.ucl.ac.uk (dhcp-81-130.eduroam.ucl.ac.uk [144.82.81.130]) by mx.google.com with ESMTPS id o54sm1554245wej.5.2010.07.12.01.43.59 (version=TLSv1/SSLv3 cipher=RC4-MD5); Mon, 12 Jul 2010 01:44:00 -0700 (PDT) Mime-Version: 1.0 (Apple Message framework v1081) Content-Type: text/plain; charset=us-ascii From: =?iso-8859-1?Q?Jo=E3o_Taveira_Ara=FAjo?= In-Reply-To: <201007120129.o6C1TkRe021669@bagheera.jungle.bt.co.uk> Date: Mon, 12 Jul 2010 09:43:58 +0100 Content-Transfer-Encoding: quoted-printable Message-Id: References: <201007120129.o6C1TkRe021669@bagheera.jungle.bt.co.uk> To: Bob Briscoe X-Mailer: Apple Mail (2.1081) Cc: conex@ietf.org Subject: Re: [conex] What's the problem: excessive congestion or capacity sharing? X-BeenThere: conex@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Congestion Exposure working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 12 Jul 2010 08:43:58 -0000 Hi Bob, On 12 Jul 2010, at 02:29, Bob Briscoe wrote: > ConEx list, >=20 > In trying to write draft-moncaster-conex-concepts-uses, the co-authors = need wider consensus from the list on how best to characterise the = problem we are trying to solve. >=20 > * One view says the problem should be characterised as excessive = congestion. > * Another view says the problem is lack of a good metric for sharing = capacity. I'd argue option B, simply because "excessive congestion" is an entirely = subjective assessment which most network operators will staunchly deny. = In part, this may be because they can't see it, but more likely than not = a combination of other factors (over-provisioning, TCP's inability to = adapt to large pipes fast enough, ...) means congestion is relatively = low. It's also terribly confusing to advocate congestion is a *good thing* as = a by-product of fast and efficient transport on one hand, and on the = other complain there is excessive congestion. I think it would be a lot easier to argue for conex on the basis that = where and when this contention does arise, congestion exposure provides = the best metric to mediate between sources. Cheers, Joao From john@jlc.net Mon Jul 12 01:55:58 2010 Return-Path: X-Original-To: conex@core3.amsl.com Delivered-To: conex@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 82A133A6A6F for ; Mon, 12 Jul 2010 01:55:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.837 X-Spam-Level: X-Spam-Status: No, score=-1.837 tagged_above=-999 required=5 tests=[BAYES_50=0.001, FH_RELAY_NODNS=1.451, HELO_MISMATCH_NET=0.611, RCVD_IN_DNSWL_MED=-4, RDNS_NONE=0.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 McYFBRYbPqZf for ; Mon, 12 Jul 2010 01:55:57 -0700 (PDT) Received: from mailhost.jlc.net (unknown [199.201.159.4]) by core3.amsl.com (Postfix) with ESMTP id 88D1A3A693B for ; Mon, 12 Jul 2010 01:55:57 -0700 (PDT) Received: by mailhost.jlc.net (Postfix, from userid 104) id 2772F33C41; Mon, 12 Jul 2010 04:56:05 -0400 (EDT) Date: Mon, 12 Jul 2010 04:56:05 -0400 From: John Leslie To: marcelo bagnulo braun Message-ID: <20100712085605.GE47417@verdi> References: <201007120129.o6C1TkRe021669@bagheera.jungle.bt.co.uk> <4C3ACF6B.4080405@it.uc3m.es> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <4C3ACF6B.4080405@it.uc3m.es> User-Agent: Mutt/1.4.1i Cc: conex@ietf.org Subject: Re: [conex] What's the problem: excessive congestion or capacity sharing? X-BeenThere: conex@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Congestion Exposure working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 12 Jul 2010 08:55:58 -0000 marcelo bagnulo braun wrote: > El 12/07/10 3:29, Bob Briscoe escribi?: >> >> In trying to write draft-moncaster-conex-concepts-uses, the co-authors >> need wider consensus from the list on how best to characterise the >> problem we are trying to solve. Indeed, Bob and I have been exchanging heated emails. He wants to rewrite the Abstract and Introduction. I don't. >> * One view says the problem should be characterised as excessive >> congestion. >> * Another view says the problem is lack of a good metric for sharing >> capacity. I think Bob wants to remove all language about "managing congestion" and replace it with language about "sharing capacity". I have some problems with that, because I prefer the dumb network to the telco model. I would like to emphasize the need to justify upgrades rather than worry about how the network decides which traffic deserves priority. I also (so far) fail to get as crisp an idea of what Bob means for the network to do under his "sharing capacity" paradigm. In any case, we are up against a posting deadline; and I have suggested to Bob that we work this out on the ConEx list _after_ the posting deadline. Poor Toby has to get _something_ out today! >> The link between the two is that capacity sharing only becomes an >> issue during congestion, but the latter view says congestion doesn't >> have to be excessive for there to still be a capacity sharing problem. I don't actually agree with Bob that there are no capacity-sharing issues outside times of congestion. (Or perhaps I misunderstand Bob: is he saying that capacity-sharing is a problem only when there's congestion, or isn't he?) >> Thoughts anyone? > > mmm, i am not sure why excessive congestion as opposed to simply > congestion? The language in Toby's current draft is quite close to what was posted to this list in the -00 draft. I may have missed a case of "excessive congestion", but I don't offhand remember that term being used. Of course, I believe all the authors agree that some congestion is at least "normal" if not indeed "essential" to the operation of the Internet. Bob has a fixation, AFAICT, that if "congestion" causes problems, it must be "excessive congestion" that's causing the problems. I, OTOH, don't agree that congestion has to be "excessive" for it to cause problems, it's merely that those problems become more serious as congestion increases. > If we rephrase this removing the excessive, it results only in > congestion, which doesn't seem to be very descriptive. I have argued in ICCRG that we need to be more careful what we mean when we say "congestion". We have tried to move in that direction in defining "congestion" in this draft. > OTOH, the concept of an alternative metric seems to match more my > current understanding. I don't quite get what you are saying here. > So without further context of the discussion, i would go for the second. Does that mean you recommend Toby accomplish that rewrite today? -- John Leslie From marcelo@it.uc3m.es Mon Jul 12 02:10:00 2010 Return-Path: X-Original-To: conex@core3.amsl.com Delivered-To: conex@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 15F1A3A6840 for ; Mon, 12 Jul 2010 02:10:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.599 X-Spam-Level: X-Spam-Status: No, score=-106.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] 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 J8unUNMIfAhu for ; Mon, 12 Jul 2010 02:09:59 -0700 (PDT) Received: from smtp03.uc3m.es (smtp03.uc3m.es [163.117.176.133]) by core3.amsl.com (Postfix) with ESMTP id D38C73A67F2 for ; Mon, 12 Jul 2010 02:09:58 -0700 (PDT) X-uc3m-safe: yes Received: from marcelo-bagnulos-macbook-pro.local (wlap005.it.uc3m.es [163.117.139.108]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by smtp03.uc3m.es (Postfix) with ESMTP id 6EB728394E9; Mon, 12 Jul 2010 11:10:05 +0200 (CEST) Message-ID: <4C3ADBED.10001@it.uc3m.es> Date: Mon, 12 Jul 2010 11:10:05 +0200 From: marcelo bagnulo braun User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.5; es-ES; rv:1.9.1.10) Gecko/20100512 Thunderbird/3.0.5 MIME-Version: 1.0 To: John Leslie References: <201007120129.o6C1TkRe021669@bagheera.jungle.bt.co.uk> <4C3ACF6B.4080405@it.uc3m.es> <20100712085605.GE47417@verdi> In-Reply-To: <20100712085605.GE47417@verdi> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit X-TM-AS-Product-Ver: IMSS-7.0.0.3116-6.0.0.1038-17500.006 Cc: conex@ietf.org Subject: Re: [conex] What's the problem: excessive congestion or capacity sharing? X-BeenThere: conex@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Congestion Exposure working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 12 Jul 2010 09:10:00 -0000 El 12/07/10 10:56, John Leslie escribió: > marcelo bagnulo braun wrote: > >> El 12/07/10 3:29, Bob Briscoe escribi?: >> >>> In trying to write draft-moncaster-conex-concepts-uses, the co-authors >>> need wider consensus from the list on how best to characterise the >>> problem we are trying to solve. >>> > Indeed, Bob and I have been exchanging heated emails. He wants to > rewrite the Abstract and Introduction. I don't. > > >>> * One view says the problem should be characterised as excessive >>> congestion. >>> * Another view says the problem is lack of a good metric for sharing >>> capacity. >>> > I think Bob wants to remove all language about "managing congestion" > and replace it with language about "sharing capacity". > it would seem odd to me that a document that describes the use cases for exposing congestion doesn't talk about congestion and only talks about sharing capacity. snip > Thoughts anyone? > >> mmm, i am not sure why excessive congestion as opposed to simply >> congestion? >> > The language in Toby's current draft is quite close to what was > posted to this list in the -00 draft. I may have missed a case of > "excessive congestion", but I don't offhand remember that term being > used. > > Of course, I believe all the authors agree that some congestion > is at least "normal" if not indeed "essential" to the operation of > the Internet. Bob has a fixation, AFAICT, that if "congestion" > causes problems, it must be "excessive congestion" that's causing > the problems. I, OTOH, don't agree that congestion has to be > "excessive" for it to cause problems, it's merely that those problems > become more serious as congestion increases. > > guessing, i would understand that excessive congestion would mean that the overall throughput of the network start to severely decline due to retransimissions, and that could be characterized as excessive congestion (as opposed to normal losses that keep TCP under control) In that context, i think that exposing congestion is not only useful during excessive congestion, but also a mean to share the available resources. >> If we rephrase this removing the excessive, it results only in >> congestion, which doesn't seem to be very descriptive. >> > I have argued in ICCRG that we need to be more careful what we > mean when we say "congestion". We have tried to move in that direction > in defining "congestion" in this draft. > > >> OTOH, the concept of an alternative metric seems to match more my >> current understanding. >> > I don't quite get what you are saying here. > I mean that exposing e2e congestion to the network is a mean to measure the service that the end host is receiving from the network, so i can see the metric as being one apsect where the use case should cover > >> So without further context of the discussion, i would go for the second. >> > Does that mean you recommend Toby accomplish that rewrite today? > > no, it is only my opinion on the questions Bob asked to the ml Regards, marcelo > -- > John Leslie > > From acooper@cdt.org Mon Jul 12 02:22:44 2010 Return-Path: X-Original-To: conex@core3.amsl.com Delivered-To: conex@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 540123A6895 for ; Mon, 12 Jul 2010 02:22:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.592 X-Spam-Level: X-Spam-Status: No, score=-2.592 tagged_above=-999 required=5 tests=[AWL=0.007, BAYES_00=-2.599] 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 jsZBhH+Gj1Ui for ; Mon, 12 Jul 2010 02:22:43 -0700 (PDT) Received: from mail.maclaboratory.net (mail.maclaboratory.net [209.190.215.232]) by core3.amsl.com (Postfix) with ESMTP id 5A6963A6403 for ; Mon, 12 Jul 2010 02:22:43 -0700 (PDT) Received: from localhost ([127.0.0.1]) by mail.maclaboratory.net (using TLSv1/SSLv3 with cipher AES128-SHA (128 bits)); Mon, 12 Jul 2010 05:22:44 -0400 Message-Id: From: Alissa Cooper To: Bob Briscoe In-Reply-To: <201007120129.o6C1TkRe021669@bagheera.jungle.bt.co.uk> Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v936) Date: Mon, 12 Jul 2010 10:22:41 +0100 References: <201007120129.o6C1TkRe021669@bagheera.jungle.bt.co.uk> X-Mailer: Apple Mail (2.936) Cc: conex@ietf.org Subject: Re: [conex] What's the problem: excessive congestion or capacity sharing? X-BeenThere: conex@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Congestion Exposure working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 12 Jul 2010 09:22:44 -0000 Hi Bob, On Jul 12, 2010, at 2:29 AM, Bob Briscoe wrote: > ConEx list, > > In trying to write draft-moncaster-conex-concepts-uses, the co- > authors need wider consensus from the list on how best to > characterise the problem we are trying to solve. > > * One view says the problem should be characterised as excessive > congestion. > * Another view says the problem is lack of a good metric for sharing > capacity. > Those two things don't seem quite comparable to me. If the question is, "what metric is that we cannot currently measure?" And the answer choices are * congestion volume, or * impact on shared capacity If you think your metric is useful even in times of no congestion (however the relevant operator wants to define those times), call it impact on shared capacity. If you think your metric is only useful in times of congestion, call it congestion volume. Alissa > The link between the two is that capacity sharing only becomes an > issue during congestion, but the latter view says congestion doesn't > have to be excessive for there to still be a capacity sharing problem. > > Thoughts anyone? > > > Bob > > > ________________________________________________________________ > Bob Briscoe, BT Innovate & Design > _______________________________________________ > conex mailing list > conex@ietf.org > https://www.ietf.org/mailman/listinfo/conex > From toby@moncaster.com Mon Jul 12 02:37:27 2010 Return-Path: X-Original-To: conex@core3.amsl.com Delivered-To: conex@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id CB0A13A67B5 for ; Mon, 12 Jul 2010 02:37:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.39 X-Spam-Level: X-Spam-Status: No, score=-0.39 tagged_above=-999 required=5 tests=[BAYES_20=-0.74, HELO_EQ_DE=0.35] 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 gE1fWMj-HR5N for ; Mon, 12 Jul 2010 02:37:26 -0700 (PDT) Received: from moutng.kundenserver.de (moutng.kundenserver.de [212.227.126.171]) by core3.amsl.com (Postfix) with ESMTP id 9473C3A6828 for ; Mon, 12 Jul 2010 02:37:26 -0700 (PDT) Received: from TobysHP (host86-156-248-3.range86-156.btcentralplus.com [86.156.248.3]) by mrelayeu.kundenserver.de (node=mrbap0) with ESMTP (Nemesis) id 0MDF52-1OJwe62NrQ-00GqBA; Mon, 12 Jul 2010 11:37:31 +0200 From: "Toby Moncaster" To: "'marcelo bagnulo braun'" , "'John Leslie'" References: <201007120129.o6C1TkRe021669@bagheera.jungle.bt.co.uk> <4C3ACF6B.4080405@it.uc3m.es> <20100712085605.GE47417@verdi> <4C3ADBED.10001@it.uc3m.es> In-Reply-To: <4C3ADBED.10001@it.uc3m.es> Date: Mon, 12 Jul 2010 10:37:28 +0100 Message-ID: <000601cb21a5$d89428e0$89bc7aa0$@com> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable X-Mailer: Microsoft Office Outlook 12.0 Thread-Index: Acshogc8UR9YZYpPQQC4fOWYE6h82wAAvJtg Content-Language: en-gb X-Provags-ID: V02:K0:oWzXGC7F8lQLiRv/tcse8SzJl/vUozOjteCI0IMquqN Df2FnXskMBJUMJLNTu3koIPhJa3bg8JmkWV4F8bv/2N7wceQfN Th6W7pMsRY/sLGITlsbddTOyPa4jvBxK0Htye3YfesMw++LGPc FAOZw++8xPfjEegl5CpgTWXnZ3z+b/0L9zCidxB6Z0uorWmh7/ oJQz6It+cDUh25eTBaymm3ZbeOFy4CPwUmK2XcZsr8= Cc: conex@ietf.org Subject: Re: [conex] What's the problem: excessive congestion or capacity sharing? X-BeenThere: conex@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Congestion Exposure working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 12 Jul 2010 09:37:27 -0000 OK, Marcelo got in before me... one inline Toby > -----Original Message----- > From: conex-bounces@ietf.org [mailto:conex-bounces@ietf.org] On Behalf > Of marcelo bagnulo braun > Sent: 12 July 2010 10:10 > To: John Leslie > Cc: conex@ietf.org > Subject: Re: [conex] What's the problem: excessive congestion or > capacity sharing? >=20 > El 12/07/10 10:56, John Leslie escribi=F3: > > marcelo bagnulo braun wrote: > > > >> El 12/07/10 3:29, Bob Briscoe escribi?: > >> > >>> In trying to write draft-moncaster-conex-concepts-uses, the co- > authors > >>> need wider consensus from the list on how best to characterise the > >>> problem we are trying to solve. > >>> > > Indeed, Bob and I have been exchanging heated emails. He wants = to > > rewrite the Abstract and Introduction. I don't. > > > > > >>> * One view says the problem should be characterised as excessive > >>> congestion. > >>> * Another view says the problem is lack of a good metric for > sharing > >>> capacity. > >>> > > I think Bob wants to remove all language about "managing > congestion" > > and replace it with language about "sharing capacity". > > > it would seem odd to me that a document that describes the use cases > for > exposing congestion doesn't talk about congestion and only talks about > sharing capacity. >=20 > snip >=20 > > Thoughts anyone? > > > >> mmm, i am not sure why excessive congestion as opposed to simply > >> congestion? > >> > > The language in Toby's current draft is quite close to what was > > posted to this list in the -00 draft. I may have missed a case of > > "excessive congestion", but I don't offhand remember that term being > > used. > > > > Of course, I believe all the authors agree that some congestion > > is at least "normal" if not indeed "essential" to the operation of > > the Internet. Bob has a fixation, AFAICT, that if "congestion" > > causes problems, it must be "excessive congestion" that's causing > > the problems. I, OTOH, don't agree that congestion has to be > > "excessive" for it to cause problems, it's merely that those = problems > > become more serious as congestion increases. > > > > > guessing, i would understand that excessive congestion would mean that > the overall throughput of the network start to severely decline due to > retransimissions, and that could be characterized as excessive > congestion (as opposed to normal losses that keep TCP under control) Yes, that is exactly the meaning I have in mind when I say "Excessive Congestion". Perhaps it would be better to talk about "detrimental = levels of congestion" or some such... Cicero (apparently) said "Never go to excess, but let moderation be your guide.=94 Congestion is a good example. If there is no congestion then = TCP, etc have no signal to work with. If there is excessive congestion you = get potential collapse, or at least a significant reduction in utility. And = when congestion is measured by ECN it is pre-empting any damage to capacity through loss. I am sure Bob could come in here with some good stuff = about the shape of the ECN marking curve... Anyway, back to re-working the draft for today's deadline... >=20 > In that context, i think that exposing congestion is not only useful > during excessive congestion, but also a mean to share the available > resources. >=20 > >> If we rephrase this removing the excessive, it results only in > >> congestion, which doesn't seem to be very descriptive. > >> > > I have argued in ICCRG that we need to be more careful what we > > mean when we say "congestion". We have tried to move in that > direction > > in defining "congestion" in this draft. > > > > > >> OTOH, the concept of an alternative metric seems to match more my > >> current understanding. > >> > > I don't quite get what you are saying here. > > >=20 > I mean that exposing e2e congestion to the network is a mean to = measure > the service that the end host is receiving from the network, so i can > see the metric as being one apsect where the use case should cover >=20 > > > >> So without further context of the discussion, i would go for the > second. > >> > > Does that mean you recommend Toby accomplish that rewrite today? > > > > > no, it is only my opinion on the questions Bob asked to the ml >=20 > Regards, marcelo >=20 >=20 > > -- > > John Leslie > > > > >=20 > _______________________________________________ > conex mailing list > conex@ietf.org > https://www.ietf.org/mailman/listinfo/conex From dave.mcdysan@verizon.com Mon Jul 12 03:37:17 2010 Return-Path: X-Original-To: conex@core3.amsl.com Delivered-To: conex@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id ECC623A696C for ; Mon, 12 Jul 2010 03:37:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.185 X-Spam-Level: X-Spam-Status: No, score=-1.185 tagged_above=-999 required=5 tests=[BAYES_40=-0.185, 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 pwXOMP2MEZYM for ; Mon, 12 Jul 2010 03:37:15 -0700 (PDT) Received: from sacmail2.verizon.com (sacmail2.verizon.com [192.76.84.41]) by core3.amsl.com (Postfix) with ESMTP id 113423A6856 for ; Mon, 12 Jul 2010 03:37:15 -0700 (PDT) Received: from irvintrmemf3.verizon.com (irvintrmemf3.verizon.com [138.83.34.103]) by sacmail2.verizon.com (8.13.7+Sun/8.13.3) with ESMTP id o6CAaKT1010198 for ; Mon, 12 Jul 2010 06:37:12 -0400 (EDT) X-AuditID: 8a532267-b7bd2ae0000002f0-e8-4c3af0534f5d Received: from smtptpa3.verizon.com ( [138.83.71.176]) by irvintrmemf3.verizon.com (Symantec Mail Security) with SMTP id 12.4A.00752.350FA3C4; Mon, 12 Jul 2010 05:37:07 -0500 (CDT) Received: from FHDP1CCMXCG01.us.one.verizon.com ([166.68.240.33]) by smtptpa3.verizon.com (8.13.3/8.13.3) with ESMTP id o6CAb6wU010588 for ; Mon, 12 Jul 2010 06:37:06 -0400 (EDT) Received: from FHDP1LUMXCV14.us.one.verizon.com ([166.68.125.35]) by FHDP1CCMXCG01.us.one.verizon.com with Microsoft SMTPSVC(6.0.3790.4675); Mon, 12 Jul 2010 06:37:06 -0400 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Mon, 12 Jul 2010 06:36:56 -0400 Message-ID: <793F49BA1FC821409F99F10862A0E4DB078CEA02@FHDP1LUMXCV14.us.one.verizon.com> In-Reply-To: <201007120129.o6C1TkRe021669@bagheera.jungle.bt.co.uk> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [conex] What's the problem: excessive congestion or capacitysharing? Thread-Index: AcshYdUrveLp3ayvSxS5xBxjOXZDtwASibHg References: <201007120129.o6C1TkRe021669@bagheera.jungle.bt.co.uk> From: "Mcdysan, David E" To: X-OriginalArrivalTime: 12 Jul 2010 10:37:06.0663 (UTC) FILETIME=[2C9BDF70:01CB21AE] X-Brightmail-Tracker: AAAAAA== Subject: Re: [conex] What's the problem: excessive congestion or capacitysharing? X-BeenThere: conex@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Congestion Exposure working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 12 Jul 2010 10:37:18 -0000 Hi Bob, I believe there are a number of use case categories, and you list two at a very high level. Below is my interpretation of your two scenarios: - "Excessive Congestion" Other posts have questioned the definition of "excessive." One definition is the case where queuing delays and possibly loss occur for (at least) packets with a QoS class with offered load greater than the configured serving bandwidth/queuing.=20 - "Sharing capacity" is quite general and could imply a number of "sharing" scenarios along some metric for fairness (not sure if this is what you meant). IMO, there is at least two other categories which are very important, and may be a partial answer to the question regarding the definition of "shared capacity" posed by John Leslie.=20 - Feedback on usage as related to subscription parameters: In some access networks (e.g., wireless) there are charges based upon usage volume. Charging may also vary by time of day and day of week. Feedback indicating whether a customer is approaching or has crossed into a new usage tier is quite important. A method more real time than a customer receiving a large bill at the end of the month is definitely an operational problem today. - Feedback on usage as related to historical usage and current usage state: Also, in other networks there are periods of peak usage and periods where there is spare capacity, and this may be charged for at a lesser rate than peak period. However, the off-peak periods are also times when service providers perform maintenance, so even though there is normally spare capacity in the middle of the night, if a failure occurs during a maintenance window then congestion may result and feedback to achieve good throughput during such a condition is desirable. This type of feedback could be used by ledbat style applications.=20 Thanks, Dave > -----Original Message----- > From: conex-bounces@ietf.org [mailto:conex-bounces@ietf.org]=20 > On Behalf Of Bob Briscoe > Sent: Sunday, July 11, 2010 9:30 PM > To: conex@ietf.org > Subject: [conex] What's the problem: excessive congestion or=20 > capacitysharing? >=20 > ConEx list, >=20 > In trying to write draft-moncaster-conex-concepts-uses, the=20 > co-authors need wider consensus from the list on how best to=20 > characterise the problem we are trying to solve. >=20 > * One view says the problem should be characterised as=20 > excessive congestion. > * Another view says the problem is lack of a good metric for=20 > sharing capacity. >=20 > The link between the two is that capacity sharing only=20 > becomes an issue during congestion, but the latter view says=20 > congestion doesn't have to be excessive for there to still be=20 > a capacity sharing problem. >=20 > Thoughts anyone? >=20 >=20 > Bob >=20 >=20 > ________________________________________________________________ > Bob Briscoe, BT Innovate & Design=20 >=20 > _______________________________________________ > conex mailing list > conex@ietf.org > https://www.ietf.org/mailman/listinfo/conex >=20 From rbriscoe@jungle.bt.co.uk Mon Jul 12 09:34:07 2010 Return-Path: X-Original-To: conex@core3.amsl.com Delivered-To: conex@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 29E163A6A45 for ; Mon, 12 Jul 2010 09:34:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.39 X-Spam-Level: X-Spam-Status: No, score=0.39 tagged_above=-999 required=5 tests=[AWL=0.093, BAYES_40=-0.185, DNS_FROM_RFC_BOGUSMX=1.482, 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 kedoW2klkw-H for ; Mon, 12 Jul 2010 09:34:00 -0700 (PDT) Received: from smtp2.smtp.bt.com (smtp2.smtp.bt.com [217.32.164.150]) by core3.amsl.com (Postfix) with ESMTP id 946063A6B63 for ; Mon, 12 Jul 2010 09:33:57 -0700 (PDT) Received: from i2kc06-ukbr.domain1.systemhost.net ([193.113.197.70]) by smtp2.smtp.bt.com with Microsoft SMTPSVC(6.0.3790.4675); Mon, 12 Jul 2010 17:34:04 +0100 Received: from cbibipnt05.iuser.iroot.adidom.com ([147.149.196.177]) by i2kc06-ukbr.domain1.systemhost.net with Microsoft SMTPSVC(6.0.3790.4675); Mon, 12 Jul 2010 17:33:42 +0100 Received: From bagheera.jungle.bt.co.uk ([132.146.168.158]) by cbibipnt05.iuser.iroot.adidom.com (WebShield SMTP v4.5 MR1a P0803.399); id 1278952418499; Mon, 12 Jul 2010 17:33:38 +0100 Received: from MUT.jungle.bt.co.uk ([10.73.208.229]) by bagheera.jungle.bt.co.uk (8.13.5/8.12.8) with ESMTP id o6CGXblx031607; Mon, 12 Jul 2010 17:33:37 +0100 Message-Id: <201007121633.o6CGXblx031607@bagheera.jungle.bt.co.uk> X-Mailer: QUALCOMM Windows Eudora Version 7.1.0.9 Date: Mon, 12 Jul 2010 17:33:35 +0100 To: Alissa Cooper From: Bob Briscoe In-Reply-To: References: <201007120129.o6C1TkRe021669@bagheera.jungle.bt.co.uk> 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: 12 Jul 2010 16:33:42.0056 (UTC) FILETIME=[FD41C280:01CB21DF] Cc: conex@ietf.org Subject: Re: [conex] What's the problem: excessive congestion or capacity sharing? X-BeenThere: conex@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Congestion Exposure working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 12 Jul 2010 16:34:07 -0000 Alissa, The distinction I was trying to make was between ultimate problems we might solve with exposed congestion (ConEx). Are we: - exposing congestion in order ultimately to reduce congestion? - exposing congestion in order to share capacity better? Bob At 10:22 12/07/2010, Alissa Cooper wrote: >Hi Bob, > >On Jul 12, 2010, at 2:29 AM, Bob Briscoe wrote: > >>ConEx list, >> >>In trying to write draft-moncaster-conex-concepts-uses, the co- >>authors need wider consensus from the list on how best to >>characterise the problem we are trying to solve. >> >>* One view says the problem should be characterised as excessive >>congestion. >>* Another view says the problem is lack of a good metric for sharing >>capacity. > >Those two things don't seem quite comparable to me. If the question is, > >"what metric is that we cannot currently measure?" > >And the answer choices are > >* congestion volume, or >* impact on shared capacity > >If you think your metric is useful even in times of no congestion >(however the relevant operator wants to define those times), call it >impact on shared capacity. If you think your metric is only useful in >times of congestion, call it congestion volume. > >Alissa > >>The link between the two is that capacity sharing only becomes an >>issue during congestion, but the latter view says congestion doesn't >>have to be excessive for there to still be a capacity sharing problem. >> >>Thoughts anyone? >> >> >>Bob >> >> >>________________________________________________________________ >>Bob Briscoe, BT Innovate & Design >>_______________________________________________ >>conex mailing list >>conex@ietf.org >>https://www.ietf.org/mailman/listinfo/conex ________________________________________________________________ Bob Briscoe, BT Innovate & Design From rbriscoe@jungle.bt.co.uk Mon Jul 12 09:49:16 2010 Return-Path: X-Original-To: conex@core3.amsl.com Delivered-To: conex@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 486273A69B4 for ; Mon, 12 Jul 2010 09:49:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.367 X-Spam-Level: X-Spam-Status: No, score=0.367 tagged_above=-999 required=5 tests=[AWL=0.070, BAYES_40=-0.185, DNS_FROM_RFC_BOGUSMX=1.482, 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 edvElymOq2-O for ; Mon, 12 Jul 2010 09:49:10 -0700 (PDT) Received: from smtp1.smtp.bt.com (smtp1.smtp.bt.com [217.32.164.137]) by core3.amsl.com (Postfix) with ESMTP id 258513A67B1 for ; Mon, 12 Jul 2010 09:49:09 -0700 (PDT) Received: from i2kc06-ukbr.domain1.systemhost.net ([193.113.197.70]) by smtp1.smtp.bt.com with Microsoft SMTPSVC(6.0.3790.4675); Mon, 12 Jul 2010 17:49:17 +0100 Received: from cbibipnt05.iuser.iroot.adidom.com ([147.149.196.177]) by i2kc06-ukbr.domain1.systemhost.net with Microsoft SMTPSVC(6.0.3790.4675); Mon, 12 Jul 2010 17:49:17 +0100 Received: From bagheera.jungle.bt.co.uk ([132.146.168.158]) by cbibipnt05.iuser.iroot.adidom.com (WebShield SMTP v4.5 MR1a P0803.399); id 1278953355541; Mon, 12 Jul 2010 17:49:15 +0100 Received: from MUT.jungle.bt.co.uk ([10.73.208.229]) by bagheera.jungle.bt.co.uk (8.13.5/8.12.8) with ESMTP id o6CGnCMF031714; Mon, 12 Jul 2010 17:49:13 +0100 Message-Id: <201007121649.o6CGnCMF031714@bagheera.jungle.bt.co.uk> X-Mailer: QUALCOMM Windows Eudora Version 7.1.0.9 Date: Mon, 12 Jul 2010 17:49:11 +0100 To: marcelo bagnulo braun From: Bob Briscoe In-Reply-To: <4C3ADBED.10001@it.uc3m.es> References: <201007120129.o6C1TkRe021669@bagheera.jungle.bt.co.uk> <4C3ACF6B.4080405@it.uc3m.es> <20100712085605.GE47417@verdi> <4C3ADBED.10001@it.uc3m.es> Mime-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1"; format=flowed Content-Transfer-Encoding: quoted-printable X-Scanned-By: MIMEDefang 2.56 on 132.146.168.158 X-OriginalArrivalTime: 12 Jul 2010 16:49:17.0211 (UTC) FILETIME=[2AA716B0:01CB21E2] Cc: conex@ietf.org Subject: Re: [conex] What's the problem: excessive congestion or capacity sharing? X-BeenThere: conex@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Congestion Exposure working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 12 Jul 2010 16:49:16 -0000 Marcelo, At 10:10 12/07/2010, marcelo bagnulo braun wrote: >El 12/07/10 10:56, John Leslie escribi=F3: >>marcelo bagnulo braun wrote: >> >>>El 12/07/10 3:29, Bob Briscoe escribi?: >>> >>[JL] I think Bob wants to remove all language about "managing= congestion" >>and replace it with language about "sharing capacity". >> >[MB] it would seem odd to me that a document=20 >that describes the use cases for exposing=20 >congestion doesn't talk about congestion and only talks about sharing= capacity. [BB] I didn't mean that. I meant we should talk=20 about using congestion exposure in order to share=20 capacity better (by the deterrent of policing=20 based on ConEx and/or voluntary changes to=20 transports because congestion-volume minimisation=20 becomes the goal of transport design). I agree with John that the other goal of reducing=20 congestion will be realised as a side-effect of=20 sharing capacity based on congestion-volume. I=20 just think we shouldn't make this the main=20 subject, because it is harder to explain this=20 emergent property of better capacity sharing - it=20 requires us to use economics to explain why less=20 'free-riding' by some will reduce congestion for everyone. >>>[MB] mmm, i am not sure why excessive congestion as opposed to simply >>>congestion? >>> >>[JL] The language in Toby's current draft is quite close to what was >>posted to this list in the -00 draft. I may have missed a case of >>"excessive congestion", but I don't offhand remember that term being >>used. >> >> Of course, I believe all the authors agree that some congestion >>is at least "normal" if not indeed "essential" to the operation of >>the Internet. Bob has a fixation, AFAICT, that if "congestion" >>causes problems, it must be "excessive congestion" that's causing >>the problems. I, OTOH, don't agree that congestion has to be >>"excessive" for it to cause problems, it's merely that those problems >>become more serious as congestion increases. [BB] I agree with that - 'excessive' was my bad paraphrasing of your= position. >>[JL] Does that mean you recommend Toby accomplish that rewrite today? >> >> >[MB] no, it is only my opinion on the questions Bob asked to the ml [BB] The statement of the problem that we are=20 arguing over is in the abstract and intro. It=20 doesn't affect the rest of the doc. So it could go out like it is now, but ideally,=20 if the ML agrees it should be changed, we would=20 want to change it for either tonight or the next rev. Cheers Bob ________________________________________________________________ Bob Briscoe, BT Innovate & Design=20 From toby@moncaster.com Mon Jul 12 10:12:36 2010 Return-Path: X-Original-To: conex@core3.amsl.com Delivered-To: conex@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 524373A69B6 for ; Mon, 12 Jul 2010 10:12:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.32 X-Spam-Level: X-Spam-Status: No, score=-1.32 tagged_above=-999 required=5 tests=[AWL=0.929, BAYES_00=-2.599, HELO_EQ_DE=0.35] 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 kH5EY94hRvQP for ; Mon, 12 Jul 2010 10:12:35 -0700 (PDT) Received: from moutng.kundenserver.de (moutng.kundenserver.de [212.227.17.8]) by core3.amsl.com (Postfix) with ESMTP id 842CD3A6974 for ; Mon, 12 Jul 2010 10:12:34 -0700 (PDT) Received: from TobysHP (host86-156-248-3.range86-156.btcentralplus.com [86.156.248.3]) by mrelayeu.kundenserver.de (node=mreu0) with ESMTP (Nemesis) id 0Lvfyq-1PAy7t0XpU-017OG3; Mon, 12 Jul 2010 19:12:37 +0200 From: "Toby Moncaster" To: Date: Mon, 12 Jul 2010 18:12:36 +0100 Message-ID: <001b01cb21e5$6cc50630$464f1290$@com> MIME-Version: 1.0 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Mailer: Microsoft Office Outlook 12.0 Thread-Index: Acsh4/kPkXxTHVZvQpGtv9ImREYLNgAABIzQ Content-Language: en-gb X-Provags-ID: V02:K0:MAslgJ5VE6EsS17KeOuUN2XLywdHUJxuMHUFftvkQNL QGiTvTLJzUUCgOsWVd9PgHlVj0K4LY3/7vMVARq4lkjJBXJCWJ UiX8tsAgUhaYn2AdOMlLOm81u2un4dx33SoyexZ2ZLJPE/zpLN lM2PUGgOTNhcFzrP8fDjg4bQZmMzwTwBBXzmyKvFo2vSOEJmNd +tNH5KXbb6fYOjTSl4Q5OUYdvbKZmhT4fWSZ2tULTs= Subject: [conex] FW: New Version Notification for draft-moncaster-conex-concepts-uses-01 X-BeenThere: conex@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Congestion Exposure working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 12 Jul 2010 17:12:36 -0000 All, I have now posted a -01 version of this Internet Draft. The HTML can be = found here: http://www.moncaster.com/conex/draft-moncaster-conex-concepts-uses-01.htm= l There are some significant changes from version 00 which I hope improve = the readability. Thanks especially to Dirk Kutscher for his advice... I haven't generated a diff because the structure has altered so much = that it would be rather messy... I think this is ready for Working Group adoption. Do people agree? If so = can we ask the WG Chairs to ask for adoption at the Maastricht meeting? I accept that there are still issues round the language used in the = Introduction and Abstract. However these require more discussion on the = mailing list and need working-group consensus (which I am not sure = exists yet). That seems to me the sort of thing that should happen after = WG adoption... Toby > -----Original Message----- > From: IETF I-D Submission Tool [mailto:idsubmission@ietf.org] > Sent: 12 July 2010 18:02 > To: toby@moncaster.com > Cc: bob.briscoe@bt.com; richard_woundy@cable.comcast.com; john@jlc.net > Subject: New Version Notification for draft-moncaster-conex-concepts- > uses-01 >=20 >=20 > A new version of I-D, draft-moncaster-conex-concepts-uses-01.txt has > been successfully submitted by Toby Moncaster and posted to the IETF > repository. >=20 > Filename: draft-moncaster-conex-concepts-uses > Revision: 01 > Title: ConEx Concepts and Use Cases > Creation_date: 2010-07-12 > WG ID: Independent Submission > Number_of_pages: 29 >=20 > Abstract: > Internet Service Providers (ISPs) are facing problems where localized > congestion prevents full utilization of the path between sender and > receiver at today's "broadband" speeds. ISPs desire to control this > congestion, which often appears to be caused by a small number of > users consuming a large amount of bandwidth. Building out more > capacity along all of the path to handle this congestion can be > expensive and may not result in improvements for all users so network > operators have sought other ways to manage congestion. The current > mechanisms all suffer from difficulty measuring the congestion (as > distinguished from the total traffic). >=20 > The ConEx Working Group is designing a mechanism to make congestion > along any path visible at the Internet Layer. This document > describes example cases where this mechanism would be useful. >=20 >=20 >=20 > The IETF Secretariat. From carlberg@g11.org.uk Mon Jul 12 10:23:04 2010 Return-Path: X-Original-To: conex@core3.amsl.com Delivered-To: conex@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 1EF6C3A6849 for ; Mon, 12 Jul 2010 10:23:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.949 X-Spam-Level: X-Spam-Status: No, score=-1.949 tagged_above=-999 required=5 tests=[AWL=0.650, BAYES_00=-2.599] 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 Re7pvBV+Lz2O for ; Mon, 12 Jul 2010 10:23:03 -0700 (PDT) Received: from portland.eukhosting.net (portland.eukhosting.net [92.48.97.5]) by core3.amsl.com (Postfix) with ESMTP id E2A553A6B9C for ; Mon, 12 Jul 2010 10:22:59 -0700 (PDT) Received: from c-76-111-69-4.hsd1.va.comcast.net ([76.111.69.4]:60873 helo=[192.168.0.20]) by portland.eukhosting.net with esmtpa (Exim 4.69) (envelope-from ) id 1OYMie-00025Q-C8; Mon, 12 Jul 2010 17:23:04 +0000 Mime-Version: 1.0 (Apple Message framework v1081) Content-Type: text/plain; charset=us-ascii From: ken carlberg In-Reply-To: <201007121633.o6CGXblx031607@bagheera.jungle.bt.co.uk> Date: Mon, 12 Jul 2010 13:23:02 -0400 Content-Transfer-Encoding: quoted-printable Message-Id: <4424D740-233E-4AE2-B428-BB4F1EDB0510@g11.org.uk> References: <201007120129.o6C1TkRe021669@bagheera.jungle.bt.co.uk> <201007121633.o6CGXblx031607@bagheera.jungle.bt.co.uk> To: Bob Briscoe X-Mailer: Apple Mail (2.1081) X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - portland.eukhosting.net X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - g11.org.uk X-Source: X-Source-Args: X-Source-Dir: Cc: conex@ietf.org Subject: Re: [conex] What's the problem: excessive congestion or capacity sharing? X-BeenThere: conex@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Congestion Exposure working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 12 Jul 2010 17:23:04 -0000 On Jul 12, 2010, at 12:33 PM, Bob Briscoe wrote: > Are we: > - exposing congestion in order ultimately to reduce congestion? > - exposing congestion in order to share capacity better? Does it have to be either/or? could we start with reducing congestion = as the default position, and also have providers be a bit more proactive = with their management skills, and therefore help distinguish themselves = from their competitors? =20 -ken= From jason_livingood@cable.comcast.com Mon Jul 12 13:27:55 2010 Return-Path: X-Original-To: conex@core3.amsl.com Delivered-To: conex@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id A318E3A689D for ; Mon, 12 Jul 2010 13:27:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 2.33 X-Spam-Level: ** X-Spam-Status: No, score=2.33 tagged_above=-999 required=5 tests=[AWL=1.998, BAYES_00=-2.599, HELO_MISMATCH_COM=0.553, HOST_MISMATCH_NET=0.311, RCVD_NUMERIC_HELO=2.067] 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 lneASVzcLTc9 for ; Mon, 12 Jul 2010 13:27:55 -0700 (PDT) Received: from cable.comcast.com (copdcimo01.potomac.co.ndcwest.comcast.net [76.96.32.251]) by core3.amsl.com (Postfix) with ESMTP id BD72E3A679F for ; Mon, 12 Jul 2010 13:27:54 -0700 (PDT) Received: from ([147.191.124.12]) by copdcimo01.cable.comcast.com with ESMTP with TLS id 5503630.3749718; Mon, 12 Jul 2010 14:31:57 -0600 Received: from PAOAKEXCSMTP01.cable.comcast.com (10.52.116.30) by copdcexhub01.cable.comcast.com (147.191.124.12) with Microsoft SMTP Server id 14.0.694.0; Mon, 12 Jul 2010 14:27:54 -0600 Received: from PACDCEXCMB04.cable.comcast.com ([24.40.15.86]) by PAOAKEXCSMTP01.cable.comcast.com with Microsoft SMTPSVC(6.0.3790.4675); Mon, 12 Jul 2010 16:27:39 -0400 Received: from 147.191.227.248 ([147.191.227.248]) by PACDCEXCMB04.cable.comcast.com ([24.40.15.86]) via Exchange Front-End Server webmail.comcast.com ([24.40.8.153]) with Microsoft Exchange Server HTTP-DAV ; Mon, 12 Jul 2010 20:27:39 +0000 User-Agent: Microsoft-Entourage/12.25.0.100505 Date: Mon, 12 Jul 2010 16:27:35 -0400 From: Jason Livingood To: ken carlberg , Bob Briscoe Message-ID: Thread-Topic: [conex] What's the problem: excessive congestion or capacity sharing? Thread-Index: AcsiAKmLLAM+DVKTUk6Q+wE2TCzpFw== In-Reply-To: <4424D740-233E-4AE2-B428-BB4F1EDB0510@g11.org.uk> MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 12 Jul 2010 20:27:39.0895 (UTC) FILETIME=[AC760070:01CB2200] Cc: conex@ietf.org Subject: Re: [conex] What's the problem: excessive congestion or capacity sharing? X-BeenThere: conex@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Congestion Exposure working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 12 Jul 2010 20:27:56 -0000 On 7/12/10 1:23 PM, "ken carlberg" wrote: > > On Jul 12, 2010, at 12:33 PM, Bob Briscoe wrote: > >> Are we: >> - exposing congestion in order ultimately to reduce congestion? >> - exposing congestion in order to share capacity better? > > Does it have to be either/or? could we start with reducing congestion as the > default position, and also have providers be a bit more proactive with their > management skills, and therefore help distinguish themselves from their > competitors? Continuing with Ken's line of thinking, I'd not restrict this now. Exposing congestion data could do a number of interesting things, which may include both of the above. Also I fear that focusing too much on this will make this into some sort of philosophical debate concerning the business model and regulatory positions, which will simply cause us to get stuck and not address the important technical work. Jason From rbriscoe@jungle.bt.co.uk Mon Jul 12 15:06:16 2010 Return-Path: X-Original-To: conex@core3.amsl.com Delivered-To: conex@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id A53F43A6C63 for ; Mon, 12 Jul 2010 15:06:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.854 X-Spam-Level: X-Spam-Status: No, score=-0.854 tagged_above=-999 required=5 tests=[AWL=1.263, BAYES_00=-2.599, DNS_FROM_RFC_BOGUSMX=1.482, 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 tLo-Q5UB7NIx for ; Mon, 12 Jul 2010 15:06:06 -0700 (PDT) Received: from smtp3.smtp.bt.com (smtp3.smtp.bt.com [217.32.164.138]) by core3.amsl.com (Postfix) with ESMTP id 420153A687A for ; Mon, 12 Jul 2010 15:06:05 -0700 (PDT) Received: from i2kc06-ukbr.domain1.systemhost.net ([193.113.197.70]) by smtp3.smtp.bt.com with Microsoft SMTPSVC(6.0.3790.4675); Mon, 12 Jul 2010 23:06:12 +0100 Received: from cbibipnt05.iuser.iroot.adidom.com ([147.149.196.177]) by i2kc06-ukbr.domain1.systemhost.net with Microsoft SMTPSVC(6.0.3790.4675); Mon, 12 Jul 2010 23:06:12 +0100 Received: From bagheera.jungle.bt.co.uk ([132.146.168.158]) by cbibipnt05.iuser.iroot.adidom.com (WebShield SMTP v4.5 MR1a P0803.399); id 1278972371498; Mon, 12 Jul 2010 23:06:11 +0100 Received: from MUT.jungle.bt.co.uk ([10.73.208.49]) by bagheera.jungle.bt.co.uk (8.13.5/8.12.8) with ESMTP id o6CM6AXk002462; Mon, 12 Jul 2010 23:06:10 +0100 Message-Id: <201007122206.o6CM6AXk002462@bagheera.jungle.bt.co.uk> X-Mailer: QUALCOMM Windows Eudora Version 7.1.0.9 Date: Mon, 12 Jul 2010 23:06:09 +0100 To: "Toby Moncaster" From: Bob Briscoe In-Reply-To: <001b01cb21e5$6cc50630$464f1290$@com> References: <001b01cb21e5$6cc50630$464f1290$@com> 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: 12 Jul 2010 22:06:12.0379 (UTC) FILETIME=[709376B0:01CB220E] Cc: conex@ietf.org Subject: Re: [conex] FW: New Version Notification for draft-moncaster-conex-concepts-uses-01 X-BeenThere: conex@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Congestion Exposure working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 12 Jul 2010 22:06:16 -0000 Toby (and co-authors / co-editor), Thanks for pulling this together and, as always, steering a path between everyone's slightly differing views. I agree that it's looking good for WG adoption, but it's for the w-g to decide that now, and for the chairs to decide whether to make the call in Maastricht. As to what to do with the text next, I think the IESG will want a little more detail on each use-case in S.8. We can work on that. A couple of co-authors (myself included) have suggested another use-case focused on the network operator using ConEx information to decide where to upgrade capacity, given the various monitoring / policing elements imply any queue won't be congested often unless there's real demand for more capacity there. BTW, I don't think it's wrong to have a decent proportion of the doc devoted to architectural elements. I suspect some on the IESG will interpret the term 'usage scenarios' in the charter as ways ConEx info is used, and others will also expect this to include 'the arrangement of the network to be able to use this info'. Still others will want to see something about how deployment gets started, so the doc has elements to satisfy all these needs. Actually, it would be worth saying some variant of the previous para at the end of the introduction, as a way to introduce the structure of the doc and to justify why all the material in it is relevant to the chartered requirement. Cheers and thanks again. Bob At 18:12 12/07/2010, Toby Moncaster wrote: >All, > >I have now posted a -01 version of this Internet Draft. The HTML can >be found here: > >http://www.moncaster.com/conex/draft-moncaster-conex-concepts-uses-01.html > >There are some significant changes from version 00 which I hope >improve the readability. Thanks especially to Dirk Kutscher for his advice... > >I haven't generated a diff because the structure has altered so much >that it would be rather messy... > >I think this is ready for Working Group adoption. Do people agree? >If so can we ask the WG Chairs to ask for adoption at the Maastricht meeting? > >I accept that there are still issues round the language used in the >Introduction and Abstract. However these require more discussion on >the mailing list and need working-group consensus (which I am not >sure exists yet). That seems to me the sort of thing that should >happen after WG adoption... > >Toby > > > -----Original Message----- > > From: IETF I-D Submission Tool [mailto:idsubmission@ietf.org] > > Sent: 12 July 2010 18:02 > > To: toby@moncaster.com > > Cc: bob.briscoe@bt.com; richard_woundy@cable.comcast.com; john@jlc.net > > Subject: New Version Notification for draft-moncaster-conex-concepts- > > uses-01 > > > > > > A new version of I-D, draft-moncaster-conex-concepts-uses-01.txt has > > been successfully submitted by Toby Moncaster and posted to the IETF > > repository. > > > > Filename: draft-moncaster-conex-concepts-uses > > Revision: 01 > > Title: ConEx Concepts and Use Cases > > Creation_date: 2010-07-12 > > WG ID: Independent Submission > > Number_of_pages: 29 > > > > Abstract: > > Internet Service Providers (ISPs) are facing problems where localized > > congestion prevents full utilization of the path between sender and > > receiver at today's "broadband" speeds. ISPs desire to control this > > congestion, which often appears to be caused by a small number of > > users consuming a large amount of bandwidth. Building out more > > capacity along all of the path to handle this congestion can be > > expensive and may not result in improvements for all users so network > > operators have sought other ways to manage congestion. The current > > mechanisms all suffer from difficulty measuring the congestion (as > > distinguished from the total traffic). > > > > The ConEx Working Group is designing a mechanism to make congestion > > along any path visible at the Internet Layer. This document > > describes example cases where this mechanism would be useful. > > > > > > > > The IETF Secretariat. > > >_______________________________________________ >conex mailing list >conex@ietf.org >https://www.ietf.org/mailman/listinfo/conex ________________________________________________________________ Bob Briscoe, BT Innovate & Design From rbriscoe@jungle.bt.co.uk Mon Jul 12 16:03:36 2010 Return-Path: X-Original-To: conex@core3.amsl.com Delivered-To: conex@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id AB6F03A6C6F for ; Mon, 12 Jul 2010 16:03:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.065 X-Spam-Level: X-Spam-Status: No, score=-1.065 tagged_above=-999 required=5 tests=[AWL=1.052, BAYES_00=-2.599, DNS_FROM_RFC_BOGUSMX=1.482, 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 3qor6cYQycL2 for ; Mon, 12 Jul 2010 16:03:30 -0700 (PDT) Received: from smtp2.smtp.bt.com (smtp2.smtp.bt.com [217.32.164.150]) by core3.amsl.com (Postfix) with ESMTP id 4F3323A68B1 for ; Mon, 12 Jul 2010 16:03:26 -0700 (PDT) Received: from i2kc06-ukbr.domain1.systemhost.net ([193.113.197.70]) by smtp2.smtp.bt.com with Microsoft SMTPSVC(6.0.3790.4675); Tue, 13 Jul 2010 00:03:33 +0100 Received: from cbibipnt05.iuser.iroot.adidom.com ([147.149.196.177]) by i2kc06-ukbr.domain1.systemhost.net with Microsoft SMTPSVC(6.0.3790.4675); Tue, 13 Jul 2010 00:03:33 +0100 Received: From bagheera.jungle.bt.co.uk ([132.146.168.158]) by cbibipnt05.iuser.iroot.adidom.com (WebShield SMTP v4.5 MR1a P0803.399); id 127897581238; Tue, 13 Jul 2010 00:03:32 +0100 Received: from MUT.jungle.bt.co.uk ([10.73.208.49]) by bagheera.jungle.bt.co.uk (8.13.5/8.12.8) with ESMTP id o6CN3S9h002959; Tue, 13 Jul 2010 00:03:29 +0100 Message-Id: <201007122303.o6CN3S9h002959@bagheera.jungle.bt.co.uk> X-Mailer: QUALCOMM Windows Eudora Version 7.1.0.9 Date: Tue, 13 Jul 2010 00:03:29 +0100 To: Jason Livingood From: Bob Briscoe In-Reply-To: References: <4424D740-233E-4AE2-B428-BB4F1EDB0510@g11.org.uk> 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: 12 Jul 2010 23:03:33.0646 (UTC) FILETIME=[73BB22E0:01CB2216] Cc: conex@ietf.org Subject: Re: [conex] What's the problem: excessive congestion or capacity sharing? X-BeenThere: conex@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Congestion Exposure working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 12 Jul 2010 23:03:36 -0000 Jason, It's just a question of how we start the ConEx use-cases doc. We have to say something succinct about what problem we are trying to solve. So we can't just shlve the question for later. Bob At 21:27 12/07/2010, Jason Livingood wrote: >On 7/12/10 1:23 PM, "ken carlberg" wrote: > > > > > On Jul 12, 2010, at 12:33 PM, Bob Briscoe wrote: > > > >> Are we: > >> - exposing congestion in order ultimately to reduce congestion? > >> - exposing congestion in order to share capacity better? > > > > Does it have to be either/or? could we start with reducing > congestion as the > > default position, and also have providers be a bit more proactive > with their > > management skills, and therefore help distinguish themselves from their > > competitors? > >Continuing with Ken's line of thinking, I'd not restrict this now. Exposing >congestion data could do a number of interesting things, which may include >both of the above. Also I fear that focusing too much on this will make >this into some sort of philosophical debate concerning the business model >and regulatory positions, which will simply cause us to get stuck and not >address the important technical work. > >Jason ________________________________________________________________ Bob Briscoe, BT Innovate & Design From lei.zhu@huawei.com Mon Jul 12 19:02:13 2010 Return-Path: X-Original-To: conex@core3.amsl.com Delivered-To: conex@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 0E1DE3A6A21 for ; Mon, 12 Jul 2010 19:02:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 2.487 X-Spam-Level: ** X-Spam-Status: No, score=2.487 tagged_above=-999 required=5 tests=[AWL=0.194, BAYES_00=-2.599, CN_BODY_35=0.339, FH_RELAY_NODNS=1.451, HELO_MISMATCH_COM=0.553, MIME_CHARSET_FARAWAY=2.45, RDNS_NONE=0.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 SWAFX2txwzMn for ; Mon, 12 Jul 2010 19:02:12 -0700 (PDT) Received: from szxga02-in.huawei.com (unknown [119.145.14.65]) by core3.amsl.com (Postfix) with ESMTP id CF2C83A6A1D for ; Mon, 12 Jul 2010 19:02:11 -0700 (PDT) Received: from huawei.com (szxga02-in [172.24.2.6]) by szxga02-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0L5H008XV4BL5T@szxga02-in.huawei.com> for conex@ietf.org; Tue, 13 Jul 2010 10:02:09 +0800 (CST) Received: from huawei.com ([172.24.2.119]) by szxga02-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0L5H005JO4BLRW@szxga02-in.huawei.com> for conex@ietf.org; Tue, 13 Jul 2010 10:02:09 +0800 (CST) Received: from z41317 ([10.111.16.163]) by szxml04-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTPA id <0L5H009EE4BLWO@szxml04-in.huawei.com> for conex@ietf.org; Tue, 13 Jul 2010 10:02:09 +0800 (CST) Date: Tue, 13 Jul 2010 10:02:10 +0800 From: Zhu Lei In-reply-to: <001b01cb21e5$6cc50630$464f1290$@com> To: 'Toby Moncaster' , conex@ietf.org Message-id: <003c01cb222f$68049850$a3106f0a@china.huawei.com> MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2900.3350 X-Mailer: Microsoft Office Outlook 11 Content-type: text/plain; charset=gb2312 Content-transfer-encoding: quoted-printable Thread-index: Acsh4/kPkXxTHVZvQpGtv9ImREYLNgAABIzQABJctIA= Subject: Re: [conex] FW: New Version Notification fordraft-moncaster-conex-concepts-uses-01 X-BeenThere: conex@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Congestion Exposure working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 13 Jul 2010 02:02:13 -0000 Hi Toby and all, I understood you are asking rough consensus of reversion 01. I have to = say that the access networks can adjust capacity of each user based on the congestion indications. I personally thought congestion indication is helpful for intermediate nodes of access networks which is capable to monitoring capacity and traffic load. So, if there is only one document containning such use cases, I'd like = to ask more time for including other use case mentioned in ML. Best regards, Zhu Lei HUAWEI TECHNOLOGIES CO.,LTD. huawei_logo -----=D3=CA=BC=FE=D4=AD=BC=FE----- =B7=A2=BC=FE=C8=CB: conex-bounces@ietf.org = [mailto:conex-bounces@ietf.org] =B4=FA=B1=ED Toby Moncaster =B7=A2=CB=CD=CA=B1=BC=E4: 2010=C4=EA7=D4=C213=C8=D5 1:13 =CA=D5=BC=FE=C8=CB: conex@ietf.org =D6=F7=CC=E2: [conex] FW: New Version Notification fordraft-moncaster-conex-concepts-uses-01 All, I have now posted a -01 version of this Internet Draft. The HTML can be found here: http://www.moncaster.com/conex/draft-moncaster-conex-concepts-uses-01.htm= l There are some significant changes from version 00 which I hope improve = the readability. Thanks especially to Dirk Kutscher for his advice... I haven't generated a diff because the structure has altered so much = that it would be rather messy... I think this is ready for Working Group adoption. Do people agree? If so = can we ask the WG Chairs to ask for adoption at the Maastricht meeting? I accept that there are still issues round the language used in the Introduction and Abstract. However these require more discussion on the mailing list and need working-group consensus (which I am not sure = exists yet). That seems to me the sort of thing that should happen after WG adoption... Toby > -----Original Message----- > From: IETF I-D Submission Tool [mailto:idsubmission@ietf.org] > Sent: 12 July 2010 18:02 > To: toby@moncaster.com > Cc: bob.briscoe@bt.com; richard_woundy@cable.comcast.com; john@jlc.net > Subject: New Version Notification for draft-moncaster-conex-concepts- > uses-01 >=20 >=20 > A new version of I-D, draft-moncaster-conex-concepts-uses-01.txt has=20 > been successfully submitted by Toby Moncaster and posted to the IETF=20 > repository. >=20 > Filename: draft-moncaster-conex-concepts-uses > Revision: 01 > Title: ConEx Concepts and Use Cases > Creation_date: 2010-07-12 > WG ID: Independent Submission > Number_of_pages: 29 >=20 > Abstract: > Internet Service Providers (ISPs) are facing problems where localized=20 > congestion prevents full utilization of the path between sender and=20 > receiver at today's "broadband" speeds. ISPs desire to control this=20 > congestion, which often appears to be caused by a small number of=20 > users consuming a large amount of bandwidth. Building out more=20 > capacity along all of the path to handle this congestion can be=20 > expensive and may not result in improvements for all users so network=20 > operators have sought other ways to manage congestion. The current=20 > mechanisms all suffer from difficulty measuring the congestion (as=20 > distinguished from the total traffic). >=20 > The ConEx Working Group is designing a mechanism to make congestion=20 > along any path visible at the Internet Layer. This document describes = > example cases where this mechanism would be useful. >=20 >=20 >=20 > The IETF Secretariat. _______________________________________________ conex mailing list conex@ietf.org https://www.ietf.org/mailman/listinfo/conex From toby@moncaster.com Tue Jul 13 01:43:17 2010 Return-Path: X-Original-To: conex@core3.amsl.com Delivered-To: conex@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 86D3A3A690E for ; Tue, 13 Jul 2010 01:43:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.91 X-Spam-Level: X-Spam-Status: No, score=0.91 tagged_above=-999 required=5 tests=[AWL=-2.230, BAYES_50=0.001, CN_BODY_35=0.339, HELO_EQ_DE=0.35, MIME_CHARSET_FARAWAY=2.45] 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 3PHIwGw3zLZe for ; Tue, 13 Jul 2010 01:43:16 -0700 (PDT) Received: from moutng.kundenserver.de (moutng.kundenserver.de [212.227.17.10]) by core3.amsl.com (Postfix) with ESMTP id 223533A68C7 for ; Tue, 13 Jul 2010 01:43:15 -0700 (PDT) Received: from TobysHP (host86-156-248-3.range86-156.btcentralplus.com [86.156.248.3]) by mrelayeu.kundenserver.de (node=mrbap0) with ESMTP (Nemesis) id 0LtlMD-1PFw7z2EVx-010wqj; Tue, 13 Jul 2010 10:43:22 +0200 From: "Toby Moncaster" To: "'Zhu Lei'" , References: <001b01cb21e5$6cc50630$464f1290$@com> <003c01cb222f$68049850$a3106f0a@china.huawei.com> In-Reply-To: <003c01cb222f$68049850$a3106f0a@china.huawei.com> Date: Tue, 13 Jul 2010 09:43:20 +0100 Message-ID: <000301cb2267$72d57a00$58806e00$@com> MIME-Version: 1.0 Content-Type: text/plain; charset="gb2312" Content-Transfer-Encoding: quoted-printable X-Mailer: Microsoft Office Outlook 12.0 Thread-index: Acsh4/kPkXxTHVZvQpGtv9ImREYLNgAABIzQABJctIAADkY4cA== Content-Language: en-gb X-Provags-ID: V02:K0:j2Q5ImCnQRCNepFcUYEvLr7hByLuUmIqK2k3qzjnqAt R8wUd2f0evEqHXwl6cUjtAM2PQGnVa+upAxnp/oPJcglzDWbuE v0qzB65iislWwICcpasR7bMZ+NdlD2bLbCPlOt2zb0tTfatTW3 Pb+kslQZTQ8Nj6wbqfXtKGCZxDr8xUAcjAbkC7hKLaEjZ+xprp IOcZO9eZJkgz+tYhBV6Qa91dAtQ8iXmVFgXfxXbOeo= Subject: Re: [conex] FW: New Version Notification fordraft-moncaster-conex-concepts-uses-01 X-BeenThere: conex@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Congestion Exposure working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 13 Jul 2010 08:43:17 -0000 All, It does seem as though Bob's email chain has sparked people to think of further use cases for ConEx (which goes to show what a powerful concept = it is). When I started this draft I was keen to limit the number of use cases = just to keep a cap on the length of the draft and to give people a better = chance to absorb things. However, a couple of the new use cases people have = talked about do seem sensible and I intend to include them in the next version = of the draft. So, if anyone else has a moment of genius about an = alternative use for ConEx now is the time to send it to the list! Toby PS, Once we are a bit further down the line I think we are going to need = to sort the use cases and concentrate on those that can be wholly achieved within the current constraints of the charter.=20 > -----Original Message----- > From: Zhu Lei [mailto:lei.zhu@huawei.com] > Sent: 13 July 2010 03:02 > To: 'Toby Moncaster'; conex@ietf.org > Subject: Re: [conex] FW: New Version Notification fordraft-moncaster- > conex-concepts-uses-01 >=20 > Hi Toby and all, >=20 > I understood you are asking rough consensus of reversion 01. I have to > say > that the access networks can adjust capacity of each user based on the > congestion indications. I personally thought congestion indication is > helpful for intermediate nodes of access networks which is capable to > monitoring capacity and traffic load. >=20 > So, if there is only one document containning such use cases, I'd like > to > ask more time for including other use case mentioned in ML. >=20 > Best regards, > Zhu Lei > HUAWEI TECHNOLOGIES CO.,LTD. huawei_logo >=20 > -----=D3=CA=BC=FE=D4=AD=BC=FE----- > =B7=A2=BC=FE=C8=CB: conex-bounces@ietf.org = [mailto:conex-bounces@ietf.org] =B4=FA=B1=ED Toby > Moncaster > =B7=A2=CB=CD=CA=B1=BC=E4: 2010=C4=EA7=D4=C213=C8=D5 1:13 > =CA=D5=BC=FE=C8=CB: conex@ietf.org > =D6=F7=CC=E2: [conex] FW: New Version Notification > fordraft-moncaster-conex-concepts-uses-01 >=20 > All, >=20 > I have now posted a -01 version of this Internet Draft. The HTML can = be > found here: >=20 > http://www.moncaster.com/conex/draft-moncaster-conex-concepts-uses- > 01.html >=20 > There are some significant changes from version 00 which I hope = improve > the > readability. Thanks especially to Dirk Kutscher for his advice... >=20 > I haven't generated a diff because the structure has altered so much > that it > would be rather messy... >=20 > I think this is ready for Working Group adoption. Do people agree? If > so can > we ask the WG Chairs to ask for adoption at the Maastricht meeting? >=20 > I accept that there are still issues round the language used in the > Introduction and Abstract. However these require more discussion on = the > mailing list and need working-group consensus (which I am not sure > exists > yet). That seems to me the sort of thing that should happen after WG > adoption... >=20 > Toby >=20 > > -----Original Message----- > > From: IETF I-D Submission Tool [mailto:idsubmission@ietf.org] > > Sent: 12 July 2010 18:02 > > To: toby@moncaster.com > > Cc: bob.briscoe@bt.com; richard_woundy@cable.comcast.com; > john@jlc.net > > Subject: New Version Notification for = draft-moncaster-conex-concepts- > > uses-01 > > > > > > A new version of I-D, draft-moncaster-conex-concepts-uses-01.txt has > > been successfully submitted by Toby Moncaster and posted to the IETF > > repository. > > > > Filename: draft-moncaster-conex-concepts-uses > > Revision: 01 > > Title: ConEx Concepts and Use Cases > > Creation_date: 2010-07-12 > > WG ID: Independent Submission > > Number_of_pages: 29 > > > > Abstract: > > Internet Service Providers (ISPs) are facing problems where = localized > > congestion prevents full utilization of the path between sender and > > receiver at today's "broadband" speeds. ISPs desire to control this > > congestion, which often appears to be caused by a small number of > > users consuming a large amount of bandwidth. Building out more > > capacity along all of the path to handle this congestion can be > > expensive and may not result in improvements for all users so = network > > operators have sought other ways to manage congestion. The current > > mechanisms all suffer from difficulty measuring the congestion (as > > distinguished from the total traffic). > > > > The ConEx Working Group is designing a mechanism to make congestion > > along any path visible at the Internet Layer. This document > describes > > example cases where this mechanism would be useful. > > > > > > > > The IETF Secretariat. >=20 >=20 > _______________________________________________ > conex mailing list > conex@ietf.org > https://www.ietf.org/mailman/listinfo/conex From prvs=3810966695=Kevin.Mason@telecom.co.nz Tue Jul 13 03:25:26 2010 Return-Path: X-Original-To: conex@core3.amsl.com Delivered-To: conex@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 951D93A659B for ; Tue, 13 Jul 2010 03:25:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.599 X-Spam-Level: X-Spam-Status: No, score=-3.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, 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 Q5wASJ7iMaJ2 for ; Tue, 13 Jul 2010 03:25:25 -0700 (PDT) Received: from mgate2.telecom.co.nz (envoy-out.telecom.co.nz [146.171.15.100]) by core3.amsl.com (Postfix) with ESMTP id 66ADC3A6968 for ; Tue, 13 Jul 2010 03:25:24 -0700 (PDT) Received: from mgate3.telecom.co.nz (unknown [146.171.1.21]) by mgate2.telecom.co.nz (Tumbleweed MailGate 3.7.1) with ESMTP id 2261710318C0; Tue, 13 Jul 2010 22:25:27 +1200 (NZST) X-WSS-ID: 0L5HRMI-03-1QC-02 X-M-MSG: Received: from hp2847.telecom.tcnz.net (hp2847.telecom.tcnz.net [146.171.228.249]) (using TLSv1 with cipher RC4-MD5 (128/128 bits)) (No client certificate requested) by mgate3.telecom.co.nz (Postfix) with ESMTP id 182B149F8443; Tue, 13 Jul 2010 22:25:29 +1200 (NZST) Received: from hp3120.telecom.tcnz.net (146.171.212.205) by hp2847.telecom.tcnz.net (146.171.228.249) with Microsoft SMTP Server (TLS) id 8.2.234.1; Tue, 13 Jul 2010 22:25:29 +1200 Received: from WNEXMBX01.telecom.tcnz.net ([146.171.212.201]) by hp3120.telecom.tcnz.net ([146.171.212.205]) with mapi; Tue, 13 Jul 2010 22:25:29 +1200 From: Kevin Mason To: Bob Briscoe , Jason Livingood Date: Tue, 13 Jul 2010 22:22:22 +1200 Thread-Topic: [conex] What's the problem: excessive congestion or capacity sharing? Thread-Index: AcsiFsL/WSbbQA6HSlebRDRJ/5mHTgAXoTPq Message-ID: <563C162F43D1B14E9FD2BC0A776C1E9127BF37589D@WNEXMBX01.telecom.tcnz.net> References: <4424D740-233E-4AE2-B428-BB4F1EDB0510@g11.org.uk> , <201007122303.o6CN3S9h002959@bagheera.jungle.bt.co.uk> In-Reply-To: <201007122303.o6CN3S9h002959@bagheera.jungle.bt.co.uk> Accept-Language: en-US, en-NZ Content-Language: en-NZ X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US, en-NZ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "conex@ietf.org" Subject: Re: [conex] What's the problem: excessive congestion or capacity sharing? X-BeenThere: conex@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Congestion Exposure working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 13 Jul 2010 10:25:26 -0000 May i suggest that what we are addressing is enhancing capacity sharing und= er overload. =20 When the volume of traffic offered to the next hop excedes that available c= apacity the link becomes overloaded. This work is about providing the netwo= rk with the means to better manage how available capacity is shared by taki= ng action at points on a path other than just at an overloaded next hop, an= d to signal more effciently to end users and the network preceding the over= load point that the path this traffic is using is overloading and if action= is not taken excessive congestion will result. =20 Kevin=20 ________________________________________ From: conex-bounces@ietf.org [conex-bounces@ietf.org] On Behalf Of Bob Bris= coe [rbriscoe@jungle.bt.co.uk] Sent: Tuesday, 13 July 2010 11:03 a.m. To: Jason Livingood Cc: conex@ietf.org Subject: Re: [conex] What's the problem: excessive congestion or capacity s= haring? Jason, It's just a question of how we start the ConEx use-cases doc. We have to say something succinct about what problem we are trying to solve. So we can't just shlve the question for later. Bob At 21:27 12/07/2010, Jason Livingood wrote: >On 7/12/10 1:23 PM, "ken carlberg" wrote: > > > > > On Jul 12, 2010, at 12:33 PM, Bob Briscoe wrote: > > > >> Are we: > >> - exposing congestion in order ultimately to reduce congestion? > >> - exposing congestion in order to share capacity better? > > > > Does it have to be either/or? could we start with reducing > congestion as the > > default position, and also have providers be a bit more proactive > with their > > management skills, and therefore help distinguish themselves from their > > competitors? > >Continuing with Ken's line of thinking, I'd not restrict this now. Exposi= ng >congestion data could do a number of interesting things, which may include >both of the above. Also I fear that focusing too much on this will make >this into some sort of philosophical debate concerning the business model >and regulatory positions, which will simply cause us to get stuck and not >address the important technical work. > >Jason ________________________________________________________________ Bob Briscoe, BT Innovate & Design _______________________________________________ conex mailing list conex@ietf.org https://www.ietf.org/mailman/listinfo/conex= From ford@isoc.org Tue Jul 13 04:31:53 2010 Return-Path: X-Original-To: conex@core3.amsl.com Delivered-To: conex@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 73FD13A685F for ; Tue, 13 Jul 2010 04:31:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.599 X-Spam-Level: X-Spam-Status: No, score=-103.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] 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 k18xEqz5antt for ; Tue, 13 Jul 2010 04:31:52 -0700 (PDT) Received: from smtp201.iad.emailsrvr.com (smtp201.iad.emailsrvr.com [207.97.245.201]) by core3.amsl.com (Postfix) with ESMTP id 8F1D93A67E9 for ; Tue, 13 Jul 2010 04:31:52 -0700 (PDT) Received: from relay10.relay.iad.mlsrvr.com (localhost [127.0.0.1]) by relay10.relay.iad.mlsrvr.com (SMTP Server) with ESMTP id 4AF8A1E09F6; Tue, 13 Jul 2010 07:32:01 -0400 (EDT) Received: by relay10.relay.iad.mlsrvr.com (Authenticated sender: ford-AT-isoc.org) with ESMTPSA id DAF731EA478; Tue, 13 Jul 2010 07:32:00 -0400 (EDT) Mime-Version: 1.0 (Apple Message framework v1081) Content-Type: text/plain; charset=us-ascii From: Matthew Ford In-Reply-To: <001b01cb21e5$6cc50630$464f1290$@com> Date: Tue, 13 Jul 2010 12:31:59 +0100 Content-Transfer-Encoding: quoted-printable Message-Id: References: <001b01cb21e5$6cc50630$464f1290$@com> To: Toby Moncaster X-Mailer: Apple Mail (2.1081) Cc: conex@ietf.org Subject: Re: [conex] FW: New Version Notification for draft-moncaster-conex-concepts-uses-01 X-BeenThere: conex@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Congestion Exposure working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 13 Jul 2010 11:31:53 -0000 On 12 Jul 2010, at 18:12, Toby Moncaster wrote: > All, >=20 > I have now posted a -01 version of this Internet Draft. The HTML can = be found here: >=20 > = http://www.moncaster.com/conex/draft-moncaster-conex-concepts-uses-01.html= >=20 > There are some significant changes from version 00 which I hope = improve the readability. Thanks especially to Dirk Kutscher for his = advice... >=20 > I haven't generated a diff because the structure has altered so much = that it would be rather messy... >=20 Note that diffs are always available from: http://tools.ietf.org/rfcdiff Mat= From john@jlc.net Tue Jul 13 06:32:40 2010 Return-Path: X-Original-To: conex@core3.amsl.com Delivered-To: conex@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 30F6B3A67A7 for ; Tue, 13 Jul 2010 06:32:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.137 X-Spam-Level: X-Spam-Status: No, score=-3.137 tagged_above=-999 required=5 tests=[AWL=1.300, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_NET=0.611, RCVD_IN_DNSWL_MED=-4, RDNS_NONE=0.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 isdWcXUIdk6k for ; Tue, 13 Jul 2010 06:32:37 -0700 (PDT) Received: from mailhost.jlc.net (unknown [199.201.159.4]) by core3.amsl.com (Postfix) with ESMTP id EF3E03A694E for ; Tue, 13 Jul 2010 06:32:36 -0700 (PDT) Received: by mailhost.jlc.net (Postfix, from userid 104) id 4CA5B33C3D; Tue, 13 Jul 2010 09:32:45 -0400 (EDT) Date: Tue, 13 Jul 2010 09:32:45 -0400 From: John Leslie To: conex@ietf.org Message-ID: <20100713133245.GN47417@verdi> References: <001b01cb21e5$6cc50630$464f1290$@com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.4.1i Subject: Re: [conex] FW: New Version Notification for draft-moncaster-conex-concepts-uses-01 X-BeenThere: conex@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Congestion Exposure working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 13 Jul 2010 13:32:40 -0000 Matthew Ford wrote: > On 12 Jul 2010, at 18:12, Toby Moncaster wrote: > >> http://www.moncaster.com/conex/draft-moncaster-conex-concepts-uses-01.html >> >> I haven't generated a diff because the structure has altered so much >> that it would be rather messy... > > Note that diffs are always available from: http://tools.ietf.org/rfcdiff Indeed -- I find it helpful, even if messy... Toby has really been working at this, as is obvious from ] ] 887 lines changed or added (The rest of us have been hard-put to keep up!) There will not, of course, be another version before Monday of Maastricht week, but I expect Toby to work on more use cases, and with some luck a rewritten Introduction that both Bob & I consent to. ;^) _If_ a new version is published July 26th, I will insist on a diff being published as well. I believe Marcelo is tending towards putting the question of adoption as a work item Tuesday, July 27th. It would be helpful for folks to weigh in on whether they prefer to have a -02 version before that question is put. For myself, I'd just as soon not... Folks (especially IESG members) will be hard-put to find time to read a newer version before Tuesday morning. Regardless of which version is proposed for a work item, IMHO, any changes would have to be agreed to on the list. And, of course, after adoption Toby (or whoever the WGCs designate as Document Editor) will be taking input from the list for revisions before it is submitted to the IESG (and the other authors will be just another WG participant, no longer capable of blocking changes). -- John Leslie From rbriscoe@jungle.bt.co.uk Tue Jul 13 09:02:10 2010 Return-Path: X-Original-To: conex@core3.amsl.com Delivered-To: conex@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 625463A699C for ; Tue, 13 Jul 2010 09:02:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.226 X-Spam-Level: X-Spam-Status: No, score=-1.226 tagged_above=-999 required=5 tests=[AWL=0.891, BAYES_00=-2.599, DNS_FROM_RFC_BOGUSMX=1.482, 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 ysqLlA61-XW7 for ; Tue, 13 Jul 2010 09:02:01 -0700 (PDT) Received: from smtp3.smtp.bt.com (smtp3.smtp.bt.com [217.32.164.138]) by core3.amsl.com (Postfix) with ESMTP id 7D7043A6870 for ; Tue, 13 Jul 2010 09:02:00 -0700 (PDT) Received: from i2kc06-ukbr.domain1.systemhost.net ([193.113.197.70]) by smtp3.smtp.bt.com with Microsoft SMTPSVC(6.0.3790.4675); Tue, 13 Jul 2010 17:02:09 +0100 Received: from cbibipnt05.iuser.iroot.adidom.com ([147.149.196.177]) by i2kc06-ukbr.domain1.systemhost.net with Microsoft SMTPSVC(6.0.3790.4675); Tue, 13 Jul 2010 17:02:09 +0100 Received: From bagheera.jungle.bt.co.uk ([132.146.168.158]) by cbibipnt05.iuser.iroot.adidom.com (WebShield SMTP v4.5 MR1a P0803.399); id 1279036927685; Tue, 13 Jul 2010 17:02:07 +0100 Received: from MUT.jungle.bt.co.uk ([10.215.130.87]) by bagheera.jungle.bt.co.uk (8.13.5/8.12.8) with ESMTP id o6DG25nF013783; Tue, 13 Jul 2010 17:02:05 +0100 Message-Id: <201007131602.o6DG25nF013783@bagheera.jungle.bt.co.uk> X-Mailer: QUALCOMM Windows Eudora Version 7.1.0.9 Date: Tue, 13 Jul 2010 17:02:05 +0100 To: Toby Moncaster , John Leslie , "Woundy, Richard" From: Bob Briscoe In-Reply-To: <563C162F43D1B14E9FD2BC0A776C1E9127BF37589D@WNEXMBX01.telec om.tcnz.net> References: <4424D740-233E-4AE2-B428-BB4F1EDB0510@g11.org.uk> <201007122303.o6CN3S9h002959@bagheera.jungle.bt.co.uk> <563C162F43D1B14E9FD2BC0A776C1E9127BF37589D@WNEXMBX01.telecom.tcnz.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: 13 Jul 2010 16:02:09.0231 (UTC) FILETIME=[BF7555F0:01CB22A4] Cc: Kevin Mason , "conex@ietf.org" Subject: Re: [conex] What's the problem: excessive congestion or capacity sharing? X-BeenThere: conex@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Congestion Exposure working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 13 Jul 2010 16:02:10 -0000 Toby, John, Rich (co-authors of use-cases I-D), To me, Kevin's text would be a good basis for introductory text to summarise the set of problems that the use-cases are about (e.g. for the abstract & Introduction). Bob At 11:22 13/07/2010, Kevin Mason wrote: >May i suggest that what we are addressing is enhancing capacity >sharing under overload. > >When the volume of traffic offered to the next hop excedes that >available capacity the link becomes overloaded. This work is about >providing the network with the means to better manage how available >capacity is shared by taking action at points on a path other than >just at an overloaded next hop, and to signal more effciently to end >users and the network preceding the overload point that the path >this traffic is using is overloading and if action is not taken >excessive congestion will result. > >Kevin > > >________________________________________ >From: conex-bounces@ietf.org [conex-bounces@ietf.org] On Behalf Of >Bob Briscoe [rbriscoe@jungle.bt.co.uk] >Sent: Tuesday, 13 July 2010 11:03 a.m. >To: Jason Livingood >Cc: conex@ietf.org >Subject: Re: [conex] What's the problem: excessive congestion or >capacity sharing? > >Jason, > >It's just a question of how we start the ConEx use-cases doc. We have >to say something succinct about what problem we are trying to solve. >So we can't just shlve the question for later. > > >Bob > >At 21:27 12/07/2010, Jason Livingood wrote: > >On 7/12/10 1:23 PM, "ken carlberg" wrote: > > > > > > > > On Jul 12, 2010, at 12:33 PM, Bob Briscoe wrote: > > > > > >> Are we: > > >> - exposing congestion in order ultimately to reduce congestion? > > >> - exposing congestion in order to share capacity better? > > > > > > Does it have to be either/or? could we start with reducing > > congestion as the > > > default position, and also have providers be a bit more proactive > > with their > > > management skills, and therefore help distinguish themselves from their > > > competitors? > > > >Continuing with Ken's line of thinking, I'd not restrict this now. Exposing > >congestion data could do a number of interesting things, which may include > >both of the above. Also I fear that focusing too much on this will make > >this into some sort of philosophical debate concerning the business model > >and regulatory positions, which will simply cause us to get stuck and not > >address the important technical work. > > > >Jason > >________________________________________________________________ >Bob Briscoe, BT Innovate & Design > >_______________________________________________ >conex mailing list >conex@ietf.org >https://www.ietf.org/mailman/listinfo/conex ________________________________________________________________ Bob Briscoe, BT Innovate & Design From marcelo@it.uc3m.es Tue Jul 13 23:42:22 2010 Return-Path: X-Original-To: conex@core3.amsl.com Delivered-To: conex@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id EC8E13A69D6 for ; Tue, 13 Jul 2010 23:42:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.314 X-Spam-Level: X-Spam-Status: No, score=-106.314 tagged_above=-999 required=5 tests=[AWL=0.285, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] 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 v1tHqovV9XQh for ; Tue, 13 Jul 2010 23:42:22 -0700 (PDT) Received: from smtp02.uc3m.es (smtp02.uc3m.es [163.117.176.132]) by core3.amsl.com (Postfix) with ESMTP id B50CD3A68BC for ; Tue, 13 Jul 2010 23:42:21 -0700 (PDT) X-uc3m-safe: yes Received: from marcelo-bagnulos-macbook-pro.local (79.30.18.95.dynamic.jazztel.es [95.18.30.79]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by smtp02.uc3m.es (Postfix) with ESMTP id 134666FE016; Wed, 14 Jul 2010 08:42:24 +0200 (CEST) Message-ID: <4C3D5C4F.50406@it.uc3m.es> Date: Wed, 14 Jul 2010 08:42:23 +0200 From: marcelo bagnulo braun User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.5; es-ES; rv:1.9.1.10) Gecko/20100512 Thunderbird/3.0.5 MIME-Version: 1.0 To: conex@ietf.org Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-TM-AS-Product-Ver: IMSS-7.0.0.3116-6.0.0.1038-17504.003 Cc: Nandita Dukkipati Subject: [conex] Next steps with draft-moncaster-conex-concepts-uses-01 X-BeenThere: conex@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Congestion Exposure working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 14 Jul 2010 06:42:23 -0000 Hi, The proposed next steps for this document is as follows: After the presentation of the document in the IETF78 CONEX WG meeting, if everything seems reasonable, we will ask for adoption of this document as WG item during the meeting and we will confirm it in the ml afterwards. So please read the document for the meeting, so you can have an opinion. Regards, marcelo > -----Original Message----- > From: IETF I-D Submission Tool [mailto:idsubmission@ietf.org] > Sent: 12 July 2010 18:02 > To: toby@moncaster.com > Cc: bob.briscoe@bt.com; richard_woundy@cable.comcast.com; john@jlc.net > Subject: New Version Notification for draft-moncaster-conex-concepts- > uses-01 > > > A new version of I-D, draft-moncaster-conex-concepts-uses-01.txt has > been successfully submitted by Toby Moncaster and posted to the IETF > repository. > > Filename: draft-moncaster-conex-concepts-uses > Revision: 01 > Title: ConEx Concepts and Use Cases > Creation_date: 2010-07-12 > WG ID: Independent Submission > Number_of_pages: 29 > > Abstract: > Internet Service Providers (ISPs) are facing problems where localized > congestion prevents full utilization of the path between sender and > receiver at today's "broadband" speeds. ISPs desire to control this > congestion, which often appears to be caused by a small number of > users consuming a large amount of bandwidth. Building out more > capacity along all of the path to handle this congestion can be > expensive and may not result in improvements for all users so network > operators have sought other ways to manage congestion. The current > mechanisms all suffer from difficulty measuring the congestion (as > distinguished from the total traffic). > > The ConEx Working Group is designing a mechanism to make congestion > along any path visible at the Internet Layer. This document > describes example cases where this mechanism would be useful. > > > > The IETF Secretariat. _______________________________________________ conex mailing list conex@ietf.org https://www.ietf.org/mailman/listinfo/conex From toby@moncaster.com Wed Jul 14 01:51:34 2010 Return-Path: X-Original-To: conex@core3.amsl.com Delivered-To: conex@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 391053A6998 for ; Wed, 14 Jul 2010 01:51:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.041 X-Spam-Level: X-Spam-Status: No, score=-1.041 tagged_above=-999 required=5 tests=[AWL=1.208, BAYES_00=-2.599, HELO_EQ_DE=0.35] 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 bC8VjDZxZM6e for ; Wed, 14 Jul 2010 01:51:33 -0700 (PDT) Received: from moutng.kundenserver.de (moutng.kundenserver.de [212.227.126.186]) by core3.amsl.com (Postfix) with ESMTP id CA7253A68B6 for ; Wed, 14 Jul 2010 01:51:32 -0700 (PDT) Received: from TobysHP (host86-156-248-3.range86-156.btcentralplus.com [86.156.248.3]) by mrelayeu.kundenserver.de (node=mrbap0) with ESMTP (Nemesis) id 0LkBNy-1P6dTk0XGc-00cMvE; Wed, 14 Jul 2010 10:51:39 +0200 From: "Toby Moncaster" To: "'Bob Briscoe'" , "'John Leslie'" , "'Woundy, Richard'" References: <4424D740-233E-4AE2-B428-BB4F1EDB0510@g11.org.uk> <201007122303.o6CN3S9h002959@bagheera.jungle.bt.co.uk> <563C162F43D1B14E9FD2BC0A776C1E9127BF37589D@WNEXMBX01.telecom.tcnz.net> <201007131602.o6DG25nF013783@bagheera.jungle.bt.co.uk> In-Reply-To: <201007131602.o6DG25nF013783@bagheera.jungle.bt.co.uk> Date: Wed, 14 Jul 2010 09:51:37 +0100 Message-ID: <000401cb2331$c5d32570$51797050$@com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 12.0 thread-index: AcsipL9SQh9hFV8MSoaDzLlrbsRcWwAi41qQ Content-Language: en-gb X-Provags-ID: V02:K0:AatBmblU7shubOQvtxUEQAIAEMLNaSTbwBtbxwPPZnn 3nmzLWnPs/17Y/m7HpariBfoKYzq5v2lLe73BhyKvSsBCdcD+M Wv1D0fyBA22CyUn+r4E5yndh2Knt9tGLDj4P0TuzZW5CtvWIpf 7rfODgc+ZJVuEbhBOYVEZnn6DtpQAE2Y0uEBLL7ae1TcsYkU/1 0CvLVH90tC7ODz3WQeA2Vh6alw/0+woaLJLu36B23c= Cc: 'Kevin Mason' , conex@ietf.org Subject: Re: [conex] What's the problem: excessive congestion or capacity sharing? X-BeenThere: conex@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Congestion Exposure working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 14 Jul 2010 08:51:34 -0000 I am not convinced this captures everything. It is fine as far as it goes, but I would prefer to insert something and phrase it more like: "When the volume of traffic offered to the next hop excedes that available capacity the link becomes overloaded. This is known as congestion. ConEx is about providing the network with the means to monitor the state of congestion throughout the path. This allows networks to better manage how available capacity is shared by taking action at points on a path other than just at an overloaded next hop. They can signal to the network preceding the overload point that the path this traffic is using is overloading and if action is not taken excessive congestion will result." I have carefully removed mention of end-users since they already see congestion information, and as they are the origin of the ConEx information they are actually the ones doing the signalling. I also feel ConEx is more about providing the signal which can then be used to encourage upstream networks and the sender to respond better. Oh, and I may steal that first sentence and use it to improve the current definition of congestion in the draft. This may also re-spark the discussion of "excessive congestion" ;-) Toby > -----Original Message----- > From: Bob Briscoe [mailto:rbriscoe@jungle.bt.co.uk] > Sent: 13 July 2010 17:02 > To: Toby Moncaster; John Leslie; Woundy, Richard > Cc: conex@ietf.org; Kevin Mason > Subject: RE: [conex] What's the problem: excessive congestion or > capacity sharing? > > Toby, John, Rich (co-authors of use-cases I-D), > > To me, Kevin's text would be a good basis for introductory text to > summarise the set of problems that the use-cases are about (e.g. for > the abstract & Introduction). > > > Bob > > At 11:22 13/07/2010, Kevin Mason wrote: > >May i suggest that what we are addressing is enhancing capacity > >sharing under overload. > > > >When the volume of traffic offered to the next hop excedes that > >available capacity the link becomes overloaded. This work is about > >providing the network with the means to better manage how available > >capacity is shared by taking action at points on a path other than > >just at an overloaded next hop, and to signal more effciently to end > >users and the network preceding the overload point that the path > >this traffic is using is overloading and if action is not taken > >excessive congestion will result. > > > >Kevin > > > > > >________________________________________ > >From: conex-bounces@ietf.org [conex-bounces@ietf.org] On Behalf Of > >Bob Briscoe [rbriscoe@jungle.bt.co.uk] > >Sent: Tuesday, 13 July 2010 11:03 a.m. > >To: Jason Livingood > >Cc: conex@ietf.org > >Subject: Re: [conex] What's the problem: excessive congestion or > >capacity sharing? > > > >Jason, > > > >It's just a question of how we start the ConEx use-cases doc. We have > >to say something succinct about what problem we are trying to solve. > >So we can't just shlve the question for later. > > > > > >Bob > > > >At 21:27 12/07/2010, Jason Livingood wrote: > > >On 7/12/10 1:23 PM, "ken carlberg" wrote: > > > > > > > > > > > On Jul 12, 2010, at 12:33 PM, Bob Briscoe wrote: > > > > > > > >> Are we: > > > >> - exposing congestion in order ultimately to reduce congestion? > > > >> - exposing congestion in order to share capacity better? > > > > > > > > Does it have to be either/or? could we start with reducing > > > congestion as the > > > > default position, and also have providers be a bit more proactive > > > with their > > > > management skills, and therefore help distinguish themselves from > their > > > > competitors? > > > > > >Continuing with Ken's line of thinking, I'd not restrict this now. > Exposing > > >congestion data could do a number of interesting things, which may > include > > >both of the above. Also I fear that focusing too much on this will > make > > >this into some sort of philosophical debate concerning the business > model > > >and regulatory positions, which will simply cause us to get stuck > and not > > >address the important technical work. > > > > > >Jason > > > >________________________________________________________________ > >Bob Briscoe, BT Innovate & Design > > > >_______________________________________________ > >conex mailing list > >conex@ietf.org > >https://www.ietf.org/mailman/listinfo/conex > > ________________________________________________________________ > Bob Briscoe, BT Innovate & Design From rbriscoe@jungle.bt.co.uk Wed Jul 14 02:55:36 2010 Return-Path: X-Original-To: conex@core3.amsl.com Delivered-To: conex@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 065143A6952 for ; Wed, 14 Jul 2010 02:55:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.006 X-Spam-Level: X-Spam-Status: No, score=-0.006 tagged_above=-999 required=5 tests=[AWL=-0.490, BAYES_50=0.001, DNS_FROM_RFC_BOGUSMX=1.482, HTML_MESSAGE=0.001, 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 mxE9B3IK84z1 for ; Wed, 14 Jul 2010 02:55:28 -0700 (PDT) Received: from smtp1.smtp.bt.com (smtp1.smtp.bt.com [217.32.164.137]) by core3.amsl.com (Postfix) with ESMTP id C95A73A659C for ; Wed, 14 Jul 2010 02:55:26 -0700 (PDT) Received: from i2kc08-ukbr.domain1.systemhost.net ([193.113.197.71]) by smtp1.smtp.bt.com with Microsoft SMTPSVC(6.0.3790.4675); Wed, 14 Jul 2010 10:55:35 +0100 Received: from cbibipnt08.iuser.iroot.adidom.com ([147.149.100.81]) by i2kc08-ukbr.domain1.systemhost.net with Microsoft SMTPSVC(6.0.3790.4675); Wed, 14 Jul 2010 10:55:35 +0100 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 127910133424; Wed, 14 Jul 2010 10:55:34 +0100 Received: from MUT.jungle.bt.co.uk ([10.215.130.87]) by bagheera.jungle.bt.co.uk (8.13.5/8.12.8) with ESMTP id o6E9tVbC024880; Wed, 14 Jul 2010 10:55:31 +0100 Message-Id: <201007140955.o6E9tVbC024880@bagheera.jungle.bt.co.uk> X-Mailer: QUALCOMM Windows Eudora Version 7.1.0.9 Date: Wed, 14 Jul 2010 10:55:26 +0100 To: Zhu Lei From: Bob Briscoe In-Reply-To: <006901cb1cf9$71e10d80$a3106f0a@china.huawei.com> References: <006901cb1cf9$71e10d80$a3106f0a@china.huawei.com> Mime-Version: 1.0 Content-Type: multipart/alternative; boundary="=====================_-1442471214==.ALT" X-Scanned-By: MIMEDefang 2.56 on 132.146.168.158 X-OriginalArrivalTime: 14 Jul 2010 09:55:35.0181 (UTC) FILETIME=[B46563D0:01CB233A] Cc: conex@ietf.org Subject: Re: [conex] An individual for your review X-BeenThere: conex@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Congestion Exposure working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 14 Jul 2010 09:55:36 -0000 --=====================_-1442471214==.ALT Content-Type: text/plain; charset="us-ascii"; format=flowed Zhu, Hi. I read your individual draft last night. draft-lei-ecn-localised-congestion-notification-00 First, we should be clear that working on new data plane congestion notification technology is not part of the ConEx charter. So, those focusing solely on the charter can stop reading now if they want. But I want to briefly review your proposal anyway, mainly to record on the mailing list what I believe is the current status of ECN deployment problems. If I can summarise your proposal, I believe the main proposed new requirement is that we should work on a congestion notification architecture that looks something like this: +--------------------------------------------------------------<---+ | +---<----+ ^ | / ^ | | | |ECN_S ECN_R | V V | --------------> | S ---> S's access net ---> core ... core ---> R's access net ---> R Where ECN_S and ECN_R are congestion notification channels from the respective access networks of the sender S and receiver R directly to S and R. I believe the proposal is currently agnostic to whether ECN_R is in-band or out-of-band, but clearly ECN_S must be out-of-band. Is the stated problem solved by this proposal? ---------------------------------------------- The stated problem this proposal aims to solve is: - congestion is mostly in access networks - ECN sometimes does not get through certain middleboxes that do not support ECN. I agree with both statements, but there seems to be a misconception in the document about what it means for a router, switch or middlebox to 'not support' ECN. ECN incremental deployment design --------------------------------- ECN was designed for incremental deployment where some, most or all routers or middleboxes do not do ECN marking. If both endpoints support ECN, they should be able to exchange packets between themselves that are ECN-capable (with an ECN-capable transport or ECT codepoint set) whatever network support there is for ECN between them. ECN was designed so that network equipment that has not been upgraded to mark the ECN field during congestion would silently forward ECN-capable packets when not congested and drop them during congestion - no different to any non-ECN-capable packets with the ECN field cleared (Not-ECT). Ways to 'not support' ECN ------------------------- Network equipment can 'not support' ECN in three ways: 1) lacks ECN: not yet upgraded to do ECN marking. 2) prevents ECN (a bug): middlebox tampers with endpoint attempts to send ECN-capable packets. Three known sub-cases: 2a) ECN-TCP drop: drops SYNs attempting to negotiate ECN in the TCP header 2b) ECN-IP drop: drops packets with ECN-capable codepoint in IP header 2c) ECN-IP normalise: reverts ECN-capable packets to Not-ECT in IP header 3) crashes with ECN (a bug): an endpoint attempt to negotiate ECN in the TCP header crashes a middlebox Case 1) is normal and is by far the most prevalent. ECN's incremental deployment design (above) copes with this just fine. Case 2) happens in a small number of cases: * Until about 2005-6 there were a number of enterprise-grade firewalls and NATs that did this, but tests showed their rules got upgraded over time and it was no longer a problem. * It is however still a problem with about five popular models of home gateway from those days that will take some time to be discarded from most homes. * Recently, a new problem has appeared on paths that were previously OK. It is thought this may be a buggy attempt to zero the Diffserv codepoint, which is also accidentally clearing the ECN field in the IP header. Case 3) happens in one known case of one model of a home gateway that was popularly deployed a few years ago. Equipment on the path exhibiting Case 2) behaviour can be detected by ECN black-hole detection code on the end-system, reverting a flow to Not-ECT in order to get packets through. There are black-hole detection patches for Linux, but black-hole detection is not configured by default with the mainline code. The The home gateway that crashes on seeing ECN in the TCP header of a SYN (Case 3) is more problematic. ECN is turned off by default for the client end of TCP connections in Windows and Linux because of this single popular bugged home gateway. It should be possible to do some heuristic test to detect if the offending model is on your home network (perhaps using uPNP or checking whether the MAC address falls within a known range). But AFAIK, no code is available to do this. Again, is the stated problem solved by this proposal? ----------------------------------------------------- The proposal seems to be focused particularly on 3GPP, where AFAIK there are no ECN deployment problems that are not under the control of the network operators who could upgrade and fix them quickly. I believe that introducing a new way to signal ECN would encounter as many deployment problems, if not more, than persevering with deployment of the existing way to do ECN. Is backward ECN a good idea anyway? ----------------------------------- The backward messages I have termed ECN_S in your proposal are reminiscent of ICMP source quench messages. SQ was deprecated for a number of reasons that also all apply to your proposal: * SQ violates layering (congestion control is assumed to be end to end in the Internet Architecture), so it can interact badly with IPsec encryption and tunneling, making it difficult to address the message back to the process on the host generating the load. * ICMP packet creation is normally (always) implemented on the ingress interface of a router. Congestion is detected on the egress, where it is too late, and too expensive wrt. critical processing time, to trigger the creation and sending of an ICMP packet, without hugely re-working the implementation architecture of most routers. * SQ creates more data (although admittedly in the other direction) during congestion, which is generally to be avoided. * SQ may get lost, and there's no 'end-middle' reliable channel between source and bottleneck to recover losses. * SQ messages can be maliciously sent to hosts as if they came from an on-path router, thus creating a DoS vulnerability. To solve this would require a complicated security association between the SQ message and the packet stream it refers to. * SQ messages are invariably discarded by firewalls, mostly because they can be spoofed (previous point). See for the history of ICMP SQ. In summary, I don't believe your proposal is a good way to solve the problems it identifies. Cheers Bob At 11:53 06/07/2010, Zhu Lei wrote: >Hi all, > >We already had some discussions which may allow wireless access >networks to notify congestions in mail list. > >I personally think that Conex charter is asking some solutions by >stating "However, the CONEX WG will initially focus on one use case, >where the end hosts and the network that contains the destination >end host are CONEX-enabled but other networks need not be." > >I have an individual draft which introduces some ideas for next f2f >meeting. I'd like to ask you to review this short document and help >identify the problems which could be resolved in Conex wg. Thank you! > >draft-lei-ecn-localised-congestion-notification-00 >Hope have your feedback soon. > >Best regards, >Lei Zhu > > >_______________________________________________ >conex mailing list >conex@ietf.org >https://www.ietf.org/mailman/listinfo/conex ________________________________________________________________ Bob Briscoe, BT Innovate & Design --=====================_-1442471214==.ALT Content-Type: text/html; charset="us-ascii" Zhu,

Hi. I read your individual draft last night.
draft-lei-ecn-localised-congestion-notification-00

First, we should be clear that working on new data plane congestion notification technology is not part of the ConEx charter. So, those focusing solely on the charter can stop reading now if they want.

But I want to briefly review your proposal anyway, mainly to record on the mailing list what I believe is the current status of ECN deployment problems.

If I can summarise your proposal, I believe the main proposed new requirement is that we should work on a congestion notification architecture that looks something like this:

+--------------------------------------------------------------<---+
|   +---<----+                                                     ^
|  /         ^                                                     |
| |          |ECN_S                                    ECN_R       |
V V          |                                     --------------> |
 S ---> S's access net ---> core ... core ---> R's access net ---> R

Where ECN_S and ECN_R are congestion notification channels from the respective access networks of the sender S and receiver R directly to S and R. I believe the proposal is currently agnostic to whether ECN_R is in-band or out-of-band, but clearly ECN_S must be out-of-band.

Is the stated problem solved by this proposal?
----------------------------------------------
The stated problem this proposal aims to solve is:
- congestion is mostly in access networks
- ECN sometimes does not get through certain middleboxes that do not support ECN.

I agree with both statements, but there seems to be a misconception in the document about what it means for a router, switch or middlebox to 'not support' ECN.

ECN incremental deployment design
---------------------------------
ECN was designed for incremental deployment where some, most or all routers or middleboxes do not do ECN marking. If both endpoints support ECN, they should be able to exchange packets between themselves that are ECN-capable (with an ECN-capable transport or ECT codepoint set) whatever network support there is for ECN between them.

ECN was designed so that network equipment that has not been upgraded to mark the ECN field during congestion would silently forward ECN-capable packets when not congested and drop them during congestion - no different to any non-ECN-capable packets with the ECN field cleared (Not-ECT).

Ways to 'not support' ECN
-------------------------
Network equipment can 'not support' ECN in three ways:
1) lacks ECN: not yet upgraded to do ECN marking.
2) prevents ECN (a bug): middlebox tampers with endpoint attempts to send ECN-capable packets. Three known sub-cases:
 2a) ECN-TCP drop: drops SYNs attempting to negotiate ECN in the TCP header
 2b) ECN-IP drop: drops packets with ECN-capable codepoint in IP header
 2c) ECN-IP normalise: reverts ECN-capable packets to Not-ECT in IP header
3) crashes with ECN (a bug): an endpoint attempt to negotiate ECN in the TCP header crashes a middlebox

Case 1) is normal and is by far the most prevalent. ECN's incremental deployment design (above) copes with this just fine.

Case 2) happens in a small number of cases:
* Until about 2005-6 there were a number of enterprise-grade firewalls and NATs that did this, but tests showed their rules got upgraded over time and it was no longer a problem.
* It is however still a problem with about five popular models of home gateway from those days that will take some time to be discarded from most homes.
* Recently, a new problem has appeared on paths that were previously OK. It is thought this may be a buggy attempt to zero the Diffserv codepoint, which is also accidentally clearing the ECN field in the IP header.

Case 3) happens in one known case of one model of a home gateway that was popularly deployed a few years ago.

Equipment on the path exhibiting Case 2) behaviour can be detected by ECN black-hole detection code on the end-system, reverting a flow to Not-ECT in order to get packets through. There are black-hole detection patches for Linux, but black-hole detection is not configured by default with the mainline code. The

The home gateway that crashes on seeing ECN in the TCP header of a SYN (Case 3) is more problematic. ECN is turned off by default for the client end of TCP connections in Windows and Linux because of this single popular bugged home gateway. It should be possible to do some heuristic test to detect if the offending model is on your home network (perhaps using uPNP or checking whether the MAC address falls within a known range). But AFAIK, no code is available to do this.

Again, is the stated problem solved by this proposal?
-----------------------------------------------------
The proposal seems to be focused particularly on 3GPP, where AFAIK there are no ECN deployment problems that are not under the control of the network operators who could upgrade and fix them quickly.

I believe that introducing a new way to signal ECN would encounter as many deployment problems, if not more, than persevering with deployment of the existing way to do ECN.

Is backward ECN a good idea anyway?
-----------------------------------
The backward messages I have termed ECN_S in your proposal are reminiscent of ICMP source quench messages. SQ was deprecated for a number of reasons that also all apply to your proposal:
* SQ violates layering (congestion control is assumed to be end to end in the Internet Architecture), so it can interact badly with IPsec encryption and tunneling, making it difficult to address the message back to the process on the host generating the load.
* ICMP packet creation is normally (always) implemented on the ingress interface of a router. Congestion is detected on the egress, where it is too late, and too expensive wrt. critical processing time, to trigger the creation and sending of an ICMP packet, without hugely re-working the implementation architecture of most routers.
* SQ creates more data (although admittedly in the other direction) during congestion, which is generally to be avoided.
* SQ may get lost, and there's no 'end-middle' reliable channel between source and bottleneck to recover losses.
* SQ messages can be maliciously sent to hosts as if they came from an on-path router, thus creating a DoS vulnerability. To solve this would require a complicated security association between the SQ message and the packet stream it refers to.
* SQ messages are invariably discarded by firewalls, mostly because they can be spoofed (previous point).

See < http://www.ietf.org/mail-archive/web/ternli/current/msg00036.html> for the history of ICMP SQ.

In summary, I don't believe your proposal is a good way to solve the problems it identifies.

Cheers


Bob

At 11:53 06/07/2010, Zhu Lei wrote:
Hi all,
 
We already had some discussions which may allow wireless access networks to notify congestions in mail list.
 
I personally think that Conex charter is asking some solutions by stating "However, the CONEX WG will initially focus on one use case, where the end hosts and the network that contains the destination end host are CONEX-enabled but other networks need not be."
 
I have an individual draft which introduces some ideas for next f2f meeting. I'd like to ask you to review this short document and help identify the problems which could be resolved in Conex wg. Thank you!
 
draft-lei-ecn-localised-congestion-notification-00
Hope have your feedback soon.
 
Best regards,
Lei Zhu

 
_______________________________________________
conex mailing list
conex@ietf.org
https://www.ietf.org/mailman/listinfo/conex

________________________________________________________________
Bob Briscoe,                                BT Innovate & Design --=====================_-1442471214==.ALT-- From rbriscoe@jungle.bt.co.uk Wed Jul 14 06:55:56 2010 Return-Path: X-Original-To: conex@core3.amsl.com Delivered-To: conex@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 3A93F3A6A27 for ; Wed, 14 Jul 2010 06:55:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.331 X-Spam-Level: X-Spam-Status: No, score=-1.331 tagged_above=-999 required=5 tests=[AWL=0.786, BAYES_00=-2.599, DNS_FROM_RFC_BOGUSMX=1.482, 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 zS0+t67rXwYv for ; Wed, 14 Jul 2010 06:55:50 -0700 (PDT) Received: from smtp3.smtp.bt.com (smtp3.smtp.bt.com [217.32.164.138]) by core3.amsl.com (Postfix) with ESMTP id 32C523A6A51 for ; Wed, 14 Jul 2010 06:55:49 -0700 (PDT) Received: from i2kc08-ukbr.domain1.systemhost.net ([193.113.197.71]) by smtp3.smtp.bt.com with Microsoft SMTPSVC(6.0.3790.4675); Wed, 14 Jul 2010 14:55:58 +0100 Received: from cbibipnt08.iuser.iroot.adidom.com ([147.149.100.81]) by i2kc08-ukbr.domain1.systemhost.net with Microsoft SMTPSVC(6.0.3790.4675); Wed, 14 Jul 2010 14:55:58 +0100 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 1279115756390; Wed, 14 Jul 2010 14:55:56 +0100 Received: from MUT.jungle.bt.co.uk ([10.215.130.87]) by bagheera.jungle.bt.co.uk (8.13.5/8.12.8) with ESMTP id o6EDtskp027740; Wed, 14 Jul 2010 14:55:54 +0100 Message-Id: <201007141355.o6EDtskp027740@bagheera.jungle.bt.co.uk> X-Mailer: QUALCOMM Windows Eudora Version 7.1.0.9 Date: Wed, 14 Jul 2010 14:55:54 +0100 To: "Toby Moncaster" From: Bob Briscoe In-Reply-To: <000401cb2331$c5d32570$51797050$@com> References: <4424D740-233E-4AE2-B428-BB4F1EDB0510@g11.org.uk> <201007122303.o6CN3S9h002959@bagheera.jungle.bt.co.uk> <563C162F43D1B14E9FD2BC0A776C1E9127BF37589D@WNEXMBX01.telecom.tcnz.net> <201007131602.o6DG25nF013783@bagheera.jungle.bt.co.uk> <000401cb2331$c5d32570$51797050$@com> 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: 14 Jul 2010 13:55:58.0304 (UTC) FILETIME=[493F4E00:01CB235C] Cc: 'Kevin Mason' , "'Woundy, Richard'" , conex@ietf.org Subject: Re: [conex] What's the problem: excessive congestion or capacity sharing? X-BeenThere: conex@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Congestion Exposure working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 14 Jul 2010 13:55:56 -0000 Toby, At 09:51 14/07/2010, Toby Moncaster wrote: >"When the volume of traffic offered to the next hop excedes that available >capacity the link becomes overloaded. ..." > >Oh, and I may steal that first sentence and use it to improve the current >definition of congestion in the draft. How about adding two words: "When the volume of traffic offered to the next hop excedes its available capacity, however temporarily, the link is said to be congested. ..." This helps addresses that class of people John L identified who think (congestion = high average utilisation). Bob ________________________________________________________________ Bob Briscoe, BT Innovate & Design From john@jlc.net Wed Jul 14 07:21:41 2010 Return-Path: X-Original-To: conex@core3.amsl.com Delivered-To: conex@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id E838D3A6B4A for ; Wed, 14 Jul 2010 07:21:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.787 X-Spam-Level: X-Spam-Status: No, score=-3.787 tagged_above=-999 required=5 tests=[AWL=0.650, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_NET=0.611, RCVD_IN_DNSWL_MED=-4, RDNS_NONE=0.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 HYwHBOKHAO45 for ; Wed, 14 Jul 2010 07:21:37 -0700 (PDT) Received: from mailhost.jlc.net (unknown [199.201.159.4]) by core3.amsl.com (Postfix) with ESMTP id 8B4243A6A7C for ; Wed, 14 Jul 2010 07:21:36 -0700 (PDT) Received: by mailhost.jlc.net (Postfix, from userid 104) id 5D89833C65; Wed, 14 Jul 2010 10:21:46 -0400 (EDT) Date: Wed, 14 Jul 2010 10:21:46 -0400 From: John Leslie To: Bob Briscoe Message-ID: <20100714142146.GP47417@verdi> References: <4424D740-233E-4AE2-B428-BB4F1EDB0510@g11.org.uk> <201007122303.o6CN3S9h002959@bagheera.jungle.bt.co.uk> <563C162F43D1B14E9FD2BC0A776C1E9127BF37589D@WNEXMBX01.telecom.tcnz.net> <201007131602.o6DG25nF013783@bagheera.jungle.bt.co.uk> <000401cb2331$c5d32570$51797050$@com> <201007141355.o6EDtskp027740@bagheera.jungle.bt.co.uk> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <201007141355.o6EDtskp027740@bagheera.jungle.bt.co.uk> User-Agent: Mutt/1.4.1i Cc: 'Kevin Mason' , conex@ietf.org Subject: Re: [conex] What's the problem: excessive congestion or capacity sharing? X-BeenThere: conex@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Congestion Exposure working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 14 Jul 2010 14:21:41 -0000 Bob Briscoe wrote: > At 09:51 14/07/2010, Toby Moncaster wrote: > >> "When the volume of traffic offered to the next hop excedes that available >> capacity the link becomes overloaded. ..." >> >> Oh, and I may steal that first sentence and use it to improve the current >> definition of congestion in the draft. > > How about adding two words: > > "When the volume of traffic offered to the next hop excedes its available > capacity, however temporarily, the link is said to be congested. ..." I don't have a problem with such language as part of the definition. I'm uneasy with putting it outside the Definitions section, and actually unhappy putting such language _before_ the Definitions section. (This is not to say I'd object to removing language in the Introduction which might seem to say something else.) > This helps addresses that class of people John L identified who think > (congestion = high average utilisation). I think it's important to start the Definitions section with a crisp definition of "congestion" which makes it clear we're talking something which is transient -- in the usual case, at least. I don't want anything in the Introduction which might be read as a competing definition. -- John Leslie From marcelo@it.uc3m.es Wed Jul 14 08:55:13 2010 Return-Path: X-Original-To: conex@core3.amsl.com Delivered-To: conex@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 69DAC3A6B82 for ; Wed, 14 Jul 2010 08:55:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.382 X-Spam-Level: X-Spam-Status: No, score=-106.382 tagged_above=-999 required=5 tests=[AWL=0.217, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] 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 M6wgfGxr+QQF for ; Wed, 14 Jul 2010 08:55:12 -0700 (PDT) Received: from smtp03.uc3m.es (smtp03.uc3m.es [163.117.176.133]) by core3.amsl.com (Postfix) with ESMTP id A69B03A6B78 for ; Wed, 14 Jul 2010 08:55:12 -0700 (PDT) X-uc3m-safe: yes Received: from marcelo-bagnulos-macbook-pro.local (wlap005.it.uc3m.es [163.117.139.108]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by smtp03.uc3m.es (Postfix) with ESMTP id 8384A83A45D for ; Wed, 14 Jul 2010 17:55:20 +0200 (CEST) Message-ID: <4C3DDDE8.4010702@it.uc3m.es> Date: Wed, 14 Jul 2010 17:55:20 +0200 From: marcelo bagnulo braun User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.5; es-ES; rv:1.9.1.10) Gecko/20100512 Thunderbird/3.0.5 MIME-Version: 1.0 To: conex@ietf.org Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-TM-AS-Product-Ver: IMSS-7.0.0.3116-6.0.0.1038-17504.007 Subject: [conex] draft agenda X-BeenThere: conex@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Congestion Exposure working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 14 Jul 2010 15:55:13 -0000 Hi, you can find a first version of the agenda at http://www.ietf.org/proceedings/78/agenda/conex.txt To all presenters, you MUST send us the slides before monday 26 july at 1700 hrs., if not we won't be able to upload the material. Regards, marcelo From lei.zhu@huawei.com Fri Jul 16 00:50:08 2010 Return-Path: X-Original-To: conex@core3.amsl.com Delivered-To: conex@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id A5BE73A69A6 for ; Fri, 16 Jul 2010 00:50:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 3.487 X-Spam-Level: *** X-Spam-Status: No, score=3.487 tagged_above=-999 required=5 tests=[AWL=-0.883, BAYES_40=-0.185, FH_RELAY_NODNS=1.451, HELO_MISMATCH_COM=0.553, HTML_MESSAGE=0.001, MIME_CHARSET_FARAWAY=2.45, RDNS_NONE=0.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 MA7t0fFAF+TL for ; Fri, 16 Jul 2010 00:50:06 -0700 (PDT) Received: from szxga03-in.huawei.com (unknown [119.145.14.66]) by core3.amsl.com (Postfix) with ESMTP id A21173A6990 for ; Fri, 16 Jul 2010 00:49:51 -0700 (PDT) Received: from huawei.com (szxga03-in [172.24.2.9]) by szxga03-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0L5N006TF4AEV7@szxga03-in.huawei.com> for conex@ietf.org; Fri, 16 Jul 2010 15:47:02 +0800 (CST) Received: from huawei.com ([172.24.2.119]) by szxga03-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0L5N00HRO4AESM@szxga03-in.huawei.com> for conex@ietf.org; Fri, 16 Jul 2010 15:47:02 +0800 (CST) Received: from z41317 ([10.111.16.163]) by szxml04-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTPA id <0L5N003WJ4ADFN@szxml04-in.huawei.com> for conex@ietf.org; Fri, 16 Jul 2010 15:47:02 +0800 (CST) Date: Fri, 16 Jul 2010 15:47:00 +0800 From: Zhu Lei In-reply-to: <201007140955.o6E9tVbC024880@bagheera.jungle.bt.co.uk> To: 'Bob Briscoe' Message-id: <000a01cb24bb$1382bad0$a3106f0a@china.huawei.com> MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2900.3350 X-Mailer: Microsoft Office Outlook 11 Content-type: multipart/alternative; boundary="Boundary_(ID_AdvYfN7ir2b+8ixTygp5Jw)" Thread-index: AcsjOvVBhzY1vS28T9yBGKtE6EI1gAAlVzRw Cc: conex@ietf.org Subject: Re: [conex] An individual for your review X-BeenThere: conex@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Congestion Exposure working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 16 Jul 2010 07:50:08 -0000 This is a multi-part message in MIME format. --Boundary_(ID_AdvYfN7ir2b+8ixTygp5Jw) Content-type: text/plain; charset=gb2312 Content-transfer-encoding: quoted-printable Hi Bob and all, =20 Thank you for identifing some problems of ECN, especially mentioned some historical technical discussions which I never heard previously. =20 The problems of ECN at the moment are clearly summerised and clarified = by Bob. I should follow the directions together with issues which is to be solved. =20 I have to say the understanding of the "proposal" is mainly correct. I highly appreciate the draft proposal and problem statement in previous e-mail. We at least need some statement in use cases draft. =20 The possible technical proposal of my mind is little bit different from = the picture. The major difference is that the ECN_S could be not = out-of-band. And, I also don't think that the ICMP is the approach. I personlly want = the in-band trasnportation of ECN mark. =20 The document seems hint the proposal, but the intention of the submitted document is to introduce the requirements. I would try to write a = technical proposal in ML soon. The slides for presentation take me time due to my native language. =20 I appologize for some delay of replying e-mail since I should have some works for internal guys in parallel. =20 Best regards, Lei _____ =20 =B7=A2=BC=FE=C8=CB: Bob Briscoe [mailto:rbriscoe@jungle.bt.co.uk]=20 =B7=A2=CB=CD=CA=B1=BC=E4: 2010=C4=EA7=D4=C214=C8=D5 17:55 =CA=D5=BC=FE=C8=CB: Zhu Lei =B3=AD=CB=CD: conex@ietf.org =D6=F7=CC=E2: Re: [conex] An individual for your review Zhu, Hi. I read your individual draft last night. draft-lei-ecn-localised-congestion-notification-00 First, we should be clear that working on new data plane congestion notification technology is not part of the ConEx charter. So, those = focusing solely on the charter can stop reading now if they want.=20 But I want to briefly review your proposal anyway, mainly to record on = the mailing list what I believe is the current status of ECN deployment problems. If I can summarise your proposal, I believe the main proposed new requirement is that we should work on a congestion notification = architecture that looks something like this: +--------------------------------------------------------------<---+ | +---<----+ ^ | / ^ | | | |ECN_S ECN_R | V V | --------------> | S ---> S's access net ---> core ... core ---> R's access net ---> R Where ECN_S and ECN_R are congestion notification channels from the respective access networks of the sender S and receiver R directly to S = and R. I believe the proposal is currently agnostic to whether ECN_R is = in-band or out-of-band, but clearly ECN_S must be out-of-band. Is the stated problem solved by this proposal? ---------------------------------------------- The stated problem this proposal aims to solve is: - congestion is mostly in access networks - ECN sometimes does not get through certain middleboxes that do not = support ECN. I agree with both statements, but there seems to be a misconception in = the document about what it means for a router, switch or middlebox to 'not support' ECN.=20 ECN incremental deployment design --------------------------------- ECN was designed for incremental deployment where some, most or all = routers or middleboxes do not do ECN marking. If both endpoints support ECN, = they should be able to exchange packets between themselves that are = ECN-capable (with an ECN-capable transport or ECT codepoint set) whatever network support there is for ECN between them. ECN was designed so that network equipment that has not been upgraded to mark the ECN field during congestion would silently forward ECN-capable packets when not congested and drop them during congestion - no = different to any non-ECN-capable packets with the ECN field cleared (Not-ECT). Ways to 'not support' ECN ------------------------- Network equipment can 'not support' ECN in three ways: 1) lacks ECN: not yet upgraded to do ECN marking. 2) prevents ECN (a bug): middlebox tampers with endpoint attempts to = send ECN-capable packets. Three known sub-cases: 2a) ECN-TCP drop: drops SYNs attempting to negotiate ECN in the TCP = header 2b) ECN-IP drop: drops packets with ECN-capable codepoint in IP header 2c) ECN-IP normalise: reverts ECN-capable packets to Not-ECT in IP = header 3) crashes with ECN (a bug): an endpoint attempt to negotiate ECN in the = TCP header crashes a middlebox Case 1) is normal and is by far the most prevalent. ECN's incremental deployment design (above) copes with this just fine. Case 2) happens in a small number of cases: * Until about 2005-6 there were a number of enterprise-grade firewalls = and NATs that did this, but tests showed their rules got upgraded over time = and it was no longer a problem.=20 * It is however still a problem with about five popular models of home gateway from those days that will take some time to be discarded from = most homes.=20 * Recently, a new problem has appeared on paths that were previously OK. = It is thought this may be a buggy attempt to zero the Diffserv codepoint, = which is also accidentally clearing the ECN field in the IP header. Case 3) happens in one known case of one model of a home gateway that = was popularly deployed a few years ago. Equipment on the path exhibiting Case 2) behaviour can be detected by = ECN black-hole detection code on the end-system, reverting a flow to Not-ECT = in order to get packets through. There are black-hole detection patches for Linux, but black-hole detection is not configured by default with the mainline code. The=20 The home gateway that crashes on seeing ECN in the TCP header of a SYN = (Case 3) is more problematic. ECN is turned off by default for the client end = of TCP connections in Windows and Linux because of this single popular = bugged home gateway. It should be possible to do some heuristic test to detect = if the offending model is on your home network (perhaps using uPNP or = checking whether the MAC address falls within a known range). But AFAIK, no code = is available to do this. Again, is the stated problem solved by this proposal? ----------------------------------------------------- The proposal seems to be focused particularly on 3GPP, where AFAIK there = are no ECN deployment problems that are not under the control of the network operators who could upgrade and fix them quickly. I believe that introducing a new way to signal ECN would encounter as = many deployment problems, if not more, than persevering with deployment of = the existing way to do ECN. Is backward ECN a good idea anyway? ----------------------------------- The backward messages I have termed ECN_S in your proposal are = reminiscent of ICMP source quench messages. SQ was deprecated for a number of = reasons that also all apply to your proposal: * SQ violates layering (congestion control is assumed to be end to end = in the Internet Architecture), so it can interact badly with IPsec = encryption and tunneling, making it difficult to address the message back to the process on the host generating the load.=20 * ICMP packet creation is normally (always) implemented on the ingress interface of a router. Congestion is detected on the egress, where it is = too late, and too expensive wrt. critical processing time, to trigger the creation and sending of an ICMP packet, without hugely re-working the implementation architecture of most routers. * SQ creates more data (although admittedly in the other direction) = during congestion, which is generally to be avoided. * SQ may get lost, and there's no 'end-middle' reliable channel between source and bottleneck to recover losses. * SQ messages can be maliciously sent to hosts as if they came from an on-path router, thus creating a DoS vulnerability. To solve this would require a complicated security association between the SQ message and = the packet stream it refers to. * SQ messages are invariably discarded by firewalls, mostly because they = can be spoofed (previous point). See < = http://www.ietf.org/mail-archive/web/ternli/current/msg00036.html> for = the history of ICMP SQ. In summary, I don't believe your proposal is a good way to solve the problems it identifies. Cheers Bob At 11:53 06/07/2010, Zhu Lei wrote: Hi all, =20 We already had some discussions which may allow wireless access networks = to notify congestions in mail list.=20 =20 I personally think that Conex charter is asking some solutions by = stating "However, the CONEX WG will initially focus on one use case, where the = end hosts and the network that contains the destination end host are CONEX-enabled but other networks need not be."=20 =20 I have an individual draft which introduces some ideas for next f2f = meeting. I'd like to ask you to review this short document and help identify the problems which could be resolved in Conex wg. Thank you! =20 draft-lei-ecn-localised-congestion-notification-00 Hope have your feedback soon. =20 Best regards, Lei Zhu =20 _______________________________________________ conex mailing list conex@ietf.org https://www.ietf.org/mailman/listinfo/conex ________________________________________________________________ Bob Briscoe, BT Innovate & Design=20 --Boundary_(ID_AdvYfN7ir2b+8ixTygp5Jw) Content-type: text/html; charset=gb2312 Content-transfer-encoding: quoted-printable

Hi Bob and all,
 
Thank you for identifing some problems of = ECN,=20 especially mentioned some historical technical discussions which I never = heard=20 previously.
 
The problems of ECN at the moment are clearly = summerised and clarified by Bob. I should follow the directions = together=20 with issues which is to be solved.
 
I = have to say the=20 understanding of the "proposal" is mainly correct. I highly appreciate = the draft=20 proposal and problem statement in previous e-mail. We at least need some = statement in use cases draft.
 
The = possible=20 technical proposal of my mind is little bit different from the = picture. The major difference is that the ECN_S could be not = out-of-band. And, I=20 also don't think that the ICMP is the approach. I personlly want the = in-band=20 trasnportation of ECN mark.
 
The = document=20 seems hint the proposal, but the intention of the submitted document is = to=20 introduce the requirements. I would try to write a technical proposal in = ML=20 soon. The slides for presentation take me time due to my native=20 language.
 
I = appologize for=20 some delay of replying e-mail since I should have some works for = internal guys=20 in parallel.
 
Best=20 regards,
Lei


=B7=A2=BC=FE=C8=CB: Bob Briscoe = [mailto:rbriscoe@jungle.bt.co.uk]=20
=B7=A2=CB=CD=CA=B1=BC=E4: 2010=C4=EA7=D4=C214=C8=D5 = 17:55
=CA=D5=BC=FE=C8=CB: Zhu Lei
=B3=AD=CB=CD:=20 conex@ietf.org
=D6=F7=CC=E2: Re: [conex] An individual for = your=20 review

Zhu,

Hi. I read your individual draft last=20 night.
draft-lei-ecn-localised-congestion-notification-00

First= , we=20 should be clear that working on new data plane congestion notification=20 technology is not part of the ConEx charter. So, those focusing solely = on the=20 charter can stop reading now if they want.

But I want to briefly = review=20 your proposal anyway, mainly to record on the mailing list what I = believe is the=20 current status of ECN deployment problems.

If I can summarise = your=20 proposal, I believe the main proposed new requirement is that we should = work on=20 a congestion notification architecture that looks something like=20 this:

+-----------------------------------------------------------= ---<---+
|  =20 +---<----+          =             &= nbsp;           &n= bsp;           &nb= sp;     =20 ^
|  /        =20 ^            =             &= nbsp;           &n= bsp;           &nb= sp;   =20 |
| |         =20 |ECN_S           &= nbsp;           &n= bsp;           =20 ECN_R       |
V=20 V         =20 |            =             &= nbsp;           =20 --------------> |
 S ---> S's access net ---> core ... = core=20 ---> R's access net ---> R

Where ECN_S and ECN_R are = congestion=20 notification channels from the respective access networks of the sender = S and=20 receiver R directly to S and R. I believe the proposal is currently = agnostic to=20 whether ECN_R is in-band or out-of-band, but clearly ECN_S must be=20 out-of-band.

Is the stated problem solved by this=20 proposal?
----------------------------------------------
The = stated=20 problem this proposal aims to solve is:
- congestion is mostly in = access=20 networks
- ECN sometimes does not get through certain middleboxes = that do not=20 support ECN.

I agree with both statements, but there seems to be = a=20 misconception in the document about what it means for a router, switch = or=20 middlebox to 'not support' ECN.

ECN incremental deployment=20 design
---------------------------------
ECN was designed for = incremental=20 deployment where some, most or all routers or middleboxes do not do ECN = marking.=20 If both endpoints support ECN, they should be able to exchange packets = between=20 themselves that are ECN-capable (with an ECN-capable transport or ECT = codepoint=20 set) whatever network support there is for ECN between them.

ECN = was=20 designed so that network equipment that has not been upgraded to mark = the ECN=20 field during congestion would silently forward ECN-capable packets when = not=20 congested and drop them during congestion - no different to any = non-ECN-capable=20 packets with the ECN field cleared (Not-ECT).

Ways to 'not = support'=20 ECN
-------------------------
Network equipment can 'not support' = ECN in=20 three ways:
1) lacks ECN: not yet upgraded to do ECN marking.
2) = prevents=20 ECN (a bug): middlebox tampers with endpoint attempts to send = ECN-capable=20 packets. Three known sub-cases:
 2a) ECN-TCP drop: drops SYNs = attempting=20 to negotiate ECN in the TCP header
 2b) ECN-IP drop: drops = packets with=20 ECN-capable codepoint in IP header
 2c) ECN-IP normalise: = reverts=20 ECN-capable packets to Not-ECT in IP header
3) crashes with ECN (a = bug): an=20 endpoint attempt to negotiate ECN in the TCP header crashes a=20 middlebox

Case 1) is normal and is by far the most prevalent. = ECN's=20 incremental deployment design (above) copes with this just = fine.

Case 2)=20 happens in a small number of cases:
* Until about 2005-6 there were a = number=20 of enterprise-grade firewalls and NATs that did this, but tests showed = their=20 rules got upgraded over time and it was no longer a problem.
* It is = however=20 still a problem with about five popular models of home gateway from = those days=20 that will take some time to be discarded from most homes.
* = Recently, a new=20 problem has appeared on paths that were previously OK. It is thought = this may be=20 a buggy attempt to zero the Diffserv codepoint, which is also = accidentally=20 clearing the ECN field in the IP header.

Case 3) happens in one = known=20 case of one model of a home gateway that was popularly deployed a few = years=20 ago.

Equipment on the path exhibiting Case 2) behaviour can be = detected=20 by ECN black-hole detection code on the end-system, reverting a flow to = Not-ECT=20 in order to get packets through. There are black-hole detection patches = for=20 Linux, but black-hole detection is not configured by default with the = mainline=20 code. The

The home gateway that crashes on seeing ECN in the TCP = header=20 of a SYN (Case 3) is more problematic. ECN is turned off by default for = the=20 client end of TCP connections in Windows and Linux because of this = single=20 popular bugged home gateway. It should be possible to do some heuristic = test to=20 detect if the offending model is on your home network (perhaps using = uPNP or=20 checking whether the MAC address falls within a known range). But AFAIK, = no code=20 is available to do this.

Again, is the stated problem solved by = this=20 proposal?
-----------------------------------------------------
The= =20 proposal seems to be focused particularly on 3GPP, where AFAIK there are = no ECN=20 deployment problems that are not under the control of the network = operators who=20 could upgrade and fix them quickly.

I believe that introducing a = new way=20 to signal ECN would encounter as many deployment problems, if not more, = than=20 persevering with deployment of the existing way to do ECN.

Is = backward=20 ECN a good idea anyway?
-----------------------------------
The = backward=20 messages I have termed ECN_S in your proposal are reminiscent of ICMP = source=20 quench messages. SQ was deprecated for a number of reasons that also all = apply=20 to your proposal:
* SQ violates layering (congestion control is = assumed=20 to be end to end in the Internet Architecture), so it can interact badly = with=20 IPsec encryption and tunneling, making it difficult to address the = message back=20 to the process on the host generating the load.
* ICMP packet = creation is=20 normally (always) implemented on the ingress interface of a router. = Congestion=20 is detected on the egress, where it is too late, and too expensive wrt. = critical=20 processing time, to trigger the creation and sending of an ICMP packet, = without=20 hugely re-working the implementation architecture of most routers.
* = SQ=20 creates more data (although admittedly in the other direction) during=20 congestion, which is generally to be avoided.
* SQ may get lost, and = there's=20 no 'end-middle' reliable channel between source and bottleneck to = recover=20 losses.
* SQ messages can be maliciously sent to hosts as if they = came from=20 an on-path router, thus creating a DoS vulnerability. To solve this = would=20 require a complicated security association between the SQ message and = the packet=20 stream it refers to.
* SQ messages are invariably discarded by = firewalls,=20 mostly because they can be spoofed (previous point).

See = <=20 http://www.ietf.org/mail-archive/web/ternli/current/msg00036.html>= for=20 the history of ICMP SQ.

In summary, I don't believe your proposal = is a=20 good way to solve the problems it=20 identifies.

Cheers


Bob

At 11:53 06/07/2010, Zhu = Lei=20 wrote:
Hi=20 all,
 
We already had some = discussions which=20 may allow wireless access networks to notify congestions in mail list. =
 
I personally think that Conex = charter is=20 asking some solutions by stating "However, the CONEX WG will initially = focus=20 on one use case, where the end hosts and the network that contains the = destination end host are CONEX-enabled but other networks need not = be."=20
 
I have an individual draft which = introduces=20 some ideas for next f2f meeting. I'd like to ask you to review this = short=20 document and help identify the problems which could be resolved in = Conex wg.=20 Thank you!
 
draft-lei-ecn-localised-congestion-notification-00
Hope = have your=20 feedback soon.
 
Best regards,
Lei = = Zhu

 
_____________________________________________= __
conex=20 mailing list
conex@ietf.org
https://www.ietf.org/mailman/listinfo/conex

___________________________________________________________= _____
Bob=20 Briscoe,           = ;            =         =20 BT Innovate & Design

--Boundary_(ID_AdvYfN7ir2b+8ixTygp5Jw)-- From rbriscoe@jungle.bt.co.uk Fri Jul 16 04:45:57 2010 Return-Path: X-Original-To: conex@core3.amsl.com Delivered-To: conex@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 23E503A6829 for ; Fri, 16 Jul 2010 04:45:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.562 X-Spam-Level: X-Spam-Status: No, score=0.562 tagged_above=-999 required=5 tests=[AWL=-1.318, BAYES_50=0.001, DNS_FROM_RFC_BOGUSMX=1.482, HTML_MESSAGE=0.001, MIME_QP_LONG_LINE=1.396, 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 bljydsM2k5pW for ; Fri, 16 Jul 2010 04:45:49 -0700 (PDT) Received: from smtp1.smtp.bt.com (smtp1.smtp.bt.com [217.32.164.137]) by core3.amsl.com (Postfix) with ESMTP id 962B03A6995 for ; Fri, 16 Jul 2010 04:45:48 -0700 (PDT) Received: from i2kc06-ukbr.domain1.systemhost.net ([193.113.197.70]) by smtp1.smtp.bt.com with Microsoft SMTPSVC(6.0.3790.4675); Fri, 16 Jul 2010 12:45:58 +0100 Received: from cbibipnt05.iuser.iroot.adidom.com ([147.149.196.177]) by i2kc06-ukbr.domain1.systemhost.net with Microsoft SMTPSVC(6.0.3790.4675); Fri, 16 Jul 2010 12:45:59 +0100 Received: From bagheera.jungle.bt.co.uk ([132.146.168.158]) by cbibipnt05.iuser.iroot.adidom.com (WebShield SMTP v4.5 MR1a P0803.399); id 1279280757108; Fri, 16 Jul 2010 12:45:57 +0100 Received: from MUT.jungle.bt.co.uk ([10.215.130.87]) by bagheera.jungle.bt.co.uk (8.13.5/8.12.8) with ESMTP id o6GBjt6B026292; Fri, 16 Jul 2010 12:45:55 +0100 Message-Id: <201007161145.o6GBjt6B026292@bagheera.jungle.bt.co.uk> X-Mailer: QUALCOMM Windows Eudora Version 7.1.0.9 Date: Fri, 16 Jul 2010 12:45:54 +0100 To: Zhu Lei From: Bob Briscoe In-Reply-To: <000a01cb24bb$1382bad0$a3106f0a@china.huawei.com> References: <201007140955.o6E9tVbC024880@bagheera.jungle.bt.co.uk> <000a01cb24bb$1382bad0$a3106f0a@china.huawei.com> Mime-Version: 1.0 Content-Type: multipart/alternative; boundary="=====================_-1263048187==.ALT" X-Scanned-By: MIMEDefang 2.56 on 132.146.168.158 X-OriginalArrivalTime: 16 Jul 2010 11:45:59.0154 (UTC) FILETIME=[756AF520:01CB24DC] Cc: conex@ietf.org Subject: Re: [conex] An individual for your review X-BeenThere: conex@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Congestion Exposure working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 16 Jul 2010 11:45:57 -0000 --=====================_-1263048187==.ALT Content-Type: text/plain; charset="iso-8859-1"; format=flowed Content-Transfer-Encoding: quoted-printable Lei, The reason I said ECN_S must clearly be out of=20 band is that, by definition in-band means within=20 the packets travelling from S to R. If you mean in-band in the packets travelling=20 from R to S, the congested node may not be on the=20 route of packets between R and S, which need not=20 follow the reverse route of the forward path between S and R. I think you will find that this expired I-D from=20 Pasi Sarolahti is very relevant: Transport-layer Considerations for Explicit Cross-layer Indications Bob At 08:47 16/07/2010, Zhu Lei wrote: >Hi Bob and all, > >Thank you for identifing some problems of ECN,=20 >especially mentioned some historical technical=20 >discussions which I never heard previously. > >The problems of ECN at the moment are clearly=20 >summerised and clarified by Bob. I should follow=20 >the directions together with issues which is to be solved. > >I have to say the understanding of the=20 >"proposal" is mainly correct. I highly=20 >appreciate the draft proposal and problem=20 >statement in previous e-mail. We at least need=20 >some statement in use cases draft. > >The possible technical proposal of my mind is=20 >little bit different from the picture. The major=20 >difference is that the ECN_S could be not=20 >out-of-band. And, I also don't think that the=20 >ICMP is the approach. I personlly want the in-band trasnportation of ECN= mark. > >The document seems hint the proposal, but the=20 >intention of the submitted document is to=20 >introduce the requirements. I would try to write=20 >a technical proposal in ML soon. The slides for=20 >presentation take me time due to my native language. > >I appologize for some delay of replying e-mail=20 >since I should have some works for internal guys in parallel. > >Best regards, >Lei > > > >---------- >=B7=A2=BC=FE=C8=CB: Bob Briscoe [mailto:rbriscoe@jungle.bt.co.uk] >=B7=A2=CB=CD=CA=B1=BC=E4: 2010=C4=EA7=D4=C214=C8=D5 17:55 >=CA=D5=BC=FE=C8=CB: Zhu Lei >=B3=AD=CB=CD: conex@ietf.org >=D6=F7=CC=E2: Re: [conex] An individual for your review > >Zhu, > >Hi. I read your individual draft last night. >draft-lei-ecn-localised-congestion-notification-00 > >First, we should be clear that working on new=20 >data plane congestion notification technology is=20 >not part of the ConEx charter. So, those=20 >focusing solely on the charter can stop reading now if they want. > >But I want to briefly review your proposal=20 >anyway, mainly to record on the mailing list=20 >what I believe is the current status of ECN deployment problems. > >If I can summarise your proposal, I believe the=20 >main proposed new requirement is that we should=20 >work on a congestion notification architecture that looks something like= this: > >+--------------------------------------------------------------<---+ >| +---<----+ ^ >| / ^ | >| | |ECN_S ECN_R | >V V | --------------> | > S ---> S's access net ---> core ... core ---> R's access net ---> R > >Where ECN_S and ECN_R are congestion=20 >notification channels from the respective access=20 >networks of the sender S and receiver R directly=20 >to S and R. I believe the proposal is currently=20 >agnostic to whether ECN_R is in-band or=20 >out-of-band, but clearly ECN_S must be out-of-band. > >Is the stated problem solved by this proposal? >---------------------------------------------- >The stated problem this proposal aims to solve is: >- congestion is mostly in access networks >- ECN sometimes does not get through certain=20 >middleboxes that do not support ECN. > >I agree with both statements, but there seems to=20 >be a misconception in the document about what it=20 >means for a router, switch or middlebox to 'not support' ECN. > >ECN incremental deployment design >--------------------------------- >ECN was designed for incremental deployment=20 >where some, most or all routers or middleboxes=20 >do not do ECN marking. If both endpoints support=20 >ECN, they should be able to exchange packets=20 >between themselves that are ECN-capable (with an=20 >ECN-capable transport or ECT codepoint set)=20 >whatever network support there is for ECN between them. > >ECN was designed so that network equipment that=20 >has not been upgraded to mark the ECN field=20 >during congestion would silently forward=20 >ECN-capable packets when not congested and drop=20 >them during congestion - no different to any=20 >non-ECN-capable packets with the ECN field cleared (Not-ECT). > >Ways to 'not support' ECN >------------------------- >Network equipment can 'not support' ECN in three ways: >1) lacks ECN: not yet upgraded to do ECN marking. >2) prevents ECN (a bug): middlebox tampers with=20 >endpoint attempts to send ECN-capable packets. Three known sub-cases: > 2a) ECN-TCP drop: drops SYNs attempting to negotiate ECN in the TCP= header > 2b) ECN-IP drop: drops packets with ECN-capable codepoint in IP header > 2c) ECN-IP normalise: reverts ECN-capable packets to Not-ECT in IP header >3) crashes with ECN (a bug): an endpoint attempt=20 >to negotiate ECN in the TCP header crashes a middlebox > >Case 1) is normal and is by far the most=20 >prevalent. ECN's incremental deployment design=20 >(above) copes with this just fine. > >Case 2) happens in a small number of cases: >* Until about 2005-6 there were a number of=20 >enterprise-grade firewalls and NATs that did=20 >this, but tests showed their rules got upgraded=20 >over time and it was no longer a problem. >* It is however still a problem with about five=20 >popular models of home gateway from those days=20 >that will take some time to be discarded from most homes. >* Recently, a new problem has appeared on paths=20 >that were previously OK. It is thought this may=20 >be a buggy attempt to zero the Diffserv=20 >codepoint, which is also accidentally clearing the ECN field in the IP= header. > >Case 3) happens in one known case of one model=20 >of a home gateway that was popularly deployed a few years ago. > >Equipment on the path exhibiting Case 2)=20 >behaviour can be detected by ECN black-hole=20 >detection code on the end-system, reverting a=20 >flow to Not-ECT in order to get packets through.=20 >There are black-hole detection patches for=20 >Linux, but black-hole detection is not=20 >configured by default with the mainline code. The > >The home gateway that crashes on seeing ECN in=20 >the TCP header of a SYN (Case 3) is more=20 >problematic. ECN is turned off by default for=20 >the client end of TCP connections in Windows and=20 >Linux because of this single popular bugged home=20 >gateway. It should be possible to do some=20 >heuristic test to detect if the offending model=20 >is on your home network (perhaps using uPNP or=20 >checking whether the MAC address falls within a=20 >known range). But AFAIK, no code is available to do this. > >Again, is the stated problem solved by this proposal? >----------------------------------------------------- >The proposal seems to be focused particularly on=20 >3GPP, where AFAIK there are no ECN deployment=20 >problems that are not under the control of the=20 >network operators who could upgrade and fix them quickly. > >I believe that introducing a new way to signal=20 >ECN would encounter as many deployment problems,=20 >if not more, than persevering with deployment of the existing way to do= ECN. > >Is backward ECN a good idea anyway? >----------------------------------- >The backward messages I have termed ECN_S in=20 >your proposal are reminiscent of ICMP source=20 >quench messages. SQ was deprecated for a number=20 >of reasons that also all apply to your proposal: >* SQ violates layering (congestion control is=20 >assumed to be end to end in the Internet=20 >Architecture), so it can interact badly with=20 >IPsec encryption and tunneling, making it=20 >difficult to address the message back to the=20 >process on the host generating the load. >* ICMP packet creation is normally (always)=20 >implemented on the ingress interface of a=20 >router. Congestion is detected on the egress,=20 >where it is too late, and too expensive wrt.=20 >critical processing time, to trigger the=20 >creation and sending of an ICMP packet, without=20 >hugely re-working the implementation architecture of most routers. >* SQ creates more data (although admittedly in=20 >the other direction) during congestion, which is generally to be avoided. >* SQ may get lost, and there's no 'end-middle'=20 >reliable channel between source and bottleneck to recover losses. >* SQ messages can be maliciously sent to hosts=20 >as if they came from an on-path router, thus=20 >creating a DoS vulnerability. To solve this=20 >would require a complicated security association=20 >between the SQ message and the packet stream it refers to. >* SQ messages are invariably discarded by=20 >firewalls, mostly because they can be spoofed (previous point). > >See <=20 >http://www.ietf.org/mail-archive/web/ternli/current/msg00036.html>=20 >for the history of ICMP SQ. > >In summary, I don't believe your proposal is a=20 >good way to solve the problems it identifies. > >Cheers > > >Bob > >At 11:53 06/07/2010, Zhu Lei wrote: >>Hi all, >> >>We already had some discussions which may allow=20 >>wireless access networks to notify congestions in mail list. >> >>I personally think that Conex charter is asking=20 >>some solutions by stating "However, the CONEX=20 >>WG will initially focus on one use case, where=20 >>the end hosts and the network that contains the=20 >>destination end host are CONEX-enabled but other networks need not be." >> >>I have an individual draft which introduces=20 >>some ideas for next f2f meeting. I'd like to=20 >>ask you to review this short document and help=20 >>identify the problems which could be resolved in Conex wg. Thank you! >> >>draft-lei-ecn-localised-congestion-notification-00 >>Hope have your feedback soon. >> >>Best regards, >>Lei Zhu >> >> >>_______________________________________________ >>conex mailing list >>conex@ietf.org >>https://www.ietf.org/mailman/listinfo/conex > >________________________________________________________________ >Bob Briscoe, BT Innovate & Design ________________________________________________________________ Bob Briscoe, BT Innovate & Design=20 --=====================_-1263048187==.ALT Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Lei,

The reason I said ECN_S must clearly be out of band is that, by definition in-band means within the packets travelling from S to R.

If you mean in-band in the packets travelling from R to S, the congested node may not be on the route of packets between R and S, which need not follow the reverse route of the forward path between S and R.

I think you will find that this expired I-D from Pasi Sarolahti is very relevant:
Transport-layer Considerations for Explicit Cross-layer Indications
< https://datatracker.ietf.org/doc/draft-sarolahti-tsvwg-crosslayer/ >


Bob

At 08:47 16/07/2010, Zhu Lei wrote:
Hi Bob and all,
 
Thank you for identifing some problems of ECN, especially mentioned some historical technical discussions which I never heard previously.
 
The problems of ECN at the moment are clearly summerised and clarified by Bob. I should follow the directions together with issues which is to be solved.
 
I have to say the understanding of the "proposal" is mainly correct. I highly appreciate the draft proposal and problem statement in previous e-mail. We at least need some statement in use cases draft.
 
The possible technical proposal of my mind is little bit different from the picture. The major difference is that the ECN_S could be not out-of-band. And, I also don't think that the ICMP is the approach. I personlly want the in-band trasnportation of ECN mark.
 
The document seems hint the proposal, but the intention of the submitted document is to introduce the requirements. I would try to write a technical proposal in ML soon. The slides for presentation take me time due to my native language.
 
I appologize for some delay of replying e-mail since I should have some works for internal guys in parallel.
 
Best regards,
Lei


=B7=A2=BC=FE=C8=CB: Bob Briscoe [ mailto:rbriscoe@jungle.bt.co.uk]
=B7=A2=CB=CD=CA=B1=BC=E4: 2010=C4=EA7=D4=C214=C8=D5 17:55
=CA=D5=BC=FE=C8=CB: Zhu Lei
=B3=AD=CB=CD: conex@ietf.org
=D6=F7=CC=E2: Re: [conex] An individual for your review

Zhu,

Hi. I read your individual draft last night.
draft-lei-ecn-localised-congestion-notification-00

First, we should be clear that working on new data plane congestion notification technology is not part of the ConEx charter. So, those focusing solely on the charter can stop reading now if they want.

But I want to briefly review your proposal anyway, mainly to record on the mailing list what I believe is the current status of ECN deployment problems.

If I can summarise your proposal, I believe the main proposed new requirement is that we should work on a congestion notification architecture that looks something like this:

+--------------------------------------------------------------<---+
|   +---<----+          &nb= sp;            &= nbsp;            = ;            &nb= sp;    ^
|  /         ^            &nb= sp;            &= nbsp;            = ;            &nb= sp;  |
| |          |ECN_S           &nbs= p;            &n= bsp;           ECN_R       |
V V          |            &nb= sp;            &= nbsp;           --------------> |
 S ---> S's access net ---> core ... core ---> R's access net ---> R

Where ECN_S and ECN_R are congestion notification channels from the respective access networks of the sender S and receiver R directly to S and R. I believe the proposal is currently agnostic to whether ECN_R is in-band or out-of-band, but clearly ECN_S must be out-of-band.

Is the stated problem solved by this proposal?
----------------------------------------------
The stated problem this proposal aims to solve is:
- congestion is mostly in access networks
- ECN sometimes does not get through certain middleboxes that do not support ECN.

I agree with both statements, but there seems to be a misconception in the document about what it means for a router, switch or middlebox to 'not support' ECN.

ECN incremental deployment design
---------------------------------
ECN was designed for incremental deployment where some, most or all routers or middleboxes do not do ECN marking. If both endpoints support ECN, they should be able to exchange packets between themselves that are ECN-capable (with an ECN-capable transport or ECT codepoint set) whatever network support there is for ECN between them.

ECN was designed so that network equipment that has not been upgraded to mark the ECN field during congestion would silently forward ECN-capable packets when not congested and drop them during congestion - no different to any non-ECN-capable packets with the ECN field cleared (Not-ECT).

Ways to 'not support' ECN
-------------------------
Network equipment can 'not support' ECN in three ways:
1) lacks ECN: not yet upgraded to do ECN marking.
2) prevents ECN (a bug): middlebox tampers with endpoint attempts to send ECN-capable packets. Three known sub-cases:
 2a) ECN-TCP drop: drops SYNs attempting to negotiate ECN in the TCP header
 2b) ECN-IP drop: drops packets with ECN-capable codepoint in IP header
 2c) ECN-IP normalise: reverts ECN-capable packets to Not-ECT in IP header
3) crashes with ECN (a bug): an endpoint attempt to negotiate ECN in the TCP header crashes a middlebox

Case 1) is normal and is by far the most prevalent. ECN's incremental deployment design (above) copes with this just fine.

Case 2) happens in a small number of cases:
* Until about 2005-6 there were a number of enterprise-grade firewalls and NATs that did this, but tests showed their rules got upgraded over time and it was no longer a problem.
* It is however still a problem with about five popular models of home gateway from those days that will take some time to be discarded from most homes.
* Recently, a new problem has appeared on paths that were previously OK. It is thought this may be a buggy attempt to zero the Diffserv codepoint, which is also accidentally clearing the ECN field in the IP header.

Case 3) happens in one known case of one model of a home gateway that was popularly deployed a few years ago.

Equipment on the path exhibiting Case 2) behaviour can be detected by ECN black-hole detection code on the end-system, reverting a flow to Not-ECT in order to get packets through. There are black-hole detection patches for Linux, but black-hole detection is not configured by default with the mainline code. The

The home gateway that crashes on seeing ECN in the TCP header of a SYN (Case 3) is more problematic. ECN is turned off by default for the client end of TCP connections in Windows and Linux because of this single popular bugged home gateway. It should be possible to do some heuristic test to detect if the offending model is on your home network (perhaps using uPNP or checking whether the MAC address falls within a known range). But AFAIK, no code is available to do this.

Again, is the stated problem solved by this proposal?
-----------------------------------------------------
The proposal seems to be focused particularly on 3GPP, where AFAIK there are no ECN deployment problems that are not under the control of the network operators who could upgrade and fix them quickly.

I believe that introducing a new way to signal ECN would encounter as many deployment problems, if not more, than persevering with deployment of the existing way to do ECN.

Is backward ECN a good idea anyway?
-----------------------------------
The backward messages I have termed ECN_S in your proposal are reminiscent of ICMP source quench messages. SQ was deprecated for a number of reasons that also all apply to your proposal:
* SQ violates layering (congestion control is assumed to be end to end in the Internet Architecture), so it can interact badly with IPsec encryption and tunneling, making it difficult to address the message back to the process on the host generating the load.
* ICMP packet creation is normally (always) implemented on the ingress interface of a router. Congestion is detected on the egress, where it is too late, and too expensive wrt. critical processing time, to trigger the creation and sending of an ICMP packet, without hugely re-working the implementation architecture of most routers.
* SQ creates more data (although admittedly in the other direction) during congestion, which is generally to be avoided.
* SQ may get lost, and there's no 'end-middle' reliable channel between source and bottleneck to recover losses.
* SQ messages can be maliciously sent to hosts as if they came from an on-path router, thus creating a DoS vulnerability. To solve this would require a complicated security association between the SQ message and the packet stream it refers to.
* SQ messages are invariably discarded by firewalls, mostly because they can be spoofed (previous point).

See < http://www.ietf.org/mail-archive/web/ternli/current/msg00036.html> for the history of ICMP SQ.

In summary, I don't believe your proposal is a good way to solve the problems it identifies.

Cheers


Bob

At 11:53 06/07/2010, Zhu Lei wrote:
Hi all,
 
We already had some discussions which may allow wireless access networks to notify congestions in mail list.
 
I personally think that Conex charter is asking some solutions by stating "However, the CONEX WG will initially focus on one use case, where the end hosts and the network that contains the destination end host are CONEX-enabled but other networks need not be."
 
I have an individual draft which introduces some ideas for next f2f meeting. I'd like to ask you to review this short document and help identify the problems which could be resolved in Conex wg. Thank you!
 
draft-lei-ecn-localised-congestion-notification-00
Hope have your feedback soon.
 
Best regards,
Lei Zhu

 
_______________________________________________
conex mailing list
conex@ietf.org
https://www.ietf.org/mailman/listinfo/conex

________________________________________________________________
Bob Briscoe,           &n= bsp;            =         BT Innovate & Design

________________________________________________________________
Bob Briscoe,           &n= bsp;            =         BT Innovate & Design --=====================_-1263048187==.ALT-- From mattmathis@google.com Fri Jul 16 13:17:58 2010 Return-Path: X-Original-To: conex@core3.amsl.com Delivered-To: conex@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 876243A6848 for ; Fri, 16 Jul 2010 13:17:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.977 X-Spam-Level: X-Spam-Status: No, score=-101.977 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, USER_IN_WHITELIST=-100] 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 DyeAk5x130u7 for ; Fri, 16 Jul 2010 13:17:57 -0700 (PDT) Received: from smtp-out.google.com (smtp-out.google.com [74.125.121.35]) by core3.amsl.com (Postfix) with ESMTP id 41B753A680F for ; Fri, 16 Jul 2010 13:17:57 -0700 (PDT) Received: from wpaz9.hot.corp.google.com (wpaz9.hot.corp.google.com [172.24.198.73]) by smtp-out.google.com with ESMTP id o6GKI8jH022266 for ; Fri, 16 Jul 2010 13:18:08 -0700 DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d=google.com; s=beta; t=1279311488; bh=ZdryazGRGzKg3TOueWPyter7Obc=; h=MIME-Version:In-Reply-To:References:Date:Message-ID:Subject:From: To:Cc:Content-Type:Content-Transfer-Encoding; b=rIjnl0OgToTeiaBOfRQlROuWwCOnVy6CmAQ6hxLR99d5utHM37u+B+wfyHqN74Mw9 HzcCw/qD+uqY5ZQ5K9NOg== DomainKey-Signature: a=rsa-sha1; s=beta; d=google.com; c=nofws; q=dns; h=mime-version:in-reply-to:references:date:message-id:subject:from:to: cc:content-type:content-transfer-encoding:x-system-of-record; b=TwH7nBPBCAEJpSO46vJHSrnkLAd6LCsz66Tn9LJ8NhWh4nkCd2AGQpKJX7zEP2g65 o29m9jJhp67allTaCGT7w== Received: from eyb7 (eyb7.prod.google.com [10.208.2.7]) by wpaz9.hot.corp.google.com with ESMTP id o6GKI6hG022887 for ; Fri, 16 Jul 2010 13:18:07 -0700 Received: by eyb7 with SMTP id 7so801330eyb.17 for ; Fri, 16 Jul 2010 13:18:06 -0700 (PDT) MIME-Version: 1.0 Received: by 10.213.3.83 with SMTP id 19mr1573055ebm.5.1279311486267; Fri, 16 Jul 2010 13:18:06 -0700 (PDT) Received: by 10.213.32.197 with HTTP; Fri, 16 Jul 2010 13:18:06 -0700 (PDT) In-Reply-To: <4C3DDDE8.4010702@it.uc3m.es> References: <4C3DDDE8.4010702@it.uc3m.es> Date: Fri, 16 Jul 2010 16:18:06 -0400 Message-ID: From: Matt Mathis To: marcelo bagnulo braun Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable X-System-Of-Record: true Cc: conex@ietf.org Subject: Re: [conex] draft agenda X-BeenThere: conex@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Congestion Exposure working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 16 Jul 2010 20:17:58 -0000 On Wed, Jul 14, 2010 at 11:55 AM, marcelo bagnulo braun wrote: > To all presenters, you MUST send us the slides before monday 26 july at 1= 700 > hrs., if not we won't be able to upload the material. According to http://www.ietf.org/meeting/cutoff-dates-2010.html#IETF78, the deadline is Friday AUG 27th.... Or am I missing something? Thanks, --MM-- The best way to predict the future is to create it. =A0- Peter Drucker From marcelo@it.uc3m.es Fri Jul 16 13:44:13 2010 Return-Path: X-Original-To: conex@core3.amsl.com Delivered-To: conex@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 8BE253A6B62 for ; Fri, 16 Jul 2010 13:44:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.385 X-Spam-Level: X-Spam-Status: No, score=-106.385 tagged_above=-999 required=5 tests=[AWL=0.214, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] 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 QisnpggaUDHH for ; Fri, 16 Jul 2010 13:44:12 -0700 (PDT) Received: from smtp01.uc3m.es (smtp01.uc3m.es [163.117.176.131]) by core3.amsl.com (Postfix) with ESMTP id 765BE3A6B55 for ; Fri, 16 Jul 2010 13:44:12 -0700 (PDT) X-uc3m-safe: yes Received: from marcelo-bagnulos-macbook-pro.local (79.30.18.95.dynamic.jazztel.es [95.18.30.79]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by smtp01.uc3m.es (Postfix) with ESMTP id D811CBE658B; Fri, 16 Jul 2010 22:44:22 +0200 (CEST) Message-ID: <4C40C4A6.80006@it.uc3m.es> Date: Fri, 16 Jul 2010 22:44:22 +0200 From: marcelo bagnulo braun User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.5; es-ES; rv:1.9.1.10) Gecko/20100512 Thunderbird/3.0.5 MIME-Version: 1.0 To: Matt Mathis References: <4C3DDDE8.4010702@it.uc3m.es> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit X-TM-AS-Product-Ver: IMSS-7.0.0.3116-6.0.0.1038-17510.000 Cc: conex@ietf.org Subject: Re: [conex] draft agenda X-BeenThere: conex@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Congestion Exposure working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 16 Jul 2010 20:44:13 -0000 That is for the proceedings, so that is the deadline for the minutes. We need to slides before the meeting, so that people can download them, hence the deadline Regards, marcelo El 16/07/10 22:18, Matt Mathis escribió: > On Wed, Jul 14, 2010 at 11:55 AM, marcelo bagnulo braun > wrote: > > >> To all presenters, you MUST send us the slides before monday 26 july at 1700 >> hrs., if not we won't be able to upload the material. >> > According to http://www.ietf.org/meeting/cutoff-dates-2010.html#IETF78, > the deadline is Friday AUG 27th.... > > Or am I missing something? > > Thanks, > --MM-- > The best way to predict the future is to create it. - Peter Drucker > > From lei.zhu@huawei.com Sun Jul 18 20:12:41 2010 Return-Path: X-Original-To: conex@core3.amsl.com Delivered-To: conex@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id D32703A69E0 for ; Sun, 18 Jul 2010 20:12:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 2.851 X-Spam-Level: ** X-Spam-Status: No, score=2.851 tagged_above=-999 required=5 tests=[AWL=0.047, BAYES_40=-0.185, FH_RELAY_NODNS=1.451, HELO_MISMATCH_COM=0.553, HTML_FONT_FACE_BAD=0.884, HTML_MESSAGE=0.001, RDNS_NONE=0.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 wj4TS8eKcqx3 for ; Sun, 18 Jul 2010 20:12:39 -0700 (PDT) Received: from szxga05-in.huawei.com (unknown [119.145.14.67]) by core3.amsl.com (Postfix) with ESMTP id 047473A6765 for ; Sun, 18 Jul 2010 20:12:35 -0700 (PDT) Received: from huawei.com (szxga05-in [172.24.2.49]) by szxga05-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0L5S00NKWBL24P@szxga05-in.huawei.com> for conex@ietf.org; Mon, 19 Jul 2010 11:12:38 +0800 (CST) Received: from huawei.com ([172.24.2.119]) by szxga05-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0L5S000L1BL1LH@szxga05-in.huawei.com> for conex@ietf.org; Mon, 19 Jul 2010 11:12:38 +0800 (CST) Received: from z41317 ([10.111.16.163]) by szxml04-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTPA id <0L5S00FM1BL0FW@szxml04-in.huawei.com> for conex@ietf.org; Mon, 19 Jul 2010 11:12:37 +0800 (CST) Date: Mon, 19 Jul 2010 11:12:36 +0800 From: Zhu Lei In-reply-to: <201007161145.o6GBjt6B026292@bagheera.jungle.bt.co.uk> To: 'Bob Briscoe' Message-id: <003501cb26f0$3d6cfb30$a3106f0a@china.huawei.com> MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2900.3350 X-Mailer: Microsoft Office Outlook 11 Content-type: multipart/alternative; boundary="Boundary_(ID_8/v4F0vVC9zw/9NdU4moLw)" Thread-index: Acsk3Hl/KropimNOR/eiWolwgA8wJQCEc3KA Cc: conex@ietf.org Subject: Re: [conex] An individual for your review X-BeenThere: conex@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Congestion Exposure working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 19 Jul 2010 03:12:42 -0000 This is a multi-part message in MIME format. --Boundary_(ID_8/v4F0vVC9zw/9NdU4moLw) Content-type: text/plain; charset=utf-8 Content-transfer-encoding: quoted-printable Hi, =20 If possible, I want to see more historical drafts related to the = crosslayer ideas and thoughts. =20 I think that S must be ECN enabled in any cases. It is important for = ECN_S knows it and is capable to notify access congestion by sending ECN = marks with TCP respones. =20 The problem meet is how to know possibilities to receive congestion = notification sent by access node(s) by UE. I personally want to oen it = for access network(e.g. link layer) in Conex working group. For example, = a statement would be useful for people working in access network who = know the ECN solution might be used to notifiy access network congestion = only. =20 Best regards, Zhu Lei _____ =20 =E5=8F=91=E4=BB=B6=E4=BA=BA: Bob Briscoe = [mailto:rbriscoe@jungle.bt.co.uk]=20 =E5=8F=91=E9=80=81=E6=97=B6=E9=97=B4: 2010=E5=B9=B47=E6=9C=8816=E6=97=A5 = 19:46 =E6=94=B6=E4=BB=B6=E4=BA=BA: Zhu Lei =E6=8A=84=E9=80=81: conex@ietf.org =E4=B8=BB=E9=A2=98: Re: [conex] An individual for your review Lei, The reason I said ECN_S must clearly be out of band is that, by = definition in-band means within the packets travelling from S to R. If you mean in-band in the packets travelling from R to S, the congested = node may not be on the route of packets between R and S, which need not = follow the reverse route of the forward path between S and R.=20 I think you will find that this expired I-D from Pasi Sarolahti is very = relevant: Transport-layer Considerations for Explicit Cross-layer Indications < = https://datatracker.ietf.org/doc/draft-sarolahti-tsvwg-crosslayer/ > Bob At 08:47 16/07/2010, Zhu Lei wrote: Hi Bob and all, =20 Thank you for identifing some problems of ECN, especially mentioned some = historical technical discussions which I never heard previously. =20 The problems of ECN at the moment are clearly summerised and clarified = by Bob. I should follow the directions together with issues which is to = be solved. =20 I have to say the understanding of the "proposal" is mainly correct. I = highly appreciate the draft proposal and problem statement in previous = e-mail. We at least need some statement in use cases draft. =20 The possible technical proposal of my mind is little bit different from = the picture. The major difference is that the ECN_S could be not = out-of-band. And, I also don't think that the ICMP is the approach. I = personlly want the in-band trasnportation of ECN mark. =20 The document seems hint the proposal, but the intention of the submitted = document is to introduce the requirements. I would try to write a = technical proposal in ML soon. The slides for presentation take me time = due to my native language. =20 I appologize for some delay of replying e-mail since I should have some = works for internal guys in parallel. =20 Best regards, Lei _____ =20 =C2=B7=C2=A2=C2=BC=C3=BE=C3=88=C3=8B: Bob Briscoe [ = mailto:rbriscoe@jungle.bt.co.uk]=20 =C2=B7=C2=A2=C3=8B=C3=8D=C3=8A=C2=B1=C2=BC=C3=A4: = 2010=C3=84=C3=AA7=C3=94=C3=8214=C3=88=C3=95 17:55 =C3=8A=C3=95=C2=BC=C3=BE=C3=88=C3=8B: Zhu Lei =C2=B3=C2=AD=C3=8B=C3=8D: conex@ietf.org =C3=96=C3=B7=C3=8C=C3=A2: Re: [conex] An individual for your review Zhu, Hi. I read your individual draft last night. draft-lei-ecn-localised-congestion-notification-00 First, we should be clear that working on new data plane congestion = notification technology is not part of the ConEx charter. So, those = focusing solely on the charter can stop reading now if they want.=20 But I want to briefly review your proposal anyway, mainly to record on = the mailing list what I believe is the current status of ECN deployment = problems. If I can summarise your proposal, I believe the main proposed new = requirement is that we should work on a congestion notification = architecture that looks something like this: +--------------------------------------------------------------<---+ | +---<----+ ^ | / ^ | | | |ECN_S ECN_R | V V | --------------> | S ---> S's access net ---> core ... core ---> R's access net ---> R Where ECN_S and ECN_R are congestion notification channels from the = respective access networks of the sender S and receiver R directly to S = and R. I believe the proposal is currently agnostic to whether ECN_R is = in-band or out-of-band, but clearly ECN_S must be out-of-band. Is the stated problem solved by this proposal? ---------------------------------------------- The stated problem this proposal aims to solve is: - congestion is mostly in access networks - ECN sometimes does not get through certain middleboxes that do not = support ECN. I agree with both statements, but there seems to be a misconception in = the document about what it means for a router, switch or middlebox to = 'not support' ECN.=20 ECN incremental deployment design --------------------------------- ECN was designed for incremental deployment where some, most or all = routers or middleboxes do not do ECN marking. If both endpoints support = ECN, they should be able to exchange packets between themselves that are = ECN-capable (with an ECN-capable transport or ECT codepoint set) = whatever network support there is for ECN between them. ECN was designed so that network equipment that has not been upgraded to = mark the ECN field during congestion would silently forward ECN-capable = packets when not congested and drop them during congestion - no = different to any non-ECN-capable packets with the ECN field cleared = (Not-ECT). Ways to 'not support' ECN ------------------------- Network equipment can 'not support' ECN in three ways: 1) lacks ECN: not yet upgraded to do ECN marking. 2) prevents ECN (a bug): middlebox tampers with endpoint attempts to = send ECN-capable packets. Three known sub-cases: 2a) ECN-TCP drop: drops SYNs attempting to negotiate ECN in the TCP = header 2b) ECN-IP drop: drops packets with ECN-capable codepoint in IP header 2c) ECN-IP normalise: reverts ECN-capable packets to Not-ECT in IP = header 3) crashes with ECN (a bug): an endpoint attempt to negotiate ECN in the = TCP header crashes a middlebox Case 1) is normal and is by far the most prevalent. ECN's incremental = deployment design (above) copes with this just fine. Case 2) happens in a small number of cases: * Until about 2005-6 there were a number of enterprise-grade firewalls = and NATs that did this, but tests showed their rules got upgraded over = time and it was no longer a problem.=20 * It is however still a problem with about five popular models of home = gateway from those days that will take some time to be discarded from = most homes.=20 * Recently, a new problem has appeared on paths that were previously OK. = It is thought this may be a buggy attempt to zero the Diffserv = codepoint, which is also accidentally clearing the ECN field in the IP = header. Case 3) happens in one known case of one model of a home gateway that = was popularly deployed a few years ago. Equipment on the path exhibiting Case 2) behaviour can be detected by = ECN black-hole detection code on the end-system, reverting a flow to = Not-ECT in order to get packets through. There are black-hole detection = patches for Linux, but black-hole detection is not configured by default = with the mainline code. The=20 The home gateway that crashes on seeing ECN in the TCP header of a SYN = (Case 3) is more problematic. ECN is turned off by default for the = client end of TCP connections in Windows and Linux because of this = single popular bugged home gateway. It should be possible to do some = heuristic test to detect if the offending model is on your home network = (perhaps using uPNP or checking whether the MAC address falls within a = known range). But AFAIK, no code is available to do this. Again, is the stated problem solved by this proposal? ----------------------------------------------------- The proposal seems to be focused particularly on 3GPP, where AFAIK there = are no ECN deployment problems that are not under the control of the = network operators who could upgrade and fix them quickly. I believe that introducing a new way to signal ECN would encounter as = many deployment problems, if not more, than persevering with deployment = of the existing way to do ECN. Is backward ECN a good idea anyway? ----------------------------------- The backward messages I have termed ECN_S in your proposal are = reminiscent of ICMP source quench messages. SQ was deprecated for a = number of reasons that also all apply to your proposal: * SQ violates layering (congestion control is assumed to be end to end = in the Internet Architecture), so it can interact badly with IPsec = encryption and tunneling, making it difficult to address the message = back to the process on the host generating the load.=20 * ICMP packet creation is normally (always) implemented on the ingress = interface of a router. Congestion is detected on the egress, where it is = too late, and too expensive wrt. critical processing time, to trigger = the creation and sending of an ICMP packet, without hugely re-working = the implementation architecture of most routers. * SQ creates more data (although admittedly in the other direction) = during congestion, which is generally to be avoided. * SQ may get lost, and there's no 'end-middle' reliable channel between = source and bottleneck to recover losses. * SQ messages can be maliciously sent to hosts as if they came from an = on-path router, thus creating a DoS vulnerability. To solve this would = require a complicated security association between the SQ message and = the packet stream it refers to. * SQ messages are invariably discarded by firewalls, mostly because they = can be spoofed (previous point). See < http://www.ietf.org/mail-archive/web/ternli/current/msg00036.html> = for the history of ICMP SQ. In summary, I don't believe your proposal is a good way to solve the = problems it identifies. Cheers Bob At 11:53 06/07/2010, Zhu Lei wrote: Hi all, =20 We already had some discussions which may allow wireless access networks = to notify congestions in mail list.=20 =20 I personally think that Conex charter is asking some solutions by = stating "However, the CONEX WG will initially focus on one use case, = where the end hosts and the network that contains the destination end = host are CONEX-enabled but other networks need not be."=20 =20 I have an individual draft which introduces some ideas for next f2f = meeting. I'd like to ask you to review this short document and help = identify the problems which could be resolved in Conex wg. Thank you! =20 draft-lei-ecn-localised-congestion-notification-00 Hope have your feedback soon. =20 Best regards, Lei Zhu =20 _______________________________________________ conex mailing list conex@ietf.org https://www.ietf.org/mailman/listinfo/conex ________________________________________________________________ Bob Briscoe, BT Innovate & Design=20 ________________________________________________________________ Bob Briscoe, BT Innovate & Design=20 --Boundary_(ID_8/v4F0vVC9zw/9NdU4moLw) Content-type: text/html; charset=utf-8 Content-transfer-encoding: quoted-printable =EF=BB=BF

Hi,
 
If possible, I want to see more historical = drafts=20 related to the crosslayer ideas and thoughts.
 
I think that S must be ECN enabled in any = cases. It is=20 important for ECN_S knows it and is capable to notify access congestion = by=20 sending ECN marks with TCP respones.
 
The problem = meet is how to=20 know possibilities to receive congestion notification sent by access=20 node(s) by UE. I personally want to oen it for access=20 network(e.g. link layer) in Conex working group. For example, a = statement would=20 be useful for people working in access network who know the ECN solution = might=20 be used to notifiy access network congestion only.
 
Best regards,
Zhu=20 Lei

=E5=8F=91=E4=BB=B6=E4=BA=BA: Bob Briscoe = [mailto:rbriscoe@jungle.bt.co.uk]=20
=E5=8F=91=E9=80=81=E6=97=B6=E9=97=B4: = 2010=E5=B9=B47=E6=9C=8816=E6=97=A5 = 19:46
=E6=94=B6=E4=BB=B6=E4=BA=BA: Zhu = Lei
=E6=8A=84=E9=80=81:=20 conex@ietf.org
=E4=B8=BB=E9=A2=98: Re: [conex] An individual = for your=20 review

Lei,

The reason I said ECN_S must clearly be out of = band is=20 that, by definition in-band means within the packets travelling from S = to=20 R.

If you mean in-band in the packets travelling from R to S, the = congested node may not be on the route of packets between R and S, which = need=20 not follow the reverse route of the forward path between S and R. =

I=20 think you will find that this expired I-D from Pasi Sarolahti is very=20 relevant:
Transport-layer Considerations for Explicit Cross-layer=20 Indications
<=20 https://datatracker.ietf.org/doc/draft-sarolahti-tsvwg-crosslayer/=20 >


Bob

At 08:47 16/07/2010, Zhu Lei wrote:
Hi Bob=20 and all,
 
Thank you = for=20 identifing some problems of ECN, especially mentioned some historical=20 technical discussions which I never heard=20 previously.
 
The = problems of ECN=20 at the moment are clearly summerised and clarified by Bob. I should = follow the=20 directions together with issues which is to be=20 solved.
 
I have to = say the=20 understanding of the "proposal" is mainly correct. I highly appreciate = the=20 draft proposal and problem statement in previous e-mail. We at least = need some=20 statement in use cases draft.
 
The possible technical proposal of my mind is little bit = different from=20 the picture. The major difference is that the ECN_S could be not = out-of-band.=20 And, I also don't think that the ICMP is the approach. I personlly = want the=20 in-band trasnportation of ECN mark.
 
The document seems hint the proposal, but the intention of = the=20 submitted document is to introduce the requirements. I would try to = write a=20 technical proposal in ML soon. The slides for presentation take me = time due to=20 my native language.
 
I=20 appologize for some delay of replying e-mail since I should have some = works=20 for internal guys in parallel.
 
Best regards,
Lei


=C2=B7=C2=A2=C2=BC=C3=BE=C3=88=C3=8B: Bob = Briscoe [=20 mailto:rbriscoe@jungle.bt.co.uk] =
=C2=B7=C2=A2=C3=8B=C3=8D=C3=8A=C2=B1=C2=BC=C3=A4: = 2010=C3=84=C3=AA7=C3=94=C3=8214=C3=88=C3=95=20 17:55
=C3=8A=C3=95=C2=BC=C3=BE=C3=88=C3=8B: Zhu = Lei
=C2=B3­=C3=8B=C3=8D:=20 conex@ietf.org
=C3=96=C3=B7=C3=8C=C3=A2: Re: [conex] An = individual for your=20 review

Zhu,

Hi. I read your individual draft last = = night.
draft-lei-ecn-localised-congestion-notification-00

First= , we=20 should be clear that working on new data plane congestion notification = technology is not part of the ConEx charter. So, those focusing solely = on the=20 charter can stop reading now if they want.

But I want to = briefly=20 review your proposal anyway, mainly to record on the mailing list what = I=20 believe is the current status of ECN deployment problems.

If I = can=20 summarise your proposal, I believe the main proposed new requirement = is that=20 we should work on a congestion notification architecture that looks = something=20 like=20 = this:

+-----------------------------------------------------------= ---<---+
|  =20 = +---<----+          =             &= nbsp;           &n= bsp;           &nb= sp;     =20 ^
|  /        =20 = ^            =             &= nbsp;           &n= bsp;           &nb= sp;   =20 |
| |         =20 = |ECN_S           &= nbsp;           &n= bsp;           =20 ECN_R       |
V=20 V         =20 = |            =             &= nbsp;           =20 --------------> |
 S ---> S's access net ---> core = ... core=20 ---> R's access net ---> R

Where ECN_S and ECN_R are = congestion=20 notification channels from the respective access networks of the = sender S and=20 receiver R directly to S and R. I believe the proposal is currently = agnostic=20 to whether ECN_R is in-band or out-of-band, but clearly ECN_S must be=20 out-of-band.

Is the stated problem solved by this=20 proposal?
----------------------------------------------
The = stated=20 problem this proposal aims to solve is:
- congestion is mostly in = access=20 networks
- ECN sometimes does not get through certain middleboxes = that do=20 not support ECN.

I agree with both statements, but there seems = to be a=20 misconception in the document about what it means for a router, switch = or=20 middlebox to 'not support' ECN.

ECN incremental deployment=20 design
---------------------------------
ECN was designed for=20 incremental deployment where some, most or all routers or middleboxes = do not=20 do ECN marking. If both endpoints support ECN, they should be able to = exchange=20 packets between themselves that are ECN-capable (with an ECN-capable = transport=20 or ECT codepoint set) whatever network support there is for ECN = between=20 them.

ECN was designed so that network equipment that has not = been=20 upgraded to mark the ECN field during congestion would silently = forward=20 ECN-capable packets when not congested and drop them during congestion = - no=20 different to any non-ECN-capable packets with the ECN field cleared=20 (Not-ECT).

Ways to 'not support'=20 ECN
-------------------------
Network equipment can 'not = support' ECN in=20 three ways:
1) lacks ECN: not yet upgraded to do ECN marking.
2) = prevents ECN (a bug): middlebox tampers with endpoint attempts to send = ECN-capable packets. Three known sub-cases:
 2a) ECN-TCP drop: = drops=20 SYNs attempting to negotiate ECN in the TCP header
 2b) ECN-IP = drop:=20 drops packets with ECN-capable codepoint in IP header
 2c) = ECN-IP=20 normalise: reverts ECN-capable packets to Not-ECT in IP header
3) = crashes=20 with ECN (a bug): an endpoint attempt to negotiate ECN in the TCP = header=20 crashes a middlebox

Case 1) is normal and is by far the most = prevalent.=20 ECN's incremental deployment design (above) copes with this just=20 fine.

Case 2) happens in a small number of cases:
* Until = about=20 2005-6 there were a number of enterprise-grade firewalls and NATs that = did=20 this, but tests showed their rules got upgraded over time and it was = no longer=20 a problem.
* It is however still a problem with about five popular = models=20 of home gateway from those days that will take some time to be = discarded from=20 most homes.
* Recently, a new problem has appeared on paths that = were=20 previously OK. It is thought this may be a buggy attempt to zero the = Diffserv=20 codepoint, which is also accidentally clearing the ECN field in the IP = header.

Case 3) happens in one known case of one model of a = home=20 gateway that was popularly deployed a few years ago.

Equipment = on the=20 path exhibiting Case 2) behaviour can be detected by ECN black-hole = detection=20 code on the end-system, reverting a flow to Not-ECT in order to get = packets=20 through. There are black-hole detection patches for Linux, but = black-hole=20 detection is not configured by default with the mainline code. The =

The=20 home gateway that crashes on seeing ECN in the TCP header of a SYN = (Case 3) is=20 more problematic. ECN is turned off by default for the client end of = TCP=20 connections in Windows and Linux because of this single popular bugged = home=20 gateway. It should be possible to do some heuristic test to detect if = the=20 offending model is on your home network (perhaps using uPNP or = checking=20 whether the MAC address falls within a known range). But AFAIK, no = code is=20 available to do this.

Again, is the stated problem solved by = this=20 = proposal?
-----------------------------------------------------
The= =20 proposal seems to be focused particularly on 3GPP, where AFAIK there = are no=20 ECN deployment problems that are not under the control of the network=20 operators who could upgrade and fix them quickly.

I believe = that=20 introducing a new way to signal ECN would encounter as many deployment = problems, if not more, than persevering with deployment of the = existing way to=20 do ECN.

Is backward ECN a good idea=20 anyway?
-----------------------------------
The backward = messages I have=20 termed ECN_S in your proposal are reminiscent of ICMP source quench = messages.=20 SQ was deprecated for a number of reasons that also all apply to your=20 proposal:
* SQ violates layering (congestion control is assumed = to be=20 end to end in the Internet Architecture), so it can interact badly = with IPsec=20 encryption and tunneling, making it difficult to address the message = back to=20 the process on the host generating the load.
* ICMP packet = creation is=20 normally (always) implemented on the ingress interface of a router. = Congestion=20 is detected on the egress, where it is too late, and too expensive = wrt.=20 critical processing time, to trigger the creation and sending of an = ICMP=20 packet, without hugely re-working the implementation architecture of = most=20 routers.
* SQ creates more data (although admittedly in the other=20 direction) during congestion, which is generally to be avoided.
* = SQ may=20 get lost, and there's no 'end-middle' reliable channel between source = and=20 bottleneck to recover losses.
* SQ messages can be maliciously sent = to=20 hosts as if they came from an on-path router, thus creating a DoS=20 vulnerability. To solve this would require a complicated security = association=20 between the SQ message and the packet stream it refers to.
* SQ = messages=20 are invariably discarded by firewalls, mostly because they can be = spoofed=20 (previous point).

See < http://www.ietf.org/mail-archive/web/ternli/current/ms= g00036.html>=20 for the history of ICMP SQ.

In summary, I don't believe your = proposal=20 is a good way to solve the problems it=20 identifies.

Cheers


Bob

At 11:53 06/07/2010, = Zhu Lei=20 wrote:
Hi=20 all,
 
We already had some = discussions which=20 may allow wireless access networks to notify congestions in mail = list.=20
 
I personally think that Conex = charter is=20 asking some solutions by stating "However, the CONEX WG will = initially focus=20 on one use case, where the end hosts and the network that contains = the=20 destination end host are CONEX-enabled but other networks need not = be."=20
 
I have an individual draft which = introduces some ideas for next f2f meeting. I'd like to ask you to = review=20 this short document and help identify the problems which could be = resolved=20 in Conex wg. Thank you!
 
draft-lei-ecn-localised-congestion-notification-00
Hope = have your=20 feedback soon.
 
Best = regards,
Lei=20 = Zhu

 
_____________________________________________= __
conex=20 mailing list
conex@ietf.org
https://www.ietf.org/mailman/listinfo/conex
_______________________________________________________________= _
Bob=20 = Briscoe,           = ;            =         =20 BT Innovate & Design

___________________________________________________________= _____
Bob=20 Briscoe,           = ;            =         =20 BT Innovate & Design

--Boundary_(ID_8/v4F0vVC9zw/9NdU4moLw)-- From rbriscoe@jungle.bt.co.uk Mon Jul 19 11:41:06 2010 Return-Path: X-Original-To: conex@core3.amsl.com Delivered-To: conex@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 860273A67A1 for ; Mon, 19 Jul 2010 11:41:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.662 X-Spam-Level: X-Spam-Status: No, score=-0.662 tagged_above=-999 required=5 tests=[AWL=0.058, BAYES_00=-2.599, DNS_FROM_RFC_BOGUSMX=1.482, HTML_MESSAGE=0.001, MIME_QP_LONG_LINE=1.396, 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 Uoa1N26uURuB for ; Mon, 19 Jul 2010 11:40:58 -0700 (PDT) Received: from smtp1.smtp.bt.com (smtp1.smtp.bt.com [217.32.164.137]) by core3.amsl.com (Postfix) with ESMTP id 5BE713A6B36 for ; Mon, 19 Jul 2010 11:40:56 -0700 (PDT) Received: from i2kc06-ukbr.domain1.systemhost.net ([193.113.197.70]) by smtp1.smtp.bt.com with Microsoft SMTPSVC(6.0.3790.4675); Mon, 19 Jul 2010 19:41:10 +0100 Received: from cbibipnt05.iuser.iroot.adidom.com ([147.149.196.177]) by i2kc06-ukbr.domain1.systemhost.net with Microsoft SMTPSVC(6.0.3790.4675); Mon, 19 Jul 2010 19:41:10 +0100 Received: From bagheera.jungle.bt.co.uk ([132.146.168.158]) by cbibipnt05.iuser.iroot.adidom.com (WebShield SMTP v4.5 MR1a P0803.399); id 1279564868771; Mon, 19 Jul 2010 19:41:08 +0100 Received: from MUT.jungle.bt.co.uk ([10.215.130.87]) by bagheera.jungle.bt.co.uk (8.13.5/8.12.8) with ESMTP id o6JIf79B003548; Mon, 19 Jul 2010 19:41:07 +0100 Message-Id: <201007191841.o6JIf79B003548@bagheera.jungle.bt.co.uk> X-Mailer: QUALCOMM Windows Eudora Version 7.1.0.9 Date: Mon, 19 Jul 2010 19:40:51 +0100 To: Zhu Lei From: Bob Briscoe In-Reply-To: <003501cb26f0$3d6cfb30$a3106f0a@china.huawei.com> References: <201007161145.o6GBjt6B026292@bagheera.jungle.bt.co.uk> <003501cb26f0$3d6cfb30$a3106f0a@china.huawei.com> Mime-Version: 1.0 Content-Type: multipart/alternative; boundary="=====================_8220690==.ALT" X-Scanned-By: MIMEDefang 2.56 on 132.146.168.158 X-OriginalArrivalTime: 19 Jul 2010 18:41:10.0146 (UTC) FILETIME=[F4C3EE20:01CB2771] Cc: conex@ietf.org Subject: Re: [conex] An individual for your review X-BeenThere: conex@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Congestion Exposure working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 19 Jul 2010 18:41:06 -0000 --=====================_8220690==.ALT Content-Type: text/plain; charset="iso-8859-1"; format=flowed Content-Transfer-Encoding: quoted-printable Lei, At 04:12 19/07/2010, Zhu Lei wrote: >=EF=BB=BF >Hi, > >If possible, I want to see more historical=20 >drafts related to the crosslayer ideas and thoughts. The refs in Pasi's draft cover all I know of, AFAIK. >I think that S must be ECN enabled in any cases.=20 >It is important for ECN_S knows it and is=20 >capable to notify access congestion by sending ECN marks with TCP respones. I agree that the current design cannot use ECN in=20 a flow of packets for which the sender is ECN-capable but the receiver is= not. But I don't believe it will make deployment any=20 easier if we introduce backward ECN_S feedback.=20 Then packets will have to signal whether the=20 router should do forward or backward feedback.=20 Because a router must not do both, otherwise it=20 will double the amount of congestion signalled.=20 We don't have room in the packet to switch=20 between forward and backward feedback. And if we=20 did take a new approach, it would require another=20 decade to wait for routers to be deployed that understand this new feature. If deployment is taking a long time, we need to=20 understand *why* before proposing changes that=20 will make deployment take even longer and be more complicated. But most importantly, I listed problems with=20 backward feedback, which ALL must to be solved=20 first. And they are ALL very good reasons against=20 backward feedback. So please address them all before taking this further. > >The problem meet is how to know possibilities to=20 >receive congestion notification sent by access=20 >node(s) by UE. I personally want to oen it for=20 >access network(e.g. link layer) in Conex working group. The ConEx group is not chartered to work on=20 changes to ECN. Chartering is a careful process=20 that takes account of everyone's views and=20 results in a precise set of work items. >For example, a statement would be useful for=20 >people working in access network who know the=20 >ECN solution might be used to notifiy access network congestion only. I wrote my my original review email very=20 carefully to explain how ECN incremental=20 deployment is designed to work (to save you=20 reading RFC3168). There is nothing in the=20 original ECN design to stop only access network=20 nodes being ECN enabled and other network nodes=20 not being ECN enabled. Indeed, that's how I would=20 expect ECN to be deployed first - by enabling ECN=20 on the nodes that are most likely to be congested. Then, if there is any unexpected congestion (e.g.=20 in the core), the endpoints will see the drop=20 from that, as well as ECN markings from the access networks. As I said, the problem (at least as stated in=20 your draft) is already solved by the original design of ECN. Bob > >Best regards, >Zhu Lei > > >---------- >=E5=8F=91=E4=BB=B6=E4=BA=BA: Bob Briscoe [mailto:rbriscoe@jungle.bt.co.uk] >=E5=8F=91=E9=80=81=E6=97=B6=E9=97=B4: 2010=E5=B9=B47=E6=9C=8816=E6=97=A5= 19:46 >=E6=94=B6=E4=BB=B6=E4=BA=BA: Zhu Lei >=E6=8A=84=E9=80=81: conex@ietf.org >=E4=B8=BB=E9=A2=98: Re: [conex] An individual for your review > >Lei, > >The reason I said ECN_S must clearly be out of=20 >band is that, by definition in-band means within=20 >the packets travelling from S to R. > >If you mean in-band in the packets travelling=20 >from R to S, the congested node may not be on=20 >the route of packets between R and S, which need=20 >not follow the reverse route of the forward path between S and R. > >I think you will find that this expired I-D from=20 >Pasi Sarolahti is very relevant: >Transport-layer Considerations for Explicit Cross-layer Indications >< https://datatracker.ietf.org/doc/draft-sarolahti-tsvwg-crosslayer/ > > > >Bob > >At 08:47 16/07/2010, Zhu Lei wrote: >>Hi Bob and all, >> >>Thank you for identifing some problems of ECN,=20 >>especially mentioned some historical technical=20 >>discussions which I never heard previously. >> >>The problems of ECN at the moment are clearly=20 >>summerised and clarified by Bob. I should=20 >>follow the directions together with issues which is to be solved. >> >>I have to say the understanding of the=20 >>"proposal" is mainly correct. I highly=20 >>appreciate the draft proposal and problem=20 >>statement in previous e-mail. We at least need=20 >>some statement in use cases draft. >> >>The possible technical proposal of my mind is=20 >>little bit different from the picture. The=20 >>major difference is that the ECN_S could be not=20 >>out-of-band. And, I also don't think that the=20 >>ICMP is the approach. I personlly want the in-band trasnportation of ECN= mark. >> >>The document seems hint the proposal, but the=20 >>intention of the submitted document is to=20 >>introduce the requirements. I would try to=20 >>write a technical proposal in ML soon. The=20 >>slides for presentation take me time due to my native language. >> >>I appologize for some delay of replying e-mail=20 >>since I should have some works for internal guys in parallel. >> >>Best regards, >>Lei >> >> >> >>---------- >>=C2=B7=C2=A2=C2=BC=C3=BE=C3=88=C3=8B: Bob Briscoe [= mailto:rbriscoe@jungle.bt.co.uk] >>=C2=B7=C2=A2=C3=8B=C3=8D=C3=8A=C2=B1=C2=BC=C3=A4: 2010=C3=84=C3=AA7=C3=94= =C3=8214=C3=88=C3=95 17:55 >>=C3=8A=C3=95=C2=BC=C3=BE=C3=88=C3=8B: Zhu Lei >>=C2=B3=AD=C3=8B=C3=8D: conex@ietf.org >>=C3=96=C3=B7=C3=8C=C3=A2: Re: [conex] An individual for your review >> >>Zhu, >> >>Hi. I read your individual draft last night. >>draft-lei-ecn-localised-congestion-notification-00 >> >>First, we should be clear that working on new=20 >>data plane congestion notification technology=20 >>is not part of the ConEx charter. So, those=20 >>focusing solely on the charter can stop reading now if they want. >> >>But I want to briefly review your proposal=20 >>anyway, mainly to record on the mailing list=20 >>what I believe is the current status of ECN deployment problems. >> >>If I can summarise your proposal, I believe the=20 >>main proposed new requirement is that we should=20 >>work on a congestion notification architecture that looks something like= this: >> >>+--------------------------------------------------------------<---+ >>| +---<----+ ^ >>| / ^ | >>| | |ECN_S ECN_R | >>V V | --------------> | >> S ---> S's access net ---> core ... core ---> R's access net ---> R >> >>Where ECN_S and ECN_R are congestion=20 >>notification channels from the respective=20 >>access networks of the sender S and receiver R=20 >>directly to S and R. I believe the proposal is=20 >>currently agnostic to whether ECN_R is in-band=20 >>or out-of-band, but clearly ECN_S must be out-of-band. >> >>Is the stated problem solved by this proposal? >>---------------------------------------------- >>The stated problem this proposal aims to solve is: >>- congestion is mostly in access networks >>- ECN sometimes does not get through certain=20 >>middleboxes that do not support ECN. >> >>I agree with both statements, but there seems=20 >>to be a misconception in the document about=20 >>what it means for a router, switch or middlebox to 'not support' ECN. >> >>ECN incremental deployment design >>--------------------------------- >>ECN was designed for incremental deployment=20 >>where some, most or all routers or middleboxes=20 >>do not do ECN marking. If both endpoints=20 >>support ECN, they should be able to exchange=20 >>packets between themselves that are ECN-capable=20 >>(with an ECN-capable transport or ECT codepoint=20 >>set) whatever network support there is for ECN between them. >> >>ECN was designed so that network equipment that=20 >>has not been upgraded to mark the ECN field=20 >>during congestion would silently forward=20 >>ECN-capable packets when not congested and drop=20 >>them during congestion - no different to any=20 >>non-ECN-capable packets with the ECN field cleared (Not-ECT). >> >>Ways to 'not support' ECN >>------------------------- >>Network equipment can 'not support' ECN in three ways: >>1) lacks ECN: not yet upgraded to do ECN marking. >>2) prevents ECN (a bug): middlebox tampers with=20 >>endpoint attempts to send ECN-capable packets. Three known sub-cases: >> 2a) ECN-TCP drop: drops SYNs attempting to negotiate ECN in the TCP= header >> 2b) ECN-IP drop: drops packets with ECN-capable codepoint in IP header >> 2c) ECN-IP normalise: reverts ECN-capable packets to Not-ECT in IP= header >>3) crashes with ECN (a bug): an endpoint=20 >>attempt to negotiate ECN in the TCP header crashes a middlebox >> >>Case 1) is normal and is by far the most=20 >>prevalent. ECN's incremental deployment design=20 >>(above) copes with this just fine. >> >>Case 2) happens in a small number of cases: >>* Until about 2005-6 there were a number of=20 >>enterprise-grade firewalls and NATs that did=20 >>this, but tests showed their rules got upgraded=20 >>over time and it was no longer a problem. >>* It is however still a problem with about five=20 >>popular models of home gateway from those days=20 >>that will take some time to be discarded from most homes. >>* Recently, a new problem has appeared on paths=20 >>that were previously OK. It is thought this may=20 >>be a buggy attempt to zero the Diffserv=20 >>codepoint, which is also accidentally clearing the ECN field in the IP= header. >> >>Case 3) happens in one known case of one model=20 >>of a home gateway that was popularly deployed a few years ago. >> >>Equipment on the path exhibiting Case 2)=20 >>behaviour can be detected by ECN black-hole=20 >>detection code on the end-system, reverting a=20 >>flow to Not-ECT in order to get packets=20 >>through. There are black-hole detection patches=20 >>for Linux, but black-hole detection is not=20 >>configured by default with the mainline code. The >> >>The home gateway that crashes on seeing ECN in=20 >>the TCP header of a SYN (Case 3) is more=20 >>problematic. ECN is turned off by default for=20 >>the client end of TCP connections in Windows=20 >>and Linux because of this single popular bugged=20 >>home gateway. It should be possible to do some=20 >>heuristic test to detect if the offending model=20 >>is on your home network (perhaps using uPNP or=20 >>checking whether the MAC address falls within a=20 >>known range). But AFAIK, no code is available to do this. >> >>Again, is the stated problem solved by this proposal? >>----------------------------------------------------- >>The proposal seems to be focused particularly=20 >>on 3GPP, where AFAIK there are no ECN=20 >>deployment problems that are not under the=20 >>control of the network operators who could upgrade and fix them quickly. >> >>I believe that introducing a new way to signal=20 >>ECN would encounter as many deployment=20 >>problems, if not more, than persevering with=20 >>deployment of the existing way to do ECN. >> >>Is backward ECN a good idea anyway? >>----------------------------------- >>The backward messages I have termed ECN_S in=20 >>your proposal are reminiscent of ICMP source=20 >>quench messages. SQ was deprecated for a number=20 >>of reasons that also all apply to your proposal: >>* SQ violates layering (congestion control is=20 >>assumed to be end to end in the Internet=20 >>Architecture), so it can interact badly with=20 >>IPsec encryption and tunneling, making it=20 >>difficult to address the message back to the=20 >>process on the host generating the load. >>* ICMP packet creation is normally (always)=20 >>implemented on the ingress interface of a=20 >>router. Congestion is detected on the egress,=20 >>where it is too late, and too expensive wrt.=20 >>critical processing time, to trigger the=20 >>creation and sending of an ICMP packet, without=20 >>hugely re-working the implementation architecture of most routers. >>* SQ creates more data (although admittedly in=20 >>the other direction) during congestion, which is generally to be avoided. >>* SQ may get lost, and there's no 'end-middle'=20 >>reliable channel between source and bottleneck to recover losses. >>* SQ messages can be maliciously sent to hosts=20 >>as if they came from an on-path router, thus=20 >>creating a DoS vulnerability. To solve this=20 >>would require a complicated security=20 >>association between the SQ message and the packet stream it refers to. >>* SQ messages are invariably discarded by=20 >>firewalls, mostly because they can be spoofed (previous point). >> >>See <=20 >>http://www.ietf.org/mail-archive/web/ternli/current/msg00036.html>=20 >>for the history of ICMP SQ. >> >>In summary, I don't believe your proposal is a=20 >>good way to solve the problems it identifies. >> >>Cheers >> >> >>Bob >> >>At 11:53 06/07/2010, Zhu Lei wrote: >>>Hi all, >>> >>>We already had some discussions which may=20 >>>allow wireless access networks to notify congestions in mail list. >>> >>>I personally think that Conex charter is=20 >>>asking some solutions by stating "However, the=20 >>>CONEX WG will initially focus on one use case,=20 >>>where the end hosts and the network that=20 >>>contains the destination end host are=20 >>>CONEX-enabled but other networks need not be." >>> >>>I have an individual draft which introduces=20 >>>some ideas for next f2f meeting. I'd like to=20 >>>ask you to review this short document and help=20 >>>identify the problems which could be resolved in Conex wg. Thank you! >>> >>>draft-lei-ecn-localised-congestion-notification-00 >>>Hope have your feedback soon. >>> >>>Best regards, >>>Lei Zhu >>> >>> >>>_______________________________________________ >>>conex mailing list >>>conex@ietf.org >>>https://www.ietf.org/mailman/listinfo/conex >> >>________________________________________________________________ >>Bob Briscoe, BT Innovate & Design > >________________________________________________________________ >Bob Briscoe, BT Innovate & Design ________________________________________________________________ Bob Briscoe, BT Innovate & Design=20 --=====================_8220690==.ALT Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Lei,

At 04:12 19/07/2010, Zhu Lei wrote:
=EF=BB=BF
Hi,
 
If possible, I want to see more historical drafts related to the crosslayer ideas and thoughts.

The refs in Pasi's draft cover all I know of, AFAIK.

I think that S must be ECN enabled in any cases. It is important for ECN_S knows it and is capable to notify access congestion by sending ECN marks with TCP respones.

I agree that the current design cannot use ECN in a flow of packets for which the sender is ECN-capable but the receiver is not.

But I don't believe it will make deployment any easier if we introduce backward ECN_S feedback. Then packets will have to signal whether the router should do forward or backward feedback. Because a router must not do both, otherwise it will double the amount of congestion signalled. We don't have room in the packet to switch between forward and backward feedback. And if we did take a new approach, it would require another decade to wait for routers to be deployed that understand this new feature.

If deployment is taking a long time, we need to understand *why* before proposing changes that will make deployment take even longer and be more complicated.

But most importantly, I listed problems with backward feedback, which ALL must to be solved first. And they are ALL very good reasons against backward feedback. So please address them all before taking this further.

 
The problem meet is how to know possibilities to receive congestion notification sent by access node(s) by UE. I personally want to oen it for access network(e.g. link layer) in Conex working group.

The ConEx group is not chartered to work on changes to ECN. Chartering is a careful process that takes account of everyone's views and results in a precise set of work items.

For example, a statement would be useful for people working in access network who know the ECN solution might be used to notifiy access network congestion only.

I wrote my my original review email very carefully to explain how ECN incremental deployment is designed to work (to save you reading RFC3168). There is nothing in the original ECN design to stop only access network nodes being ECN enabled and other network nodes not being ECN enabled. Indeed, that's how I would expect ECN to be deployed first - by enabling ECN on the nodes that are most likely to be congested.

Then, if there is any unexpected congestion (e.g. in the core), the endpoints will see the drop from that, as well as ECN markings from the access networks.

As I said, the problem (at least as stated in your draft) is already solved by the original design of ECN.


Bob


 
Best regards,
Zhu Lei

=E5=8F=91=E4=BB=B6=E4=BA=BA: Bob Briscoe [ mailto:rbriscoe@jungle.bt.co.uk]
=E5=8F=91=E9=80=81=E6=97=B6=E9=97=B4: 2010=E5=B9=B47=E6=9C=8816=E6=97= =A5 19:46
=E6=94=B6=E4=BB=B6=E4=BA=BA: Zhu Lei
=E6=8A=84=E9=80=81: conex@ietf.org
=E4=B8=BB=E9=A2=98: Re: [conex] An individual for your review

Lei,

The reason I said ECN_S must clearly be out of band is that, by definition in-band means within the packets travelling from S to R.

If you mean in-band in the packets travelling from R to S, the congested node may not be on the route of packets between R and S, which need not follow the reverse route of the forward path between S and R.

I think you will find that this expired I-D from Pasi Sarolahti is very relevant:
Transport-layer Considerations for Explicit Cross-layer Indications
< https://datatracker.ietf.org/doc/draft-sarolahti-tsvwg-crosslayer/ >


Bob

At 08:47 16/07/2010, Zhu Lei wrote:
Hi Bob and all,
 
Thank you for identifing some problems of ECN, especially mentioned some historical technical discussions which I never heard previously.
 
The problems of ECN at the moment are clearly summerised and clarified by Bob. I should follow the directions together with issues which is to be solved.
 
I have to say the understanding of the "proposal" is mainly correct. I highly appreciate the draft proposal and problem statement in previous e-mail. We at least need some statement in use cases draft.
 
The possible technical proposal of my mind is little bit different from the picture. The major difference is that the ECN_S could be not out-of-band. And, I also don't think that the ICMP is the approach. I personlly want the in-band trasnportation of ECN mark.
 
The document seems hint the proposal, but the intention of the submitted document is to introduce the requirements. I would try to write a technical proposal in ML soon. The slides for presentation take me time due to my native language.
 
I appologize for some delay of replying e-mail since I should have some works for internal guys in parallel.
 
Best regards,
Lei


=C2=B7=C2=A2=C2=BC=C3=BE=C3=88=C3=8B: Bob Briscoe [ mailto:rbriscoe@jungle.bt.co.uk]
=C2=B7=C2=A2=C3=8B=C3=8D=C3=8A=C2=B1=C2=BC=C3=A4: 2010=C3=84=C3=AA7= =C3=94=C3=8214=C3=88=C3=95 17:55
=C3=8A=C3=95=C2=BC=C3=BE=C3=88=C3=8B: Zhu Lei
=C2=B3=AD=C3=8B=C3=8D: conex@ietf.org
=C3=96=C3=B7=C3=8C=C3=A2: Re: [conex] An individual for your= review

Zhu,

Hi. I read your individual draft last night.
draft-lei-ecn-localised-congestion-notification-00

First, we should be clear that working on new data plane congestion notification technology is not part of the ConEx charter. So, those focusing solely on the charter can stop reading now if they want.

But I want to briefly review your proposal anyway, mainly to record on the mailing list what I believe is the current status of ECN deployment problems.

If I can summarise your proposal, I believe the main proposed new requirement is that we should work on a congestion notification architecture that looks something like this:

+--------------------------------------------------------------<---+
|   +---<----+          &nb= sp;            &= nbsp;            = ;            &nb= sp;    ^
|  /         ^            &nb= sp;            &= nbsp;            = ;            &nb= sp;  |
| |          |ECN_S           &nbs= p;            &n= bsp;           ECN_R       |
V V          |            &nb= sp;            &= nbsp;           --------------> |
 S ---> S's access net ---> core ... core ---> R's access net ---> R

Where ECN_S and ECN_R are congestion notification channels from the respective access networks of the sender S and receiver R directly to S and R. I believe the proposal is currently agnostic to whether ECN_R is in-band or out-of-band, but clearly ECN_S must be out-of-band.

Is the stated problem solved by this proposal?
----------------------------------------------
The stated problem this proposal aims to solve is:
- congestion is mostly in access networks
- ECN sometimes does not get through certain middleboxes that do not support ECN.

I agree with both statements, but there seems to be a misconception in the document about what it means for a router, switch or middlebox to 'not support' ECN.

ECN incremental deployment design
---------------------------------
ECN was designed for incremental deployment where some, most or all routers or middleboxes do not do ECN marking. If both endpoints support ECN, they should be able to exchange packets between themselves that are ECN-capable (with an ECN-capable transport or ECT codepoint set) whatever network support there is for ECN between them.

ECN was designed so that network equipment that has not been upgraded to mark the ECN field during congestion would silently forward ECN-capable packets when not congested and drop them during congestion - no different to any non-ECN-capable packets with the ECN field cleared (Not-ECT).

Ways to 'not support' ECN
-------------------------
Network equipment can 'not support' ECN in three ways:
1) lacks ECN: not yet upgraded to do ECN marking.
2) prevents ECN (a bug): middlebox tampers with endpoint attempts to send ECN-capable packets. Three known sub-cases:
 2a) ECN-TCP drop: drops SYNs attempting to negotiate ECN in the TCP header
 2b) ECN-IP drop: drops packets with ECN-capable codepoint in IP header
 2c) ECN-IP normalise: reverts ECN-capable packets to Not-ECT in IP header
3) crashes with ECN (a bug): an endpoint attempt to negotiate ECN in the TCP header crashes a middlebox

Case 1) is normal and is by far the most prevalent. ECN's incremental deployment design (above) copes with this just fine.

Case 2) happens in a small number of cases:
* Until about 2005-6 there were a number of enterprise-grade firewalls and NATs that did this, but tests showed their rules got upgraded over time and it was no longer a problem.
* It is however still a problem with about five popular models of home gateway from those days that will take some time to be discarded from most homes.
* Recently, a new problem has appeared on paths that were previously OK. It is thought this may be a buggy attempt to zero the Diffserv codepoint, which is also accidentally clearing the ECN field in the IP header.

Case 3) happens in one known case of one model of a home gateway that was popularly deployed a few years ago.

Equipment on the path exhibiting Case 2) behaviour can be detected by ECN black-hole detection code on the end-system, reverting a flow to Not-ECT in order to get packets through. There are black-hole detection patches for Linux, but black-hole detection is not configured by default with the mainline code. The

The home gateway that crashes on seeing ECN in the TCP header of a SYN (Case 3) is more problematic. ECN is turned off by default for the client end of TCP connections in Windows and Linux because of this single popular bugged home gateway. It should be possible to do some heuristic test to detect if the offending model is on your home network (perhaps using uPNP or checking whether the MAC address falls within a known range). But AFAIK, no code is available to do this.

Again, is the stated problem solved by this proposal?
-----------------------------------------------------
The proposal seems to be focused particularly on 3GPP, where AFAIK there are no ECN deployment problems that are not under the control of the network operators who could upgrade and fix them quickly.

I believe that introducing a new way to signal ECN would encounter as many deployment problems, if not more, than persevering with deployment of the existing way to do ECN.

Is backward ECN a good idea anyway?
-----------------------------------
The backward messages I have termed ECN_S in your proposal are reminiscent of ICMP source quench messages. SQ was deprecated for a number of reasons that also all apply to your proposal:
* SQ violates layering (congestion control is assumed to be end to end in the Internet Architecture), so it can interact badly with IPsec encryption and tunneling, making it difficult to address the message back to the process on the host generating the load.
* ICMP packet creation is normally (always) implemented on the ingress interface of a router. Congestion is detected on the egress, where it is too late, and too expensive wrt. critical processing time, to trigger the creation and sending of an ICMP packet, without hugely re-working the implementation architecture of most routers.
* SQ creates more data (although admittedly in the other direction) during congestion, which is generally to be avoided.
* SQ may get lost, and there's no 'end-middle' reliable channel between source and bottleneck to recover losses.
* SQ messages can be maliciously sent to hosts as if they came from an on-path router, thus creating a DoS vulnerability. To solve this would require a complicated security association between the SQ message and the packet stream it refers to.
* SQ messages are invariably discarded by firewalls, mostly because they can be spoofed (previous point).

See < http://www.ietf.org/mail-archive/web/ternli/current/msg00036.html> for the history of ICMP SQ.

In summary, I don't believe your proposal is a good way to solve the problems it identifies.

Cheers


Bob

At 11:53 06/07/2010, Zhu Lei wrote:
Hi all,
 
We already had some discussions which may allow wireless access networks to notify congestions in mail list.
 
I personally think that Conex charter is asking some solutions by stating "However, the CONEX WG will initially focus on one use case, where the end hosts and the network that contains the destination end host are CONEX-enabled but other networks need not be."
 
I have an individual draft which introduces some ideas for next f2f meeting. I'd like to ask you to review this short document and help identify the problems which could be resolved in Conex wg. Thank you!
 
draft-lei-ecn-localised-congestion-notification-00
Hope have your feedback soon.
 
Best regards,
Lei Zhu

 
_______________________________________________
conex mailing list
conex@ietf.org
https://www.ietf.org/mailman/listinfo/conex

________________________________________________________________
Bob Briscoe,           &n= bsp;            =         BT Innovate & Design

________________________________________________________________
Bob Briscoe,           &n= bsp;            =         BT Innovate & Design

________________________________________________________________
Bob Briscoe,           &n= bsp;            =         BT Innovate & Design --=====================_8220690==.ALT-- From lei.zhu@huawei.com Tue Jul 20 00:24:54 2010 Return-Path: X-Original-To: conex@core3.amsl.com Delivered-To: conex@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id C999C3A69ED for ; Tue, 20 Jul 2010 00:24:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 2.937 X-Spam-Level: ** X-Spam-Status: No, score=2.937 tagged_above=-999 required=5 tests=[AWL=-0.053, BAYES_50=0.001, FH_RELAY_NODNS=1.451, HELO_MISMATCH_COM=0.553, HTML_FONT_FACE_BAD=0.884, HTML_MESSAGE=0.001, RDNS_NONE=0.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 ovvERjJrKiFN for ; Tue, 20 Jul 2010 00:24:52 -0700 (PDT) Received: from szxga03-in.huawei.com (unknown [119.145.14.66]) by core3.amsl.com (Postfix) with ESMTP id 616733A6BF0 for ; Tue, 20 Jul 2010 00:23:38 -0700 (PDT) Received: from huawei.com (szxga03-in [172.24.2.9]) by szxga03-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0L5U005OKHT89E@szxga03-in.huawei.com> for conex@ietf.org; Tue, 20 Jul 2010 15:22:21 +0800 (CST) Received: from huawei.com ([172.24.2.119]) by szxga03-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0L5U00IJVHT803@szxga03-in.huawei.com> for conex@ietf.org; Tue, 20 Jul 2010 15:22:20 +0800 (CST) Received: from z41317 ([10.111.16.163]) by szxml06-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTPA id <0L5U00HKWHT7JH@szxml06-in.huawei.com> for conex@ietf.org; Tue, 20 Jul 2010 15:22:20 +0800 (CST) Date: Tue, 20 Jul 2010 15:22:19 +0800 From: Zhu Lei In-reply-to: <201007191841.o6JIf79B003548@bagheera.jungle.bt.co.uk> To: 'Bob Briscoe' Message-id: <000001cb27dc$4a1bb7d0$a3106f0a@china.huawei.com> MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2900.3350 X-Mailer: Microsoft Office Outlook 11 Content-type: multipart/alternative; boundary="Boundary_(ID_V04+DcRacfg8FFncd0gsrA)" Thread-index: Acsncf9oC+8PACuZQayUuAhGuWvVlQAZ23eQ Cc: conex@ietf.org Subject: Re: [conex] An individual for your review X-BeenThere: conex@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Congestion Exposure working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 20 Jul 2010 07:24:54 -0000 This is a multi-part message in MIME format. --Boundary_(ID_V04+DcRacfg8FFncd0gsrA) Content-type: text/plain; charset=utf-8 Content-transfer-encoding: quoted-printable Hi Bob, =20 I send this e-mail for clarfication of the solutions in the mind.=20 =20 I am try to make sure that the impact on existing solution is minimum, = even no needs to change endpoints behaviors. The backward ECN is also = not expected to be used. You may see the following text in slides for = f2f meeting. Others related to background and statements to be concluded = are more difficult. To be honest, I am thinking your suggestions in last = e-mail and if we have a proper solution satisfy everybody. =20 =E2=80=A2Highlight:=20 =C2=A7Negotiation of ECN only for local access network is kept to be = OPEN for access network system;=20 =C2=A7Others(no changes):=20 qUse IPv4 TOS or IPv6 Traffic Class Octet to encode one of the ECN = values=20 qFor TCP, use two flags in the TCP header to signal the sender to reduce = the amount of information it sends.=20 q =E2=80=A2Impacts on existing solutions=20 =C2=A7No changes to existing ECN mechanism:=20 qNo changes to endpoints, no changes to intermediate nodes.=20 =C2=A7NOTE: only impact on the endpoints and access networks which are = proposed to notify localized congestion to endpoints.=20 =20 =20 Best regards, Zhu Lei _____ =20 =E5=8F=91=E4=BB=B6=E4=BA=BA: Bob Briscoe = [mailto:rbriscoe@jungle.bt.co.uk]=20 =E5=8F=91=E9=80=81=E6=97=B6=E9=97=B4: 2010=E5=B9=B47=E6=9C=8820=E6=97=A5 = 2:41 =E6=94=B6=E4=BB=B6=E4=BA=BA: Zhu Lei =E6=8A=84=E9=80=81: conex@ietf.org =E4=B8=BB=E9=A2=98: Re: [conex] An individual for your review Lei, At 04:12 19/07/2010, Zhu Lei wrote: =C3=AF=C2=BB=C2=BF=20 Hi, =20 If possible, I want to see more historical drafts related to the = crosslayer ideas and thoughts. The refs in Pasi's draft cover all I know of, AFAIK. I think that S must be ECN enabled in any cases. It is important for = ECN_S knows it and is capable to notify access congestion by sending ECN = marks with TCP respones. I agree that the current design cannot use ECN in a flow of packets for = which the sender is ECN-capable but the receiver is not. But I don't believe it will make deployment any easier if we introduce = backward ECN_S feedback. Then packets will have to signal whether the = router should do forward or backward feedback. Because a router must not = do both, otherwise it will double the amount of congestion signalled. We = don't have room in the packet to switch between forward and backward = feedback. And if we did take a new approach, it would require another = decade to wait for routers to be deployed that understand this new = feature. If deployment is taking a long time, we need to understand *why* before = proposing changes that will make deployment take even longer and be more = complicated. But most importantly, I listed problems with backward feedback, which = ALL must to be solved first. And they are ALL very good reasons against = backward feedback. So please address them all before taking this = further. The problem meet is how to know possibilities to receive congestion = notification sent by access node(s) by UE. I personally want to oen it = for access network(e.g. link layer) in Conex working group.=20 The ConEx group is not chartered to work on changes to ECN. Chartering = is a careful process that takes account of everyone's views and results = in a precise set of work items.=20 For example, a statement would be useful for people working in access = network who know the ECN solution might be used to notifiy access = network congestion only. I wrote my my original review email very carefully to explain how ECN = incremental deployment is designed to work (to save you reading = RFC3168). There is nothing in the original ECN design to stop only = access network nodes being ECN enabled and other network nodes not being = ECN enabled. Indeed, that's how I would expect ECN to be deployed first = - by enabling ECN on the nodes that are most likely to be congested. Then, if there is any unexpected congestion (e.g. in the core), the = endpoints will see the drop from that, as well as ECN markings from the = access networks. As I said, the problem (at least as stated in your draft) is already = solved by the original design of ECN. Bob Best regards, Zhu Lei _____ =20 =C3=A5=C2=8F=E2=80=98=C3=A4=C2=BB=C2=B6=C3=A4=C2=BA=C2=BA: Bob Briscoe [ = mailto:rbriscoe@jungle.bt.co.uk]=20 =C3=A5=C2=8F=E2=80=98=C3=A9=E2=82=AC=C2=81=C3=A6=E2=80=94=C2=B6=C3=A9=E2=80= =94=C2=B4: = 2010=C3=A5=C2=B9=C2=B47=C3=A6=C5=93=CB=8616=C3=A6=E2=80=94=C2=A5 19:46 =C3=A6=E2=80=9D=C2=B6=C3=A4=C2=BB=C2=B6=C3=A4=C2=BA=C2=BA: Zhu Lei =C3=A6=C5=A0=E2=80=9E=C3=A9=E2=82=AC=C2=81: conex@ietf.org =C3=A4=C2=B8=C2=BB=C3=A9=C2=A2=CB=9C: Re: [conex] An individual for your = review Lei, The reason I said ECN_S must clearly be out of band is that, by = definition in-band means within the packets travelling from S to R. If you mean in-band in the packets travelling from R to S, the congested = node may not be on the route of packets between R and S, which need not = follow the reverse route of the forward path between S and R.=20 I think you will find that this expired I-D from Pasi Sarolahti is very = relevant: Transport-layer Considerations for Explicit Cross-layer Indications < https://datatracker.ietf.org/doc/draft-sarolahti-tsvwg-crosslayer/ > Bob At 08:47 16/07/2010, Zhu Lei wrote: Hi Bob and all, =20 Thank you for identifing some problems of ECN, especially mentioned some = historical technical discussions which I never heard previously. =20 The problems of ECN at the moment are clearly summerised and clarified = by Bob. I should follow the directions together with issues which is to = be solved. =20 I have to say the understanding of the "proposal" is mainly correct. I = highly appreciate the draft proposal and problem statement in previous = e-mail. We at least need some statement in use cases draft. =20 The possible technical proposal of my mind is little bit different from = the picture. The major difference is that the ECN_S could be not = out-of-band. And, I also don't think that the ICMP is the approach. I = personlly want the in-band trasnportation of ECN mark. =20 The document seems hint the proposal, but the intention of the submitted = document is to introduce the requirements. I would try to write a = technical proposal in ML soon. The slides for presentation take me time = due to my native language. =20 I appologize for some delay of replying e-mail since I should have some = works for internal guys in parallel. =20 Best regards, Lei _____ =20 =C3=82=C2=B7=C3=82=C2=A2=C3=82=C2=BC=C3=83=C2=BE=C3=83=CB=86=C3=83=E2=80=B9= : Bob Briscoe [ mailto:rbriscoe@jungle.bt.co.uk]=20 =C3=82=C2=B7=C3=82=C2=A2=C3=83=E2=80=B9=C3=83=C2=8D=C3=83=C5=A0=C3=82=C2=B1= =C3=82=C2=BC=C3=83=C2=A4: = 2010=C3=83=E2=80=9E=C3=83=C2=AA7=C3=83=E2=80=9D=C3=83=E2=80=9A14=C3=83=CB= =86=C3=83=E2=80=A2 17:55 =C3=83=C5=A0=C3=83=E2=80=A2=C3=82=C2=BC=C3=83=C2=BE=C3=83=CB=86=C3=83=E2=80= =B9: Zhu Lei =C3=82=C2=B3=C2=AD=C3=83=E2=80=B9=C3=83=C2=8D: conex@ietf.org =C3=83=E2=80=93=C3=83=C2=B7=C3=83=C5=92=C3=83=C2=A2: Re: [conex] An = individual for your review Zhu, Hi. I read your individual draft last night. draft-lei-ecn-localised-congestion-notification-00 First, we should be clear that working on new data plane congestion = notification technology is not part of the ConEx charter. So, those = focusing solely on the charter can stop reading now if they want.=20 But I want to briefly review your proposal anyway, mainly to record on = the mailing list what I believe is the current status of ECN deployment = problems. If I can summarise your proposal, I believe the main proposed new = requirement is that we should work on a congestion notification = architecture that looks something like this: +--------------------------------------------------------------<---+ | +---<----+ ^ | / ^ | | | |ECN_S ECN_R | V V | --------------> | S ---> S's access net ---> core ... core ---> R's access net ---> R Where ECN_S and ECN_R are congestion notification channels from the = respective access networks of the sender S and receiver R directly to S = and R. I believe the proposal is currently agnostic to whether ECN_R is = in-band or out-of-band, but clearly ECN_S must be out-of-band. Is the stated problem solved by this proposal? ---------------------------------------------- The stated problem this proposal aims to solve is: - congestion is mostly in access networks - ECN sometimes does not get through certain middleboxes that do not = support ECN. I agree with both statements, but there seems to be a misconception in = the document about what it means for a router, switch or middlebox to = 'not support' ECN.=20 ECN incremental deployment design --------------------------------- ECN was designed for incremental deployment where some, most or all = routers or middleboxes do not do ECN marking. If both endpoints support = ECN, they should be able to exchange packets between themselves that are = ECN-capable (with an ECN-capable transport or ECT codepoint set) = whatever network support there is for ECN between them. ECN was designed so that network equipment that has not been upgraded to = mark the ECN field during congestion would silently forward ECN-capable = packets when not congested and drop them during congestion - no = different to any non-ECN-capable packets with the ECN field cleared = (Not-ECT). Ways to 'not support' ECN ------------------------- Network equipment can 'not support' ECN in three ways: 1) lacks ECN: not yet upgraded to do ECN marking. 2) prevents ECN (a bug): middlebox tampers with endpoint attempts to = send ECN-capable packets. Three known sub-cases: 2a) ECN-TCP drop: drops SYNs attempting to negotiate ECN in the TCP = header 2b) ECN-IP drop: drops packets with ECN-capable codepoint in IP header 2c) ECN-IP normalise: reverts ECN-capable packets to Not-ECT in IP = header 3) crashes with ECN (a bug): an endpoint attempt to negotiate ECN in the = TCP header crashes a middlebox Case 1) is normal and is by far the most prevalent. ECN's incremental = deployment design (above) copes with this just fine. Case 2) happens in a small number of cases: * Until about 2005-6 there were a number of enterprise-grade firewalls = and NATs that did this, but tests showed their rules got upgraded over = time and it was no longer a problem.=20 * It is however still a problem with about five popular models of home = gateway from those days that will take some time to be discarded from = most homes.=20 * Recently, a new problem has appeared on paths that were previously OK. = It is thought this may be a buggy attempt to zero the Diffserv = codepoint, which is also accidentally clearing the ECN field in the IP = header. Case 3) happens in one known case of one model of a home gateway that = was popularly deployed a few years ago. Equipment on the path exhibiting Case 2) behaviour can be detected by = ECN black-hole detection code on the end-system, reverting a flow to = Not-ECT in order to get packets through. There are black-hole detection = patches for Linux, but black-hole detection is not configured by default = with the mainline code. The=20 The home gateway that crashes on seeing ECN in the TCP header of a SYN = (Case 3) is more problematic. ECN is turned off by default for the = client end of TCP connections in Windows and Linux because of this = single popular bugged home gateway. It should be possible to do some = heuristic test to detect if the offending model is on your home network = (perhaps using uPNP or checking whether the MAC address falls within a = known range). But AFAIK, no code is available to do this. Again, is the stated problem solved by this proposal? ----------------------------------------------------- The proposal seems to be focused particularly on 3GPP, where AFAIK there = are no ECN deployment problems that are not under the control of the = network operators who could upgrade and fix them quickly. I believe that introducing a new way to signal ECN would encounter as = many deployment problems, if not more, than persevering with deployment = of the existing way to do ECN. Is backward ECN a good idea anyway? ----------------------------------- The backward messages I have termed ECN_S in your proposal are = reminiscent of ICMP source quench messages. SQ was deprecated for a = number of reasons that also all apply to your proposal: * SQ violates layering (congestion control is assumed to be end to end = in the Internet Architecture), so it can interact badly with IPsec = encryption and tunneling, making it difficult to address the message = back to the process on the host generating the load.=20 * ICMP packet creation is normally (always) implemented on the ingress = interface of a router. Congestion is detected on the egress, where it is = too late, and too expensive wrt. critical processing time, to trigger = the creation and sending of an ICMP packet, without hugely re-working = the implementation architecture of most routers. * SQ creates more data (although admittedly in the other direction) = during congestion, which is generally to be avoided. * SQ may get lost, and there's no 'end-middle' reliable channel between = source and bottleneck to recover losses. * SQ messages can be maliciously sent to hosts as if they came from an = on-path router, thus creating a DoS vulnerability. To solve this would = require a complicated security association between the SQ message and = the packet stream it refers to. * SQ messages are invariably discarded by firewalls, mostly because they = can be spoofed (previous point). See < http://www.ietf.org/mail-archive/web/ternli/current/msg00036.html> = for the history of ICMP SQ. In summary, I don't believe your proposal is a good way to solve the = problems it identifies. Cheers Bob At 11:53 06/07/2010, Zhu Lei wrote: Hi all, =20 We already had some discussions which may allow wireless access networks = to notify congestions in mail list.=20 =20 I personally think that Conex charter is asking some solutions by = stating "However, the CONEX WG will initially focus on one use case, = where the end hosts and the network that contains the destination end = host are CONEX-enabled but other networks need not be."=20 =20 I have an individual draft which introduces some ideas for next f2f = meeting. I'd like to ask you to review this short document and help = identify the problems which could be resolved in Conex wg. Thank you! =20 draft-lei-ecn-localised-congestion-notification-00 Hope have your feedback soon. =20 Best regards, Lei Zhu =20 _______________________________________________ conex mailing list conex@ietf.org https://www.ietf.org/mailman/listinfo/conex ________________________________________________________________ Bob Briscoe, BT Innovate & Design=20 ________________________________________________________________ Bob Briscoe, BT Innovate & Design=20 ________________________________________________________________ Bob Briscoe, BT Innovate & Design=20 --Boundary_(ID_V04+DcRacfg8FFncd0gsrA) Content-type: text/html; charset=utf-8 Content-transfer-encoding: quoted-printable =EF=BB=BF

Hi Bob,
 
I send this e-mail for clarfication of the = solutions in=20 the mind.
 
I am try to make sure that the impact on = existing=20 solution is minimum, even no needs to change endpoints behaviors. The = backward=20 ECN is also not expected to be used. You may see the following text in = slides=20 for f2f meeting. Others related to background and statements to be=20 concluded are more difficult. To be honest, I am thinking your = suggestions in=20 last e-mail and if we have a proper solution satisfy=20 everybody.
 
=E2=80=A2Highlight:
=C2=A7Negotiation=20 of ECN only for local access network is kept to be OPEN for access=20 network system;
=C2=A7Others(no = changes):=20
qUse  IPv4 TOS or = IPv6 Traffic=20 Class Octet to encode one of the ECN values
qFor TCP, use two flags in the TCP header to signal the sender = to reduce=20 the amount of information it sends.
q
=E2=80=A2Impacts on existing solutions
=C2=A7No=20 changes to existing ECN mechanism:
qNo changes to endpoints, no changes to intermediate nodes.
=C2=A7NOTE:=20 only impact on the endpoints and access networks which are proposed = to=20 notify localized congestion to endpoints.
 
 

Best=20 regards,
Zhu Lei

=E5=8F=91=E4=BB=B6=E4=BA=BA: Bob Briscoe = [mailto:rbriscoe@jungle.bt.co.uk]=20
=E5=8F=91=E9=80=81=E6=97=B6=E9=97=B4: = 2010=E5=B9=B47=E6=9C=8820=E6=97=A5 = 2:41
=E6=94=B6=E4=BB=B6=E4=BA=BA: Zhu = Lei
=E6=8A=84=E9=80=81:=20 conex@ietf.org
=E4=B8=BB=E9=A2=98: Re: [conex] An individual = for your=20 review

Lei,

At 04:12 19/07/2010, Zhu Lei wrote:
=C3=AF=C2=BB=C2=BF =
Hi,
 
If = possible, I want=20 to see more historical drafts related to the crosslayer ideas and=20 thoughts.

The refs in Pasi's draft cover all I = know of,=20 AFAIK.

I think=20 that S must be ECN enabled in any cases. It is important for ECN_S = knows it=20 and is capable to notify access congestion by sending ECN marks with = TCP=20 respones.

I agree that the current design = cannot use ECN=20 in a flow of packets for which the sender is ECN-capable but the = receiver is=20 not.

But I don't believe it will make deployment any easier if we = introduce backward ECN_S feedback. Then packets will have to signal = whether the=20 router should do forward or backward feedback. Because a router must not = do=20 both, otherwise it will double the amount of congestion signalled. We = don't have=20 room in the packet to switch between forward and backward feedback. And = if we=20 did take a new approach, it would require another decade to wait for = routers to=20 be deployed that understand this new feature.

If deployment is = taking a=20 long time, we need to understand *why* before proposing changes that = will make=20 deployment take even longer and be more complicated.

But most=20 importantly, I listed problems with backward feedback, which ALL must to = be=20 solved first. And they are ALL very good reasons against backward = feedback. So=20 please address them all before taking this further.


The=20 problem meet is how to know possibilities to receive congestion = notification=20 sent by access node(s) by UE. I personally want to oen it for access=20 network(e.g. link layer) in Conex working group. =

The=20 ConEx group is not chartered to work on changes to ECN. Chartering is a = careful=20 process that takes account of everyone's views and results in a precise = set of=20 work items.

For=20 example, a statement would be useful for people working in access = network who=20 know the ECN solution might be used to notifiy access network = congestion=20 only.

I wrote my my original review email very = carefully=20 to explain how ECN incremental deployment is designed to work (to save = you=20 reading RFC3168). There is nothing in the original ECN design to stop = only=20 access network nodes being ECN enabled and other network nodes not being = ECN=20 enabled. Indeed, that's how I would expect ECN to be deployed first - by = enabling ECN on the nodes that are most likely to be = congested.

Then, if=20 there is any unexpected congestion (e.g. in the core), the endpoints = will see=20 the drop from that, as well as ECN markings from the access = networks.

As=20 I said, the problem (at least as stated in your draft) is already solved = by the=20 original design of ECN.


Bob



Best=20 regards,
Zhu = Lei

=C3=A5=C2=8F=E2=80=98=C3=A4=C2=BB=C2=B6=C3=A4=C2=BA=C2=BA: Bob Briscoe [=20 mailto:rbriscoe@jungle.bt.co.uk] =
=C3=A5=C2=8F=E2=80=98=C3=A9=E2=82=AC=C2=81=C3=A6=E2=80=94=C2=B6=C3= =A9=E2=80=94=C2=B4: = 2010=C3=A5=C2=B9=C2=B47=C3=A6=C5=93=CB=8616=C3=A6=E2=80=94=C2=A5=20 = 19:46
=C3=A6=E2=80=9D=C2=B6=C3=A4=C2=BB=C2=B6=C3=A4=C2=BA=C2=BA: Zhu Lei
=C3=A6=C5=A0=E2=80=9E=C3=A9=E2=82=AC=C2=81:=20 conex@ietf.org
=C3=A4=C2=B8=C2=BB=C3=A9=C2=A2=CB=9C: Re: = [conex] An individual for your=20 review

Lei,

The reason I said ECN_S must clearly = be out=20 of band is that, by definition in-band means within the packets = travelling=20 from S to R.

If you mean in-band in the packets travelling from = R to S,=20 the congested node may not be on the route of packets between R and S, = which=20 need not follow the reverse route of the forward path between S and R. =

I think you will find that this expired I-D from Pasi = Sarolahti is=20 very relevant:
Transport-layer Considerations for Explicit = Cross-layer=20 Indications
< https://datatracker.ietf.org/doc/draft-sarolahti-tsvwg= -crosslayer/=20 >


Bob

At 08:47 16/07/2010, Zhu Lei wrote:
Hi Bob=20 and all,
 
Thank = you for=20 identifing some problems of ECN, especially mentioned some = historical=20 technical discussions which I never heard=20 previously.
 
The = problems of=20 ECN at the moment are clearly summerised and clarified by Bob. I = should=20 follow the directions together with issues which is to be=20 solved.
 
I have to = say the=20 understanding of the "proposal" is mainly correct. I highly = appreciate the=20 draft proposal and problem statement in previous e-mail. We at least = need=20 some statement in use cases draft.
 
The possible technical proposal of my mind is little bit = different=20 from the picture. The major difference is that the ECN_S could be = not=20 out-of-band. And, I also don't think that the ICMP is the approach. = I=20 personlly want the in-band trasnportation of ECN=20 mark.
 
The = document seems hint=20 the proposal, but the intention of the submitted document is to = introduce=20 the requirements. I would try to write a technical proposal in ML = soon. The=20 slides for presentation take me time due to my native=20 language.
 
I = appologize for=20 some delay of replying e-mail since I should have some works for = internal=20 guys in parallel.
 
Best=20 regards,
Lei


=C3=82=C2=B7=C3=82=C2=A2=C3=82=C2=BC=C3=83=C2=BE=C3=83=CB=86=C3= =83=E2=80=B9: Bob Briscoe [ mailto:rbriscoe@jungle.bt.co.uk]=20 =
=C3=82=C2=B7=C3=82=C2=A2=C3=83=E2=80=B9=C3=83=C2=8D=C3=83=C5=A0=C3= =82=C2=B1=C3=82=C2=BC=C3=83=C2=A4: = 2010=C3=83=E2=80=9E=C3=83=C2=AA7=C3=83=E2=80=9D=C3=83=E2=80=9A14=C3=83=CB= =86=C3=83=E2=80=A2=20 = 17:55
=C3=83=C5=A0=C3=83=E2=80=A2=C3=82=C2=BC=C3=83=C2=BE=C3=83=CB=86= =C3=83=E2=80=B9: Zhu = Lei
=C3=82=C2=B3­=C3=83=E2=80=B9=C3=83=C2=8D:=20 = conex@ietf.org
=C3=83=E2=80=93=C3=83=C2=B7=C3=83=C5=92=C3=83=C2=A2:= Re: [conex] An individual for your=20 review

Zhu,

Hi. I read your individual draft = last=20 = night.
draft-lei-ecn-localised-congestion-notification-00

First= ,=20 we should be clear that working on new data plane congestion = notification=20 technology is not part of the ConEx charter. So, those focusing = solely on=20 the charter can stop reading now if they want.

But I want to = briefly=20 review your proposal anyway, mainly to record on the mailing list = what I=20 believe is the current status of ECN deployment problems.

If = I can=20 summarise your proposal, I believe the main proposed new requirement = is that=20 we should work on a congestion notification architecture that looks=20 something like=20 = this:

+-----------------------------------------------------------= ---<---+
|  =20 = +---<----+          =             &= nbsp;           &n= bsp;           &nb= sp;     =20 ^
|  /        =20 = ^            =             &= nbsp;           &n= bsp;           &nb= sp;   =20 |
| |         =20 = |ECN_S           &= nbsp;           &n= bsp;           =20 ECN_R       |
V=20 V         =20 = |            =             &= nbsp;           =20 --------------> |
 S ---> S's access net ---> core = ... core=20 ---> R's access net ---> R

Where ECN_S and ECN_R are = congestion=20 notification channels from the respective access networks of the = sender S=20 and receiver R directly to S and R. I believe the proposal is = currently=20 agnostic to whether ECN_R is in-band or out-of-band, but clearly = ECN_S must=20 be out-of-band.

Is the stated problem solved by this=20 proposal?
----------------------------------------------
The = stated=20 problem this proposal aims to solve is:
- congestion is mostly in = access=20 networks
- ECN sometimes does not get through certain middleboxes = that do=20 not support ECN.

I agree with both statements, but there = seems to be=20 a misconception in the document about what it means for a router, = switch or=20 middlebox to 'not support' ECN.

ECN incremental deployment=20 design
---------------------------------
ECN was designed for=20 incremental deployment where some, most or all routers or = middleboxes do not=20 do ECN marking. If both endpoints support ECN, they should be able = to=20 exchange packets between themselves that are ECN-capable (with an=20 ECN-capable transport or ECT codepoint set) whatever network support = there=20 is for ECN between them.

ECN was designed so that network = equipment=20 that has not been upgraded to mark the ECN field during congestion = would=20 silently forward ECN-capable packets when not congested and drop = them during=20 congestion - no different to any non-ECN-capable packets with the = ECN field=20 cleared (Not-ECT).

Ways to 'not support'=20 ECN
-------------------------
Network equipment can 'not = support' ECN=20 in three ways:
1) lacks ECN: not yet upgraded to do ECN = marking.
2)=20 prevents ECN (a bug): middlebox tampers with endpoint attempts to = send=20 ECN-capable packets. Three known sub-cases:
 2a) ECN-TCP = drop: drops=20 SYNs attempting to negotiate ECN in the TCP header
 2b) = ECN-IP drop:=20 drops packets with ECN-capable codepoint in IP header
 2c) = ECN-IP=20 normalise: reverts ECN-capable packets to Not-ECT in IP header
3) = crashes=20 with ECN (a bug): an endpoint attempt to negotiate ECN in the TCP = header=20 crashes a middlebox

Case 1) is normal and is by far the most=20 prevalent. ECN's incremental deployment design (above) copes with = this just=20 fine.

Case 2) happens in a small number of cases:
* Until = about=20 2005-6 there were a number of enterprise-grade firewalls and NATs = that did=20 this, but tests showed their rules got upgraded over time and it was = no=20 longer a problem.
* It is however still a problem with about = five=20 popular models of home gateway from those days that will take some = time to=20 be discarded from most homes.
* Recently, a new problem has = appeared on=20 paths that were previously OK. It is thought this may be a buggy = attempt to=20 zero the Diffserv codepoint, which is also accidentally clearing the = ECN=20 field in the IP header.

Case 3) happens in one known case of = one=20 model of a home gateway that was popularly deployed a few years=20 ago.

Equipment on the path exhibiting Case 2) behaviour can = be=20 detected by ECN black-hole detection code on the end-system, = reverting a=20 flow to Not-ECT in order to get packets through. There are = black-hole=20 detection patches for Linux, but black-hole detection is not = configured by=20 default with the mainline code. The

The home gateway that = crashes on=20 seeing ECN in the TCP header of a SYN (Case 3) is more problematic. = ECN is=20 turned off by default for the client end of TCP connections in = Windows and=20 Linux because of this single popular bugged home gateway. It should = be=20 possible to do some heuristic test to detect if the offending model = is on=20 your home network (perhaps using uPNP or checking whether the MAC = address=20 falls within a known range). But AFAIK, no code is available to do=20 this.

Again, is the stated problem solved by this=20 = proposal?
-----------------------------------------------------
The= =20 proposal seems to be focused particularly on 3GPP, where AFAIK there = are no=20 ECN deployment problems that are not under the control of the = network=20 operators who could upgrade and fix them quickly.

I believe = that=20 introducing a new way to signal ECN would encounter as many = deployment=20 problems, if not more, than persevering with deployment of the = existing way=20 to do ECN.

Is backward ECN a good idea=20 anyway?
-----------------------------------
The backward = messages I=20 have termed ECN_S in your proposal are reminiscent of ICMP source = quench=20 messages. SQ was deprecated for a number of reasons that also all = apply to=20 your proposal:
* SQ violates layering (congestion control is = assumed=20 to be end to end in the Internet Architecture), so it can interact = badly=20 with IPsec encryption and tunneling, making it difficult to address = the=20 message back to the process on the host generating the load.
* = ICMP=20 packet creation is normally (always) implemented on the ingress = interface of=20 a router. Congestion is detected on the egress, where it is too = late, and=20 too expensive wrt. critical processing time, to trigger the creation = and=20 sending of an ICMP packet, without hugely re-working the = implementation=20 architecture of most routers.
* SQ creates more data (although = admittedly=20 in the other direction) during congestion, which is generally to be=20 avoided.
* SQ may get lost, and there's no 'end-middle' reliable = channel=20 between source and bottleneck to recover losses.
* SQ messages = can be=20 maliciously sent to hosts as if they came from an on-path router, = thus=20 creating a DoS vulnerability. To solve this would require a = complicated=20 security association between the SQ message and the packet stream it = refers=20 to.
* SQ messages are invariably discarded by firewalls, mostly = because=20 they can be spoofed (previous point).

See < http://www.ietf.org/mail-archive/web/ternli/current/ms= g00036.html>=20 for the history of ICMP SQ.

In summary, I don't believe your = proposal=20 is a good way to solve the problems it=20 identifies.

Cheers


Bob

At 11:53 06/07/2010, = Zhu Lei=20 wrote:
Hi=20 all,
 
We already had some = discussions=20 which may allow wireless access networks to notify congestions in = mail=20 list.
 
I personally think that = Conex=20 charter is asking some solutions by stating "However, the CONEX WG = will=20 initially focus on one use case, where the end hosts and the = network that=20 contains the destination end host are CONEX-enabled but other = networks=20 need not be."
 
I have an = individual draft=20 which introduces some ideas for next f2f meeting. I'd like to ask = you to=20 review this short document and help identify the problems which = could be=20 resolved in Conex wg. Thank you!
 
draft-lei-ecn-localised-congestion-notification-00
Hope have = your feedback soon.
 
Best = regards,
Lei=20 = Zhu

 
_____________________________________________= __
conex=20 mailing list
conex@ietf.org
https://www.ietf.org/mailman/listinfo/conex
_______________________________________________________________= _
Bob=20 = Briscoe,           = ;            =         =20 BT Innovate & Design=20 =

________________________________________________________= ________
Bob=20 = Briscoe,           = ;            =         =20 BT Innovate & Design

___________________________________________________________= _____
Bob=20 Briscoe,           = ;            =         =20 BT Innovate & Design

--Boundary_(ID_V04+DcRacfg8FFncd0gsrA)-- From rbriscoe@jungle.bt.co.uk Tue Jul 20 10:05:11 2010 Return-Path: X-Original-To: conex@core3.amsl.com Delivered-To: conex@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 9C2873A68EA for ; Tue, 20 Jul 2010 10:05:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.635 X-Spam-Level: X-Spam-Status: No, score=0.635 tagged_above=-999 required=5 tests=[AWL=-1.245, BAYES_50=0.001, DNS_FROM_RFC_BOGUSMX=1.482, HTML_MESSAGE=0.001, MIME_QP_LONG_LINE=1.396, 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 5NDuF5+1gU1L for ; Tue, 20 Jul 2010 10:05:03 -0700 (PDT) Received: from smtp1.smtp.bt.com (smtp1.smtp.bt.com [217.32.164.137]) by core3.amsl.com (Postfix) with ESMTP id 222F73A690E for ; Tue, 20 Jul 2010 10:05:01 -0700 (PDT) Received: from i2kc08-ukbr.domain1.systemhost.net ([193.113.197.71]) by smtp1.smtp.bt.com with Microsoft SMTPSVC(6.0.3790.4675); Tue, 20 Jul 2010 18:05:16 +0100 Received: from cbibipnt08.iuser.iroot.adidom.com ([147.149.100.81]) by i2kc08-ukbr.domain1.systemhost.net with Microsoft SMTPSVC(6.0.3790.4675); Tue, 20 Jul 2010 18:05:15 +0100 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 1279645514762; Tue, 20 Jul 2010 18:05:14 +0100 Received: from MUT.jungle.bt.co.uk ([10.215.130.87]) by bagheera.jungle.bt.co.uk (8.13.5/8.12.8) with ESMTP id o6KH5CKl017600; Tue, 20 Jul 2010 18:05:12 +0100 Message-Id: <201007201705.o6KH5CKl017600@bagheera.jungle.bt.co.uk> X-Mailer: QUALCOMM Windows Eudora Version 7.1.0.9 Date: Tue, 20 Jul 2010 18:05:08 +0100 To: Zhu Lei From: Bob Briscoe In-Reply-To: <000001cb27dc$4a1bb7d0$a3106f0a@china.huawei.com> References: <201007191841.o6JIf79B003548@bagheera.jungle.bt.co.uk> <000001cb27dc$4a1bb7d0$a3106f0a@china.huawei.com> Mime-Version: 1.0 Content-Type: multipart/alternative; boundary="=====================_88864270==.ALT" X-Scanned-By: MIMEDefang 2.56 on 132.146.168.158 X-OriginalArrivalTime: 20 Jul 2010 17:05:15.0836 (UTC) FILETIME=[B957A7C0:01CB282D] Cc: conex@ietf.org Subject: Re: [conex] An individual for your review X-BeenThere: conex@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Congestion Exposure working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 20 Jul 2010 17:05:11 -0000 --=====================_88864270==.ALT Content-Type: text/plain; charset="iso-8859-1"; format=flowed Content-Transfer-Encoding: quoted-printable Lei, May-be I had better wait until your presentation=20 - I don't understand the bullets without the extended words behind them. But again, I don't think ConEx is the right place=20 for this. If there's something to change in ECN=20 that affects the IP layer, it would probably be done in tsvwg. The main point of my original mail was that the=20 problem you *seem* to be trying to solve is not a=20 problem. So I would first like to see your=20 statement of precisely what problem you are=20 trying to solve, before discussing solutions to=20 something that may not need solving. Bob At 08:22 20/07/2010, Zhu Lei wrote: >=EF=BB=BF >Hi Bob, > >I send this e-mail for clarfication of the solutions in the mind. > >I am try to make sure that the impact on=20 >existing solution is minimum, even no needs to=20 >change endpoints behaviors. The backward ECN is=20 >also not expected to be used. You may see the=20 >following text in slides for f2f meeting. Others=20 >related to background and statements to be=20 >concluded are more difficult. To be honest, I am=20 >thinking your suggestions in last e-mail and if=20 >we have a proper solution satisfy everybody. > >=95Highlight: >=C2=A7Negotiation of ECN only for local access=20 >network is kept to be OPEN for access network system; >=C2=A7Others(no changes): >qUse IPv4 TOS or IPv6 Traffic Class Octet to encode one of the ECN values >qFor TCP, use two flags in the TCP header to=20 >signal the sender to reduce the amount of information it sends. >q >=95Impacts on existing solutions >=C2=A7No changes to existing ECN mechanism: >qNo changes to endpoints, no changes to intermediate nodes. >=C2=A7NOTE: only impact on the endpoints and access=20 >networks which are proposed to notify localized congestion to endpoints. > > > >Best regards, >Zhu Lei > > >---------- >=E5=8F=91=E4=BB=B6=E4=BA=BA: Bob Briscoe [mailto:rbriscoe@jungle.bt.co.uk] >=E5=8F=91=E9=80=81=E6=97=B6=E9=97=B4: 2010=E5=B9=B47=E6=9C=8820=E6=97=A5= 2:41 >=E6=94=B6=E4=BB=B6=E4=BA=BA: Zhu Lei >=E6=8A=84=E9=80=81: conex@ietf.org >=E4=B8=BB=E9=A2=98: Re: [conex] An individual for your review > >Lei, > >At 04:12 19/07/2010, Zhu Lei wrote: >>=C3=AF=C2=BB=C2=BF >>Hi, >> >>If possible, I want to see more historical=20 >>drafts related to the crosslayer ideas and thoughts. > >The refs in Pasi's draft cover all I know of, AFAIK. > >>I think that S must be ECN enabled in any=20 >>cases. It is important for ECN_S knows it and=20 >>is capable to notify access congestion by sending ECN marks with TCP= respones. > >I agree that the current design cannot use ECN=20 >in a flow of packets for which the sender is=20 >ECN-capable but the receiver is not. > >But I don't believe it will make deployment any=20 >easier if we introduce backward ECN_S feedback.=20 >Then packets will have to signal whether the=20 >router should do forward or backward feedback.=20 >Because a router must not do both, otherwise it=20 >will double the amount of congestion signalled.=20 >We don't have room in the packet to switch=20 >between forward and backward feedback. And if we=20 >did take a new approach, it would require=20 >another decade to wait for routers to be=20 >deployed that understand this new feature. > >If deployment is taking a long time, we need to=20 >understand *why* before proposing changes that=20 >will make deployment take even longer and be more complicated. > >But most importantly, I listed problems with=20 >backward feedback, which ALL must to be solved=20 >first. And they are ALL very good reasons=20 >against backward feedback. So please address=20 >them all before taking this further. > >> >>The problem meet is how to know possibilities=20 >>to receive congestion notification sent by=20 >>access node(s) by UE. I personally want to oen=20 >>it for access network(e.g. link layer) in Conex working group. > >The ConEx group is not chartered to work on=20 >changes to ECN. Chartering is a careful process=20 >that takes account of everyone's views and=20 >results in a precise set of work items. > >>For example, a statement would be useful for=20 >>people working in access network who know the=20 >>ECN solution might be used to notifiy access network congestion only. > >I wrote my my original review email very=20 >carefully to explain how ECN incremental=20 >deployment is designed to work (to save you=20 >reading RFC3168). There is nothing in the=20 >original ECN design to stop only access network=20 >nodes being ECN enabled and other network nodes=20 >not being ECN enabled. Indeed, that's how I=20 >would expect ECN to be deployed first - by=20 >enabling ECN on the nodes that are most likely to be congested. > >Then, if there is any unexpected congestion=20 >(e.g. in the core), the endpoints will see the=20 >drop from that, as well as ECN markings from the access networks. > >As I said, the problem (at least as stated in=20 >your draft) is already solved by the original design of ECN. > > >Bob > > >> >>Best regards, >>Zhu Lei >> >> >>---------- >>=C3=A5=C2=8F=E2=80=98=C3=A4=C2=BB=C2=B6=C3=A4=C2=BA=C2=BA: Bob Briscoe [= mailto:rbriscoe@jungle.bt.co.uk] >>=C3=A5=C2=8F=E2=80=98=C3=A9=80=C2=81=C3=A6=97=C2=B6=C3=C2=B6=C3=A9=97=C2= =B4: 2010=C3=A5=C2=B9=C2=B47=C3=A6=9C=8816=C3=A6=97=C2=A5 19:46 >>=C3=A6=E2=80=9D=C2=B6=C3=A4=C2=BB=C2=B6=C3=A4=C2=BA=C2=BA: Zhu Lei >>=C3=A6=8A=84=C3=A9=80=C2=81: > conex@ietf.org >>=C3=A4=C2=B8=C2=BB=C3=A9=C2=A2=98: Re: [conex] An individual for your= review >> >>Lei, >> >>The reason I said ECN_S must clearly be out of=20 >>band is that, by definition in-band means=20 >>within the packets travelling from S to R. >> >>If you mean in-band in the packets travelling=20 >>from R to S, the congested node may not be on=20 >>the route of packets between R and S, which=20 >>need not follow the reverse route of the forward path between S and R. >> >>I think you will find that this expired I-D=20 >>from Pasi Sarolahti is very relevant: >>Transport-layer Considerations for Explicit Cross-layer Indications >>< https://datatracker.ietf.org/doc/draft-sarolahti-tsvwg-crosslayer/ > >> >> >>Bob >> >>At 08:47 16/07/2010, Zhu Lei wrote: >>>Hi Bob and all, >>> >>>Thank you for identifing some problems of ECN,=20 >>>especially mentioned some historical technical=20 >>>discussions which I never heard previously. >>> >>>The problems of ECN at the moment are clearly=20 >>>summerised and clarified by Bob. I should=20 >>>follow the directions together with issues which is to be solved. >>> >>>I have to say the understanding of the=20 >>>"proposal" is mainly correct. I highly=20 >>>appreciate the draft proposal and problem=20 >>>statement in previous e-mail. We at least need=20 >>>some statement in use cases draft. >>> >>>The possible technical proposal of my mind is=20 >>>little bit different from the picture. The=20 >>>major difference is that the ECN_S could be=20 >>>not out-of-band. And, I also don't think that=20 >>>the ICMP is the approach. I personlly want the=20 >>>in-band trasnportation of ECN mark. >>> >>>The document seems hint the proposal, but the=20 >>>intention of the submitted document is to=20 >>>introduce the requirements. I would try to=20 >>>write a technical proposal in ML soon. The=20 >>>slides for presentation take me time due to my native language. >>> >>>I appologize for some delay of replying e-mail=20 >>>since I should have some works for internal guys in parallel. >>> >>>Best regards, >>>Lei >>> >>> >>> >>>---------- >>>=C3=82=C2=B7=C3=82=C2=A2=C3=82=C2=BC=C3=83=C2=BE=C3=83=88=C3=83=E2=80=B9:= Bob Briscoe [ mailto:rbriscoe@jungle.bt.co.uk] >>>=C3=82=C2=B7=C3=82=C2=A2=C3=83=E2=80=B9=C3=83=C2=8D=C3=83=8A=C3=82=C2=B1= =C3=82=C2=BC=C3=83=C2=A4: 2010=C3=83=84=C3=83=C2=AA7=C3=83=E2=80=9D=C3=83=82= 14=C3=83=CB=C3=83=CB=86=C3=83=95 17:55 >>>=C3=83=8A=C3=83=95=C3=82=C2=BC=C3=83=C2=BE=C3=83=88=83=CB=86=C3=83=E2=80= =B9: Zhu Lei >>>=C3=82=C2=B3=AD=C3=83=E2=80=B9=C3=83=C2=8D: conex@ietf.org >>>=C3=83=96=C3=83=C2=B7=C3=83=8C=C3=83=C2=A2:=A2: Re: [conex] An individual= for your review >>> >>>Zhu, >>> >>>Hi. I read your individual draft last night. >>>draft-lei-ecn-localised-congestion-notification-00 >>> >>>First, we should be clear that working on new=20 >>>data plane congestion notification technology=20 >>>is not part of the ConEx charter. So, those=20 >>>focusing solely on the charter can stop reading now if they want. >>> >>>But I want to briefly review your proposal=20 >>>anyway, mainly to record on the mailing list=20 >>>what I believe is the current status of ECN deployment problems. >>> >>>If I can summarise your proposal, I believe=20 >>>the main proposed new requirement is that we=20 >>>should work on a congestion notification=20 >>>architecture that looks something like this: >>> >>>+--------------------------------------------------------------<---+ >>>| +---<----+ ^ >>>| / ^ | >>>| | |ECN_S ECN_R | >>>V V | --------------> | >>> S ---> S's access net ---> core ... core ---> R's access net ---> R >>> >>>Where ECN_S and ECN_R are congestion=20 >>>notification channels from the respective=20 >>>access networks of the sender S and receiver R=20 >>>directly to S and R. I believe the proposal is=20 >>>currently agnostic to whether ECN_R is in-band=20 >>>or out-of-band, but clearly ECN_S must be out-of-band. >>> >>>Is the stated problem solved by this proposal? >>>---------------------------------------------- >>>The stated problem this proposal aims to solve is: >>>- congestion is mostly in access networks >>>- ECN sometimes does not get through certain=20 >>>middleboxes that do not support ECN. >>> >>>I agree with both statements, but there seems=20 >>>to be a misconception in the document about=20 >>>what it means for a router, switch or middlebox to 'not support' ECN. >>> >>>ECN incremental deployment design >>>--------------------------------- >>>ECN was designed for incremental deployment=20 >>>where some, most or all routers or middleboxes=20 >>>do not do ECN marking. If both endpoints=20 >>>support ECN, they should be able to exchange=20 >>>packets between themselves that are=20 >>>ECN-capable (with an ECN-capable transport or=20 >>>ECT codepoint set) whatever network support there is for ECN between= them. >>> >>>ECN was designed so that network equipment=20 >>>that has not been upgraded to mark the ECN=20 >>>field during congestion would silently forward=20 >>>ECN-capable packets when not congested and=20 >>>drop them during congestion - no different to=20 >>>any non-ECN-capable packets with the ECN field cleared (Not-ECT). >>> >>>Ways to 'not support' ECN >>>------------------------- >>>Network equipment can 'not support' ECN in three ways: >>>1) lacks ECN: not yet upgraded to do ECN marking. >>>2) prevents ECN (a bug): middlebox tampers=20 >>>with endpoint attempts to send ECN-capable packets. Three known= sub-cases: >>> 2a) ECN-TCP drop: drops SYNs attempting to negotiate ECN in the TCP= header >>> 2b) ECN-IP drop: drops packets with ECN-capable codepoint in IP header >>> 2c) ECN-IP normalise: reverts ECN-capable packets to Not-ECT in IP= header >>>3) crashes with ECN (a bug): an endpoint=20 >>>attempt to negotiate ECN in the TCP header crashes a middlebox >>> >>>Case 1) is normal and is by far the most=20 >>>prevalent. ECN's incremental deployment design=20 >>>(above) copes with this just fine. >>> >>>Case 2) happens in a small number of cases: >>>* Until about 2005-6 there were a number of=20 >>>enterprise-grade firewalls and NATs that did=20 >>>this, but tests showed their rules got=20 >>>upgraded over time and it was no longer a problem. >>>* It is however still a problem with about=20 >>>five popular models of home gateway from those=20 >>>days that will take some time to be discarded from most homes. >>>* Recently, a new problem has appeared on=20 >>>paths that were previously OK. It is thought=20 >>>this may be a buggy attempt to zero the=20 >>>Diffserv codepoint, which is also accidentally=20 >>>clearing the ECN field in the IP header. >>> >>>Case 3) happens in one known case of one model=20 >>>of a home gateway that was popularly deployed a few years ago. >>> >>>Equipment on the path exhibiting Case 2)=20 >>>behaviour can be detected by ECN black-hole=20 >>>detection code on the end-system, reverting a=20 >>>flow to Not-ECT in order to get packets=20 >>>through. There are black-hole detection=20 >>>patches for Linux, but black-hole detection is=20 >>>not configured by default with the mainline code. The >>> >>>The home gateway that crashes on seeing ECN in=20 >>>the TCP header of a SYN (Case 3) is more=20 >>>problematic. ECN is turned off by default for=20 >>>the client end of TCP connections in Windows=20 >>>and Linux because of this single popular=20 >>>bugged home gateway. It should be possible to=20 >>>do some heuristic test to detect if the=20 >>>offending model is on your home network=20 >>>(perhaps using uPNP or checking whether the=20 >>>MAC address falls within a known range). But=20 >>>AFAIK, no code is available to do this. >>> >>>Again, is the stated problem solved by this proposal? >>>----------------------------------------------------- >>>The proposal seems to be focused particularly=20 >>>on 3GPP, where AFAIK there are no ECN=20 >>>deployment problems that are not under the=20 >>>control of the network operators who could upgrade and fix them quickly. >>> >>>I believe that introducing a new way to signal=20 >>>ECN would encounter as many deployment=20 >>>problems, if not more, than persevering with=20 >>>deployment of the existing way to do ECN. >>> >>>Is backward ECN a good idea anyway? >>>----------------------------------- >>>The backward messages I have termed ECN_S in=20 >>>your proposal are reminiscent of ICMP source=20 >>>quench messages. SQ was deprecated for a=20 >>>number of reasons that also all apply to your proposal: >>>* SQ violates layering (congestion control is=20 >>>assumed to be end to end in the Internet=20 >>>Architecture), so it can interact badly with=20 >>>IPsec encryption and tunneling, making it=20 >>>difficult to address the message back to the=20 >>>process on the host generating the load. >>>* ICMP packet creation is normally (always)=20 >>>implemented on the ingress interface of a=20 >>>router. Congestion is detected on the egress,=20 >>>where it is too late, and too expensive wrt.=20 >>>critical processing time, to trigger the=20 >>>creation and sending of an ICMP packet,=20 >>>without hugely re-working the implementation architecture of most= routers. >>>* SQ creates more data (although admittedly in=20 >>>the other direction) during congestion, which is generally to be avoided. >>>* SQ may get lost, and there's no 'end-middle'=20 >>>reliable channel between source and bottleneck to recover losses. >>>* SQ messages can be maliciously sent to hosts=20 >>>as if they came from an on-path router, thus=20 >>>creating a DoS vulnerability. To solve this=20 >>>would require a complicated security=20 >>>association between the SQ message and the packet stream it refers to. >>>* SQ messages are invariably discarded by=20 >>>firewalls, mostly because they can be spoofed (previous point). >>> >>>See <=20 >>>http://www.ietf.org/mail-archive/web/ternli/current/msg00036.html>=20 >>>for the history of ICMP SQ. >>> >>>In summary, I don't believe your proposal is a=20 >>>good way to solve the problems it identifies. >>> >>>Cheers >>> >>> >>>Bob >>> >>>At 11:53 06/07/2010, Zhu Lei wrote: >>>>Hi all, >>>> >>>>We already had some discussions which may=20 >>>>allow wireless access networks to notify congestions in mail list. >>>> >>>>I personally think that Conex charter is=20 >>>>asking some solutions by stating "However,=20 >>>>the CONEX WG will initially focus on one use=20 >>>>case, where the end hosts and the network=20 >>>>that contains the destination end host are=20 >>>>CONEX-enabled but other networks need not be." >>>> >>>>I have an individual draft which introduces=20 >>>>some ideas for next f2f meeting. I'd like to=20 >>>>ask you to review this short document and=20 >>>>help identify the problems which could be resolved in Conex wg. Thank= you! >>>> >>>>draft-lei-ecn-localised-congestion-notification-00 >>>>Hope have your feedback soon. >>>> >>>>Best regards, >>>>Lei Zhu >>>> >>>> >>>>_______________________________________________ >>>>conex mailing list >>>>conex@ietf.org >>>>https://www.ietf.org/mailman/listinfo/conex >>> >>>________________________________________________________________ >>>Bob Briscoe, BT Innovate & Design >> >>________________________________________________________________ >>Bob Briscoe, BT Innovate & Design > >________________________________________________________________ >Bob Briscoe, BT Innovate & Design ________________________________________________________________ Bob Briscoe, BT Innovate & Design=20 --=====================_88864270==.ALT Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Lei,

May-be I had better wait until your presentation - I don't understand the bullets without the extended words behind them.

But again, I don't think ConEx is the right place for this. If there's something to change in ECN that affects the IP layer, it would probably be done in tsvwg.

The main point of my original mail was that the problem you *seem* to be trying to solve is not a problem. So I would first like to see your statement of precisely what problem you are trying to solve, before discussing solutions to something that may not need solving.


Bob

At 08:22 20/07/2010, Zhu Lei wrote:
=EF=BB=BF
Hi Bob,
 
I send this e-mail for clarfication of the solutions in the mind.
 
I am try to make sure that the impact on existing solution is minimum, even no needs to change endpoints behaviors. The backward ECN is also not expected to be used. You may see the following text in slides for f2f meeting. Others related to background and statements to be concluded are more difficult. To be honest, I am thinking your suggestions in last e-mail and if we have a proper solution satisfy everybody.
 
=95Highlight:
=C2=A7Negotiation of ECN only for local access network is kept to be OPE= N for access network system;
=C2=A7Others(no changes):
qUse  IPv4 TOS or IPv6 Traffic Class Octet to encode one of the ECN values
qFor TCP, use two flags in the TCP header to signal the sender to reduce the amount of information it sends.
q
=95Impacts on existing solutions
=C2=A7No changes to existing ECN mechanism:
qNo changes to endpoints, no changes to intermediate nodes.
=C2=A7NOTE: only impact on the endpoints and access networks which are proposed to notify localized congestion to endpoints.
 
 

Best regards,
Zhu Lei

=E5=8F=91=E4=BB=B6=E4=BA=BA: Bob Briscoe [ mailto:rbriscoe@jungle.bt.co.uk]
=E5=8F=91=E9=80=81=E6=97=B6=E9=97=B4: 2010=E5=B9=B47=E6=9C=8820=E6=97= =A5 2:41
=E6=94=B6=E4=BB=B6=E4=BA=BA: Zhu Lei
=E6=8A=84=E9=80=81: conex@ietf.org
=E4=B8=BB=E9=A2=98: Re: [conex] An individual for your review

Lei,

At 04:12 19/07/2010, Zhu Lei wrote:
=C3=AF=C2=BB=C2=BF
Hi,
 
If possible, I want to see more historical drafts related to the crosslayer ideas and thoughts.

The refs in Pasi's draft cover all I know of, AFAIK.

I think that S must be ECN enabled in any cases. It is important for ECN_S knows it and is capable to notify access congestion by sending ECN marks with TCP respones.

I agree that the current design cannot use ECN in a flow of packets for which the sender is ECN-capable but the receiver is not.

But I don't believe it will make deployment any easier if we introduce backward ECN_S feedback. Then packets will have to signal whether the router should do forward or backward feedback. Because a router must not do both, otherwise it will double the amount of congestion signalled. We don't have room in the packet to switch between forward and backward feedback. And if we did take a new approach, it would require another decade to wait for routers to be deployed that understand this new feature.

If deployment is taking a long time, we need to understand *why* before proposing changes that will make deployment take even longer and be more complicated.

But most importantly, I listed problems with backward feedback, which ALL must to be solved first. And they are ALL very good reasons against backward feedback. So please address them all before taking this further.


The problem meet is how to know possibilities to receive congestion notification sent by access node(s) by UE. I personally want to oen it for access network(e.g. link layer) in Conex working group.

The ConEx group is not chartered to work on changes to ECN. Chartering is a careful process that takes account of everyone's views and results in a precise set of work items.

For example, a statement would be useful for people working in access network who know the ECN solution might be used to notifiy access network congestion only.

I wrote my my original review email very carefully to explain how ECN incremental deployment is designed to work (to save you reading RFC3168). There is nothing in the original ECN design to stop only access network nodes being ECN enabled and other network nodes not being ECN enabled. Indeed, that's how I would expect ECN to be deployed first - by enabling ECN on the nodes that are most likely to be congested.

Then, if there is any unexpected congestion (e.g. in the core), the endpoints will see the drop from that, as well as ECN markings from the access networks.

As I said, the problem (at least as stated in your draft) is already solved by the original design of ECN.


Bob



Best regards,
Zhu Lei

=C3=A5=C2=8F=E2=80=98=C3=A4=C2=BB=C2=B6=C3=A4=C2=BA=C2=BA:= Bob Briscoe [ mailto:rbriscoe@jungle.bt.co.uk]
=C3=A5=C2=8F=E2=80=98=C3=A9=80=C2=81=C3=A6=97=C2=B6=C3=C2=B6=C3=A9=97=C2= =B4: 2010=C3=A5=C2=B9=C2=B47=C3=A6=9C=8816=C3=A6=97=C2=A5 19:46
=C3=A6=E2=80=9D=C2=B6=C3=A4=C2=BB=C2=B6=C3=A4=C2=BA=C2=BA: Zhu= Lei
=C3=A6=8A=84=C3=A9=80=C2=81: > conex@ietf.org
=C3=A4=C2=B8=C2=BB=C3=A9=C2=A2=98: Re: [conex] An individual for your= review

Lei,

The reason I said ECN_S must clearly be out of band is that, by definition in-band means within the packets travelling from S to R.

If you mean in-band in the packets travelling from R to S, the congested node may not be on the route of packets between R and S, which need not follow the reverse route of the forward path between S and R.

I think you will find that this expired I-D from Pasi Sarolahti is very relevant:
Transport-layer Considerations for Explicit Cross-layer Indications
< https://datatracker.ietf.org/doc/draft-sarolahti-tsvwg-crosslayer/ >


Bob

At 08:47 16/07/2010, Zhu Lei wrote:
Hi Bob and all,
 
Thank you for identifing some problems of ECN, especially mentioned some historical technical discussions which I never heard previously.
 
The problems of ECN at the moment are clearly summerised and clarified by Bob. I should follow the directions together with issues which is to be solved.
 
I have to say the understanding of the "proposal" is mainly correct. I highly appreciate the draft proposal and problem statement in previous e-mail. We at least need some statement in use cases draft.
 
The possible technical proposal of my mind is little bit different from the picture. The major difference is that the ECN_S could be not out-of-band. And, I also don't think that the ICMP is the approach. I personlly want the in-band trasnportation of ECN mark.
 
The document seems hint the proposal, but the intention of the submitted document is to introduce the requirements. I would try to write a technical proposal in ML soon. The slides for presentation take me time due to my native language.
 
I appologize for some delay of replying e-mail since I should have some works for internal guys in parallel.
 
Best regards,
Lei


=C3=82=C2=B7=C3=82=C2=A2=C3=82=C2=BC=C3=83=C2=BE=C3=83=88= =C3=83=E2=80=B9: Bob Briscoe [ mailto:rbriscoe@jungle.bt.co.uk]
=C3=82=C2=B7=C3=82=C2=A2=C3=83=E2=80=B9=C3=83=C2=8D=C3=83=8A=C3=82=C2=B1= =C3=82=C2=BC=C3=83=C2=A4: 2010=C3=83=84=C3=83=C2=AA7=C3=83=E2=80=9D=C3= =83=8214=C3=83=CB=C3=83=CB=86=C3=83=95 17:55
=C3=83=8A=C3=83=95=C3=82=C2=BC=C3=83=C2=BE=C3=83=88=83=CB=86=C3=83=E2=80= =B9: Zhu Lei
=C3=82=C2=B3=AD=C3=83=E2=80=B9=C3=83=C2=8D: conex@ietf.org
=C3=83=96=C3=83=C2=B7=C3=83=8C=C3=83=C2=A2:=A2: Re: [conex] An= individual for your review

Zhu,

Hi. I read your individual draft last night.
draft-lei-ecn-localised-congestion-notification-00

First, we should be clear that working on new data plane congestion notification technology is not part of the ConEx charter. So, those focusing solely on the charter can stop reading now if they want.

But I want to briefly review your proposal anyway, mainly to record on the mailing list what I believe is the current status of ECN deployment problems.

If I can summarise your proposal, I believe the main proposed new requirement is that we should work on a congestion notification architecture that looks something like this:

+--------------------------------------------------------------<---+
|   +---<----+          &nb= sp;            &= nbsp;            = ;            &nb= sp;    ^
|  /         ^            &nb= sp;            &= nbsp;            = ;            &nb= sp;  |
| |          |ECN_S           &nbs= p;            &n= bsp;           ECN_R       |
V V          |            &nb= sp;            &= nbsp;           --------------> |
 S ---> S's access net ---> core ... core ---> R's access net ---> R

Where ECN_S and ECN_R are congestion notification channels from the respective access networks of the sender S and receiver R directly to S and R. I believe the proposal is currently agnostic to whether ECN_R is in-band or out-of-band, but clearly ECN_S must be out-of-band.

Is the stated problem solved by this proposal?
----------------------------------------------
The stated problem this proposal aims to solve is:
- congestion is mostly in access networks
- ECN sometimes does not get through certain middleboxes that do not support ECN.

I agree with both statements, but there seems to be a misconception in the document about what it means for a router, switch or middlebox to 'not support' ECN.

ECN incremental deployment design
---------------------------------
ECN was designed for incremental deployment where some, most or all routers or middleboxes do not do ECN marking. If both endpoints support ECN, they should be able to exchange packets between themselves that are ECN-capable (with an ECN-capable transport or ECT codepoint set) whatever network support there is for ECN between them.

ECN was designed so that network equipment that has not been upgraded to mark the ECN field during congestion would silently forward ECN-capable packets when not congested and drop them during congestion - no different to any non-ECN-capable packets with the ECN field cleared (Not-ECT).

Ways to 'not support' ECN
-------------------------
Network equipment can 'not support' ECN in three ways:
1) lacks ECN: not yet upgraded to do ECN marking.
2) prevents ECN (a bug): middlebox tampers with endpoint attempts to send ECN-capable packets. Three known sub-cases:
 2a) ECN-TCP drop: drops SYNs attempting to negotiate ECN in the TCP header
 2b) ECN-IP drop: drops packets with ECN-capable codepoint in IP header
 2c) ECN-IP normalise: reverts ECN-capable packets to Not-ECT in IP header
3) crashes with ECN (a bug): an endpoint attempt to negotiate ECN in the TCP header crashes a middlebox

Case 1) is normal and is by far the most prevalent. ECN's incremental deployment design (above) copes with this just fine.

Case 2) happens in a small number of cases:
* Until about 2005-6 there were a number of enterprise-grade firewalls and NATs that did this, but tests showed their rules got upgraded over time and it was no longer a problem.
* It is however still a problem with about five popular models of home gateway from those days that will take some time to be discarded from most homes.
* Recently, a new problem has appeared on paths that were previously OK. It is thought this may be a buggy attempt to zero the Diffserv codepoint, which is also accidentally clearing the ECN field in the IP header.

Case 3) happens in one known case of one model of a home gateway that was popularly deployed a few years ago.

Equipment on the path exhibiting Case 2) behaviour can be detected by ECN black-hole detection code on the end-system, reverting a flow to Not-ECT in order to get packets through. There are black-hole detection patches for Linux, but black-hole detection is not configured by default with the mainline code. The

The home gateway that crashes on seeing ECN in the TCP header of a SYN (Case 3) is more problematic. ECN is turned off by default for the client end of TCP connections in Windows and Linux because of this single popular bugged home gateway. It should be possible to do some heuristic test to detect if the offending model is on your home network (perhaps using uPNP or checking whether the MAC address falls within a known range). But AFAIK, no code is available to do this.

Again, is the stated problem solved by this proposal?
-----------------------------------------------------
The proposal seems to be focused particularly on 3GPP, where AFAIK there are no ECN deployment problems that are not under the control of the network operators who could upgrade and fix them quickly.

I believe that introducing a new way to signal ECN would encounter as many deployment problems, if not more, than persevering with deployment of the existing way to do ECN.

Is backward ECN a good idea anyway?
-----------------------------------
The backward messages I have termed ECN_S in your proposal are reminiscent of ICMP source quench messages. SQ was deprecated for a number of reasons that also all apply to your proposal:
* SQ violates layering (congestion control is assumed to be end to end in the Internet Architecture), so it can interact badly with IPsec encryption and tunneling, making it difficult to address the message back to the process on the host generating the load.
* ICMP packet creation is normally (always) implemented on the ingress interface of a router. Congestion is detected on the egress, where it is too late, and too expensive wrt. critical processing time, to trigger the creation and sending of an ICMP packet, without hugely re-working the implementation architecture of most routers.
* SQ creates more data (although admittedly in the other direction) during congestion, which is generally to be avoided.
* SQ may get lost, and there's no 'end-middle' reliable channel between source and bottleneck to recover losses.
* SQ messages can be maliciously sent to hosts as if they came from an on-path router, thus creating a DoS vulnerability. To solve this would require a complicated security association between the SQ message and the packet stream it refers to.
* SQ messages are invariably discarded by firewalls, mostly because they can be spoofed (previous point).

See < http://www.ietf.org/mail-archive/web/ternli/current/msg00036.html> for the history of ICMP SQ.

In summary, I don't believe your proposal is a good way to solve the problems it identifies.

Cheers


Bob

At 11:53 06/07/2010, Zhu Lei wrote:
Hi all,
 
We already had some discussions which may allow wireless access networks to notify congestions in mail list.
 
I personally think that Conex charter is asking some solutions by stating "However, the CONEX WG will initially focus on one use case, where the end hosts and the network that contains the destination end host are CONEX-enabled but other networks need not be."
 
I have an individual draft which introduces some ideas for next f2f meeting. I'd like to ask you to review this short document and help identify the problems which could be resolved in Conex wg. Thank you!
 
draft-lei-ecn-localised-congestion-notification-00
Hope have your feedback soon.
 
Best regards,
Lei Zhu

 
_______________________________________________
conex mailing list
conex@ietf.org
https://www.ietf.org/mailman/listinfo/conex

________________________________________________________________
Bob Briscoe,           &n= bsp;            =         BT Innovate & Design

________________________________________________________________
Bob Briscoe,           &n= bsp;            =         BT Innovate & Design

________________________________________________________________
Bob Briscoe,           &n= bsp;            =         BT Innovate & Design

________________________________________________________________
Bob Briscoe,           &n= bsp;            =         BT Innovate & Design --=====================_88864270==.ALT-- From rbriscoe@jungle.bt.co.uk Fri Jul 23 15:35:29 2010 Return-Path: X-Original-To: conex@core3.amsl.com Delivered-To: conex@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id F07E83A68D3 for ; Fri, 23 Jul 2010 15:35:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.075 X-Spam-Level: X-Spam-Status: No, score=-0.075 tagged_above=-999 required=5 tests=[AWL=-0.559, BAYES_50=0.001, DNS_FROM_RFC_BOGUSMX=1.482, HTML_MESSAGE=0.001, 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 ydzXalZoL4c3 for ; Fri, 23 Jul 2010 15:35:22 -0700 (PDT) Received: from smtp1.smtp.bt.com (smtp1.smtp.bt.com [217.32.164.137]) by core3.amsl.com (Postfix) with ESMTP id 30F413A67EB for ; Fri, 23 Jul 2010 15:35:21 -0700 (PDT) Received: from i2kc06-ukbr.domain1.systemhost.net ([193.113.197.70]) by smtp1.smtp.bt.com with Microsoft SMTPSVC(6.0.3790.4675); Fri, 23 Jul 2010 23:35:39 +0100 Received: from cbibipnt05.iuser.iroot.adidom.com ([147.149.196.177]) by i2kc06-ukbr.domain1.systemhost.net with Microsoft SMTPSVC(6.0.3790.4675); Fri, 23 Jul 2010 23:35:39 +0100 Received: From bagheera.jungle.bt.co.uk ([132.146.168.158]) by cbibipnt05.iuser.iroot.adidom.com (WebShield SMTP v4.5 MR1a P0803.399); id 1279924537423; Fri, 23 Jul 2010 23:35:37 +0100 Received: from MUT.jungle.bt.co.uk ([10.215.130.87]) by bagheera.jungle.bt.co.uk (8.13.5/8.12.8) with ESMTP id o6NMZZ1e015875; Fri, 23 Jul 2010 23:35:35 +0100 Message-Id: <201007232235.o6NMZZ1e015875@bagheera.jungle.bt.co.uk> X-Mailer: QUALCOMM Windows Eudora Version 7.1.0.9 Date: Fri, 23 Jul 2010 23:35:33 +0100 To: Nandita Dukkipati From: Bob Briscoe In-Reply-To: References: <201007231949.o6NJn38t014418@bagheera.jungle.bt.co.uk> Mime-Version: 1.0 Content-Type: multipart/alternative; boundary="=====================_367890228==.ALT" X-Scanned-By: MIMEDefang 2.56 on 132.146.168.158 X-OriginalArrivalTime: 23 Jul 2010 22:35:39.0016 (UTC) FILETIME=[601E2080:01CB2AB7] Cc: "conex@ietf.org" Subject: Re: [conex] Intent of charter: division of concepts across docs X-BeenThere: conex@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Congestion Exposure working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 23 Jul 2010 22:35:29 -0000 --=====================_367890228==.ALT Content-Type: text/plain; charset="us-ascii"; format=flowed Nandita, [Adding the list] My prejudices go like this: >- Which doc should aim to be a stand-alone introduction to ConEx? * Use-cases (the one we've written covers "Concepts and Use-cases", which allows us to make it an introductory doc) also, Abstract ConEx Mechanism should be possible to understand without having read use-cases first, but I imagine it will be more focused just on the mechanisms, not why they are there, nor different ways they might go together. >- Which doc would be best to define ConEx terminology? * Abstract ConEx mechanism But, as use-cases has to go first, it will have to define terminology for its own use. So we should try to have a decent version of the Abstract ConEx mechanism before w-g submits use-cases for RFC. >- Where should we discuss incremental deployment and deployment incentives. > (is use-cases more about *what* ConEx is used for than *how* it's used) > (we surely want a more detailed check on incremental deployability > once we've defined the detailed protocol) Multiple places with increasing degress of solidity: * In use-cases (with some vagueness allowed) * In each experimental track doc, protocol specifics for partial deployment have to be defined * In one or more of the informational evaluation docs, I would expect to see a more precise evaluation of how well a partial deployment worked, or whether there were incentives to start deployment and so forth. Bob At 21:21 23/07/2010, Nandita Dukkipati wrote: >Bob, > >That's a great question and I believe we should set aside time in >the WG for this discussion. Given that we have ~40 mins. left in the >slot, I don't see an issue time wise. Marcello may comment as well. > >That said, could you come up with a plan (and post to the list) on >what would be the most logical way of mapping these questions to the >chartered documents. The discussion will be more focussed and >targeted if we begin with your plan as starting point. > >Thanks, >-Nandita > >On Fri, Jul 23, 2010 at 12:49 PM, Bob Briscoe ><rbriscoe@jungle.bt.co.uk> wrote: >Nandita, Marcelo, > >I want to start a discussion for anyone on the list, but you (the >chairs) may have initial views to kick this off. > >It's not immediately obvious in which of the 4 chartered docs the >following concepts belong (if indeed we choose to write exactly the >same number of docs as there are bullet pointed docs in the charter): > >- Which doc should aim to be a stand-alone introduction to ConEx? >- Which doc would be best to define ConEx terminology? >- Where should we discuss incremental deployment and deployment incentives. > (is use-cases more about *what* ConEx is used for than *how* it's used) > (we surely want a more detailed check on incremental deployability > once we've defined the detailed protocol) > >These questions have arisen in writing draft-moncaster-conex-concepts-uses > >Do you intend to put aside some time in the w-g on Tue for >discussing these sort of doc co-ordinating questions? > > >Bob > > >________________________________________________________________ >Bob Briscoe, BT Innovate & Design > ________________________________________________________________ Bob Briscoe, BT Innovate & Design --=====================_367890228==.ALT Content-Type: text/html; charset="us-ascii" Nandita,

[Adding the list]

My prejudices go like this:

- Which doc should aim to be a stand-alone introduction to ConEx?

* Use-cases (the one we've written covers "Concepts and Use-cases", which allows us to make it an introductory doc)

also, Abstract ConEx Mechanism should be possible to understand without having read use-cases first, but I imagine it will be more focused just on the mechanisms, not why they are there, nor different ways they might go together.

- Which doc would be best to define ConEx terminology?

* Abstract ConEx mechanism

But, as use-cases has to go first, it will have to define terminology for its own use. So we should try to have a decent version of the Abstract ConEx mechanism before w-g submits use-cases for RFC.

- Where should we discuss incremental deployment and deployment incentives.
 (is use-cases more about *what* ConEx is used for than *how* it's used)
 (we surely want a more detailed check on incremental deployability once we've defined the detailed protocol)

Multiple places with increasing degress of solidity:
* In use-cases (with some vagueness allowed)
* In each experimental track doc, protocol specifics for partial deployment have to be defined
* In one or more of the informational evaluation docs, I would expect to see a more precise evaluation of how well a partial deployment worked, or whether there were incentives to start deployment and so forth.



Bob

At 21:21 23/07/2010, Nandita Dukkipati wrote:
Bob,

That's a great question and I believe we should set aside time in the WG for this discussion. Given that we have ~40 mins. left in the slot, I don't see an issue time wise. Marcello may comment as well.

That said, could you come up with a plan (and post to the list) on what would be the most logical way of mapping these questions to the chartered documents. The discussion will be more focussed and targeted if we begin with your plan as starting point.

Thanks,
-Nandita

On Fri, Jul 23, 2010 at 12:49 PM, Bob Briscoe <rbriscoe@jungle.bt.co.uk > wrote:
Nandita, Marcelo,

I want to start a discussion for anyone on the list, but you (the chairs) may have initial views to kick this off.

It's not immediately obvious in which of the 4 chartered docs the following concepts belong (if indeed we choose to write exactly the same number of docs as there are bullet pointed docs in the charter):

- Which doc should aim to be a stand-alone introduction to ConEx?
- Which doc would be best to define ConEx terminology?
- Where should we discuss incremental deployment and deployment incentives.
 (is use-cases more about *what* ConEx is used for than *how* it's used)
 (we surely want a more detailed check on incremental deployability once we've defined the detailed protocol)

These questions have arisen in writing draft-moncaster-conex-concepts-uses

Do you intend to put aside some time in the w-g on Tue for discussing these sort of doc co-ordinating questions?


Bob


________________________________________________________________
Bob Briscoe,                                BT Innovate & Design

________________________________________________________________
Bob Briscoe,                                BT Innovate & Design --=====================_367890228==.ALT-- From john@jlc.net Fri Jul 23 16:54:30 2010 Return-Path: X-Original-To: conex@core3.amsl.com Delivered-To: conex@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 5C3453A67FB for ; Fri, 23 Jul 2010 16:54:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.666 X-Spam-Level: X-Spam-Status: No, score=-3.666 tagged_above=-999 required=5 tests=[AWL=0.333, BAYES_50=0.001, RCVD_IN_DNSWL_MED=-4] 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 vvTWo9iK-Y4y for ; Fri, 23 Jul 2010 16:54:29 -0700 (PDT) Received: from mailhost.jlc.net (mailhost.jlc.net [199.201.159.4]) by core3.amsl.com (Postfix) with ESMTP id 253593A67E7 for ; Fri, 23 Jul 2010 16:54:29 -0700 (PDT) Received: by mailhost.jlc.net (Postfix, from userid 104) id 07B4333C67; Fri, 23 Jul 2010 19:54:48 -0400 (EDT) Date: Fri, 23 Jul 2010 19:54:48 -0400 From: John Leslie To: Bob Briscoe Message-ID: <20100723235447.GE69747@verdi> References: <201007231949.o6NJn38t014418@bagheera.jungle.bt.co.uk> <201007232235.o6NMZZ1e015875@bagheera.jungle.bt.co.uk> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <201007232235.o6NMZZ1e015875@bagheera.jungle.bt.co.uk> User-Agent: Mutt/1.4.1i Cc: "conex@ietf.org" Subject: Re: [conex] Intent of charter: division of concepts across docs X-BeenThere: conex@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Congestion Exposure working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 23 Jul 2010 23:54:30 -0000 Bob Briscoe wrote: > > My prejudices go like this: > >> - Which doc should aim to be a stand-alone introduction to ConEx? > > * Use-cases (the one we've written covers "Concepts and Use-cases", > which allows us to make it an introductory doc) I think the rest of the authors agree: I certainly do. > also, Abstract ConEx Mechanism should be possible to understand > without having read use-cases first, but I imagine it will be more > focused just on the mechanisms, not why they are there, nor different > ways they might go together. The Mechanism document will get specific about a number of things we've intentionally left vague so far, but IMHO it shouldn't go into detail about _why_ you might use the mechanisms. >> - Which doc would be best to define ConEx terminology? > > * Abstract ConEx mechanism A perhaps surprisingly important issue... > But, as use-cases has to go first, it will have to define terminology > for its own use. So we should try to have a decent version of the > Abstract ConEx mechanism before w-g submits use-cases for RFC. So far, Use-Cases has defined terminology "for its own use," and this has made Bob uneasy. He's quite determined that the "real" definitions should provably deliver what they promise, and fears that the Use-Cases definitions will imply promises to deliver something we can't deliver. I, at least, and the rest of the authors to some extent, believe that definitions can evolve as the WG progresses. For one obvious example, I have pretty strong opinions an what "congestion" should mean in its "real" definition; but I am not concerned as we run through much-less-rigorous mini-definitions in early documents. I would not tend to support holding up the Use-Cases document for nailing down details of definitions of terms in some later document. >> - Where should we discuss incremental deployment and deployment >> incentives. (is use-cases more about *what* ConEx is used for >> than *how* it's used) We could use some WG guidance here. The _question_ of deployability must be tackled in the Use-Cases document, but it seems to me to be inappropriate to lay out many details of deployment (not least since actual deployment won't follow our plan anyway). I'd like to punt most of the details to another document... >> (we surely want a more detailed check on incremental >> deployability once we've defined the detailed protocol) I agree with Bob here. > Multiple places with increasing degress of solidity: > * In use-cases (with some vagueness allowed) I'd go for "quite a bit" of vagueness... > * In each experimental track doc, protocol specifics for partial > deployment have to be defined I agree with Bob here. > * In one or more of the informational evaluation docs, I would > expect to see a more precise evaluation of how well a partial > deployment worked, or whether there were incentives to start > deployment and so forth. "Worked so far," of course... I agree with Bob that review of how deployment is coming along is essential; and I despair of predicting what this will show. I _have_ considered deployment incentives at length, but I'm disinclined to put much of my musings into the Use-Cases document. A deployment plan is an essential piece of the Experiment-track documents we will write; and it should be specific enough to report to what extent the experiment succeeds in deployment. -- John Leslie From rbriscoe@jungle.bt.co.uk Sat Jul 24 02:51:28 2010 Return-Path: X-Original-To: conex@core3.amsl.com Delivered-To: conex@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 23FBE3A6816 for ; Sat, 24 Jul 2010 02:51:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.351 X-Spam-Level: X-Spam-Status: No, score=-1.351 tagged_above=-999 required=5 tests=[AWL=0.766, BAYES_00=-2.599, DNS_FROM_RFC_BOGUSMX=1.482, 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 T4kM8wv08cu1 for ; Sat, 24 Jul 2010 02:51:22 -0700 (PDT) Received: from smtp1.smtp.bt.com (smtp1.smtp.bt.com [217.32.164.137]) by core3.amsl.com (Postfix) with ESMTP id EA8713A68B3 for ; Sat, 24 Jul 2010 02:51:21 -0700 (PDT) Received: from i2kc08-ukbr.domain1.systemhost.net ([193.113.197.71]) by smtp1.smtp.bt.com with Microsoft SMTPSVC(6.0.3790.4675); Sat, 24 Jul 2010 10:51:39 +0100 Received: from cbibipnt08.iuser.iroot.adidom.com ([147.149.100.81]) by i2kc08-ukbr.domain1.systemhost.net with Microsoft SMTPSVC(6.0.3790.4675); Sat, 24 Jul 2010 10:51:39 +0100 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 1279965098176; Sat, 24 Jul 2010 10:51:38 +0100 Received: from MUT.jungle.bt.co.uk ([10.142.208.181]) by bagheera.jungle.bt.co.uk (8.13.5/8.12.8) with ESMTP id o6O9paf1021246; Sat, 24 Jul 2010 10:51:37 +0100 Message-Id: <201007240951.o6O9paf1021246@bagheera.jungle.bt.co.uk> X-Mailer: QUALCOMM Windows Eudora Version 7.1.0.9 Date: Sat, 24 Jul 2010 10:51:37 +0100 To: John Leslie From: Bob Briscoe In-Reply-To: <20100723235447.GE69747@verdi> References: <201007231949.o6NJn38t014418@bagheera.jungle.bt.co.uk> <201007232235.o6NMZZ1e015875@bagheera.jungle.bt.co.uk> <20100723235447.GE69747@verdi> 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: 24 Jul 2010 09:51:39.0163 (UTC) FILETIME=[CFD966B0:01CB2B15] Cc: "conex@ietf.org" Subject: Re: [conex] Intent of charter: division of concepts across docs X-BeenThere: conex@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Congestion Exposure working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 24 Jul 2010 09:51:28 -0000 John, I agree with you on not holding up use-cases for the sake of terminology definitions in the abstract mechanism doc. That's a message for us to get going with the abstract mech doc, not to hold up use-cases if we don't. I was merely saying *it would be nice" to have a decent version of the abstract mechanisms doc with a decent consensus on what terminology we're going to use before use-cases gets to RFC. If people read use-cases as a gateway into the work, terminology inconsistent with later docs will confuse. Terminology is a non-trivial task for ConEx because there's a fair few new concepts that the IETF doesn't already have words for. Bob At 00:54 24/07/2010, John Leslie wrote: > >> - Which doc would be best to define ConEx terminology? > > > > * Abstract ConEx mechanism > > A perhaps surprisingly important issue... > > > But, as use-cases has to go first, it will have to define terminology > > for its own use. So we should try to have a decent version of the > > Abstract ConEx mechanism before w-g submits use-cases for RFC. > > So far, Use-Cases has defined terminology "for its own use," and >this has made Bob uneasy. He's quite determined that the "real" >definitions should provably deliver what they promise, and fears that >the Use-Cases definitions will imply promises to deliver something we >can't deliver. > > I, at least, and the rest of the authors to some extent, believe >that definitions can evolve as the WG progresses. For one obvious >example, I have pretty strong opinions an what "congestion" should >mean in its "real" definition; but I am not concerned as we run >through much-less-rigorous mini-definitions in early documents. > > I would not tend to support holding up the Use-Cases document >for nailing down details of definitions of terms in some later >document. ________________________________________________________________ Bob Briscoe, BT Innovate & Design From john@jlc.net Sat Jul 24 05:33:25 2010 Return-Path: X-Original-To: conex@core3.amsl.com Delivered-To: conex@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id CA6753A68C2 for ; Sat, 24 Jul 2010 05:33:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.211 X-Spam-Level: X-Spam-Status: No, score=-5.211 tagged_above=-999 required=5 tests=[AWL=1.388, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] 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 sHCaaHmu2nqt for ; Sat, 24 Jul 2010 05:33:20 -0700 (PDT) Received: from mailhost.jlc.net (mailhost.jlc.net [199.201.159.4]) by core3.amsl.com (Postfix) with ESMTP id 345A33A69EE for ; Sat, 24 Jul 2010 05:33:18 -0700 (PDT) Received: by mailhost.jlc.net (Postfix, from userid 104) id 5F65233C3B; Sat, 24 Jul 2010 08:33:37 -0400 (EDT) Date: Sat, 24 Jul 2010 08:33:37 -0400 From: John Leslie To: Bob Briscoe Message-ID: <20100724123337.GI69747@verdi> References: <201007231949.o6NJn38t014418@bagheera.jungle.bt.co.uk> <201007232235.o6NMZZ1e015875@bagheera.jungle.bt.co.uk> <20100723235447.GE69747@verdi> <201007240951.o6O9paf1021246@bagheera.jungle.bt.co.uk> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <201007240951.o6O9paf1021246@bagheera.jungle.bt.co.uk> User-Agent: Mutt/1.4.1i Cc: "conex@ietf.org" Subject: Re: [conex] Intent of charter: division of concepts across docs X-BeenThere: conex@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Congestion Exposure working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 24 Jul 2010 12:33:26 -0000 Bob Briscoe wrote: > > I agree with you on not holding up use-cases for the sake of > terminology definitions in the abstract mechanism doc. > > That's a message for us to get going with the abstract mech doc, not > to hold up use-cases if we don't. I'm nervous about starting into a new document without guidance from the chairs... > I was merely saying *it would be nice" to have a decent version of > the abstract mechanisms doc with a decent consensus on what > terminology we're going to use before use-cases gets to RFC. If > people read use-cases as a gateway into the work, terminology > inconsistent with later docs will confuse. I don't think the confusion is necessarily that bad... > Terminology is a non-trivial task for ConEx because there's a fair > few new concepts that the IETF doesn't already have words for. I agree with that. Might I suggest working on terminology in the ConEx wiki: http://trac.tools.ietf.org/wg/conex/trac/wiki -- John Leslie From nanditad@google.com Sun Jul 25 15:50:43 2010 Return-Path: X-Original-To: conex@core3.amsl.com Delivered-To: conex@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 8A0C03A684C for ; Sun, 25 Jul 2010 15:50:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -105.231 X-Spam-Level: X-Spam-Status: No, score=-105.231 tagged_above=-999 required=5 tests=[AWL=-0.744, BAYES_05=-1.11, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] 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 kzcqyx20R3lg for ; Sun, 25 Jul 2010 15:50:39 -0700 (PDT) Received: from smtp-out.google.com (smtp-out.google.com [216.239.44.51]) by core3.amsl.com (Postfix) with ESMTP id 18EA23A682A for ; Sun, 25 Jul 2010 15:50:36 -0700 (PDT) Received: from wpaz29.hot.corp.google.com (wpaz29.hot.corp.google.com [172.24.198.93]) by smtp-out.google.com with ESMTP id o6PMonHP026343 for ; Sun, 25 Jul 2010 15:50:49 -0700 DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d=google.com; s=beta; t=1280098250; bh=VkXlyigIweYRswIM3trvPiytcKc=; h=MIME-Version:In-Reply-To:References:Date:Message-ID:Subject:From: To:Cc:Content-Type; b=dPoeZsgkRfVB1E+sVhzKnwp3XG5L+mKLDOxp1rFIXpIAZ+aYD7s2eokAiiUm8RksB QdBiT7eDabQNXXZ+G3pGQ== DomainKey-Signature: a=rsa-sha1; s=beta; d=google.com; c=nofws; q=dns; h=mime-version:in-reply-to:references:date:message-id:subject:from:to: cc:content-type:x-system-of-record; b=kALRNwPAOc6YHshiiWKlQy9sRUsOv0ZJ51yjDkqaEwOrhQcEzZJbIER7rXIoQkEjC 7m8xoJcI4MJRGN6+xZdSw== Received: from ywe9 (ywe9.prod.google.com [10.192.5.9]) by wpaz29.hot.corp.google.com with ESMTP id o6PMomi2001412 for ; Sun, 25 Jul 2010 15:50:49 -0700 Received: by ywe9 with SMTP id 9so308621ywe.8 for ; Sun, 25 Jul 2010 15:50:48 -0700 (PDT) MIME-Version: 1.0 Received: by 10.90.80.4 with SMTP id d4mr5163507agb.11.1280098248545; Sun, 25 Jul 2010 15:50:48 -0700 (PDT) Received: by 10.91.37.13 with HTTP; Sun, 25 Jul 2010 15:50:48 -0700 (PDT) In-Reply-To: <201007232235.o6NMZZ1e015875@bagheera.jungle.bt.co.uk> References: <201007231949.o6NJn38t014418@bagheera.jungle.bt.co.uk> <201007232235.o6NMZZ1e015875@bagheera.jungle.bt.co.uk> Date: Sun, 25 Jul 2010 22:50:48 +0000 Message-ID: From: Nandita Dukkipati To: Bob Briscoe Content-Type: multipart/alternative; boundary=00163631092961d71c048c3e1948 X-System-Of-Record: true Cc: "conex@ietf.org" Subject: Re: [conex] Intent of charter: division of concepts across docs X-BeenThere: conex@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Congestion Exposure working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 25 Jul 2010 22:50:43 -0000 --00163631092961d71c048c3e1948 Content-Type: text/plain; charset=ISO-8859-1 On Fri, Jul 23, 2010 at 10:35 PM, Bob Briscoe wrote: > Nandita, > > [Adding the list] > > My prejudices go like this: > > - Which doc should aim to be a stand-alone introduction to ConEx? > > * Use-cases (the one we've written covers "Concepts and Use-cases", which > allows us to make it an introductory doc) > Bob, I believe the use-cases document should be the one landing place for anyone who cares to know the high order bits of ConEx. Therefore, it should have the best possible introduction to ConEx --- my feeling is that pieces of such an Intro. are currently strewn in several disparate documents/papers/slides. I am glad you brought up this question; please give it a thought on what that best stand-alone introduction would look like. -Nandita --00163631092961d71c048c3e1948 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable

On Fri, Jul 23, 2010 at 10:35 PM, Bob Briscoe <rbriscoe@ju= ngle.bt.co.uk> wrote:
Nandita,

[Adding the list]

My prejudices go like this:
- Which doc should aim to be a stand-alone introduction to ConEx?
* Use-cases (the one we've written covers "Concepts and Use-cases", which allows us to make it an introductory doc)
<= /blockquote>

Bob,

I believe the= use-cases document should be the one landing place for anyone who cares to= know the high order bits of ConEx. Therefore, it should have the best poss= ible introduction to ConEx --- my feeling is that pieces of such an Intro. = are currently strewn in several disparate documents/papers/slides.=A0

I am glad you brought up this question; please give it = a thought on what that best stand-alone introduction would look like.
=

-Nandita
--00163631092961d71c048c3e1948-- From nanditad@google.com Sun Jul 25 16:02:53 2010 Return-Path: X-Original-To: conex@core3.amsl.com Delivered-To: conex@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 0B1023A682A for ; Sun, 25 Jul 2010 16:02:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.976 X-Spam-Level: X-Spam-Status: No, score=-101.976 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, USER_IN_WHITELIST=-100] 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 2F0ZRLVkAKjp for ; Sun, 25 Jul 2010 16:02:52 -0700 (PDT) Received: from smtp-out.google.com (smtp-out.google.com [74.125.121.35]) by core3.amsl.com (Postfix) with ESMTP id BD16D3A680D for ; Sun, 25 Jul 2010 16:02:51 -0700 (PDT) Received: from hpaq6.eem.corp.google.com (hpaq6.eem.corp.google.com [172.25.149.6]) by smtp-out.google.com with ESMTP id o6PN3BfJ020994 for ; Sun, 25 Jul 2010 16:03:11 -0700 DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d=google.com; s=beta; t=1280098991; bh=5zp4KwWEqPI7cEU0gpIq2gFN+K4=; h=MIME-Version:In-Reply-To:References:Date:Message-ID:Subject:From: To:Cc:Content-Type; b=k8ykJZKnpUA8WU4O7Q4SaB5pOWzzfP/TdIkmpt+DlMaA8VciMmHCR1ugueTsCPIMg JTeAd6QH+aZfYG4PZldqA== DomainKey-Signature: a=rsa-sha1; s=beta; d=google.com; c=nofws; q=dns; h=mime-version:in-reply-to:references:date:message-id:subject:from:to: cc:content-type:x-system-of-record; b=BIIJJlTbZqgoTRYtM3b3OBsGZ8cyA9Esg81eNJmTkY0PmImFrF2kuobQ6xYup+Iqv E9wMKiLG9oNF1iurTaB8g== Received: from gwb15 (gwb15.prod.google.com [10.200.2.15]) by hpaq6.eem.corp.google.com with ESMTP id o6PN39WB018769 for ; Sun, 25 Jul 2010 16:03:10 -0700 Received: by gwb15 with SMTP id 15so1617934gwb.34 for ; Sun, 25 Jul 2010 16:03:09 -0700 (PDT) MIME-Version: 1.0 Received: by 10.90.50.14 with SMTP id x14mr5143939agx.55.1280098989191; Sun, 25 Jul 2010 16:03:09 -0700 (PDT) Received: by 10.91.37.13 with HTTP; Sun, 25 Jul 2010 16:03:09 -0700 (PDT) In-Reply-To: <20100724123337.GI69747@verdi> References: <201007231949.o6NJn38t014418@bagheera.jungle.bt.co.uk> <201007232235.o6NMZZ1e015875@bagheera.jungle.bt.co.uk> <20100723235447.GE69747@verdi> <201007240951.o6O9paf1021246@bagheera.jungle.bt.co.uk> <20100724123337.GI69747@verdi> Date: Sun, 25 Jul 2010 23:03:09 +0000 Message-ID: From: Nandita Dukkipati To: John Leslie Content-Type: multipart/alternative; boundary=00163630f58b8733d3048c3e454a X-System-Of-Record: true Cc: "conex@ietf.org" Subject: Re: [conex] Intent of charter: division of concepts across docs X-BeenThere: conex@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Congestion Exposure working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 25 Jul 2010 23:02:53 -0000 --00163630f58b8733d3048c3e454a Content-Type: text/plain; charset=ISO-8859-1 John, > I'm nervous about starting into a new document without guidance > from the chairs... > Although we will submit the documents sequentially as per the milestones (use-case description followed by abstract specification and so on), we should work simultaneously on charter items even if their milestones are further along in the process. -Nandita > > I was merely saying *it would be nice" to have a decent version of > > the abstract mechanisms doc with a decent consensus on what > > terminology we're going to use before use-cases gets to RFC. If > > people read use-cases as a gateway into the work, terminology > > inconsistent with later docs will confuse. > > I don't think the confusion is necessarily that bad... > > > Terminology is a non-trivial task for ConEx because there's a fair > > few new concepts that the IETF doesn't already have words for. > > I agree with that. > > Might I suggest working on terminology in the ConEx wiki: > > http://trac.tools.ietf.org/wg/conex/trac/wiki > > -- > John Leslie > --00163630f58b8733d3048c3e454a Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
John,
=A0
=A0 I'm nervous about starting into a new document without guida= nce
from the chairs...

Although we will sub= mit the documents sequentially as per the milestones=A0
(use-case= description followed by abstract specification and so on), we should work<= /div>
simultaneously on charter items even if their milestones are further a= long in the process.

-Nandita

=

> I was merely saying *it would be nice" to have a decent version o= f
> the abstract mechanisms doc with a decent consensus on what
> terminology we're going to use before use-cases gets to RFC. If > people read use-cases as a gateway into the work, terminology
> inconsistent with later docs will confuse.

=A0 I don't think the confusion is necessarily that bad...

> Terminology is a non-trivial task for ConEx because there's a fair=
> few new concepts that the IETF doesn't already have words for.

=A0 I agree with that.

=A0 Might I suggest working on terminology in the ConEx wiki:

http://trac.tools.ietf.org/wg/conex/trac/wiki

--
John Leslie <john@jlc.net>

--00163630f58b8733d3048c3e454a-- From toby@moncaster.com Mon Jul 26 02:53:08 2010 Return-Path: X-Original-To: conex@core3.amsl.com Delivered-To: conex@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 8ABE43A67F1 for ; Mon, 26 Jul 2010 02:53:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.264 X-Spam-Level: X-Spam-Status: No, score=-1.264 tagged_above=-999 required=5 tests=[AWL=0.984, BAYES_00=-2.599, HELO_EQ_DE=0.35, HTML_MESSAGE=0.001] 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 DWXHZpGNgVu9 for ; Mon, 26 Jul 2010 02:53:07 -0700 (PDT) Received: from moutng.kundenserver.de (moutng.kundenserver.de [212.227.126.171]) by core3.amsl.com (Postfix) with ESMTP id 4ADC33A67EE for ; Mon, 26 Jul 2010 02:53:07 -0700 (PDT) Received: from TobysHP (host86-156-248-3.range86-156.btcentralplus.com [86.156.248.3]) by mrelayeu.kundenserver.de (node=mreu1) with ESMTP (Nemesis) id 0LhAEV-1PP3Wj0U9H-00nnH7; Mon, 26 Jul 2010 11:53:27 +0200 From: "Toby Moncaster" To: "'Nandita Dukkipati'" , "'Bob Briscoe'" References: <201007231949.o6NJn38t014418@bagheera.jungle.bt.co.uk> <201007232235.o6NMZZ1e015875@bagheera.jungle.bt.co.uk> In-Reply-To: Date: Mon, 26 Jul 2010 10:53:25 +0100 Message-ID: <001801cb2ca8$64fd4980$2ef7dc80$@com> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0019_01CB2CB0.C6C1B180" X-Mailer: Microsoft Office Outlook 12.0 Thread-Index: AcssS96pn5Ygx8z3Ryq3/LriBs0U3QAW+hDw Content-Language: en-gb X-Provags-ID: V02:K0:tA61g4mvM/JAJQLYwCwez5AA52TAh32QdVFeTTcOtEs mNmsTtgjHB+B0xdcqRuFI6DKQtkVgLJn0kra397IEQW5pXRVAE lDkcYflMgDHT/bN6abWzJX/bXTHaSS8T7OxkRREEJjPn+euJHv 0sfNtEVhA1RgM4PstBPUnbtTxqa1BJAvnqL/xVRAb57VYf193i UHHjqBNL1iB3x3WUHl3dkujPgcTUTEHG3eu+Xzre04= Cc: conex@ietf.org Subject: Re: [conex] Intent of charter: division of concepts across docs X-BeenThere: conex@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Congestion Exposure working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 26 Jul 2010 09:53:08 -0000 This is a multi-part message in MIME format. ------=_NextPart_000_0019_01CB2CB0.C6C1B180 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit That makes the most sense to me. After all this is the first milestone and so (in theory) should exist as a stand-alone document. It does raise an important question for the list: How can we best describe ConEx? Of the many intros that are out there, which seems easiest to understand and which most confusing? Is the current draft going down the right lines? Toby From: conex-bounces@ietf.org [mailto:conex-bounces@ietf.org] On Behalf Of Nandita Dukkipati Sent: 25 July 2010 23:51 To: Bob Briscoe Cc: conex@ietf.org Subject: Re: [conex] Intent of charter: division of concepts across docs On Fri, Jul 23, 2010 at 10:35 PM, Bob Briscoe wrote: Nandita, [Adding the list] My prejudices go like this: - Which doc should aim to be a stand-alone introduction to ConEx? * Use-cases (the one we've written covers "Concepts and Use-cases", which allows us to make it an introductory doc) Bob, I believe the use-cases document should be the one landing place for anyone who cares to know the high order bits of ConEx. Therefore, it should have the best possible introduction to ConEx --- my feeling is that pieces of such an Intro. are currently strewn in several disparate documents/papers/slides. I am glad you brought up this question; please give it a thought on what that best stand-alone introduction would look like. -Nandita ------=_NextPart_000_0019_01CB2CB0.C6C1B180 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

That makes the most sense to me. After all this is the = first milestone and so (in theory) should exist as a stand-alone document. =

 

It does raise an important question for the = list:

 

How can we best describe ConEx? Of the many intros that = are out there, which seems easiest to understand and which most confusing? Is = the current draft going down the right lines?

 

Toby

 

From: conex-bounces@ietf.org [mailto:conex-bounces@ietf.org] On Behalf Of Nandita = Dukkipati
Sent: 25 July 2010 23:51
To: Bob Briscoe
Cc: conex@ietf.org
Subject: Re: [conex] Intent of charter: division of concepts = across docs

 

On Fri, Jul 23, 2010 at 10:35 PM, Bob Briscoe = <rbriscoe@jungle.bt.co.uk>= wrote:

Nandita,

[Adding the list]

My prejudices go like this:

- Which doc should aim = to be a stand-alone introduction to ConEx?

* Use-cases (the one we've written covers = "Concepts and Use-cases", which allows us to make it an introductory = doc)

 

Bob,

 

I believe the use-cases document should be the one = landing place for anyone who cares to know the high order bits of ConEx. = Therefore, it should have the best possible introduction to ConEx --- my feeling is = that pieces of such an Intro. are currently strewn in several disparate documents/papers/slides. 

 

I am glad you brought up this question; please give = it a thought on what that best stand-alone introduction would look = like.

 

-Nandita

------=_NextPart_000_0019_01CB2CB0.C6C1B180-- From toby@moncaster.com Mon Jul 26 04:07:41 2010 Return-Path: X-Original-To: conex@core3.amsl.com Delivered-To: conex@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 31C873A6A0B for ; Mon, 26 Jul 2010 04:07:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.428 X-Spam-Level: X-Spam-Status: No, score=-1.428 tagged_above=-999 required=5 tests=[AWL=0.821, BAYES_00=-2.599, HELO_EQ_DE=0.35] 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 5OxTQgoYU+OG for ; Mon, 26 Jul 2010 04:07:38 -0700 (PDT) Received: from moutng.kundenserver.de (moutng.kundenserver.de [212.227.126.171]) by core3.amsl.com (Postfix) with ESMTP id 880A53A69D2 for ; Mon, 26 Jul 2010 04:07:33 -0700 (PDT) Received: from TobysHP (host86-156-248-3.range86-156.btcentralplus.com [86.156.248.3]) by mrelayeu.kundenserver.de (node=mreu0) with ESMTP (Nemesis) id 0Lx3Yj-1P5iIf11Sr-016ZGY; Mon, 26 Jul 2010 13:07:49 +0200 From: "Toby Moncaster" To: "'Toby Moncaster'" , "'Nandita Dukkipati'" , "'Bob Briscoe'" References: <201007231949.o6NJn38t014418@bagheera.jungle.bt.co.uk> <201007232235.o6NMZZ1e015875@bagheera.jungle.bt.co.uk> <001801cb2ca8$64fd4980$2ef7dc80$@com> In-Reply-To: <001801cb2ca8$64fd4980$2ef7dc80$@com> Date: Mon, 26 Jul 2010 12:07:48 +0100 Message-ID: <002701cb2cb2$c8a10df0$59e329d0$@com> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable X-Mailer: Microsoft Office Outlook 12.0 Thread-Index: AcssS96pn5Ygx8z3Ryq3/LriBs0U3QAW+hDwAAKyP9A= Content-Language: en-gb X-Provags-ID: V02:K0:XCl0Emx2/rBB1pRn3+ht8KLJEv6fubiWsgg8qeNE1I+ rK2EC5A/LORKx2P7DYh8txhmcUl7QrhrK+Xlnvxr1/ejK3vwjw PV+6xauSfKIHr5U79W9alnSEJ/OwnrJugceE0n6xUoposC9JdX S3GRuD5tNbMs1ImPCLL7W303f/zm3TalC1nHgAF+Q7JIxgjcPs IVxY6UvlpaGmK/KaV40wVbi+yYqfIsPruo733IF3DA= Cc: conex@ietf.org Subject: Re: [conex] Intent of charter: division of concepts across docs X-BeenThere: conex@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Congestion Exposure working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 26 Jul 2010 11:07:41 -0000 I was asked to furnish a list of suitable links for introductions to = ConEx or to Bob's re-ECN protocol (which achieves similar aims to ConEx): General introduction for non-specialist audience: Bob Briscoe, =93Internet Fairer is Faster", White Paper (Jun 2009) =20 Current ConEx use cases document: Toby Moncaster et al, "ConEx Concepts and Uses" (Jul 2010)=20 = ConEx Problem statement: Toby Moncaster et al "The Need for Congestion Exposure in the Internet " =20 Re-ECN drafts (expired) =20 Bob Briscoe et al, "Re-ECN: The Motivation for Adding Accountability for Causing Congestion to TCP/IP" =20 Bob Briscoe et al, "Re-ECN: Adding Accountability for Causing Congestion = to TCP/IP" =20 More technical paper about how to control congestion, but includes some stuff about exposing it as well: Arnaud Jacquet et al: "Policing freedom to use the internet resource = pool" =20 There are also presentations like Bob's presentation to ConEx BoF in Hiroshima: =20 And I am sure Bob can find some more links for people! Toby From: conex-bounces@ietf.org [mailto:conex-bounces@ietf.org] On Behalf = Of Toby Moncaster Sent: 26 July 2010 10:53 To: 'Nandita Dukkipati'; 'Bob Briscoe' Cc: conex@ietf.org Subject: Re: [conex] Intent of charter: division of concepts across docs That makes the most sense to me. After all this is the first milestone = and so (in theory) should exist as a stand-alone document.=20 It does raise an important question for the list: How can we best describe ConEx? Of the many intros that are out there, = which seems easiest to understand and which most confusing? Is the current = draft going down the right lines? Toby From: conex-bounces@ietf.org [mailto:conex-bounces@ietf.org] On Behalf = Of Nandita Dukkipati Sent: 25 July 2010 23:51 To: Bob Briscoe Cc: conex@ietf.org Subject: Re: [conex] Intent of charter: division of concepts across docs On Fri, Jul 23, 2010 at 10:35 PM, Bob Briscoe wrote: Nandita, [Adding the list] My prejudices go like this: - Which doc should aim to be a stand-alone introduction to ConEx? * Use-cases (the one we've written covers "Concepts and Use-cases", = which allows us to make it an introductory doc) Bob, I believe the use-cases document should be the one landing place for = anyone who cares to know the high order bits of ConEx. Therefore, it should = have the best possible introduction to ConEx --- my feeling is that pieces of such an Intro. are currently strewn in several disparate documents/papers/slides.=A0 I am glad you brought up this question; please give it a thought on what that best stand-alone introduction would look like. -Nandita From leslie@thinkingcat.com Mon Jul 26 09:53:41 2010 Return-Path: X-Original-To: conex@core3.amsl.com Delivered-To: conex@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 20D2D3A67B6 for ; Mon, 26 Jul 2010 09:53:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] 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 U1Dr-7mMaqMR for ; Mon, 26 Jul 2010 09:53:39 -0700 (PDT) Received: from zeke.ecotroph.net (zeke.ecotroph.net [70.164.19.155]) by core3.amsl.com (Postfix) with ESMTP id 5DC7D3A657C for ; Mon, 26 Jul 2010 09:53:39 -0700 (PDT) Received: from beethoven.local ([::ffff:212.29.185.158]) (AUTH: PLAIN leslie, SSL: TLSv1/SSLv3,256bits,AES256-SHA) by zeke.ecotroph.net with esmtp; Mon, 26 Jul 2010 12:53:58 -0400 id 015842F5.4C4DBDA7.000049B5 Message-ID: <4C4DBD9D.5000602@thinkingcat.com> Date: Mon, 26 Jul 2010 12:53:49 -0400 From: Leslie Daigle User-Agent: Thunderbird 2.0.0.24 (Macintosh/20100228) MIME-Version: 1.0 To: Toby Moncaster References: <002901cb195e$addca590$0995f0b0$@com> In-Reply-To: <002901cb195e$addca590$0995f0b0$@com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: conex@ietf.org Subject: Re: [conex] FW: New Version Notification for draft-moncaster-conex-concepts-uses-00 X-BeenThere: conex@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Congestion Exposure working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 26 Jul 2010 16:53:41 -0000 Hi, A couple of general comments -- I like the way the description of what congestion exposure actually is has evolved -- it seems much crisper. I'm afraid I still see 2 documents here, for the sake of continued relevance and clarity beyond current audiences. More detail -- I believe my comment from the earlier document still stands: [On March 7, I wrote:] > Reading through the document again, I was struck by the focus on > "ISPs". Perhaps one of the ways to emphasize the "inter-network" > aspect of this proposal is to back out of that: remove all instances > of "ISP" in this document, and focus the text on networks, whatever > their type. The first paragraph of the document now refers to "network operators', which is probably as reasonable a generalization as any to replace ISP -- could be mobile data networks, could be educational/research networks, etc. This is perhaps one instance of a more fundamental issue, in my opinion: I understand Bob's argument that the use cases and mechanisms are commonly understood when discussed together. But I think that keeping them together in the same document (even following Marcelo's proposed restructuring) is going to unnecessarily limit understanding of the concepts: they will be _too_ tied to the use cases. This is reflected in the other thread about whether this is congestion exposure for [excessive] congestion management, or for capacity sharing. IMO: when someone is referring back to the canonical CONEX documents in 5 years, they should be able to read the RFC that describes the CONEX mechanisms, without having to mentally subtract the use case illustrations that are relevant today, but perhaps distracting tomorrow. To try to be a bit clearer of how I would see this as two documents, I could suggest: Mechanisms, with a new introduction and keeping 2, 4, 5, and 7 (s/ISP/network operator/g) Uses, keeping 1, 8, and 9 I'm not sure I understand that section 6 was fully motivated to be included in either document. Leslie. Toby Moncaster wrote: > All, > > I have just posted this revised document, addressing most of > Marcelo's comments. Notice the new filename and title... There is a > changelog in the draft and there is a link to the diff below... > > HTML at > http://www.moncaster.com/conex/draft-moncaster-conex-concepts-uses-00.html > > > > DIFF at http://www.moncaster.com/conex/Diff0.htm > > I think this is now in a good enough state to be adopted as the first > WG document. The changes make this pretty close to what is requested > in the charter (namely a use cases document). There is a section on > mechanisms because to my mind a use cases document with no > description of mechanism is useless (as there would be no way for > people to judge how realistic the use cases are). > > So, to ask the question formally, does anyone else think this is > ready for WG adoption? What do the chairs think? Will the chairs > propose this for adoption or do you intend to wait until it has been > discussed at Maastricht? > > Toby > > PS Dirk, I saw your email (or skimmed it anyway), but it was too late > to incorporate your suggestions into this release. Hopefully I will > have time next week to do another revision and will probably > incorporate the majority of your suggestions > >> -----Original Message----- From: IETF I-D Submission Tool >> [mailto:idsubmission@ietf.org] Sent: 01 July 2010 21:39 To: >> toby@moncaster.com Cc: bob.briscoe@bt.com; >> richard_woundy@cable.comcast.com; john@jlc.net Subject: New Version >> Notification for draft-moncaster-conex-concepts- uses-00 >> >> >> A new version of I-D, draft-moncaster-conex-concepts-uses-00.txt >> has been successfully submitted by Toby Moncaster and posted to the >> IETF repository. >> >> Filename: draft-moncaster-conex-concepts-uses Revision: 00 Title: >> ConEx Concepts and Use Cases Creation_date: 2010-07-01 WG ID: >> Independent Submission Number_of_pages: 20 >> >> Abstract: Internet Service Providers (ISPs) are facing problems >> where congestion prevents full utilization of the path between >> sender and receiver at today's "broadband" speeds. ISPs desire to >> control the congestion, which often appears to be caused by a small >> number of users consuming a large amount of bandwidth. Building >> out more capacity along all of the path to handle this congestion >> can be expensive; and network operators have sought other ways to >> manage congestion. The current mechanisms all suffer from >> difficulty measuring the congestion (as distinguished from the >> total traffic). >> >> The ConEx Working Group is designing a mechanism to make congestion >> along any path visible at the Internet Layer. This document >> discusses this mechanism. >> >> >> >> The IETF Secretariat. > > > _______________________________________________ conex mailing list > conex@ietf.org https://www.ietf.org/mailman/listinfo/conex > -- ------------------------------------------------------------------- "Reality: Yours to discover." -- ThinkingCat Leslie Daigle leslie@thinkingcat.com ------------------------------------------------------------------- From rbriscoe@jungle.bt.co.uk Mon Jul 26 17:04:11 2010 Return-Path: X-Original-To: conex@core3.amsl.com Delivered-To: conex@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id CA4B73A6829 for ; Mon, 26 Jul 2010 17:04:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.117 X-Spam-Level: X-Spam-Status: No, score=-1.117 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, DNS_FROM_RFC_BOGUSMX=1.482] 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 YvtPQYj4-2Et for ; Mon, 26 Jul 2010 17:04:04 -0700 (PDT) Received: from mailrelay.hotspotsvankpn.com (mailrelay.hotspotsvankpn.com [82.94.177.187]) by core3.amsl.com (Postfix) with ESMTP id 187943A65A6 for ; Mon, 26 Jul 2010 17:04:03 -0700 (PDT) Received: from localhost (localhost.localdomain [127.0.0.1]) by mailrelay.hotspotsvankpn.com (amavis-input) with ESMTP id C4148118135; Tue, 27 Jul 2010 02:04:24 +0200 (CEST) X-Virus-Scanned: amavisd-new at hotspotsvankpn.com Received: from mailrelay.hotspotsvankpn.com ([127.0.0.1]) by localhost (lnx-smtp01.hotspotsvankpn.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id cD564ITnPPiL; Tue, 27 Jul 2010 02:04:22 +0200 (CEST) Received: from MUT.jungle.bt.co.uk (ip212-238-55-64.hotspotsvankpn.com [212.238.55.64]) by mailrelay.hotspotsvankpn.com (Postfix) with ESMTP id 4590F11811B; Tue, 27 Jul 2010 02:04:22 +0200 (CEST) X-Mailer: QUALCOMM Windows Eudora Version 7.1.0.9 Date: Tue, 27 Jul 2010 01:04:21 +0100 To: "Toby Moncaster" From: Bob Briscoe In-Reply-To: <002701cb2cb2$c8a10df0$59e329d0$@com> References: <201007231949.o6NJn38t014418@bagheera.jungle.bt.co.uk> <201007232235.o6NMZZ1e015875@bagheera.jungle.bt.co.uk> <001801cb2ca8$64fd4980$2ef7dc80$@com> <002701cb2cb2$c8a10df0$59e329d0$@com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Message-Id: <20100727000422.4590F11811B@mailrelay.hotspotsvankpn.com> Cc: conex@ietf.org Subject: Re: [conex] Intent of charter: division of concepts across docs X-BeenThere: conex@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Congestion Exposure working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 27 Jul 2010 00:04:11 -0000 Toby, Thanks. That's a good primary reading list. I maintain a page with papers about ConEx/re-feedback/re-ECN/fairness etc. It has a section called "primary documentation", giving summaries of what audience they are aimed at, and what they cover. I haven't included the recent ConEx docs that Toby lists, but will do straight after the IETF. It also includes more focused ones on DDoS mitigation and commercial interconnection models. It is a bit biased towards my own papers, but also includes related work, evaluations by others, links to implementations, weighted congestion controls, standards activity, articles in the media, etc. HTH Bob At 12:07 26/07/2010, Toby Moncaster wrote: >I was asked to furnish a list of suitable links for introductions to ConEx >or to Bob's re-ECN protocol (which achieves similar aims to ConEx): > >General introduction for non-specialist audience: > >Bob Briscoe, "Internet Fairer is Faster", White Paper (Jun 2009) > > >Current ConEx use cases document: > >Toby Moncaster et al, "ConEx Concepts and Uses" (Jul 2010) > > >ConEx Problem statement: > >Toby Moncaster et al "The Need for Congestion Exposure in the Internet " > > >Re-ECN drafts (expired) > >Bob Briscoe et al, "Re-ECN: The Motivation for Adding Accountability for >Causing Congestion to TCP/IP" >vation-01.html> > >Bob Briscoe et al, "Re-ECN: Adding Accountability for Causing Congestion to >TCP/IP" >tml> > >More technical paper about how to control congestion, but includes some >stuff about exposing it as well: > >Arnaud Jacquet et al: "Policing freedom to use the internet resource pool" > > > >There are also presentations like Bob's presentation to ConEx BoF in >Hiroshima: > > > > >And I am sure Bob can find some more links for people! > >Toby > > > >From: conex-bounces@ietf.org [mailto:conex-bounces@ietf.org] On Behalf Of >Toby Moncaster >Sent: 26 July 2010 10:53 >To: 'Nandita Dukkipati'; 'Bob Briscoe' >Cc: conex@ietf.org >Subject: Re: [conex] Intent of charter: division of concepts across docs > >That makes the most sense to me. After all this is the first milestone and >so (in theory) should exist as a stand-alone document. > >It does raise an important question for the list: > >How can we best describe ConEx? Of the many intros that are out there, which >seems easiest to understand and which most confusing? Is the current draft >going down the right lines? > >Toby > >From: conex-bounces@ietf.org [mailto:conex-bounces@ietf.org] On Behalf Of >Nandita Dukkipati >Sent: 25 July 2010 23:51 >To: Bob Briscoe >Cc: conex@ietf.org >Subject: Re: [conex] Intent of charter: division of concepts across docs > >On Fri, Jul 23, 2010 at 10:35 PM, Bob Briscoe >wrote: >Nandita, > >[Adding the list] > >My prejudices go like this: >- Which doc should aim to be a stand-alone introduction to ConEx? >* Use-cases (the one we've written covers "Concepts and Use-cases", which >allows us to make it an introductory doc) > >Bob, > >I believe the use-cases document should be the one landing place for anyone >who cares to know the high order bits of ConEx. Therefore, it should have >the best possible introduction to ConEx --- my feeling is that pieces of >such an Intro. are currently strewn in several disparate >documents/papers/slides. > >I am glad you brought up this question; please give it a thought on what >that best stand-alone introduction would look like. > >-Nandita ________________________________________________________________ Bob Briscoe, BT Innovate & Design From dave.mcdysan@verizon.com Mon Jul 26 23:48:25 2010 Return-Path: X-Original-To: conex@core3.amsl.com Delivered-To: conex@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id C2F4F3A69D8 for ; Mon, 26 Jul 2010 23:48:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.392 X-Spam-Level: X-Spam-Status: No, score=-2.392 tagged_above=-999 required=5 tests=[AWL=1.207, BAYES_00=-2.599, 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 8djywScRmrfd for ; Mon, 26 Jul 2010 23:48:23 -0700 (PDT) Received: from tpamail4.verizon.com (tpamail4.verizon.com [192.76.82.161]) by core3.amsl.com (Postfix) with ESMTP id 704073A69A5 for ; Mon, 26 Jul 2010 23:48:23 -0700 (PDT) Received: from tpaintrmemf3.verizon.com (tpaintrmemf3.verizon.com [138.83.67.58]) by tpamail4.verizon.com (8.13.6/8.13.3) with ESMTP id o6R6j7PZ001061; Tue, 27 Jul 2010 02:45:07 -0400 (EDT) X-AuditID: 8a53433a-b7bbaae000005fc1-40-4c4e81461836 Received: from smtptpa3.verizon.com ( [138.83.71.176]) by tpaintrmemf3.verizon.com (EMF) with SMTP id 4F.5E.24513.6418E4C4; Tue, 27 Jul 2010 02:48:38 -0400 (EDT) Received: from FHDP1CCMXCG02.us.one.verizon.com ([166.68.240.34]) by smtptpa3.verizon.com (8.13.3/8.13.3) with ESMTP id o6R6mcJQ019034; Tue, 27 Jul 2010 02:48:38 -0400 (EDT) Received: from FHDP1LUMXCV14.us.one.verizon.com ([166.68.125.35]) by FHDP1CCMXCG02.us.one.verizon.com with Microsoft SMTPSVC(6.0.3790.4675); Tue, 27 Jul 2010 02:48:38 -0400 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable X-MimeOLE: Produced By Microsoft Exchange V6.5 Date: Tue, 27 Jul 2010 02:47:09 -0400 Message-ID: <793F49BA1FC821409F99F10862A0E4DB07B63224@FHDP1LUMXCV14.us.one.verizon.com> In-Reply-To: <4C4DBD9D.5000602@thinkingcat.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [conex] FW: New Version Notificationfor draft-moncaster-conex-concepts-uses-00 Thread-Index: Acss4yt6zOsr2Qj4Ti653YySYBHAGQAc8eKg References: <002901cb195e$addca590$0995f0b0$@com> <4C4DBD9D.5000602@thinkingcat.com> From: "Mcdysan, David E" To: "Leslie Daigle" , "Toby Moncaster" X-OriginalArrivalTime: 27 Jul 2010 06:48:38.0315 (UTC) FILETIME=[BDFE37B0:01CB2D57] X-Brightmail-Tracker: AAAAAA== Cc: conex@ietf.org Subject: Re: [conex] FW: New Version Notificationfor draft-moncaster-conex-concepts-uses-00 X-BeenThere: conex@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Congestion Exposure working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 27 Jul 2010 06:48:25 -0000 I had a similar thought reading this document -- it actually contains a relatively small amount of material on use cases, more material on concepts, and the majority of the document is on on a mechanism. >From the charter, use cases is the first deliverable (with primarily a focus on the intra-network scenario), while the description of an abstract specification is the second major deliverable. Thanks, Dave > -----Original Message----- > From: conex-bounces@ietf.org [mailto:conex-bounces@ietf.org]=20 > On Behalf Of Leslie Daigle > Sent: Monday, July 26, 2010 12:54 PM > To: Toby Moncaster > Cc: conex@ietf.org > Subject: Re: [conex] FW: New Version Notificationfor=20 > draft-moncaster-conex-concepts-uses-00 >=20 >=20 > Hi, >=20 >=20 > A couple of general comments -- >=20 > I like the way the description of what congestion exposure=20 > actually is has evolved -- it seems much crisper. >=20 > I'm afraid I still see 2 documents here, for the sake of=20 > continued relevance and clarity beyond current audiences. >=20 >=20 > More detail -- >=20 > I believe my comment from the earlier document still stands: >=20 > [On March 7, I wrote:] > > Reading through the document again, I was struck by the focus on > > "ISPs". Perhaps one of the ways to emphasize the "inter-network" > > aspect of this proposal is to back out of that: remove all=20 > instances > > of "ISP" in this document, and focus the text on networks, whatever > > their type. >=20 > The first paragraph of the document now refers to "network=20 > operators',=20 > which is probably as reasonable a generalization as any to=20 > replace ISP=20 > -- could be mobile data networks, could be educational/research=20 > networks, etc. >=20 > This is perhaps one instance of a more fundamental issue, in=20 > my opinion:=20 > I understand Bob's argument that the use cases and mechanisms are=20 > commonly understood when discussed together. But I think=20 > that keeping=20 > them together in the same document (even following Marcelo's proposed=20 > restructuring) is going to unnecessarily limit understanding of the=20 > concepts: they will be _too_ tied to the use cases. >=20 > This is reflected in the other thread about whether this is=20 > congestion=20 > exposure for [excessive] congestion management, or for=20 > capacity sharing. >=20 > IMO: when someone is referring back to the canonical CONEX=20 > documents in=20 > 5 years, they should be able to read the RFC that describes the CONEX=20 > mechanisms, without having to mentally subtract the use case=20 > illustrations that are relevant today, but perhaps=20 > distracting tomorrow. >=20 > To try to be a bit clearer of how I would see this as two=20 > documents, I=20 > could suggest: >=20 >=20 > Mechanisms, with a new introduction and keeping 2, 4, 5, and 7=20 > (s/ISP/network operator/g) >=20 > Uses, keeping 1, 8, and 9 >=20 > I'm not sure I understand that section 6 was fully motivated to be=20 > included in either document. >=20 >=20 > Leslie. >=20 > Toby Moncaster wrote: > > All, > >=20 > > I have just posted this revised document, addressing most of=20 > > Marcelo's comments. Notice the new filename and title... There is a=20 > > changelog in the draft and there is a link to the diff below... > >=20 > > HTML at=20 > >=20 > http://www.moncaster.com/conex/draft-moncaster-conex-concepts- > uses-00.html > >=20 > >=20 > >=20 > > DIFF at http://www.moncaster.com/conex/Diff0.htm > >=20 > > I think this is now in a good enough state to be adopted as=20 > the first > > WG document. The changes make this pretty close to what is=20 > requested > > in the charter (namely a use cases document). There is a=20 > section on=20 > > mechanisms because to my mind a use cases document with no=20 > > description of mechanism is useless (as there would be no way for=20 > > people to judge how realistic the use cases are). > >=20 > > So, to ask the question formally, does anyone else think this is=20 > > ready for WG adoption? What do the chairs think? Will the chairs=20 > > propose this for adoption or do you intend to wait until it=20 > has been=20 > > discussed at Maastricht? > >=20 > > Toby > >=20 > > PS Dirk, I saw your email (or skimmed it anyway), but it=20 > was too late > > to incorporate your suggestions into this release.=20 > Hopefully I will=20 > > have time next week to do another revision and will probably=20 > > incorporate the majority of your suggestions > >=20 > >> -----Original Message----- From: IETF I-D Submission Tool=20 > >> [mailto:idsubmission@ietf.org] Sent: 01 July 2010 21:39 To:=20 > >> toby@moncaster.com Cc: bob.briscoe@bt.com;=20 > >> richard_woundy@cable.comcast.com; john@jlc.net Subject: New Version > >> Notification for draft-moncaster-conex-concepts- uses-00 > >>=20 > >>=20 > >> A new version of I-D, draft-moncaster-conex-concepts-uses-00.txt=20 > >> has been successfully submitted by Toby Moncaster and posted to the > >> IETF repository. > >>=20 > >> Filename: draft-moncaster-conex-concepts-uses Revision:=09 > 00 Title: > >> ConEx Concepts and Use Cases Creation_date: =20 > 2010-07-01 WG ID:=20 > >> Independent Submission Number_of_pages: 20 > >>=20 > >> Abstract: Internet Service Providers (ISPs) are facing problems=20 > >> where congestion prevents full utilization of the path between=20 > >> sender and receiver at today's "broadband" speeds. ISPs desire to=20 > >> control the congestion, which often appears to be caused by a small > >> number of users consuming a large amount of bandwidth. Building=20 > >> out more capacity along all of the path to handle this congestion=20 > >> can be expensive; and network operators have sought other ways to=20 > >> manage congestion. The current mechanisms all suffer from=20 > >> difficulty measuring the congestion (as distinguished from the=20 > >> total traffic). > >>=20 > >> The ConEx Working Group is designing a mechanism to make congestion > >> along any path visible at the Internet Layer. This document=20 > >> discusses this mechanism. > >>=20 > >>=20 > >>=20 > >> The IETF Secretariat. > >=20 > >=20 > > _______________________________________________ conex mailing list=20 > > conex@ietf.org https://www.ietf.org/mailman/listinfo/conex > >=20 >=20 > --=20 >=20 > ------------------------------------------------------------------- > "Reality: > Yours to discover." > -- ThinkingCat > Leslie Daigle > leslie@thinkingcat.com > ------------------------------------------------------------------- > _______________________________________________ > conex mailing list > conex@ietf.org > https://www.ietf.org/mailman/listinfo/conex >=20 From dave.mcdysan@verizon.com Tue Jul 27 00:32:15 2010 Return-Path: X-Original-To: conex@core3.amsl.com Delivered-To: conex@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 6CB703A69E9 for ; Tue, 27 Jul 2010 00:32:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.995 X-Spam-Level: X-Spam-Status: No, score=-2.995 tagged_above=-999 required=5 tests=[AWL=0.604, BAYES_00=-2.599, 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 WPKxqVNNHDxW for ; Tue, 27 Jul 2010 00:32:13 -0700 (PDT) Received: from sacmail4.verizon.com (sacmail4.verizon.com [192.76.84.42]) by core3.amsl.com (Postfix) with ESMTP id C20593A6A98 for ; Tue, 27 Jul 2010 00:32:12 -0700 (PDT) Received: from irvintrmemf1.verizon.com (irvintrmemf1.verizon.com [138.83.34.101]) by sacmail4.verizon.com (8.13.7+Sun/8.13.3) with ESMTP id o6R7WH7U008566; Tue, 27 Jul 2010 03:32:23 -0400 (EDT) X-AuditID: 8a532265-b7b2aae000005dc2-0d-4c4e8b84a91a Received: from smtptpa3.verizon.com ( [138.83.71.176]) by irvintrmemf1.verizon.com (Symantec Brightmail Gateway) with SMTP id 98.10.24002.48B8E4C4; Tue, 27 Jul 2010 02:32:20 -0500 (CDT) Received: from FHDP1CCMXCG01.us.one.verizon.com ([166.68.240.33]) by smtptpa3.verizon.com (8.13.3/8.13.3) with ESMTP id o6R7WKgO002905; Tue, 27 Jul 2010 03:32:20 -0400 (EDT) Received: from FHDP1LUMXCV14.us.one.verizon.com ([166.68.125.35]) by FHDP1CCMXCG01.us.one.verizon.com with Microsoft SMTPSVC(6.0.3790.4675); Tue, 27 Jul 2010 03:32:20 -0400 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable X-MimeOLE: Produced By Microsoft Exchange V6.5 Date: Tue, 27 Jul 2010 03:32:13 -0400 Message-ID: <793F49BA1FC821409F99F10862A0E4DB07B63225@FHDP1LUMXCV14.us.one.verizon.com> In-Reply-To: <20100723235447.GE69747@verdi> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [conex] Intent of charter: division of concepts across docs Thread-Index: Acsqwqk1zJZiVEflSJysFO0EGBGdNQCl62sw References: <201007231949.o6NJn38t014418@bagheera.jungle.bt.co.uk><201007232235.o6NMZZ1e015875@bagheera.jungle.bt.co.uk> <20100723235447.GE69747@verdi> From: "Mcdysan, David E" To: "John Leslie" , "Bob Briscoe" X-OriginalArrivalTime: 27 Jul 2010 07:32:20.0257 (UTC) FILETIME=[D8CAD110:01CB2D5D] X-Brightmail-Tracker: AAAAAA== Cc: conex@ietf.org Subject: Re: [conex] Intent of charter: division of concepts across docs X-BeenThere: conex@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Congestion Exposure working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 27 Jul 2010 07:32:15 -0000 I chose this message to respond to since I agree with many of John's points. I also include some responses in line intended to help advance the work, summarized as follows: * Use cases need not have the same terminology as the final experimental specification, however, terminology in the abstract mechanism should align with the IPv6 specification. * As John indicated in a separate post, the use case document will become historical, and may not be as relevant in the future as the abstract mechanism and experimental specification. * IMO, the use cases should use terminology that is relevant to the use case. Hopefully, a mapping at the end of the use case document could map the range of terminology unique to particular use cases to that of the abstract mechanism. Thanks, Dave=20 > -----Original Message----- > From: conex-bounces@ietf.org [mailto:conex-bounces@ietf.org]=20 > On Behalf Of John Leslie > Sent: Friday, July 23, 2010 7:55 PM > To: Bob Briscoe > Cc: conex@ietf.org > Subject: Re: [conex] Intent of charter: division of concepts=20 > across docs >=20 > Bob Briscoe wrote: > >=20 > > My prejudices go like this: > >=20 > >> - Which doc should aim to be a stand-alone introduction to ConEx? > >=20 > > * Use-cases (the one we've written covers "Concepts and Use-cases",=20 > > which allows us to make it an introductory doc) >=20 > I think the rest of the authors agree: I certainly do. As summarized above, the introduction should use terminology and examples specific to a use case that is familiar to current readers. As John pointed out earlier, additional use cases (and terminology) will likely evolve if conex is sucessful (as we hope it becomes).=20 >=20 > > also, Abstract ConEx Mechanism should be possible to understand =20 > > without having read use-cases first, but I imagine it will be more =20 > > focused just on the mechanisms, not why they are there, nor=20 > different =20 > > ways they might go together. >=20 > The Mechanism document will get specific about a number of=20 > things we've intentionally left vague so far, but IMHO it=20 > shouldn't go into detail about _why_ you might use the mechanisms. I think the use case needs to provide at least high-level motivation for development of at least some of the mechanisms. I agree that it should not provide detail. Hopefully, the document has several use cases justifying aspects of the abstract mechanism(s). >=20 > >> - Which doc would be best to define ConEx terminology? > >=20 > > * Abstract ConEx mechanism >=20 > A perhaps surprisingly important issue... I agree. Mapping from use case specific terminology to a common abstract model could occur at the end of the use case document. After experimentation, there could be an updated use case document, that hopefully, adds some new use cases and refines the description of the ones initially described. >=20 > > But, as use-cases has to go first, it will have to define=20 > terminology=20 > > for its own use. So we should try to have a decent version of the=20 > > Abstract ConEx mechanism before w-g submits use-cases for RFC. >=20 > So far, Use-Cases has defined terminology "for its own=20 > use," and this has made Bob uneasy. He's quite determined=20 > that the "real" > definitions should provably deliver what they promise, and=20 > fears that the Use-Cases definitions will imply promises to=20 > deliver something we can't deliver. >=20 > I, at least, and the rest of the authors to some extent,=20 > believe that definitions can evolve as the WG progresses. For=20 > one obvious example, I have pretty strong opinions an what=20 > "congestion" should mean in its "real" definition; but I am=20 > not concerned as we run through much-less-rigorous=20 > mini-definitions in early documents. >=20 > I would not tend to support holding up the Use-Cases=20 > document for nailing down details of definitions of terms in=20 > some later document. >=20 I agree. See my more specific proposals above and the summary. > >> - Where should we discuss incremental deployment and deployment > >> incentives. (is use-cases more about *what* ConEx is used for > >> than *how* it's used) >=20 > We could use some WG guidance here. The _question_ of=20 > deployability must be tackled in the Use-Cases document, but=20 > it seems to me to be inappropriate to lay out many details of=20 > deployment (not least since actual deployment won't follow=20 > our plan anyway). >=20 > I'd like to punt most of the details to another document... >=20 I agree. > >> (we surely want a more detailed check on incremental > >> deployability once we've defined the detailed protocol) >=20 > I agree with Bob here. >=20 Agreed. > > Multiple places with increasing degress of solidity: > > * In use-cases (with some vagueness allowed) >=20 > I'd go for "quite a bit" of vagueness... >=20 I would suggest phrasing this as "terminology familiar and relevant to the particular use case" instead of vagueness. > > * In each experimental track doc, protocol specifics for partial=20 > > deployment have to be defined >=20 > I agree with Bob here. In the specification? (Third deliverable) >=20 > > * In one or more of the informational evaluation docs, I would > > expect to see a more precise evaluation of how well a partial > > deployment worked, or whether there were incentives to start > > deployment and so forth. >=20 > "Worked so far," of course... >=20 > I agree with Bob that review of how deployment is coming=20 > along is essential; and I despair of predicting what this will show. >=20 > I _have_ considered deployment incentives at length, but=20 > I'm disinclined to put much of my musings into the Use-Cases document. > A deployment plan is an essential piece of the=20 > Experiment-track documents we will write; and it should be=20 > specific enough to report to what extent the experiment=20 > succeeds in deployment. I agree >=20 > -- > John Leslie > _______________________________________________ > conex mailing list > conex@ietf.org > https://www.ietf.org/mailman/listinfo/conex >=20 From jukka.manner@tkk.fi Thu Jul 29 08:09:47 2010 Return-Path: X-Original-To: conex@core3.amsl.com Delivered-To: conex@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id DFD6B3A6A0A for ; Thu, 29 Jul 2010 08:09:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.913 X-Spam-Level: X-Spam-Status: No, score=-5.913 tagged_above=-999 required=5 tests=[AWL=0.686, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] 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 SbQ2DNkW4Uyq for ; Thu, 29 Jul 2010 08:09:46 -0700 (PDT) Received: from smtp-4.hut.fi (smtp-4.hut.fi [130.233.228.94]) by core3.amsl.com (Postfix) with ESMTP id 8378F3A6A05 for ; Thu, 29 Jul 2010 08:09:30 -0700 (PDT) Received: from localhost (katosiko.hut.fi [130.233.228.115]) by smtp-4.hut.fi (8.13.6/8.12.10) with ESMTP id o6TF9qNa001841 for ; Thu, 29 Jul 2010 18:09:52 +0300 Received: from smtp-4.hut.fi ([130.233.228.94]) by localhost (katosiko.hut.fi [130.233.228.115]) (amavisd-new, port 10024) with LMTP id 22707-1111 for ; Thu, 29 Jul 2010 18:09:52 +0300 (EEST) Received: from smtp.netlab.hut.fi (luuri.netlab.hut.fi [130.233.154.177]) by smtp-4.hut.fi (8.13.6/8.12.10) with ESMTP id o6TF9mK3001829 for ; Thu, 29 Jul 2010 18:09:49 +0300 Received: from localhost (localhost.localdomain [127.0.0.1]) by smtp.netlab.hut.fi (Postfix) with ESMTP id C99B21E157 for ; Thu, 29 Jul 2010 18:09:48 +0300 (EEST) X-Virus-Scanned: by amavisd-new at luuri.netlab.hut.fi Received: from smtp.netlab.hut.fi ([127.0.0.1]) by localhost (luuri.netlab.hut.fi [127.0.0.1]) (amavisd-new, port 10024) with LMTP id WLCo+c-HIeuo for ; Thu, 29 Jul 2010 18:09:45 +0300 (EEST) Received: from [130.129.146.245] (dhcp-92f5.meeting.ietf.org [130.129.146.245]) by smtp.netlab.hut.fi (Postfix) with ESMTPSA id 08D3A1E135 for ; Thu, 29 Jul 2010 18:09:44 +0300 (EEST) Message-ID: <4C5199B8.8070809@tkk.fi> Date: Thu, 29 Jul 2010 17:09:44 +0200 From: Jukka Manner User-Agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.9.3a1pre) Gecko/20091222 Shredder/3.1a1pre MIME-Version: 1.0 To: conex@ietf.org Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-TKK-Virus-Scanned: by amavisd-new-2.1.2-hutcc at katosiko.hut.fi Subject: [conex] Comments on the two draft-moncaster-conex-* X-BeenThere: conex@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Congestion Exposure working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 29 Jul 2010 15:09:48 -0000 Hi, I went through the two draft-moncaster documents, use cases and problem statement. They are mostly readable and relatively easy to follow. Some parts really need more explanation, or at least some thought (probably just the latter). I have two proposals: 1. The two drafts have a lot in common and a reader checking both drafts will encounter a lot of repetition. I would suggest to consider if the documents could be merged as one. 2. It is not very obvious how would the network in practice find and treat two users, where one is a heavy user and the other a small user (or users). Could you add some text on how the conex scheme would work, show some concrete example with network congestion, created load and the network response. I know this info is there but it would benefit from a concrete example(s) with numbers. Hope this helps, Jukka From toby@moncaster.com Thu Jul 29 10:17:25 2010 Return-Path: X-Original-To: conex@core3.amsl.com Delivered-To: conex@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 376C728C21A for ; Thu, 29 Jul 2010 10:17:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.891 X-Spam-Level: X-Spam-Status: No, score=-1.891 tagged_above=-999 required=5 tests=[AWL=0.358, BAYES_00=-2.599, HELO_EQ_DE=0.35] 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 Ju5PlGhrM08r for ; Thu, 29 Jul 2010 10:17:22 -0700 (PDT) Received: from moutng.kundenserver.de (moutng.kundenserver.de [212.227.17.8]) by core3.amsl.com (Postfix) with ESMTP id A0F6D28C23F for ; Thu, 29 Jul 2010 10:16:45 -0700 (PDT) Received: from TobysHP (host86-156-248-3.range86-156.btcentralplus.com [86.156.248.3]) by mrelayeu.kundenserver.de (node=mrbap0) with ESMTP (Nemesis) id 0MP1RX-1ObTeh0cQp-0064sK; Thu, 29 Jul 2010 19:17:07 +0200 From: "Toby Moncaster" To: "'Jukka Manner'" , References: <4C5199B8.8070809@tkk.fi> In-Reply-To: <4C5199B8.8070809@tkk.fi> Date: Thu, 29 Jul 2010 18:17:01 +0100 Message-ID: <003301cb2f41$dc669080$9533b180$@com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 12.0 Thread-Index: AcsvMEOkeiPQprNiSDuR1y/JFmLxVgAEEQUQ Content-Language: en-gb X-Provags-ID: V02:K0:LDAr7QBq8AYCpo9Fl/muAx1F2RXBcYlEX4lG/I91nA8 hzMB2w3fLiRY41WeQqUV3uzZrp9EFUqbMClP8j3S3ojsC3qGgU yBdEiUoPpJcvLwVKGb8Dfdl5oF1SjvEhmAL8v2LYS4XjsSGXqW Gn5aaD/kIVEvrhFiTrjJ/MrfyLShZyXA/HZxockBbJmm3HR64l EIe+wa1uwrRk6JZnNN8iKN5PHJltGl6W2d8kwVTXwk= Subject: Re: [conex] Comments on the two draft-moncaster-conex-* X-BeenThere: conex@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Congestion Exposure working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 29 Jul 2010 17:17:25 -0000 Hi Jukka, Thanks for the comments... Some responses inline Toby > -----Original Message----- > From: conex-bounces@ietf.org [mailto:conex-bounces@ietf.org] On Behalf > Of Jukka Manner > Sent: 29 July 2010 16:10 > To: conex@ietf.org > Subject: [conex] Comments on the two draft-moncaster-conex-* > > Hi, > > I went through the two draft-moncaster documents, use cases and problem > statement. They are mostly readable and relatively easy to follow. Some > parts really need more explanation, or at least some thought (probably > just the latter). > > I have two proposals: > > 1. The two drafts have a lot in common and a reader checking both > drafts > will encounter a lot of repetition. I would suggest to consider if the > documents could be merged as one. The Problem statement draft was written as part of the motivations for setting up this working group. It has now served its purpose and the authors are probably going to allow it to expire. The idea is that the Use Cases document should pick up some of the key motivations from the problem statement and is, in effect, the next step > > 2. It is not very obvious how would the network in practice find and > treat two users, where one is a heavy user and the other a small user > (or users). Could you add some text on how the conex scheme would work, > show some concrete example with network congestion, created load and > the > network response. I know this info is there but it would benefit from a > concrete example(s) with numbers. Reliably identifying different users is always going to be an issue in the Internet. In the absence of source-address spoofing you can identify a source-destination pair and use that. By adding up all the congestion-volume you see for each id at a given point you can identify the "heaviest" users. At the border of a network, the operator can use ConEx to see how much congestion is being caused in its network by each source (if it trusts source addresses) or can use other heuristics to identify which user is "heavy" and which isn't... {individual reply as 1 of 4 authors} I might consider having a simple numerical example, probably as an appendix to the use cases. > > Hope this helps, > Jukka > _______________________________________________ > conex mailing list > conex@ietf.org > https://www.ietf.org/mailman/listinfo/conex From dave.mcdysan@verizon.com Thu Jul 29 10:49:49 2010 Return-Path: X-Original-To: conex@core3.amsl.com Delivered-To: conex@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 6C1CB3A682F for ; Thu, 29 Jul 2010 10:49:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.368 X-Spam-Level: X-Spam-Status: No, score=-2.368 tagged_above=-999 required=5 tests=[AWL=-0.628, BAYES_20=-0.74, 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 uPGcaFfcrnI7 for ; Thu, 29 Jul 2010 10:49:48 -0700 (PDT) Received: from sacmail2.verizon.com (sacmail2.verizon.com [192.76.84.41]) by core3.amsl.com (Postfix) with ESMTP id 4773D3A67D0 for ; Thu, 29 Jul 2010 10:49:48 -0700 (PDT) Received: from irvintrmemf3.verizon.com (irvintrmemf3.verizon.com [138.83.34.103]) by sacmail2.verizon.com (8.13.7+Sun/8.13.3) with ESMTP id o6THo7QD021563 for ; Thu, 29 Jul 2010 13:50:12 -0400 (EDT) X-AuditID: 8a532267-b7bd7ae0000040b1-78-4c51bf4e5ca3 Received: from smtptpa4.verizon.com ( [138.83.71.177]) by irvintrmemf3.verizon.com (Symantec Mail Security) with SMTP id 28.9D.16561.E4FB15C4; Thu, 29 Jul 2010 12:50:06 -0500 (CDT) Received: from FHDP1CCMXCG02.us.one.verizon.com ([166.68.240.34]) by smtptpa4.verizon.com (8.13.3/8.13.3) with ESMTP id o6THo5rT004606 for ; Thu, 29 Jul 2010 13:50:06 -0400 (EDT) Received: from FHDP1LUMXCV14.us.one.verizon.com ([166.68.125.35]) by FHDP1CCMXCG02.us.one.verizon.com with Microsoft SMTPSVC(6.0.3790.4675); Thu, 29 Jul 2010 13:50:04 -0400 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Thu, 29 Jul 2010 13:49:51 -0400 Message-ID: <793F49BA1FC821409F99F10862A0E4DB07CA27A9@FHDP1LUMXCV14.us.one.verizon.com> In-Reply-To: <793F49BA1FC821409F99F10862A0E4DB07B63225@FHDP1LUMXCV14.us.one.verizon.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Detailed Comments on what is use case versus (abstract) mechanism in draft-moncaster-conex-concepts-uses-01.txt Thread-Index: Acsqwqk1zJZiVEflSJysFO0EGBGdNQCl62swAAImNMA= References: <201007231949.o6NJn38t014418@bagheera.jungle.bt.co.uk><201007232235.o6NMZZ1e015875@bagheera.jungle.bt.co.uk><20100723235447.GE69747@verdi> <793F49BA1FC821409F99F10862A0E4DB07B63225@FHDP1LUMXCV14.us.one.verizon.com> From: "Mcdysan, David E" To: X-OriginalArrivalTime: 29 Jul 2010 17:50:04.0129 (UTC) FILETIME=[79685D10:01CB2F46] X-Brightmail-Tracker: AAAAAA== Subject: [conex] Detailed Comments on what is use case versus (abstract) mechanism in draft-moncaster-conex-concepts-uses-01.txt X-BeenThere: conex@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Congestion Exposure working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 29 Jul 2010 17:49:49 -0000 As requested by Marcelo in the wg meeting, below is a more detailed review of draft-moncaster-conex-concepts-uses-01.txt as to what sections are a use case versus an mechanism. Thanks, Dave 1. Introduction=20 " (Wireless ISPs and cellular internet have different tradeoffs which we will not discuss here.) " IMO, This is an important set of use cases which need to be included. " The ConEx working group proposes that Internet Protocol (IP) packets have two "congestion" fields. The exact protocol details of these fields are for another document, but we expect them to provide measures of "congestion so far" and "congestion still expected". " Above is mechanism. 2. Definitions IMO, using ECN (a specific mechanism) as the basis of use case definitions is a duplication of the wg charter deliverable of an abstract mechanism. This thread runs through the document and should be replaced with terminology aligned with the draft abstract mechanism. A single network which is ECN enabled is a specific use case. 3. Existing Approaches to Congestion Management=20 IMO, the text here is quite relevant to use cases. A use case should define a problem which is not currently solved, and in terminology and a context specific to the use case describe at a high level what form of congestion, if exposed in a particular way, would enable an improvement over the current situation. 4. Exposing Congestion This section is primarily mechanism. 4.1. ECN - a Step in the Right Direction =20 ECN is a specific use case and should be described. Issues with it (e.g., limited deployment in operator network equipment) should be mentioned. 5. Requirements for ConEx=20 Attibutes like timeliness, accuracy and visibility (there may be more) could be a good set of terminology in which to describe various use cases, as well as decide on an appropriate abstract mechanism. 5.1. ConEx Issues=20 The descriptions of interaction with non-conex traffic and over/under declaration of conex traffic should be rewritten as attributes which may apply to some (possibly not all) use cases. The bulleted list introduced by the text: "There are three approaches that may work ..." is mechanism (approach is synomomous with mechanism). 6. A Possible Congestion Exposure Mechanism=20 The title (as well as the text) declares this as "Mechanism" and not use case. The references could be cited in the ECN enabled network use case. 7. ConEx Architectural Elements=20 The second paragraph begins: "In the following we are assuming the most abstract version of the ConEx mechanism ..." The next six pages are candidates for the abstract mechanism document 7.1. ConEx Monitoring . . . . . . . . . . . . . . . . . . . . . 13 7.1.1. Edge Monitoring . . . . . . . . . . . . . . . . . . . 13 7.1.2. Border Monitoring . . . . . . . . . . . . . . . . . . 15 7.2. ConEx Policing . . . . . . . . . . . . . . . . . . . . . . 15 7.2.1. Egress Policing . . . . . . . . . . . . . . . . . . . 16 7.2.2. Ingress Policing . . . . . . . . . . . . . . . . . . . 17 7.2.3. Border Policing . . . . . . . . . . . . . . . . . . . 18 Based upon the questions I asked in the wg, the scheduler associated with the queue (i.e., work conserving or non-work conserving) should be added to the abstract mechanism draft. 8. ConEx Use Cases . . . . . . . . . . . . . . . . . . . . . . . 19 Page 19 is where the document first states that use cases are described. A use case document needs to get to this much sooner! Each of these subsections has a similar structural issue -- it begins with some good motivational text and terminology relevant to the use case, but then goes on the summarize how the previously described mechanism can address the described problem. I suggest that the latter part of the text could be rewritten to describe high-level requirements on what could be done by conex to improve the situation and why this would be expected to improve matters. If there is general agreement on this approach, I would be happy to work on text with the draft authors. Furthermore, as we collect use cases (several more were mentioned during the meeting), we may be able to categorize them as having similar characteristics or parameters. Using this categorization, the terminology of the abstract mechanism draft may be used to describe how the class of similar use cases would be supported. 8.1. ConEx as a basis for traffic management =20 8.2. ConEx to incentivise scavenger transports =20 8.3. ConEx to mitigate DDoS=20 8.4. Accounting for Congestion Volume=20 8.5. ConEx as a form of differential QoS =20 8.6. Partial vs. Full Deployment =20 9. Other issues=20 9.1. Congestion as a Commercial Secret =20 I'm not sure how to categorize this section. It seems that external measurements of performance (e.g., by end users as mentioned in the last paragraph) is a contradiction to the assertion in the first paragraph that some network operators want to keep congestion secret. Suggest rewording into a use case, otherwise deletion. 9.2. Information Security=20 Suggest that these be made criteria and/or make them part of use case classes or make them general security consideration. 10. Security Considerations Reword and combine with thoughts from 9.2 and edit out mention of mechanism. =20 From dave.mcdysan@verizon.com Thu Jul 29 11:23:12 2010 Return-Path: X-Original-To: conex@core3.amsl.com Delivered-To: conex@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id DD43428C16B for ; Thu, 29 Jul 2010 11:23:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.172 X-Spam-Level: X-Spam-Status: No, score=-3.172 tagged_above=-999 required=5 tests=[AWL=0.427, BAYES_00=-2.599, 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 Lq4qDTBJGkF1 for ; Thu, 29 Jul 2010 11:23:11 -0700 (PDT) Received: from sacmail2.verizon.com (sacmail2.verizon.com [192.76.84.41]) by core3.amsl.com (Postfix) with ESMTP id BA64328C18A for ; Thu, 29 Jul 2010 11:23:11 -0700 (PDT) Received: from irvintrmemf3.verizon.com (irvintrmemf3.verizon.com [138.83.34.103]) by sacmail2.verizon.com (8.13.7+Sun/8.13.3) with ESMTP id o6TIL9Dn003097; Thu, 29 Jul 2010 14:23:14 -0400 (EDT) X-AuditID: 8a532267-b7bd7ae0000040b1-15-4c51c703c5c2 Received: from smtptpa3.verizon.com ( [138.83.71.176]) by irvintrmemf3.verizon.com (Symantec Mail Security) with SMTP id 90.80.16561.307C15C4; Thu, 29 Jul 2010 13:23:00 -0500 (CDT) Received: from FHDP1CCMXCG02.us.one.verizon.com ([166.68.240.34]) by smtptpa3.verizon.com (8.13.3/8.13.3) with ESMTP id o6TIMwl8023882; Thu, 29 Jul 2010 14:22:59 -0400 (EDT) Received: from FHDP1LUMXCV14.us.one.verizon.com ([166.68.125.35]) by FHDP1CCMXCG02.us.one.verizon.com with Microsoft SMTPSVC(6.0.3790.4675); Thu, 29 Jul 2010 14:22:57 -0400 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Thu, 29 Jul 2010 14:22:46 -0400 Message-ID: <793F49BA1FC821409F99F10862A0E4DB07CA27CB@FHDP1LUMXCV14.us.one.verizon.com> In-Reply-To: <003301cb2f41$dc669080$9533b180$@com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [conex] Comments on the two draft-moncaster-conex-* Thread-Index: AcsvMEOkeiPQprNiSDuR1y/JFmLxVgAEEQUQAAI1s5A= References: <4C5199B8.8070809@tkk.fi> <003301cb2f41$dc669080$9533b180$@com> From: "Mcdysan, David E" To: "Toby Moncaster" , "Jukka Manner" , X-OriginalArrivalTime: 29 Jul 2010 18:22:57.0865 (UTC) FILETIME=[11D89390:01CB2F4B] X-Brightmail-Tracker: AAAAAA== Subject: Re: [conex] Comments on the two draft-moncaster-conex-* X-BeenThere: conex@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Congestion Exposure working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 29 Jul 2010 18:23:13 -0000 Hi, A few responses in line. Dave=20 > -----Original Message----- > From: conex-bounces@ietf.org [mailto:conex-bounces@ietf.org]=20 > On Behalf Of Toby Moncaster > Sent: Thursday, July 29, 2010 1:17 PM > To: 'Jukka Manner'; conex@ietf.org > Subject: Re: [conex] Comments on the two draft-moncaster-conex-* >=20 > Hi Jukka, >=20 > Thanks for the comments... Some responses inline >=20 > Toby >=20 > > -----Original Message----- > > From: conex-bounces@ietf.org=20 > [mailto:conex-bounces@ietf.org] On Behalf=20 > > Of Jukka Manner > > Sent: 29 July 2010 16:10 > > To: conex@ietf.org > > Subject: [conex] Comments on the two draft-moncaster-conex-* > >=20 > > Hi, > >=20 > > I went through the two draft-moncaster documents, use cases and=20 > > problem statement. They are mostly readable and relatively easy to=20 > > follow. Some parts really need more explanation, or at least some=20 > > thought (probably just the latter). > >=20 > > I have two proposals: > >=20 > > 1. The two drafts have a lot in common and a reader checking both=20 > > drafts will encounter a lot of repetition. I would suggest=20 > to consider=20 > > if the documents could be merged as one. >=20 > The Problem statement draft was written as part of the=20 > motivations for setting up this working group. It has now=20 > served its purpose and the authors are probably going to=20 > allow it to expire. The idea is that the Use Cases document=20 > should pick up some of the key motivations from the problem=20 > statement and is, in effect, the next step Makes sense to me. I just sent comments on the general use case vs mechanism comment I posted earlier this week as requested by the chair for your consideration. >=20 > >=20 > > 2. It is not very obvious how would the network in practice=20 > find and=20 > > treat two users, where one is a heavy user and the other a=20 > small user=20 > > (or users). Could you add some text on how the conex scheme would=20 > > work, show some concrete example with network congestion,=20 > created load=20 > > and the network response. I know this info is there but it would=20 > > benefit from a concrete example(s) with numbers. >=20 > Reliably identifying different users is always going to be an=20 > issue in the Internet. In the absence of source-address=20 > spoofing you can identify a source-destination pair and use=20 > that. By adding up all the congestion-volume you see for each=20 > id at a given point you can identify the "heaviest" users. > At the border of a network, the operator can use ConEx to see=20 > how much congestion is being caused in its network by each=20 > source (if it trusts source addresses) or can use other=20 > heuristics to identify which user is "heavy" and which isn't... >=20 > {individual reply as 1 of 4 authors} I might consider having=20 > a simple numerical example, probably as an appendix to the use cases.=20 >=20 I agree that a use case of heavy vs small user is an important use case. Possibly the example from section 8.4 of the use case draft could be amended with this concept and expand the tragedy of the commons example to have shepherds with flocks of different sizes. I had this use case in mind at the mike at the plenary from Frank Varian, a version of which might be a start for the text you propose in an appendix: In many networks, 20% are heavy users generate 80% of the traffic. This means that a heavy user generates 16 times as much traffic as a small user. However, in a bandwidth tier priced network, heavy and small users may in fact pay nearly the same price. On average during periods of peak use, the heavy user sends at near the bandwidth tier value while small users send in an intermittent manner. The (access) network is engineered at the peak capacity of all these users, and when it is congested, the heavy users are creating 16x the congestion of small users. Long-term (e.g., monthly) usage volume based pricing helps address this inequity, but; is complex for users to understand, and does not address the situation where heavy users send at a high rate, but only for a fraction of the usage measurement interval (e.g., a month). What is needed in the use case is a more equitable means for a service provider to more equitably assign allocation of costs to the heavy and small users. > >=20 > > Hope this helps, > > Jukka > > _______________________________________________ > > conex mailing list > > conex@ietf.org > > https://www.ietf.org/mailman/listinfo/conex >=20 > _______________________________________________ > conex mailing list > conex@ietf.org > https://www.ietf.org/mailman/listinfo/conex >=20