From teco@inf-net.nl Fri Apr 1 02:01:13 2011 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 E33323A6452 for ; Fri, 1 Apr 2011 02:01:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.556 X-Spam-Level: X-Spam-Status: No, score=-3.556 tagged_above=-999 required=5 tests=[AWL=0.043, 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 Yv1FEnL3-0QG for ; Fri, 1 Apr 2011 02:01:13 -0700 (PDT) Received: from mail-bw0-f44.google.com (mail-bw0-f44.google.com [209.85.214.44]) by core3.amsl.com (Postfix) with ESMTP id 2C87D3A6405 for ; Fri, 1 Apr 2011 02:01:12 -0700 (PDT) Received: by bwz13 with SMTP id 13so2566563bwz.31 for ; Fri, 01 Apr 2011 02:02:52 -0700 (PDT) Received: by 10.204.74.11 with SMTP id s11mr3410059bkj.43.1301648572548; Fri, 01 Apr 2011 02:02:52 -0700 (PDT) Received: from dhcp-522a.meeting.ietf.org (dhcp-522a.meeting.ietf.org [130.129.82.42]) by mx.google.com with ESMTPS id 16sm1244144bkm.6.2011.04.01.02.02.51 (version=TLSv1/SSLv3 cipher=OTHER); Fri, 01 Apr 2011 02:02:51 -0700 (PDT) From: Teco Boot Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Date: Fri, 1 Apr 2011 11:02:47 +0200 Message-Id: <154F7D11-884F-446C-9DF7-EC9DE6FD7E88@inf-net.nl> To: conex@ietf.org Mime-Version: 1.0 (Apple Message framework v1082) X-Mailer: Apple Mail (2.1082) Subject: [conex] Using DSCP 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, 01 Apr 2011 09:01:14 -0000 Seen the struggle finding bits in IPv4 and IPv6 headers for Conex signaling, we could explore the option using codepoints from DSCP pools 2 & 3 (EXP/LU). This limits Conex to separate set of PHBs. But the approach would work equivalent for v4 and v6, without to much trouble. Is a limitation to Default PHB acceptable? Teco From bob.briscoe@bt.com Fri Apr 1 02:45:23 2011 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 630AF3A6781 for ; Fri, 1 Apr 2011 02:45:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.477 X-Spam-Level: X-Spam-Status: No, score=-3.477 tagged_above=-999 required=5 tests=[AWL=0.122, 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 MH5ZW1owkP+A for ; Fri, 1 Apr 2011 02:45:22 -0700 (PDT) Received: from smtp4.smtp.bt.com (smtp4.smtp.bt.com [217.32.164.151]) by core3.amsl.com (Postfix) with ESMTP id 477F13A679C for ; Fri, 1 Apr 2011 02:45:22 -0700 (PDT) Received: from i2kc08-ukbr.domain1.systemhost.net ([193.113.197.71]) by smtp4.smtp.bt.com with Microsoft SMTPSVC(6.0.3790.4675); Fri, 1 Apr 2011 10:47:01 +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); Fri, 1 Apr 2011 10:47:01 +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 1301651219601; Fri, 1 Apr 2011 10:46:59 +0100 Received: from MUT.jungle.bt.co.uk ([10.73.193.101]) by bagheera.jungle.bt.co.uk (8.13.5/8.12.8) with ESMTP id p319kvpI028515; Fri, 1 Apr 2011 10:46:58 +0100 Message-Id: <201104010946.p319kvpI028515@bagheera.jungle.bt.co.uk> X-Mailer: QUALCOMM Windows Eudora Version 7.1.0.9 Date: Fri, 01 Apr 2011 10:46:57 +0100 To: Teco Boot From: Bob Briscoe In-Reply-To: <154F7D11-884F-446C-9DF7-EC9DE6FD7E88@inf-net.nl> References: <154F7D11-884F-446C-9DF7-EC9DE6FD7E88@inf-net.nl> 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: 01 Apr 2011 09:47:01.0227 (UTC) FILETIME=[BFDEFBB0:01CBF051] Cc: conex@ietf.org Subject: Re: [conex] Using DSCP 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, 01 Apr 2011 09:45:23 -0000 Teco, There's an architectural objection, which we might be able to side-step for experiments, but also a practical objection: - architectural: as you point out, ConEx should be orthogonal to DS, and therefore, if we used the DS field, we would need to pair up a DSCP up against every DSCP in use. - pragmatic: I'd like to be able to do experiments on the public Internet, so the participating users have a reason to want to take part in the experiment (rather than being limited to just a few sites). DSCPs often get bleached, and relying on local use would mean not being able to use e2e paths unless they were wholly within networks participating in the experiment. Bob At 10:02 01/04/2011, Teco Boot wrote: >Seen the struggle finding bits in IPv4 and IPv6 headers for >Conex signaling, we could explore the option using codepoints >from DSCP pools 2 & 3 (EXP/LU). This limits Conex to separate >set of PHBs. But the approach would work equivalent for v4 and >v6, without to much trouble. > >Is a limitation to Default PHB acceptable? > >Teco > >_______________________________________________ >conex mailing list >conex@ietf.org >https://www.ietf.org/mailman/listinfo/conex ________________________________________________________________ Bob Briscoe, BT Innovate & Design From teco@inf-net.nl Fri Apr 1 03:21:32 2011 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 60E083A67F1 for ; Fri, 1 Apr 2011 03:21:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.566 X-Spam-Level: X-Spam-Status: No, score=-3.566 tagged_above=-999 required=5 tests=[AWL=0.033, 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 GTho3uJpHyrC for ; Fri, 1 Apr 2011 03:21:28 -0700 (PDT) Received: from mail-bw0-f44.google.com (mail-bw0-f44.google.com [209.85.214.44]) by core3.amsl.com (Postfix) with ESMTP id 49BAA3A67EF for ; Fri, 1 Apr 2011 03:21:27 -0700 (PDT) Received: by bwz13 with SMTP id 13so2613441bwz.31 for ; Fri, 01 Apr 2011 03:23:07 -0700 (PDT) Received: by 10.204.14.130 with SMTP id g2mr530057bka.116.1301653386469; Fri, 01 Apr 2011 03:23:06 -0700 (PDT) Received: from dhcp-14b8.meeting.ietf.org (dhcp-14b8.meeting.ietf.org [130.129.20.184]) by mx.google.com with ESMTPS id w3sm1292931bkt.17.2011.04.01.03.23.04 (version=TLSv1/SSLv3 cipher=OTHER); Fri, 01 Apr 2011 03:23:05 -0700 (PDT) Mime-Version: 1.0 (Apple Message framework v1082) Content-Type: text/plain; charset=us-ascii From: Teco Boot In-Reply-To: <201104010946.p319kvpI028515@bagheera.jungle.bt.co.uk> Date: Fri, 1 Apr 2011 12:23:03 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: <5E4EE016-F5ED-402C-A484-B19976C4F558@inf-net.nl> References: <154F7D11-884F-446C-9DF7-EC9DE6FD7E88@inf-net.nl> <201104010946.p319kvpI028515@bagheera.jungle.bt.co.uk> To: Bob Briscoe X-Mailer: Apple Mail (2.1082) Cc: conex@ietf.org Subject: Re: [conex] Using DSCP 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, 01 Apr 2011 10:21:32 -0000 Bob, Op 1 apr 2011, om 11:46 heeft Bob Briscoe het volgende geschreven: > Teco, >=20 > There's an architectural objection, which we might be able to = side-step for experiments, but also a practical objection: >=20 > - architectural: as you point out, ConEx should be orthogonal to DS, = and therefore, if we used the DS field, we would need to pair up a DSCP = up against every DSCP in use. Yes. But Conex for Default PHB would be the far most important one. = Conex PHBs are mapped to Default PHB by default. > - pragmatic: I'd like to be able to do experiments on the public = Internet, so the participating users have a reason to want to take part = in the experiment (rather than being limited to just a few sites). DSCPs = often get bleached, and relying on local use would mean not being able = to use e2e paths unless they were wholly within networks participating = in the experiment. Yes. Public Internet has limitations. But the experiment could show = Conex benefits where it worked. The IPv6 destination option requires IPv6 connectivity. Not available = everywhere yet, I think. Very pragmatic:=20 - use DSCP for Default PHB traffic; - use IPv6 Destination Option for other PHB; - forget IPv4 && non_Default_PHB. Some people force us to such model. We could document this pressure, and = use is as reasoning for this pragmatic approach. Teco > Bob >=20 > At 10:02 01/04/2011, Teco Boot wrote: >> Seen the struggle finding bits in IPv4 and IPv6 headers for >> Conex signaling, we could explore the option using codepoints >> from DSCP pools 2 & 3 (EXP/LU). This limits Conex to separate >> set of PHBs. But the approach would work equivalent for v4 and >> v6, without to much trouble. >>=20 >> Is a limitation to Default PHB acceptable? >>=20 >> Teco >>=20 >> _______________________________________________ >> conex mailing list >> conex@ietf.org >> https://www.ietf.org/mailman/listinfo/conex >=20 > ________________________________________________________________ > Bob Briscoe, BT Innovate & Design=20 From swmike@swm.pp.se Fri Apr 1 03:38:20 2011 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 1CA883A67F2 for ; Fri, 1 Apr 2011 03:38:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.556 X-Spam-Level: X-Spam-Status: No, score=-2.556 tagged_above=-999 required=5 tests=[AWL=0.043, 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 N24QKdVTamWx for ; Fri, 1 Apr 2011 03:38:19 -0700 (PDT) Received: from uplift.swm.pp.se (ipv6.swm.pp.se [IPv6:2a00:801::f]) by core3.amsl.com (Postfix) with ESMTP id 0D0263A67F5 for ; Fri, 1 Apr 2011 03:38:17 -0700 (PDT) Received: by uplift.swm.pp.se (Postfix, from userid 501) id 4CB359C; Fri, 1 Apr 2011 12:39:56 +0200 (CEST) Received: from localhost (localhost [127.0.0.1]) by uplift.swm.pp.se (Postfix) with ESMTP id 4A8B19A for ; Fri, 1 Apr 2011 12:39:56 +0200 (CEST) Date: Fri, 1 Apr 2011 12:39:56 +0200 (CEST) From: Mikael Abrahamsson To: conex@ietf.org Message-ID: User-Agent: Alpine 2.00 (DEB 1167 2008-08-23) Organization: People's Front Against WWW MIME-Version: 1.0 Content-Type: TEXT/PLAIN; format=flowed; charset=US-ASCII Subject: [conex] offer regarding IPSEC tunnel testing 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, 01 Apr 2011 10:38:20 -0000 Hello. If someone produces running code for preferrably Linux, I can participate in a test involving a Linux box + ipsec tunnel router(s) (Cisco) at my end. I work for an ISP, so the machine would be reachable from anywhere anyone was interested in doing testing. PS. I haven't checked that cisco actually has IPSEC for IPv6 working, but it would surprise me if they didn't. -- Mikael Abrahamsson email: swmike@swm.pp.se From toby@moncaster.com Fri Apr 1 03:41:54 2011 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 8F3103A67F3 for ; Fri, 1 Apr 2011 03:41:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.189 X-Spam-Level: X-Spam-Status: No, score=-2.189 tagged_above=-999 required=5 tests=[AWL=0.060, 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 ReFO-p-ch4v5 for ; Fri, 1 Apr 2011 03:41:53 -0700 (PDT) Received: from moutng.kundenserver.de (moutng.kundenserver.de [212.227.126.171]) by core3.amsl.com (Postfix) with ESMTP id 7B8853A67ED for ; Fri, 1 Apr 2011 03:41:53 -0700 (PDT) Received: from TobysHP (host86-149-183-12.range86-149.btcentralplus.com [86.149.183.12]) by mrelayeu.kundenserver.de (node=mrbap1) with ESMTP (Nemesis) id 0LkBS6-1PZ1AM48R0-00cC19; Fri, 01 Apr 2011 12:43:33 +0200 From: "Toby Moncaster" To: "'Mikael Abrahamsson'" , References: In-Reply-To: Date: Fri, 1 Apr 2011 11:43:29 +0100 Message-ID: <002501cbf059$a3922290$eab667b0$@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: AcvwWStVET15sbdcQCK7qx/Gqbnj7wAAFDDg Content-Language: en-gb X-Provags-ID: V02:K0:HI5lGtBh9UQH/94giOCdBMgd0M5P9HE7u5jfUC4lBvv WBDJBFeCBN9SHl8TASVuRQgmE0G3tkU3wge3uasYxNLu+0mczE hKZvm68SFTle1yb5LQwsBn+sD7Pl+R+DATNEoRiVliwQ+YhSaB DlQZQdxn/YmPeREb/tnDZnAIwScaSiqfrzrx7djkZIpwHR81mM pMuoovS8VogxqiJ7oLvEJSIJ9sKmhZ1SXzdRUmzUVI= Subject: Re: [conex] offer regarding IPSEC tunnel testing 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, 01 Apr 2011 10:41:54 -0000 > -----Original Message----- > From: conex-bounces@ietf.org [mailto:conex-bounces@ietf.org] On Behalf > Of Mikael Abrahamsson > Sent: 01 April 2011 11:40 > To: conex@ietf.org > Subject: [conex] offer regarding IPSEC tunnel testing > > > Hello. > > If someone produces running code for preferrably Linux, I can > participate > in a test involving a Linux box + ipsec tunnel router(s) (Cisco) at my > end. > > I work for an ISP, so the machine would be reachable from anywhere > anyone > was interested in doing testing. > > PS. I haven't checked that cisco actually has IPSEC for IPv6 working, > but > it would surprise me if they didn't. And if they don't, doesn't it just make our job easier? ;) Toby > > -- > Mikael Abrahamsson email: swmike@swm.pp.se > _______________________________________________ > conex mailing list > conex@ietf.org > https://www.ietf.org/mailman/listinfo/conex From bob.briscoe@bt.com Fri Apr 1 05:50:23 2011 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 52EF23A684F for ; Fri, 1 Apr 2011 05:50:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.482 X-Spam-Level: X-Spam-Status: No, score=-3.482 tagged_above=-999 required=5 tests=[AWL=0.117, 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 7QpLMVAsbR+i for ; Fri, 1 Apr 2011 05:50:08 -0700 (PDT) Received: from smtp2.smtp.bt.com (smtp2.smtp.bt.com [217.32.164.150]) by core3.amsl.com (Postfix) with ESMTP id 7E4913A6845 for ; Fri, 1 Apr 2011 05:50:07 -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); Fri, 1 Apr 2011 13:51:46 +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, 1 Apr 2011 13:51:46 +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 1301662305360; Fri, 1 Apr 2011 13:51:45 +0100 Received: from MUT.jungle.bt.co.uk ([10.73.129.105]) by bagheera.jungle.bt.co.uk (8.13.5/8.12.8) with ESMTP id p31CphYF029178; Fri, 1 Apr 2011 13:51:44 +0100 Message-Id: <201104011251.p31CphYF029178@bagheera.jungle.bt.co.uk> X-Mailer: QUALCOMM Windows Eudora Version 7.1.0.9 Date: Fri, 01 Apr 2011 13:51:38 +0100 To: Teco Boot From: Bob Briscoe In-Reply-To: <5E4EE016-F5ED-402C-A484-B19976C4F558@inf-net.nl> References: <154F7D11-884F-446C-9DF7-EC9DE6FD7E88@inf-net.nl> <201104010946.p319kvpI028515@bagheera.jungle.bt.co.uk> <5E4EE016-F5ED-402C-A484-B19976C4F558@inf-net.nl> 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: 01 Apr 2011 12:51:46.0629 (UTC) FILETIME=[8F491750:01CBF06B] Cc: conex@ietf.org Subject: Re: [conex] Using DSCP 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, 01 Apr 2011 12:50:23 -0000 Teco, At 11:23 01/04/2011, Teco Boot wrote: >Bob, > >Op 1 apr 2011, om 11:46 heeft Bob Briscoe het volgende geschreven: > > > Teco, > > > > There's an architectural objection, which we might be able to > side-step for experiments, but also a practical objection: > > > > - architectural: as you point out, ConEx should be orthogonal to > DS, and therefore, if we used the DS field, we would need to pair > up a DSCP up against every DSCP in use. > >Yes. But Conex for Default PHB would be the far most important one. >Conex PHBs are mapped to Default PHB by default. > > > - pragmatic: I'd like to be able to do experiments on the public > Internet, so the participating users have a reason to want to take > part in the experiment (rather than being limited to just a few > sites). DSCPs often get bleached, and relying on local use would > mean not being able to use e2e paths unless they were wholly within > networks participating in the experiment. > >Yes. Public Internet has limitations. But the experiment could show >Conex benefits where it worked. >The IPv6 destination option requires IPv6 connectivity. Not >available everywhere yet, I think. > >Very pragmatic: > - use DSCP for Default PHB traffic; > - use IPv6 Destination Option for other PHB; Why not Dst Opt for all IPv6? Otherwise there's interop issues. > - forget IPv4 && non_Default_PHB. Well, I'm working on the IPv4 case. See draft-briscoe-ipv4-id-reuse I know we're not chartered for v4, but v4 obviously requires some groundwork that needs starting in parallel if it is to be ready for any future rechartering to extend ConEx to v4. (not to mention v6 which needs a complete brain-transplant) >Some people force us to such model. We could document this pressure, >and use is as reasoning for this pragmatic approach. Yes, I argued for documenting this too. We have actually found a requirement that wasn't recognised when v6 was built. v6 extensions headers and hop-by-hop options assumed there are only three types of IP-aware node: router, tunnel endpoint or host. However, there can be IP-aware nodes between the endpoints that are not necessarily routers; in our case traffic management nodes, or more generally IP-monitoring functions that may trigger some action. We need a header-type that always gets copied to the outer and is not encrypted, but which is ignored hop-by-hop by routers, then it can still be seen by this new type of node (monitor). Bob >Teco > > > > Bob > > > > At 10:02 01/04/2011, Teco Boot wrote: > >> Seen the struggle finding bits in IPv4 and IPv6 headers for > >> Conex signaling, we could explore the option using codepoints > >> from DSCP pools 2 & 3 (EXP/LU). This limits Conex to separate > >> set of PHBs. But the approach would work equivalent for v4 and > >> v6, without to much trouble. > >> > >> Is a limitation to Default PHB acceptable? > >> > >> Teco > >> > >> _______________________________________________ > >> conex mailing list > >> conex@ietf.org > >> https://www.ietf.org/mailman/listinfo/conex > > > > ________________________________________________________________ > > Bob Briscoe, BT Innovate & Design ________________________________________________________________ Bob Briscoe, BT Innovate & Design From karagian@cs.utwente.nl Sun Apr 3 05:58:24 2011 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 4363A3A6984 for ; Sun, 3 Apr 2011 05:58:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.124 X-Spam-Level: X-Spam-Status: No, score=0.124 tagged_above=-999 required=5 tests=[AWL=0.628, BAYES_00=-2.599, HELO_EQ_NL=0.55, HOST_EQ_NL=1.545] 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 eXmm-VRWauRL for ; Sun, 3 Apr 2011 05:58:23 -0700 (PDT) Received: from denhaag.ewi.utwente.nl (denhaag.ewi.utwente.nl [130.89.10.11]) by core3.amsl.com (Postfix) with ESMTP id 0B9B83A67E7 for ; Sun, 3 Apr 2011 05:58:22 -0700 (PDT) Received: from webmail.cs.utwente.nl (janus.ewi.utwente.nl [130.89.10.26]) by denhaag.ewi.utwente.nl (8.13.6/8.13.6) with SMTP id p33CxTSj011229; Sun, 3 Apr 2011 14:59:29 +0200 (MEST) Received: from 84.82.109.231 (auth. user karagian@imap1.ewi.utwente.nl) by webmail.cs.utwente.nl with HTTP; Sun, 03 Apr 2011 12:59:53 +0000 To: "conex@ietf.org" Date: Sun, 03 Apr 2011 12:59:53 +0000 X-Mailer: IlohaMail/0.8.13 (On: webmail.cs.utwente.nl) Message-ID: From: "Georgios Karagiannis" Bounce-To: "Georgios Karagiannis" Errors-To: "Georgios Karagiannis" MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable X-Scanned-By: MIMEDefang 2.52 on 130.89.10.11 X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-3.0rc3 (denhaag.ewi.utwente.nl [130.89.10.11]); Sun, 03 Apr 2011 14:59:38 +0200 (MEST) Subject: [conex] new internet draft on exposing conex throughput 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, 03 Apr 2011 12:58:24 -0000 Hi all I have just submitted the Internet draft entitled: =7F"Exposing Conex Throughput", see http://www.ietf.org/id/draft-karagiannis-conex-throughput-exposure-00.txt. This document describes a possible implementation complexity problem associated with the current Conex concept defined by the ConEx WG and it proposes a solution to this. This problem occurs due to the fact that it is complex to measure the congestion rate, at each intermediate Conex enabled device. A conex enabled device can be for example, a policer or an audit device. Moreover, this document provides a solution to this problem, by measuring and monitoring the per flow throughput on each intermediate Conex enabled device instead of measuring and monitoring the per flow congestion rate on each intermediate Conex enabled device. The mentioned problem is related to the fact that in the context of Conex it is complex to measure the congestion rate, see [RFC5348] at each intermediate Conex enabled device. In particular, the main solution proposed in [draft-ietf-conex-abstract-mech-01] on measuring the congestion rate on an audit device is: "The auditor could monitor TCP flows or aggregates of flows, only holding state on a flow if it first sends a Credit or a Re-Echo-Loss marking. The auditor could detect retransmissions by monitoring sequence numbers. It would assure that (volume of retransmitted data) <=3D (volume of data marked Re-Echo-Loss). Traffic would only be auditable in this way if it conformed to the standard TCP protocol and the IP payload was not encrypted (e.g. with IPsec). ", from [draft-ietf-conex-abstract-mech-01]. In other words, an audit device needs to keep per flow (individual or aggregated) state after it receives a credit or Re-echo-Loss marking in order to measure the per flow congestion rate. In addition to this the audit device must be able to read the TCP header in order to observe the TCP header numbers. This is complex to be implemented and it is not always possible, e.g., when the IP payload is encrypted (e.g. with IPsec). In this way the audit device is also able to take into consideration also the number of ECN CE marked packets that were dropped by nodes located upstream. Note that in my opinion the same method of measuring the congestion rate at a policer is required as the one applied at the audit device. This document provides a solution to this problem, by measuring and monitoring the per flow throughput on each intermediate Conex enabled device instead of measuring and monitoring the per flow congestion rate on each intermediate Conex enabled device. Comments are welcome! Best regards, Georgios From marcelo@it.uc3m.es Sun Apr 3 23:09:09 2011 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 9899A3A68CB for ; Sun, 3 Apr 2011 23:09:09 -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 qp+gj6oj32EJ for ; Sun, 3 Apr 2011 23:09:07 -0700 (PDT) Received: from smtp02.uc3m.es (smtp02.uc3m.es [163.117.176.132]) by core3.amsl.com (Postfix) with ESMTP id A6F9D3A6906 for ; Sun, 3 Apr 2011 23:09:07 -0700 (PDT) X-uc3m-safe: yes Received: from marcelo-bagnulos-macbook-pro-2.local (192.50.22.95.dynamic.jazztel.es [95.22.50.192]) (using TLSv1 with cipher AES256-SHA (256/256 bits)) (No client certificate requested) by smtp02.uc3m.es (Postfix) with ESMTP id 1F45065708C for ; Mon, 4 Apr 2011 08:10:48 +0200 (CEST) Message-ID: <4D9960E7.6040404@it.uc3m.es> Date: Mon, 04 Apr 2011 08:10:47 +0200 From: marcelo bagnulo braun User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.5; es-ES; rv:1.9.2.15) Gecko/20110303 Thunderbird/3.1.9 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.5.0.1024-18052.003 Subject: [conex] V6 encoding of conex information 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, 04 Apr 2011 06:09:09 -0000 Hi, During the meeting in Prague, the WG expressed that the best option to encode conex information was in a v6 Destination option. As decisions are made on the ml, this mail is to confirm the decision of encoding conex info in destination options. Regards, marcelo From dave.mcdysan@verizon.com Mon Apr 4 05:05:42 2011 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 4CEA328C0EF for ; Mon, 4 Apr 2011 05:05:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.519 X-Spam-Level: X-Spam-Status: No, score=-3.519 tagged_above=-999 required=5 tests=[AWL=0.080, 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 bjaYO1ykwWXJ for ; Mon, 4 Apr 2011 05:05:34 -0700 (PDT) Received: from sacmail2.verizon.com (sacmail2.verizon.com [192.76.84.41]) by core3.amsl.com (Postfix) with ESMTP id 9D61C3A67A1 for ; Mon, 4 Apr 2011 05:05:34 -0700 (PDT) Received: from fldsmtpi01.verizon.com (fldsmtpi01.verizon.com [166.68.71.143]) by sacmail2.verizon.com (8.13.7+Sun/8.13.3) with ESMTP id p34C7GcI028547 for ; Mon, 4 Apr 2011 08:07:17 -0400 (EDT) From: "Mcdysan, David E" X-IronPort-AV: E=Sophos;i="4.63,296,1299456000"; d="scan'208";a="23572547" Received: from fhdp1lumxc7hb02.verizon.com (HELO FHDP1LUMXC7HB02.us.one.verizon.com) ([166.68.59.189]) by fldsmtpi01.verizon.com with ESMTP; 04 Apr 2011 12:07:16 +0000 Received: from fhdp1lumxc7v11.us.one.verizon.com ([169.254.1.173]) by FHDP1LUMXC7HB02.us.one.verizon.com ([2002:a644:3bbd::a644:3bbd]) with mapi; Mon, 4 Apr 2011 08:07:16 -0400 To: "conex@ietf.org" Date: Mon, 4 Apr 2011 08:07:13 -0400 Thread-Topic: [conex] comments/suggestions on draft-ietf-conex-concepts-uses-01 Thread-Index: AcvywNZSG8lNoO0/SsqE4alM0n7ZVg== Message-ID: In-Reply-To: <10CDB575-B519-4421-819E-3E911BF53D26@cdt.org> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.1.0.101012 acceptlanguage: en-US Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: Re: [conex] comments/suggestions on draft-ietf-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, 04 Apr 2011 12:05:42 -0000 As I mentioned in the status presentation last Thursday, I planned to send a paragraph to the conex wg list with proposed text for an additional paragraph to be placed at the end of section 5.1. I am responding to point 1 Alissas' Email on this subject, since I think her note summarizes wg consensus on this topic well. (Also note that this closely aligns with the text cited from the reference [Bauer09]). The remainder of section 6 relating to this topic would be removed, with discussion required to determine whether the wg sees value in keeping section 6.2 (possibly in an Appendix), or removing that as well. The formulation of this approach by Toby helped me better understand conex, but if that is not wg consensus, then so be it. "Traffic measurements over time scales longer than that of policers/shapers involving conex information can be used to adjust the token bucket parameters of these policers and adjust parameters of shapers. These longer time scale conex related measurements can also provide other uses [Bauer09, pg.18-19], such as; achieve better understanding user traffic requirements, provide a better basis for planning investments, enable better service customization, or achieve better matching of costs and usage. When measurement is done in a network element that implements a shaper, the amount which self congestion contributes to overall congestion may be estimated for similar uses. These traffic management techniques employing conex information may help address the challenging problem where a small percentage of users (e.g., 20%) generate a large portion of the traffic (e.g., 80%) [Varian09]. " Also, based upon some misunderstanding of terminology that was apparent on the list, I propose that the RFC 2475 definition of "shaper" be added to section 3.1, existing approaches. Thanks, Dave On Friday3/25/11 4:37 AM, "Alissa Cooper" wrote: >In my reading of section 6, it presents 2 distinct issues: > >1) Long time scales: A use case (or perhaps a few variations on the >same use case) for the conex signal as currently described in abstract- >mech, wherein conex helps network operators to manage congestion, >conduct traffic shaping, and capacity-plan over periods much longer >than network speeds (e.g., minutes/hours/days/months) > >2) Shaper presence: A suggestion that conex could signal the presence >of a traffic shaper (in addition to or instead of how the conex signal >is currently described in abstract-mech) and a use case for such a >signal wherein recipients of the signal can use it to request that >sender's traffic shaper parameters be altered > >I think the issue of long time scales, which is described in the >introductory text to section 6 and briefly in 6.1 and 6.2, could >instead be succinctly addressed by adding a couple of sentences to 5.1 >to explain that the use of conex for managing "heavy" users could >occur over shorter or longer time scales and could have the added >affect of helping operators to do longer-term capacity planning. > >Signaling the presence of a shaper seems to me to be a separate animal >altogether, and one over which there is some obvious disagreement. But >at least half of section 6 seems to be devoted to the idea that >operators would have uses for aggregating conex information over long >time frames, and I think those uses could be incorporated with a brief >addition to section 5.1. > >Alissa > >On Mar 17, 2011, at 12:25 PM, Mcdysan, David E wrote: > >> Hi Nandita, >> >> A few responses to your questions on the new section in line below >> prefixed by DM which were previously posted to the list that I >> believe (at least partially) address your comments. >> >> I propose that the working group work toward how to organize/merge/ >> move the new text better into the existing outline. >> >> Thanks, >> >> Dave >> >> From: Nandita Dukkipati >> Date: Thu, 17 Mar 2011 03:28:25 -0400 >> To: Toby Moncaster , John Leslie , >> Bob Briscoe , "Woundy, Richard" >>> >, David McDysan >> Cc: "conex@ietf.org" >> Subject: comments/suggestions on draft-ietf-conex-concepts-uses-01 >> >> On reading the latest draft, I have three high level comments >> roughly in the following order of importance- >> >> *** >> Statistical Multiplexing over different timescales. >> This reads like a rambling story. I have read and re-read it, and I >> am still left wondering - >> * What is _the_ main point? How about starting the section by >> stating your main point upfront as opposed leaving it to the reader >> to figure it out. >> >> DM - From my 3/10/11 on the list >> >> 1) A few "heavy" users generate most of the traffic and service >> providers >> want to better assign the cost (of provisioning an upgrade) for the >> time >> when congestion is anticipated to occur. Existing mechanisms, flat >> rate, >> bandwidth tier shapers, and usage tiers do not completely address the >> service provider objective and/or are not popular with users. >> >> 2) In some service provider networks shapers are implemented to >> limit the >> maximum bandwidth per user. Although overflow or marking in the shaper >> queue appears as congestion to the receiver, this "self-congestion" >> differs from congestion of a shared resource since a remedy could be >> to >> indicate to the user that changing the shaper rate (i.e., "go faster") >> would alleviate "self-congestion." >> >> * Why and how is this use case distinct from that of traffic >> management which already seems to have a broad scope? Is it really >> distinct? >> >> DM - From my 3/11/11 post to the list >> >> Editorially, this (section 5.1) could be a place to state the >> problem with an additional >> reference to [Varian]. >> >> Editorially, bandwidth tier pricing could be added to section 3.1, >> Existing approaches. >> >> I am now thinking that editorially a separate section is not a good >> idea, >> since the points can be merged into the existing outline, in at >> least the >> places mentioned above. >> >> I think adding that the use case needs to meet service provider >> economic >> congestion needs as well as be acceptable to users is an important >> point >> not in the current text. Traffic management (aka policing) may have >> the >> problem that it may not be popular with user. There has already been >> negative feedback on the list regarding policing (IMO, Traffic >> management >> is a better term). >> >> >> * [minor] Why not make this use case a part of Sec. 5? >> >> DM =AD the minutes recorded adding the agreement to add this as a new >> section. (A new subsection, and or merging thoughts with other use >> cases (e.g., as suggested above) is what I believe the wg needs to >> discuss. >> >> *** >> Partial versus full deployment. >> Clearly, it belongs to this draft. But why is it a part of use >> cases? Looks out of place to me. >> >> *** >> Sec 4. Exposing congestion. >> =B3We argue that congestion needs.... More specifically, a network >> needs to be able to measure how much congestion any particular >> traffic expects to cause between the monitoring point in the network >> and the destination ("rest-of-path congestion"). This would be a new >> capability.=B2 >> >> Could you add more clarity and explanation on why local congestion >> information at any given node is not sufficient. Why does a node >> require congestion information from a monitoring point to the >> destination to be able to manage its own congestion? A succinct >> explanation and/or an example will go a long way. >> >> _______________________________________________ >> conex mailing list >> conex@ietf.org >> https://www.ietf.org/mailman/listinfo/conex > > From toby@moncaster.com Mon Apr 4 09:41:56 2011 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 2421C28C118 for ; Mon, 4 Apr 2011 09:41:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.198 X-Spam-Level: X-Spam-Status: No, score=-2.198 tagged_above=-999 required=5 tests=[AWL=0.050, 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 KqvK7MFWYLs3 for ; Mon, 4 Apr 2011 09:41:52 -0700 (PDT) Received: from moutng.kundenserver.de (moutng.kundenserver.de [212.227.126.186]) by core3.amsl.com (Postfix) with ESMTP id 4DDF63A6A01 for ; Mon, 4 Apr 2011 09:41:52 -0700 (PDT) Received: from TobysHP (host86-149-183-12.range86-149.btcentralplus.com [86.149.183.12]) by mrelayeu.kundenserver.de (node=mrbap2) with ESMTP (Nemesis) id 0MY4Nk-1QSfKz0z20-00V1Nu; Mon, 04 Apr 2011 18:43:21 +0200 From: "Toby Moncaster" To: , "'marcelo bagnulo braun'" , "'Nandita Dukkipati'" Date: Mon, 4 Apr 2011 17:43:19 +0100 Message-ID: <002501cbf2e7$67bf5270$373df750$@com> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0026_01CBF2EF.C983BA70" X-Mailer: Microsoft Office Outlook 12.0 Thread-Index: Acvy52c8hWaGq2h3S9OPTRHFVjvW1A== Content-Language: en-gb X-Provags-ID: V02:K0:WaQDK8awrdpX5ufCNTJl7BrXDg9H5KPOAtQrT/ni66J 5y4eBqinOVlhHHBqTOdZpNEaoh3Nxkw1rMKClX2SqbdILxrl9T 4y1x2aFNzR2D5R8NmJHG5a2RdslrY/nTVYJfImnznTCgfvUGsu QforC8pq3hONO58nILwpoCOj2K9olJT4JhTb/cW5xKE/u0yzI6 prZv2iqHlZHaRJjS7Ufo3Rvq82Tp8+o6SJSQWLDDyg= Cc: draft-ietf-conex-concepts-uses@tools.ietf.org Subject: [conex] giving up as editor of use draft-ietf-conex-concepts-uses 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, 04 Apr 2011 16:41:56 -0000 This is a multi-part message in MIME format. ------=_NextPart_000_0026_01CBF2EF.C983BA70 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit All, During Thursday's meeting, Marcelo made it pretty clear that he felt no progress was being made on the concepts and use cases document. I am the main editor of the document and have had the pen for most of the past 4 months. This means that the problems with the document must be a failure on my part. I am keen that ConEx should progress smoothly through the IETF and that requires the working group chairs to be confident in the editor. I also know that I haven't been able to contribute as much time and energy as I might have hoped. With that in mind I am resigning as editor of the document. Hopefully Marcelo and Nandita will be able to find a replacement they have more confidence in and who is able to make better progress with this surprisingly difficult document. I would still like to contribute as an author and WG member and I wish any successor as editor good luck in what is a largely thankless task, Yours, Toby Moncaster ------=_NextPart_000_0026_01CBF2EF.C983BA70 Content-Type: text/html; charset="US-ASCII" Content-Transfer-Encoding: quoted-printable

All,

 

During = Thursday’s meeting, Marcelo made it pretty clear that he felt no = progress was being made on the concepts and use cases document. I am the = main editor of the document and have had the pen for most of the past 4 = months. This means that the problems with the document must be a failure = on my part.

 

I am keen that ConEx should progress smoothly through = the IETF and that requires the working group chairs to be confident in = the editor. I also know that I haven’t been able to contribute as = much time and energy as I might have hoped. With that in mind I am = resigning as editor of the document. Hopefully Marcelo and Nandita will = be able to find a replacement they have more confidence in and who is = able to make better progress with this surprisingly difficult = document.

         &= nbsp;           &n= bsp;           &nb= sp;           &nbs= p;            = ;            =             &= nbsp;           &n= bsp;           &nb= sp;           &nbs= p;            = ;            =             &= nbsp;           &n= bsp;          =

I would still like to contribute as = an author and WG member and I wish any successor as editor good luck in = what is a largely thankless task,

 

Yours,

 

Toby = Moncaster

------=_NextPart_000_0026_01CBF2EF.C983BA70-- From carlberg@g11.org.uk Tue Apr 5 02:03:40 2011 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 B30183A68EF for ; Tue, 5 Apr 2011 02:03:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.47 X-Spam-Level: X-Spam-Status: No, score=-2.47 tagged_above=-999 required=5 tests=[AWL=0.128, BAYES_00=-2.599, 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 doEVGF1WmRSf for ; Tue, 5 Apr 2011 02:03:33 -0700 (PDT) Received: from portland.eukhosting.net (portland.eukhosting.net [92.48.97.5]) by core3.amsl.com (Postfix) with ESMTP id 9C3323A68E9 for ; Tue, 5 Apr 2011 02:03:32 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=default; d=g11.org.uk; h=Received:Subject:Mime-Version:Content-Type:From:In-Reply-To:Date:Cc:Message-Id:References:To:X-Mailer:X-Source:X-Source-Args:X-Source-Dir; b=sIeCH5LSIV/DzxAU6YCzPisd0g3cj/t8OghhtaDgXoBag+zQcADxb+6E8gKea17R/zZ6gb6LAJCwgkDUzcMIGlPnIhk0gPklrIt58t4X/OYlGmSLMBWtltS8dT+Zj8zA; Received: from c-76-111-69-4.hsd1.va.comcast.net ([76.111.69.4]:64956 helo=[192.168.0.20]) by portland.eukhosting.net with esmtpa (Exim 4.69) (envelope-from ) id 1Q72CB-0003kC-Pb; Tue, 05 Apr 2011 09:05:08 +0000 Mime-Version: 1.0 (Apple Message framework v1082) Content-Type: multipart/alternative; boundary=Apple-Mail-28--582919417 From: ken carlberg In-Reply-To: <002501cbf2e7$67bf5270$373df750$@com> Date: Tue, 5 Apr 2011 05:05:11 -0400 Message-Id: <232AFD59-B6E6-4338-8AB0-0175AE72B712@g11.org.uk> References: <002501cbf2e7$67bf5270$373df750$@com> To: Toby Moncaster X-Mailer: Apple Mail (2.1082) 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] giving up as editor of use draft-ietf-conex-concepts-uses 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, 05 Apr 2011 09:03:40 -0000 --Apple-Mail-28--582919417 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=windows-1252 Toby, Confidence in this arena is a two way street -- the confidence in the = editors as well as the confidence in the chairs. Waiting until the end = of a meeting to express significant concerns about a draft certainly = grabs the attention of the authors and the rest of the working group. = However, the lack of a detailed explanation of these concerns (ie, what = is exactly broken, and why) is equally frustrating to come across. = Given such a general sweeping statement, time should have been allotted = by the chairs to provide more specific insight of these concerns to the = group. If a new lead editor is chosen, I would hope we would see a more = detailed discussion of the perceived problems on this list, and = relatively soon. -ken =20 On Apr 4, 2011, at 12:43 PM, Toby Moncaster wrote: > All, > =20 > During Thursday=92s meeting, Marcelo made it pretty clear that he felt = no progress was being made on the concepts and use cases document. I am = the main editor of the document and have had the pen for most of the = past 4 months. This means that the problems with the document must be a = failure on my part. > =20 > I am keen that ConEx should progress smoothly through the IETF and = that requires the working group chairs to be confident in the editor. I = also know that I haven=92t been able to contribute as much time and = energy as I might have hoped. With that in mind I am resigning as editor = of the document. Hopefully Marcelo and Nandita will be able to find a = replacement they have more confidence in and who is able to make better = progress with this surprisingly difficult document. > = = =20 > I would still like to contribute as an author and WG member and I wish = any successor as editor good luck in what is a largely thankless task, > =20 > Yours, > =20 > Toby Moncaster > _______________________________________________ > conex mailing list > conex@ietf.org > https://www.ietf.org/mailman/listinfo/conex --Apple-Mail-28--582919417 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=windows-1252 Toby,

Confidence in this arena = is a two way street -- the confidence in the editors as well as the = confidence in the chairs.  Waiting until the end of a meeting to = express significant concerns about a draft certainly grabs the attention = of the authors and the rest of the working group.  However, the = lack of a detailed explanation of these concerns (ie, what is exactly = broken, and why) is equally frustrating to come across.  Given such = a general sweeping statement, time should have been allotted by the = chairs to provide more specific insight of these concerns to the = group.

If a new lead editor is chosen, I would = hope we would see a more detailed discussion of the perceived problems = on this list, and relatively = soon.

-ken
 

<= div>
On Apr 4, 2011, at 12:43 PM, Toby Moncaster = wrote:

All,
During Thursday=92s meeting, Marcelo = made it pretty clear that he felt no progress was being made on the = concepts and use cases document. I am the main editor of the document = and have had the pen for most of the past 4 months. This means that the = problems with the document must be a failure on my = part.
 
I am keen that = ConEx should progress smoothly through the IETF and that requires the = working group chairs to be confident in the editor. I also know that I = haven=92t been able to contribute as much time and energy as I might = have hoped. With that in mind I am resigning as editor of the document. = Hopefully Marcelo and Nandita will be able to find a replacement they = have more confidence in and who is able to make better progress with = this surprisingly difficult document.
I would still like = to contribute as an author and WG member and I wish any successor as = editor good luck in what is a largely thankless = task,
 
 
To: References: <002501cbf2e7$67bf5270$373df750$@com> <232AFD59-B6E6-4338-8AB0-0175AE72B712@g11.org.uk> Date: Tue, 5 Apr 2011 12:37:36 +0200 Message-ID: <743716A955734296A132B8CCC29DE920@dynamic.ewi.utwente.nl> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_002C_01CBF38E.410FA100" X-Mailer: Microsoft Office Outlook 11 In-Reply-To: <232AFD59-B6E6-4338-8AB0-0175AE72B712@g11.org.uk> Thread-Index: AcvzcKT7zkxKr5STS5a8vaolbMiGdAADHiug X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.5994 X-Scanned-By: MIMEDefang 2.52 on 130.89.10.11 X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-3.0rc3 (denhaag.ewi.utwente.nl [130.89.10.11]); Tue, 05 Apr 2011 12:37:27 +0200 (MEST) Subject: [conex] new draft submiited: draft-karagiannis-conex-congestion-calculation-00.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: Tue, 05 Apr 2011 10:36:13 -0000 This is a multi-part message in MIME format. ------=_NextPart_000_002C_01CBF38E.410FA100 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Hi all I have just submitted the following Conex related draft entitled "Calculating Exposed Congestion by using TCP Throughput Changes", see below: http://www.ietf.org/id/draft-karagiannis-conex-congestion-calculation-00.txt This document describes a possible implementation complexity problem associated with the current Conex concept defined by the ConEx WG and it proposes a solution to this. This problem occurs due to the fact that it is complex to measure the congestion rate at the sender side. The solution proposed in draft-briscoe-tsvwg-re-ecn-tcp-09 to calculate the exposed congestion rate at the sender seems to be quite complex to be implemented, since protocol changes need to be accomplished in order to modify the semantics of the TCP header, i.e., the semantics of the flags: NS, CWR and ECE. This document provides a solution to this problem as follows. When the sender needs to reduce its sending rate, then the sender can calculate the exposed congestion rate by subtracting the TCP throughput calculated during a a Round Trip Time (RTT), i.e., (RTTi) from the TCP throughput calculated at the same sender side during the previous RTT, i.e., (RTTi-1), where i is an integer equal or higher than 1. The TCP throughput at the sender side can be calculated using, e.g., the TCP throughput equation specified in [RFC5348]. Comments are welcome! Best regards, Georgios ------=_NextPart_000_002C_01CBF38E.410FA100 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable
Hi=20 all
 
I have just=20 submitted the following Conex related draft entitled
"Calculating=20 Exposed Congestion by using TCP Throughput Changes", see = below:
 
http://www.ietf.org/id/draft-karagiannis-conex-congestion-ca= lculation-00.txt
 

This document=20 describes a possible implementation complexity problem
associated = with the=20 current Conex concept defined by the ConEx WG
and it proposes a = solution to=20 this. This problem occurs due
to the fact that it is complex to = measure the=20 congestion rate
at the sender side.
 
The solution=20 proposed in  draft-briscoe-tsvwg-re-ecn-tcp-09 to calculate
the = exposed=20 congestion rate at the sender seems to be quite complex
to be = implemented,=20 since protocol changes need to be accomplished in
order to modify = the=20 semantics of the TCP header, i.e., the semantics of the flags:
NS, = CWR and=20 ECE.
 
This document=20 provides a solution to this problem as follows.
When the sender needs = to=20 reduce its sending rate, then the sender can
calculate the exposed=20 congestion rate by subtracting the TCP
throughput calculated during = a a=20 Round Trip Time (RTT), i.e., (RTTi)
from the TCP throughput = calculated at=20 the same sender side during the
previous RTT, i.e., (RTTi-1), where = i is an=20 integer equal or higher
than 1.
The TCP throughput=20 at the sender side can be calculated using, e.g.,
the TCP throughput=20 equation specified in [RFC5348].
 
Comments are=20 welcome!
 
Best=20 regards,
Georgios
------=_NextPart_000_002C_01CBF38E.410FA100-- From john@jlc.net Tue Apr 5 04:34:38 2011 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 839CE28C103 for ; Tue, 5 Apr 2011 04:34:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.501 X-Spam-Level: X-Spam-Status: No, score=-106.501 tagged_above=-999 required=5 tests=[AWL=0.098, 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 QaWPTpCZ6J1o for ; Tue, 5 Apr 2011 04:34:31 -0700 (PDT) Received: from mailhost.jlc.net (mailhost.jlc.net [199.201.159.4]) by core3.amsl.com (Postfix) with ESMTP id 8DF643A692E for ; Tue, 5 Apr 2011 04:34:27 -0700 (PDT) Received: by mailhost.jlc.net (Postfix, from userid 104) id 478A133C22; Tue, 5 Apr 2011 07:36:10 -0400 (EDT) Date: Tue, 5 Apr 2011 07:36:10 -0400 From: John Leslie To: Georgios Karagiannis Message-ID: <20110405113610.GA10281@verdi> References: Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable In-Reply-To: User-Agent: Mutt/1.4.1i Cc: "conex@ietf.org" Subject: Re: [conex] new internet draft on exposing conex throughput 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, 05 Apr 2011 11:34:38 -0000 Georgios Karagiannis wrote: >=20 > I have just submitted the Internet draft entitled: =7F"Exposing Conex > Throughput", see > http://www.ietf.org/id/draft-karagiannis-conex-throughput-exposure-00.txt. Thanks for the work that went into this. > This document describes a possible implementation complexity problem > associated with the current Conex concept defined by the ConEx WG and it > proposes a solution to this. This problem occurs due to the fact that it > is complex to measure the congestion rate, at each intermediate Conex > enabled device. A conex enabled device can be for example, a policer or > an audit device. Moreover, this document provides a solution to this > problem, by measuring and monitoring the per flow throughput on each > intermediate Conex enabled device instead of measuring and monitoring > the per flow congestion rate on each intermediate Conex enabled device. It's clear that you and I don't share the same view of what the abstract-mechanism draft calls for. You are seeing flow-state being required at many ConEx nodes along the path; I am seeing flow-state being optional at one ConEx node near the receiver. Perhaps both of us are wrong... It would probably be good to clarify the wording in abstract-mechanism to prevent such misunderstandings. > The mentioned problem is related to the fact that in the context of > Conex it is complex to measure the congestion rate, see [RFC5348] at > each intermediate Conex enabled device. In particular, the main solution > proposed in [draft-ietf-conex-abstract-mech-01] on measuring > the congestion rate on an audit device is: "The auditor could monitor > TCP flows or aggregates of flows, only holding state on a flow if it > first sends a Credit or a Re-Echo-Loss marking. The auditor could > detect retransmissions by monitoring sequence numbers. It would > assure that (volume of retransmitted data) <=3D (volume of data marked > Re-Echo-Loss). Traffic would only be auditable in this way if it > conformed to the standard TCP protocol and the IP payload was not > encrypted (e.g. with IPsec). ", from > [draft-ietf-conex-abstract-mech-01]. I have no enthusiasm for keeping this much flow state. I understood the flow-state noted in abstract-mechanism to be intended to monitor packet loss near the receiver for a partial-deployment scenario where it is likely that there will be a congested node which doesn't ECN-mark (but instead drops the packet) _before_ the auditing device. (I am not convinced this is worth the effort.) > In other words, an audit device needs to keep per flow (individual or > aggregated) state after it receives a credit or Re-echo-Loss marking > in order to measure the per flow congestion rate. In addition to this > the audit device must be able to read the TCP header in order to > observe the TCP header numbers. This is complex to be implemented and > it is not always possible, e.g., when the IP payload is > encrypted (e.g. with IPsec). In this way the audit device is also > able to take into consideration also the number of ECN CE marked > packets that were dropped by nodes located upstream. This is true. It's _part_ of why I'm unenthusiastic. > Note that in my opinion the same method of measuring the congestion > rate at a policer is required as the one applied at the audit device. I wouldn't agree. My understanding of the policer function in abstract-mechanism is that it's there to restrain the amount of congestion-expected marking that enters the backbone. > This document provides a solution to this problem, by > measuring and monitoring the per flow throughput on each intermediate > Conex enabled device instead of measuring and monitoring the per flow > congestion rate on each intermediate Conex enabled device. >=20 > Comments are welcome! Honestly, I don't think it would help; and it looks to be _really_ hard to reach sufficient deployment. -- John Leslie From karagian@cs.utwente.nl Tue Apr 5 04:52:17 2011 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 4D5E03A6403 for ; Tue, 5 Apr 2011 04:52:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.204 X-Spam-Level: X-Spam-Status: No, score=-0.204 tagged_above=-999 required=5 tests=[AWL=0.300, BAYES_00=-2.599, HELO_EQ_NL=0.55, HOST_EQ_NL=1.545] 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 caZiRJv7cnit for ; Tue, 5 Apr 2011 04:52:10 -0700 (PDT) Received: from denhaag.ewi.utwente.nl (denhaag.ewi.utwente.nl [130.89.10.11]) by core3.amsl.com (Postfix) with ESMTP id E9BCA3A67B3 for ; Tue, 5 Apr 2011 04:52:09 -0700 (PDT) Received: from ewi977 (ewi977.ewi.utwente.nl [130.89.12.129]) by denhaag.ewi.utwente.nl (8.13.6/8.13.6) with ESMTP id p35BrEcW018698; Tue, 5 Apr 2011 13:53:17 +0200 (MEST) From: "Georgios Karagiannis" To: "'John Leslie'" References: <20110405113610.GA10281@verdi> Date: Tue, 5 Apr 2011 13:53:35 +0200 Message-ID: <8F8BDA94420247398DA717AAF31DFA46@dynamic.ewi.utwente.nl> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable X-Mailer: Microsoft Office Outlook 11 In-Reply-To: Thread-Index: AcvzhavgL+nZn8DnSd6A8Jxu6uOYrgAAF5UgAABhIWA= X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.5994 X-Scanned-By: MIMEDefang 2.52 on 130.89.10.11 X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-3.0rc3 (denhaag.ewi.utwente.nl [130.89.10.11]); Tue, 05 Apr 2011 13:53:26 +0200 (MEST) Cc: conex@ietf.org Subject: Re: [conex] new internet draft on exposing conex throughput 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, 05 Apr 2011 11:52:17 -0000 Hi John Thanks for the comments! Please see in line! =20 > -----Original Message----- > From: John Leslie [mailto:john@jlc.net] > Sent: dinsdag 5 april 2011 13:36 > To: Georgios Karagiannis > Cc: conex@ietf.org > Subject: Re: [conex] new internet draft on exposing conex throughput >=20 > Georgios Karagiannis wrote: > >=20 > > I have just submitted the Internet draft entitled: =7F"Exposing = Conex=20 > > Throughput", see > >=20 > http://www.ietf.org/id/draft-karagiannis-conex-throughput-expo sure-00.txt. >=20 > Thanks for the work that went into this. >=20 > > This document describes a possible implementation > complexity problem > > associated with the current Conex concept defined by the > ConEx WG and > > it proposes a solution to this. This problem occurs due to the fact=20 > > that it is complex to measure the congestion rate, at each=20 > > intermediate Conex enabled device. A conex enabled device > can be for > > example, a policer or an audit device. Moreover, this document=20 > > provides a solution to this problem, by measuring and > monitoring the > > per flow throughput on each intermediate Conex enabled > device instead > > of measuring and monitoring the per flow congestion rate on > each intermediate Conex enabled device. >=20 > It's clear that you and I don't share the same view of what the=20 > abstract-mechanism draft calls for. >=20 > You are seeing flow-state being required at many ConEx nodes along=20 > the path; I am seeing flow-state being optional at one ConEx node near = > the receiver. Georgios: In my opinion without having flow state, and assuming that the = ECN CE marked packets=20 might be be dropped on a communication path, then the current Conex = concept=20 might not work properly. >=20 > Perhaps both of us are wrong... It would probably be good=20 > to clarify the wording in abstract-mechanism to prevent such=20 > misunderstandings. >=20 > > The mentioned problem is related to the fact that in the context of=20 > > Conex it is complex to measure the congestion rate, see=20 > [RFC5348] at=20 > > each intermediate Conex enabled device. In particular, the main=20 > > solution proposed in [draft-ietf-conex-abstract-mech-01] on=20 > measuring=20 > > the congestion rate on an audit device is: "The auditor=20 > could monitor=20 > > TCP flows or aggregates of flows, only holding state on a=20 > flow if it=20 > > first sends a Credit or a Re-Echo-Loss marking. The auditor could=20 > > detect retransmissions by monitoring sequence numbers. It would=20 > > assure that (volume of retransmitted data) <=3D (volume of=20 > data marked=20 > > Re-Echo-Loss). Traffic would only be auditable in this way if it=20 > > conformed to the standard TCP protocol and the IP payload was not=20 > > encrypted (e.g. with IPsec). ", from=20 > > [draft-ietf-conex-abstract-mech-01]. >=20 > I have no enthusiasm for keeping this much flow state. I=20 > understood the flow-state noted in abstract-mechanism to be=20 > intended to monitor packet loss near the receiver for a=20 > partial-deployment scenario where it is likely that there=20 > will be a congested node which doesn't ECN-mark (but instead=20 > drops the packet) _before_ the auditing device. >=20 > (I am not convinced this is worth the effort.) Georgios: In my opinion without having flow state, and assuming that the = ECN CE marked packets=20 might be be dropped on a communication path, then the current Conex = concept=20 might not work properly. >=20 > > In other words, an audit device needs to keep per flow=20 > (individual or > > aggregated) state after it receives a credit or=20 > Re-echo-Loss marking=20 > > in order to measure the per flow congestion rate. In=20 > addition to this=20 > > the audit device must be able to read the TCP header in order to=20 > > observe the TCP header numbers. This is complex to be=20 > implemented and=20 > > it is not always possible, e.g., when the IP payload is encrypted=20 > > (e.g. with IPsec). In this way the audit device is also=20 > able to take=20 > > into consideration also the number of ECN CE marked packets=20 > that were=20 > > dropped by nodes located upstream. >=20 > This is true. It's _part_ of why I'm unenthusiastic. >=20 > > Note that in my opinion the same method of measuring the congestion=20 > > rate at a policer is required as the one applied at the=20 > audit device. >=20 > I wouldn't agree. My understanding of the policer function=20 > in abstract-mechanism is that it's there to restrain the=20 > amount of congestion-expected marking that enters the backbone. Georgios: Yes, but this policer, in addition to the policing policy that = it needs to have, it should be aware of the signaled exposed congestion and = of the=20 measured congestion on the path! If the congestion on the path cannot be measured accurately, then the policer will probably take wrong decisions on e.g., it can police traffic that should not be policed.=20 This will have signifficant implications when an accounting application = is used on top of the policer.=20 Best regards, Georgios >=20 > > This document provides a solution to this problem, by measuring and=20 > > monitoring the per flow throughput on each intermediate=20 > Conex enabled=20 > > device instead of measuring and monitoring the per flow congestion=20 > > rate on each intermediate Conex enabled device. > >=20 > > Comments are welcome! >=20 > Honestly, I don't think it would help; and it looks to be=20 > _really_ hard to reach sufficient deployment. >=20 > -- > John Leslie >=20 =20 From toby@moncaster.com Tue Apr 5 08:19:02 2011 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 DCAA928C0DE for ; Tue, 5 Apr 2011 08:19:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.2 X-Spam-Level: X-Spam-Status: No, score=-2.2 tagged_above=-999 required=5 tests=[AWL=0.048, 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 Zmqq5vIHTfAo for ; Tue, 5 Apr 2011 08:18:56 -0700 (PDT) Received: from moutng.kundenserver.de (moutng.kundenserver.de [212.227.17.9]) by core3.amsl.com (Postfix) with ESMTP id 533063A693F for ; Tue, 5 Apr 2011 08:18:56 -0700 (PDT) Received: from TobysHP (host86-149-183-12.range86-149.btcentralplus.com [86.149.183.12]) by mrelayeu.kundenserver.de (node=mreu1) with ESMTP (Nemesis) id 0LuYWS-1PyVAj2E2y-00znKn; Tue, 05 Apr 2011 17:20:38 +0200 From: "Toby Moncaster" To: Date: Tue, 5 Apr 2011 16:20:34 +0100 Message-ID: <004001cbf3a5$02b6a9f0$0823fdd0$@com> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0041_01CBF3AD.647B3900" X-Mailer: Microsoft Office Outlook 12.0 Thread-Index: AcvzpQJF0+TsC/rJSGW3sBHbODrp7g== Content-Language: en-gb X-Provags-ID: V02:K0:D/hrFBsy9SEwraFONown5mlMuyod+zYk/hW3Q69gZGu SqmARNhmHA9ZQRMHKPM/Cg1MOLVbfUsPZ2V5OsYd7m9sUPrbum l8dwsn4lhJ8EzUSOveS78bwhngyOk3psJHcxSNwZOP3ejmIt/S qbl1iUoPTzJEW6bNWZu/sI+97ugsHtGW6QYEvDX5oIyoR9ADaT VVb166uTQaVjr3ayfQ4mieZxW/gxW9vJUBMTMHqSPA= Subject: [conex] my personal views on draft-ietf-conex-concepts-uses 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, 05 Apr 2011 15:19:03 -0000 This is a multi-part message in MIME format. ------=_NextPart_000_0041_01CBF3AD.647B3900 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Hi All, As I am no longer editor of draft-ietf-conex-concepts-uses I can express my views on the document as an individual (rather than as the representative of the of the co-authors). Having had a thorough re-think about how best to progress ConEx through the IETF, I have come to the conclusion that the current draft is failing because it tries to do too much for a single document. In its current form, the document is doing two things. It seeks to explain the rationale of ConEx and it tries to give a list of use cases where ConEx seems to add most value. I now think these two parts can't exist in a single document since the latter tends to distract attention from the former. Marcelo ad Nandita have lofty ambitions for this document, which should serve as the ambassador for ConEx. This should be the document that silences our critics, or at least shows them that their fears about ConEx are unfounded. It should also act to enthuse the developer, vendor and operator communities to start working on ConEx and thus start the ball rolling for eventual deployment. So my proposal to the new editing team is as follows. . Re-write the introduction of the draft to provide a clear motivation for ConEx . Write a section explaining what Conex is and (importantly) what it isn't. This needs to contrast it to alternative approaches (such as over-provisioning) and show how those alternative approaches are flawed. . Then have a short section using a single network deployment as an example of how ConEx can operate (for instance, using ConEx as a mechanism to control the usage of a resource-constrained shared network such as those that are provided for students on university campuses). This should be explained in terms of familiar concepts (the approach taken in [policing freedom], where the policer is described in terms of a token bucket). . Then give a detailed use case for the "charter scenario" of partial deployment with only sender and sender's network ConEx-enabled. This needs to show how (for instance) the sender's network can use ConEx to ensure that user's are not contributing to local congestion and are thus not causing other users to suffer a degradation in service. . Finally have a complete section on partial deployment models (the third bullet on Bob's list). This would look at the different arrangements of networks (sender, core, receiver), what each network needs to do about conex and what advantages it gets through being conex aware. Such a document would best be called "ConEx Concepts and Motivations". By limiting the use cases described in the document it allows people to focus on what ConEx is actually doing and how it works. Until they understand that, there is no point trying to convince them of the huge range of uses to which it can be put. Then we can create a separate document bringing together all the other use cases and incorporating some of the individual work that has been contributed to ConEx. That document can be published a bit later than the other one and it can then assume that people are able to understand ConEx properly. ------=_NextPart_000_0041_01CBF3AD.647B3900 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hi = All,

 

As I am no longer editor of = draft-ietf-conex-concepts-uses I can express my views on the document as = an individual (rather than as the representative of the of the = co-authors).

 

Having had a thorough re-think about how best to = progress ConEx through the IETF, I have come to the conclusion that the = current draft is failing because it tries to do too much for a single = document. In its current form, the document is doing two things. It = seeks to explain the rationale of ConEx and it tries to give a list of = use cases where ConEx seems to add most value. I now think these two = parts can’t exist in a single document since the latter tends to = distract attention from the former.

 

Marcelo ad = Nandita have lofty ambitions for this document, which should serve as = the ambassador for ConEx. This should be the document that silences our = critics, or at least shows them that their fears about ConEx are = unfounded. It should also act to enthuse the developer, vendor and = operator communities to start working on ConEx and thus start the ball = rolling for eventual deployment.

 

So my = proposal to the new editing team is as follows.

·         = Re-write  the introduction of the = draft to provide a clear motivation for ConEx

·         = Write a section explaining what Conex is = and (importantly) what it isn’t. This needs to contrast it to = alternative approaches (such as over-provisioning) and show how those = alternative approaches are flawed.

·         = Then have a short section using a single = network deployment as an example of how ConEx can operate (for instance, = using ConEx as a mechanism to control the usage of a = resource-constrained shared network such as those that are provided for = students on university campuses). This should be explained in terms of = familiar concepts (the approach taken in [policing freedom], where the = policer is described in terms of a token bucket).

·         = Then give a detailed use case for the = “charter scenario” of partial deployment with only sender = and sender’s network ConEx-enabled. This needs to show how (for = instance) the sender’s network can use ConEx to ensure that = user’s are not contributing to local congestion and are thus not = causing other users to suffer a degradation in service.

·         =  Finally have a complete section on = partial deployment models (the third bullet on Bob’s list). This = would look at the different arrangements of networks (sender, core, = receiver), what each network needs to do about conex and what advantages = it gets through being conex aware.

 

Such a = document would best be called “ConEx Concepts and = Motivations”. By limiting the use cases described in the document = it allows people to focus on what ConEx is actually doing and how it = works. Until they understand that, there is no point trying to convince = them of the huge range of uses to which it can be put.

 

Then we can = create a separate document bringing together all the other use cases and = incorporating some of the individual work that has been contributed to = ConEx. That document can be published a bit later than the other one and = it can then assume that people are able to understand ConEx = properly.

------=_NextPart_000_0041_01CBF3AD.647B3900-- From mirja.kuehlewind@ikr.uni-stuttgart.de Tue Apr 5 15:38:09 2011 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 6628428C151 for ; Tue, 5 Apr 2011 15:38:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.074 X-Spam-Level: X-Spam-Status: No, score=-2.074 tagged_above=-999 required=5 tests=[AWL=0.175, 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 vRquDh3SJQQY for ; Tue, 5 Apr 2011 15:38:07 -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 6544328C147 for ; Tue, 5 Apr 2011 15:38:07 -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 4A22E633B2; Wed, 6 Apr 2011 00:39:49 +0200 (CEST) Received: from vpn-2-cl177 (vpn-2-cl177 [10.41.21.177]) by netsrv1.ikr.uni-stuttgart.de (Postfix) with ESMTP id 1AE0359A8A; Wed, 6 Apr 2011 00:39:49 +0200 (CEST) From: Mirja Kuehlewind Organization: University of Stuttgart (Germany), IKR To: conex@ietf.org Date: Wed, 6 Apr 2011 00:39:48 +0200 User-Agent: KMail/1.9.10 (enterprise35 0.20101217.1207316) References: In-Reply-To: X-KMail-QuotePrefix: > MIME-Version: 1.0 Content-Type: Text/Plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Content-Disposition: inline Message-Id: <201104060039.48305.mirja.kuehlewind@ikr.uni-stuttgart.de> Subject: Re: [conex] comments/suggestions on draft-ietf-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, 05 Apr 2011 22:38:09 -0000 Hi Dave, thx, I really like your text proposal. I guess the term 'self congestion'=20 needs to be defined as well...? But otherwise this text make the use case=20 very clear to me! Mirja On Monday 04 April 2011 14:07:13 Mcdysan, David E wrote: > As I mentioned in the status presentation last Thursday, I planned to send > a paragraph to the conex wg list with proposed text for an additional > paragraph to be placed at the end of section 5.1. > > I am responding to point 1 Alissas' Email on this subject, since I think > her note summarizes wg consensus on this topic well. (Also note that this > closely aligns with the text cited from the reference [Bauer09]). > > The remainder of section 6 relating to this topic would be removed, with > discussion required to determine whether the wg sees value in keeping > section 6.2 (possibly in an Appendix), or removing that as well. The > formulation of this approach by Toby helped me better understand conex, > but if that is not wg consensus, then so be it. > > "Traffic measurements over time scales longer than that of > policers/shapers involving conex information can be used to adjust the > token bucket parameters of these policers and adjust parameters of > shapers. These longer time scale conex related measurements can also > provide other uses [Bauer09, pg.18-19], such as; achieve better > understanding user traffic requirements, provide a better basis for > planning investments, enable better service customization, or achieve > better matching of costs and usage. When measurement is done in a network > element that implements a shaper, the amount which self congestion > contributes to overall congestion may be estimated for similar uses. These > traffic management techniques employing conex information may help address > the challenging problem where a small percentage of users (e.g., 20%) > generate a large portion of the traffic (e.g., 80%) [Varian09]. " > > > Also, based upon some misunderstanding of terminology that was apparent on > the list, I propose that the RFC 2475 definition of "shaper" be added to > section 3.1, existing approaches. > > Thanks, > > Dave > > On Friday3/25/11 4:37 AM, "Alissa Cooper" wrote: > >In my reading of section 6, it presents 2 distinct issues: > > > >1) Long time scales: A use case (or perhaps a few variations on the > >same use case) for the conex signal as currently described in abstract- > >mech, wherein conex helps network operators to manage congestion, > >conduct traffic shaping, and capacity-plan over periods much longer > >than network speeds (e.g., minutes/hours/days/months) > > > >2) Shaper presence: A suggestion that conex could signal the presence > >of a traffic shaper (in addition to or instead of how the conex signal > >is currently described in abstract-mech) and a use case for such a > >signal wherein recipients of the signal can use it to request that > >sender's traffic shaper parameters be altered > > > >I think the issue of long time scales, which is described in the > >introductory text to section 6 and briefly in 6.1 and 6.2, could > >instead be succinctly addressed by adding a couple of sentences to 5.1 > >to explain that the use of conex for managing "heavy" users could > >occur over shorter or longer time scales and could have the added > >affect of helping operators to do longer-term capacity planning. > > > >Signaling the presence of a shaper seems to me to be a separate animal > >altogether, and one over which there is some obvious disagreement. But > >at least half of section 6 seems to be devoted to the idea that > >operators would have uses for aggregating conex information over long > >time frames, and I think those uses could be incorporated with a brief > >addition to section 5.1. > > > >Alissa > > > >On Mar 17, 2011, at 12:25 PM, Mcdysan, David E wrote: > >> Hi Nandita, > >> > >> A few responses to your questions on the new section in line below > >> prefixed by DM which were previously posted to the list that I > >> believe (at least partially) address your comments. > >> > >> I propose that the working group work toward how to organize/merge/ > >> move the new text better into the existing outline. > >> > >> Thanks, > >> > >> Dave > >> > >> From: Nandita Dukkipati > >> Date: Thu, 17 Mar 2011 03:28:25 -0400 > >> To: Toby Moncaster , John Leslie , > >> Bob Briscoe , "Woundy, Richard" > >> >> > >> >, David McDysan > >> > >> Cc: "conex@ietf.org" > >> Subject: comments/suggestions on draft-ietf-conex-concepts-uses-01 > >> > >> On reading the latest draft, I have three high level comments > >> roughly in the following order of importance- > >> > >> *** > >> Statistical Multiplexing over different timescales. > >> This reads like a rambling story. I have read and re-read it, and I > >> am still left wondering - > >> * What is _the_ main point? How about starting the section by > >> stating your main point upfront as opposed leaving it to the reader > >> to figure it out. > >> > >> DM - From my 3/10/11 on the list > >> > >> 1) A few "heavy" users generate most of the traffic and service > >> providers > >> want to better assign the cost (of provisioning an upgrade) for the > >> time > >> when congestion is anticipated to occur. Existing mechanisms, flat > >> rate, > >> bandwidth tier shapers, and usage tiers do not completely address the > >> service provider objective and/or are not popular with users. > >> > >> 2) In some service provider networks shapers are implemented to > >> limit the > >> maximum bandwidth per user. Although overflow or marking in the shaper > >> queue appears as congestion to the receiver, this "self-congestion" > >> differs from congestion of a shared resource since a remedy could be > >> to > >> indicate to the user that changing the shaper rate (i.e., "go faster") > >> would alleviate "self-congestion." > >> > >> * Why and how is this use case distinct from that of traffic > >> management which already seems to have a broad scope? Is it really > >> distinct? > >> > >> DM - From my 3/11/11 post to the list > >> > >> Editorially, this (section 5.1) could be a place to state the > >> problem with an additional > >> reference to [Varian]. > >> > >> Editorially, bandwidth tier pricing could be added to section 3.1, > >> Existing approaches. > >> > >> I am now thinking that editorially a separate section is not a good > >> idea, > >> since the points can be merged into the existing outline, in at > >> least the > >> places mentioned above. > >> > >> I think adding that the use case needs to meet service provider > >> economic > >> congestion needs as well as be acceptable to users is an important > >> point > >> not in the current text. Traffic management (aka policing) may have > >> the > >> problem that it may not be popular with user. There has already been > >> negative feedback on the list regarding policing (IMO, Traffic > >> management > >> is a better term). > >> > >> > >> * [minor] Why not make this use case a part of Sec. 5? > >> > >> DM =AD the minutes recorded adding the agreement to add this as a new > >> section. (A new subsection, and or merging thoughts with other use > >> cases (e.g., as suggested above) is what I believe the wg needs to > >> discuss. > >> > >> *** > >> Partial versus full deployment. > >> Clearly, it belongs to this draft. But why is it a part of use > >> cases? Looks out of place to me. > >> > >> *** > >> Sec 4. Exposing congestion. > >> =B3We argue that congestion needs.... More specifically, a network > >> needs to be able to measure how much congestion any particular > >> traffic expects to cause between the monitoring point in the network > >> and the destination ("rest-of-path congestion"). This would be a new > >> capability.=B2 > >> > >> Could you add more clarity and explanation on why local congestion > >> information at any given node is not sufficient. Why does a node > >> require congestion information from a monitoring point to the > >> destination to be able to manage its own congestion? A succinct > >> explanation and/or an example will go a long way. > >> > >> _______________________________________________ > >> conex mailing list > >> conex@ietf.org > >> https://www.ietf.org/mailman/listinfo/conex > > _______________________________________________ > conex mailing list > conex@ietf.org > https://www.ietf.org/mailman/listinfo/conex =2D-=20 =2D------------------------------------------------------------------ Dipl.-Ing. Mirja K=FChlewind Institute of Communication Networks and Computer Engineering (IKR) University of Stuttgart, Germany Pfaffenwaldring 47, D-70569 Stuttgart tel: +49(0)711/685-67973 email: mirja.kuehlewind@ikr.uni-stuttgart.de web: www.ikr.uni-stuttgart.de =2D------------------------------------------------------------------ From mirja.kuehlewind@ikr.uni-stuttgart.de Tue Apr 5 15:52:13 2011 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 76E443A6811 for ; Tue, 5 Apr 2011 15:52:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.082 X-Spam-Level: X-Spam-Status: No, score=-2.082 tagged_above=-999 required=5 tests=[AWL=0.167, 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 QWU5rFz3TWn4 for ; Tue, 5 Apr 2011 15:52:12 -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 4608D3A6810 for ; Tue, 5 Apr 2011 15:52:12 -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 44CFC633B2; Wed, 6 Apr 2011 00:53:55 +0200 (CEST) Received: from vpn-2-cl177 (vpn-2-cl177 [10.41.21.177]) by netsrv1.ikr.uni-stuttgart.de (Postfix) with ESMTP id 1BEAA59A8A; Wed, 6 Apr 2011 00:53:55 +0200 (CEST) From: Mirja Kuehlewind Organization: University of Stuttgart (Germany), IKR To: conex@ietf.org Date: Wed, 6 Apr 2011 00:53:54 +0200 User-Agent: KMail/1.9.10 (enterprise35 0.20101217.1207316) References: <004001cbf3a5$02b6a9f0$0823fdd0$@com> In-Reply-To: <004001cbf3a5$02b6a9f0$0823fdd0$@com> X-KMail-QuotePrefix: > MIME-Version: 1.0 Content-Type: Text/Plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Content-Disposition: inline Message-Id: <201104060053.54832.mirja.kuehlewind@ikr.uni-stuttgart.de> Subject: Re: [conex] my personal views on draft-ietf-conex-concepts-uses 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, 05 Apr 2011 22:52:13 -0000 Hi Toby, I believe thats a very good proposal! I was always looking at the use case = doc=20 as something that can be read by somebody who heard the first time of ConEx= =20 and wants to get an idea of what ConEx is good for. That means understandin= g=20 the/a benefit of ConEx without knowing all the details about the mechanism.= =20 The use case draft in the current state is probably more confusing than=20 anythingelse. Splitting up into two doc sounds for me as the right way=20 forward to reach both goals - explaining the benefit of ConEx to an ingenuo= us=20 reader and documenting possible use cases to be considered in deployment. Mirja P.S.: Thx for the effort you put into this draft and also previous versions! On Tuesday 05 April 2011 17:20:34 Toby Moncaster wrote: > Hi All, > > > > As I am no longer editor of draft-ietf-conex-concepts-uses I can express = my > views on the document as an individual (rather than as the representative > of the of the co-authors). > > > > Having had a thorough re-think about how best to progress ConEx through t= he > IETF, I have come to the conclusion that the current draft is failing > because it tries to do too much for a single document. In its current for= m, > the document is doing two things. It seeks to explain the rationale of > ConEx and it tries to give a list of use cases where ConEx seems to add > most value. I now think these two parts can't exist in a single document > since the latter tends to distract attention from the former. > > > > Marcelo ad Nandita have lofty ambitions for this document, which should > serve as the ambassador for ConEx. This should be the document that > silences our critics, or at least shows them that their fears about ConEx > are unfounded. It should also act to enthuse the developer, vendor and > operator communities to start working on ConEx and thus start the ball > rolling for eventual deployment. > > > > So my proposal to the new editing team is as follows. > > . Re-write the introduction of the draft to provide a clear > motivation for ConEx > > . Write a section explaining what Conex is and (importantly) what > it isn't. This needs to contrast it to alternative approaches (such as > over-provisioning) and show how those alternative approaches are flawed. > > . Then have a short section using a single network deployment as = an > example of how ConEx can operate (for instance, using ConEx as a mechanism > to control the usage of a resource-constrained shared network such as tho= se > that are provided for students on university campuses). This should be > explained in terms of familiar concepts (the approach taken in [policing > freedom], where the policer is described in terms of a token bucket). > > . Then give a detailed use case for the "charter scenario" of > partial deployment with only sender and sender's network ConEx-enabled. > This needs to show how (for instance) the sender's network can use ConEx = to > ensure that user's are not contributing to local congestion and are thus > not causing other users to suffer a degradation in service. > > . Finally have a complete section on partial deployment models > (the third bullet on Bob's list). This would look at the different > arrangements of networks (sender, core, receiver), what each network needs > to do about conex and what advantages it gets through being conex aware. > > > > Such a document would best be called "ConEx Concepts and Motivations". By > limiting the use cases described in the document it allows people to focus > on what ConEx is actually doing and how it works. Until they understand > that, there is no point trying to convince them of the huge range of uses > to which it can be put. > > > > Then we can create a separate document bringing together all the other use > cases and incorporating some of the individual work that has been > contributed to ConEx. That document can be published a bit later than the > other one and it can then assume that people are able to understand ConEx > properly. =2D-=20 =2D------------------------------------------------------------------ Dipl.-Ing. Mirja K=FChlewind Institute of Communication Networks and Computer Engineering (IKR) University of Stuttgart, Germany Pfaffenwaldring 47, D-70569 Stuttgart tel: +49(0)711/685-67973 email: mirja.kuehlewind@ikr.uni-stuttgart.de web: www.ikr.uni-stuttgart.de =2D------------------------------------------------------------------ From dave.mcdysan@verizon.com Wed Apr 6 06:54:56 2011 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 AA4983A69C7 for ; Wed, 6 Apr 2011 06:54:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.523 X-Spam-Level: X-Spam-Status: No, score=-3.523 tagged_above=-999 required=5 tests=[AWL=0.076, 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 IOo7ytjTrN44 for ; Wed, 6 Apr 2011 06:54:55 -0700 (PDT) Received: from sacmail4.verizon.com (sacmail4.verizon.com [192.76.84.42]) by core3.amsl.com (Postfix) with ESMTP id 6606C3A69C5 for ; Wed, 6 Apr 2011 06:54:54 -0700 (PDT) Received: from fldsmtpi01.verizon.com (fldsmtpi01.verizon.com [166.68.71.143]) by sacmail4.verizon.com (8.13.7+Sun/8.13.3) with ESMTP id p36DuXSD019092 for ; Wed, 6 Apr 2011 09:56:36 -0400 (EDT) From: "Mcdysan, David E" X-IronPort-AV: E=Sophos;i="4.63,310,1299456000"; d="scan'208";a="25042614" Received: from fhdp1lumxc7hb05.verizon.com (HELO FHDP1LUMXC7HB05.us.one.verizon.com) ([166.68.59.192]) by fldsmtpi01.verizon.com with ESMTP; 06 Apr 2011 13:56:33 +0000 Received: from fhdp1lumxc7v11.us.one.verizon.com ([169.254.1.78]) by FHDP1LUMXC7HB05.us.one.verizon.com ([2002:a644:3bc0::a644:3bc0]) with mapi; Wed, 6 Apr 2011 09:56:33 -0400 To: Mirja Kuehlewind , "conex@ietf.org" Date: Wed, 6 Apr 2011 09:56:33 -0400 Thread-Topic: [conex] comments/suggestions on draft-ietf-conex-concepts-uses-01 Thread-Index: Acv0Ym9V7pyUcab0TLKRH1rCdvDUDw== Message-ID: In-Reply-To: <201104060039.48305.mirja.kuehlewind@ikr.uni-stuttgart.de> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.1.0.101012 acceptlanguage: en-US Content-Type: text/plain; charset="windows-1254" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: Re: [conex] comments/suggestions on draft-ietf-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, 06 Apr 2011 13:54:56 -0000 Hi Mirja, Thank you for the feedback. A definition of "self congestion" was added to section 1 of use-cases-01 as follows: Congestion takes two distinct forms. The first results from the interaction of traffic from one set of users with traffic from other users, causing in a reduction in service (a cost) for all of them. the second, often referred to as "self-congestion", occurs when an increase in traffic from a single user causes that user to suffer a worse service (for instance because their traffic is being "shaped" by their ISP, or because they have an excessively large buffer in their home router). ConEx is principally interested in the first form of congestion since it involves informing those other users of the impact you expect to have on them. Editorially, possibly the description of these terms should be in definitions, but as I mentioned in Prague this was new text that the wg should review. Thanks, Dave On Tuesday4/5/11 6:39 PM, "Mirja Kuehlewind" wrote: >Hi Dave, > >thx, I really like your text proposal. I guess the term 'self congestion' >needs to be defined as well...? But otherwise this text make the use case >very clear to me! > >Mirja > > >On Monday 04 April 2011 14:07:13 Mcdysan, David E wrote: >> As I mentioned in the status presentation last Thursday, I planned to >>send >> a paragraph to the conex wg list with proposed text for an additional >> paragraph to be placed at the end of section 5.1. >> >> I am responding to point 1 Alissas' Email on this subject, since I think >> her note summarizes wg consensus on this topic well. (Also note that >>this >> closely aligns with the text cited from the reference [Bauer09]). >> >> The remainder of section 6 relating to this topic would be removed, with >> discussion required to determine whether the wg sees value in keeping >> section 6.2 (possibly in an Appendix), or removing that as well. The >> formulation of this approach by Toby helped me better understand conex, >> but if that is not wg consensus, then so be it. >> >> "Traffic measurements over time scales longer than that of >> policers/shapers involving conex information can be used to adjust the >> token bucket parameters of these policers and adjust parameters of >> shapers. These longer time scale conex related measurements can also >> provide other uses [Bauer09, pg.18-19], such as; achieve better >> understanding user traffic requirements, provide a better basis for >> planning investments, enable better service customization, or achieve >> better matching of costs and usage. When measurement is done in a >>network >> element that implements a shaper, the amount which self congestion >> contributes to overall congestion may be estimated for similar uses. >>These >> traffic management techniques employing conex information may help >>address >> the challenging problem where a small percentage of users (e.g., 20%) >> generate a large portion of the traffic (e.g., 80%) [Varian09]. " >> >> >> Also, based upon some misunderstanding of terminology that was apparent >>on >> the list, I propose that the RFC 2475 definition of "shaper" be added to >> section 3.1, existing approaches. >> >> Thanks, >> >> Dave >> >> On Friday3/25/11 4:37 AM, "Alissa Cooper" wrote: >> >In my reading of section 6, it presents 2 distinct issues: >> > >> >1) Long time scales: A use case (or perhaps a few variations on the >> >same use case) for the conex signal as currently described in abstract- >> >mech, wherein conex helps network operators to manage congestion, >> >conduct traffic shaping, and capacity-plan over periods much longer >> >than network speeds (e.g., minutes/hours/days/months) >> > >> >2) Shaper presence: A suggestion that conex could signal the presence >> >of a traffic shaper (in addition to or instead of how the conex signal >> >is currently described in abstract-mech) and a use case for such a >> >signal wherein recipients of the signal can use it to request that >> >sender's traffic shaper parameters be altered >> > >> >I think the issue of long time scales, which is described in the >> >introductory text to section 6 and briefly in 6.1 and 6.2, could >> >instead be succinctly addressed by adding a couple of sentences to 5.1 >> >to explain that the use of conex for managing "heavy" users could >> >occur over shorter or longer time scales and could have the added >> >affect of helping operators to do longer-term capacity planning. >> > >> >Signaling the presence of a shaper seems to me to be a separate animal >> >altogether, and one over which there is some obvious disagreement. But >> >at least half of section 6 seems to be devoted to the idea that >> >operators would have uses for aggregating conex information over long >> >time frames, and I think those uses could be incorporated with a brief >> >addition to section 5.1. >> > >> >Alissa >> > >> >On Mar 17, 2011, at 12:25 PM, Mcdysan, David E wrote: >> >> Hi Nandita, >> >> >> >> A few responses to your questions on the new section in line below >> >> prefixed by DM which were previously posted to the list that I >> >> believe (at least partially) address your comments. >> >> >> >> I propose that the working group work toward how to organize/merge/ >> >> move the new text better into the existing outline. >> >> >> >> Thanks, >> >> >> >> Dave >> >> >> >> From: Nandita Dukkipati >> >> Date: Thu, 17 Mar 2011 03:28:25 -0400 >> >> To: Toby Moncaster , John Leslie , >> >> Bob Briscoe , "Woundy, Richard" >> >>> >> >> >> >, David McDysan >> >> >> >> Cc: "conex@ietf.org" >> >> Subject: comments/suggestions on draft-ietf-conex-concepts-uses-01 >> >> >> >> On reading the latest draft, I have three high level comments >> >> roughly in the following order of importance- >> >> >> >> *** >> >> Statistical Multiplexing over different timescales. >> >> This reads like a rambling story. I have read and re-read it, and I >> >> am still left wondering - >> >> * What is _the_ main point? How about starting the section by >> >> stating your main point upfront as opposed leaving it to the reader >> >> to figure it out. >> >> >> >> DM - From my 3/10/11 on the list >> >> >> >> 1) A few "heavy" users generate most of the traffic and service >> >> providers >> >> want to better assign the cost (of provisioning an upgrade) for the >> >> time >> >> when congestion is anticipated to occur. Existing mechanisms, flat >> >> rate, >> >> bandwidth tier shapers, and usage tiers do not completely address the >> >> service provider objective and/or are not popular with users. >> >> >> >> 2) In some service provider networks shapers are implemented to >> >> limit the >> >> maximum bandwidth per user. Although overflow or marking in the >>shaper >> >> queue appears as congestion to the receiver, this "self-congestion" >> >> differs from congestion of a shared resource since a remedy could be >> >> to >> >> indicate to the user that changing the shaper rate (i.e., "go >>faster") >> >> would alleviate "self-congestion." >> >> >> >> * Why and how is this use case distinct from that of traffic >> >> management which already seems to have a broad scope? Is it really >> >> distinct? >> >> >> >> DM - From my 3/11/11 post to the list >> >> >> >> Editorially, this (section 5.1) could be a place to state the >> >> problem with an additional >> >> reference to [Varian]. >> >> >> >> Editorially, bandwidth tier pricing could be added to section 3.1, >> >> Existing approaches. >> >> >> >> I am now thinking that editorially a separate section is not a good >> >> idea, >> >> since the points can be merged into the existing outline, in at >> >> least the >> >> places mentioned above. >> >> >> >> I think adding that the use case needs to meet service provider >> >> economic >> >> congestion needs as well as be acceptable to users is an important >> >> point >> >> not in the current text. Traffic management (aka policing) may have >> >> the >> >> problem that it may not be popular with user. There has already been >> >> negative feedback on the list regarding policing (IMO, Traffic >> >> management >> >> is a better term). >> >> >> >> >> >> * [minor] Why not make this use case a part of Sec. 5? >> >> >> >> DM =AD the minutes recorded adding the agreement to add this as a new >> >> section. (A new subsection, and or merging thoughts with other use >> >> cases (e.g., as suggested above) is what I believe the wg needs to >> >> discuss. >> >> >> >> *** >> >> Partial versus full deployment. >> >> Clearly, it belongs to this draft. But why is it a part of use >> >> cases? Looks out of place to me. >> >> >> >> *** >> >> Sec 4. Exposing congestion. >> >> =B3We argue that congestion needs.... More specifically, a network >> >> needs to be able to measure how much congestion any particular >> >> traffic expects to cause between the monitoring point in the network >> >> and the destination ("rest-of-path congestion"). This would be a new >> >> capability.=B2 >> >> >> >> Could you add more clarity and explanation on why local congestion >> >> information at any given node is not sufficient. Why does a node >> >> require congestion information from a monitoring point to the >> >> destination to be able to manage its own congestion? A succinct >> >> explanation and/or an example will go a long way. >> >> >> >> _______________________________________________ >> >> conex mailing list >> >> conex@ietf.org >> >> https://www.ietf.org/mailman/listinfo/conex >> >> _______________________________________________ >> conex mailing list >> conex@ietf.org >> https://www.ietf.org/mailman/listinfo/conex > > > >--=20 >------------------------------------------------------------------- >Dipl.-Ing. Mirja K=FChlewind >Institute of Communication Networks and Computer Engineering (IKR) >University of Stuttgart, Germany >Pfaffenwaldring 47, D-70569 Stuttgart > >tel: +49(0)711/685-67973 >email: mirja.kuehlewind@ikr.uni-stuttgart.de >web: www.ikr.uni-stuttgart.de >------------------------------------------------------------------- From bob.briscoe@bt.com Wed Apr 6 08:13:18 2011 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 26EC328C102 for ; Wed, 6 Apr 2011 08:13:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.484 X-Spam-Level: X-Spam-Status: No, score=-3.484 tagged_above=-999 required=5 tests=[AWL=0.115, 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 CmukKUFfPIDt for ; Wed, 6 Apr 2011 08:13:16 -0700 (PDT) Received: from smtp1.smtp.bt.com (smtp1.smtp.bt.com [217.32.164.137]) by core3.amsl.com (Postfix) with ESMTP id 073C228B23E for ; Wed, 6 Apr 2011 08:13:15 -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, 6 Apr 2011 16:14: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, 6 Apr 2011 16:14: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 1302102897299; Wed, 6 Apr 2011 16:14:57 +0100 Received: from MUT.jungle.bt.co.uk ([10.73.61.35]) by bagheera.jungle.bt.co.uk (8.13.5/8.12.8) with ESMTP id p36FEq20022657; Wed, 6 Apr 2011 16:14:53 +0100 Message-Id: <201104061514.p36FEq20022657@bagheera.jungle.bt.co.uk> X-Mailer: QUALCOMM Windows Eudora Version 7.1.0.9 Date: Wed, 06 Apr 2011 16:13:53 +0100 To: Dirk Kutscher 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: 06 Apr 2011 15:14:58.0410 (UTC) FILETIME=[647394A0:01CBF46D] Cc: ConEx IETF list , draft-kutscher-conex-mobile@tools.ietf.org Subject: [conex] Review comments: draft-kutscher-conex-mobile-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: Wed, 06 Apr 2011 15:13:18 -0000 Dirk & co-authors, General points: --------------- * I liked the draft (perhaps because it was positive about ConEx ;) and found it well-written and very readable. * It was often written the wrong way round, assessing whether mobile networks would be a good fit for ConEx, rather than assessing whether ConEx would be a good fit for mobile networks. * It would be useful to describe the precise benefit that ConEx might add to mobile that would not be possible without it. Personally I think this has to do with providing a simple way to bring real-time cost information from throughout the network to the control point where customer policies are known and traffic control is applied (see later). * The draft has a good structure and scope - whatever you change, please try to preseve these. Technical points ---------------- 1. Intro " where the UE (User Equipment, i.e. mobile end host), its access network and possibly an operator's core network can be CONEX-enabled. " Surely the servers or caches are the main nodes to ConEx enable? It also needs to be made clear what it means to ConEx enable a network (ie place policy / audit functions at its edges). 3.1 ConEx as a basis for traffic management I don't think we should be embarrassed to say that ConEx might be useful to DPI in the shorter term. Then, longer term, it provides an evolution path to achieve the main traffic management objectives of DPI, but in a neutral way. This agnosticism is an incremental deployment strength of ConEx (when I first introduced re-ECN to the IETF, I described its benefits for network operators with either conservative or liberal policies - I was thinking of cellular walled gardens as the conservative case). ConEx information can be used in two different ways, perhaps both at the same time on different traffic: a) per flow policy-based traffic management (enhancing DPI) b) bulk packet traffic management (replacing DPI) Why ConEx helps DPI: DPI is effectively used for yield management, optimising revenue vs cost on a per-session basis. However, currently DPI only has cost information based on inference of likely future flow volume based on application type. ConEx would provide real-time cost information, so that this yield management could be based on actual network conditions, not guesses and inferences. As you say, longer term ConEx allows the PCC architecture to be revisted. ConEx could be used to manage all traffic; except 'opt-in' traffic where the user equipment or server explicitly signals to the mobile network on a per-session basis. I predict that the transition from a) to b) will occur as competition commoditises the session-based approach. Per-session yield management only makes sense while excess profits can be extracted from different sessions. 3.2. CONEX to incentivize scavenger transports "the mobile communication network will be used like any other access network, " This is unclear to those who don't know how a mobile network currently tries to work: identifying all this traffic and trying to handle it all differently. The second para is unclear and vague. Why will it eventually be difficult to distinguish the different apps? What exactly is reflected by current DPI activities? 3.3. Accounting for Congestion Volume This section is the first time received and sent are distinguished. This ought to have been already said earlier. 3.4 ConEx as a form of differential QoS The point needs to be made here that ConEx info can be used in two different ways: a) as additional info to help the network to impose different QoS for different sessions b) so that the network can allow user equipment to take different amounts of bandwidth in response to congestion, but still enforce overall limits on the contribution to congestion. This is a similar flow/bulk choice as discussed for DPI, which I think could be brought out more as a theme throughout the document. 3.5 Partial vs. Full Deployment para1: conex-abstract-mech says the aim is for ConEx to be initially deployed solely on the sender. As well as the case of the ConEx-enabled UE (presumably as sender), this doc also needs to consider the much more prevalent case of a server or cache as sender, particularly a server/cache directly connected to the mobile network, which would be a very plausible deployment case. para2: Roaming: It is relatively easy to shift the state associated with a policy device as a user roams. This is already done when the state associated with a user's account is shifted during a hand-over. You may want to refer to this paper on the design of a distributed policer: Raghavan, B., Vishwanath, K., Ramabhadran, S., Yocum, K. & Snoeren, A.C., "Cloud control with distributed rate limiting," Proc. ACM SIGCOMM'07, Computer Communication Review 37(4):337--348 ACM (2007) DOI: http://doi.acm.org/10.1145/1282427.1282419 para3: It is right to mention that traffic offload may move the attachment point and therefore shift where policy has to be monitored and enforced. But it should also be pointed out that ConEx information would be likely to drive decisions to offload traffic in the first place, and lack of ConEx makes such decisions harder. 4.1 Possible Deployment Scenarios I suggest an additional scenario 3) that is perhaps a more likely deployment. The sender supports ConEx and offers e2e ConEx info to nodes on the network path, but not all the networks on the path use the information or audit it. Given we are likely to have a variant of ConEx that works with existing receivers, this will be an important partial deployment scenario. " the case when CONEX is only implemented in a few networks, or when operators decide to not expose and account for congestion for inter-domain traffic." To be clear, operators cannot decide to not expose ConEx information if senders expose it. OK, the operator might bleach ConEx information, but this may break e2e authentication and consequently be considered somewhat equivalent to sending TCP resets to p2p applications >:-} Perhaps you intended to talk about operators deciding not to expose ECN inter-domain? 4.2. Implementing CONEX Functions in the EPS ConEx function placement: - First, you need to say which function you are talking about. I assume you mean the policy function. - Second, ConEx information is unchanged along the whole path, so reading ConEx information should be placement-agnostic along the path. - Third, placement is sensitive to ECN (or drop) information, which does change along the path. But, importantly, the operator can use tunnelling to preserve the ECN information as it was at a remote upstream point, which will be frozen in the inner header of the tunnel. Therefore, again, reading ECN info can be placement-agnostic along the path. - Fourth, although monitoring information can be placement-agnostic, as you say, the action as a result will be placement-sensitive. - Fifth, however, a case not considered is where a rudimentary policing function (e.g. bulk) is placed close to the edge, then a richer (e.g. per-flow) policing function is placed in a more centralised location. The outer policing function would protect sufficiently against unresponsive sources, while the inner policing function takes advantage of economies of scale for managing such complex policies. Downlink policers at borders: Ought to mention the possibility of ConEx monitoring function at borders driving out-of-band mechanisms rather than direct policing intervention, eg. a border contract with penalties based on ConEx info. 5. Implications for ConEx " the mobile network may encounter longer delay and higher loss rate but most of the flows are short- lived. " I don't understand the connection between the two parts of this sentence. Why the word 'but'? In all networks, most flows are short-lived, and the Credit packets in ConEx are designed to provide the right incentives precisely for this case. What's different about mobile networks here? Tunnelling: Could refer to draft-briscoe-tsvwg-ecn-encap-guidelines, although that only deals with tunnelling ECN, not ConEx. Editorial --------- 1. Intro s/CONEX, as described in [I-D.ietf-conex-concepts-uses] is a technology to/ /CONEX, as described in [I-D.ietf-conex-concepts-uses], is a technology to/ 2. Overview of 3GPPP... Features described but not labelled in Fig 1: EPC, eNB, P-GW, s/GWs/gateways/ 3. ConEx Use Cases s/extend/extent/ 3.1 s/create a certain dynamics/ /create certain dynamics/ s/for bearers establishment/ /for bearer establishment/ Expand 'PDN'. s/Previously more static approach ... have been applied/ /Previously more static approaches ... have been applied/ 3.6 s/the 3GPP EPS in a system architecture that/ /the 3GPP EPS is a system architecture that/ s/such as an LTE mobile communication networks/ /such as an LTE mobile communication network/ 4.1 Possible Deployment Scenarios para2: would be useful to break down into enumerated bullets (especially if you add the 3rd scenario I suggest above) 4.2. Implementing CONEX Functions in the EPS s/re-act/react/ s/based on function related/ /based on a function related/ " implementations of CONEX may require the network to enforce proper congestion contribution declaration (i.e., as droppers in the Re- ECN proposal). " Ought to now reference the new terminology 'audit function' in conex-abstract-mech. HTH Thankyou again, Bob ________________________________________________________________ Bob Briscoe, BT Innovate & Design From Dirk.Kutscher@neclab.eu Wed Apr 6 08:41:54 2011 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 8A74328B23E for ; Wed, 6 Apr 2011 08:41:54 -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 k7ywd4KUZ8UP for ; Wed, 6 Apr 2011 08:41:51 -0700 (PDT) Received: from smtp0.neclab.eu (smtp0.neclab.eu [195.37.70.41]) by core3.amsl.com (Postfix) with ESMTP id 8A40128C11B for ; Wed, 6 Apr 2011 08:41:50 -0700 (PDT) Received: from localhost (localhost.localdomain [127.0.0.1]) by smtp0.neclab.eu (Postfix) with ESMTP id 53E962C00020E; Wed, 6 Apr 2011 17:46:39 +0200 (CEST) X-Virus-Scanned: Amavisd on Debian GNU/Linux (atlas2.office.hd) Received: from smtp0.neclab.eu ([127.0.0.1]) by localhost (atlas2.office.hd [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 6jkhpB5j3YtR; Wed, 6 Apr 2011 17:46:39 +0200 (CEST) Received: from METHONE.office.hd (Methone.office.hd [192.168.24.54]) by smtp0.neclab.eu (Postfix) with ESMTP id 30D662C00020D; Wed, 6 Apr 2011 17:46:24 +0200 (CEST) Received: from Polydeuces.office.hd ([169.254.3.246]) by METHONE.office.hd ([192.168.24.54]) with mapi id 14.01.0270.001; Wed, 6 Apr 2011 17:43:19 +0200 From: Dirk Kutscher To: Bob Briscoe Thread-Topic: Review comments: draft-kutscher-conex-mobile-00 Thread-Index: AQHL9G1pTMcA9ltE80OtnGX3R5nWb5RQ9GNg Date: Wed, 6 Apr 2011 15:43:17 +0000 Message-ID: <82AB329A76E2484D934BBCA77E9F524905B13DC8@Polydeuces.office.hd> References: <201104061514.p36FEq20022657@bagheera.jungle.bt.co.uk> In-Reply-To: <201104061514.p36FEq20022657@bagheera.jungle.bt.co.uk> Accept-Language: de-DE, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.1.2.105] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: ConEx IETF list , "draft-kutscher-conex-mobile@tools.ietf.org" Subject: Re: [conex] Review comments: draft-kutscher-conex-mobile-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: Wed, 06 Apr 2011 15:41:54 -0000 Bob, excellent feedback -- thanks a lot! One of the items on our todo list was exactly to elaborate on the real-time= cost information benefit that ConEx can provide in this environment, so yo= ur input is really helpful. We will consider this for the update. Cheers, Dirk > -----Original Message----- > From: Bob Briscoe [mailto:bob.briscoe@bt.com] > Sent: Wednesday, April 06, 2011 5:14 PM > To: Dirk Kutscher > Cc: draft-kutscher-conex-mobile@tools.ietf.org; ConEx IETF list > Subject: Review comments: draft-kutscher-conex-mobile-00 >=20 > Dirk & co-authors, >=20 > General points: > --------------- > * I liked the draft (perhaps because it was positive about ConEx ;) > and found it well-written and very readable. > * It was often written the wrong way round, assessing whether mobile > networks would be a good fit for ConEx, rather than assessing whether > ConEx would be a good fit for mobile networks. > * It would be useful to describe the precise benefit that ConEx might > add to mobile that would not be possible without it. Personally I > think this has to do with providing a simple way to bring real-time > cost information from throughout the network to the control point > where customer policies are known and traffic control is applied (see > later). > * The draft has a good structure and scope - whatever you change, > please try to preseve these. >=20 >=20 > Technical points > ---------------- > 1. Intro > " where the UE (User Equipment, > i.e. mobile end host), its access network and possibly an > operator's > core network can be CONEX-enabled. > " > Surely the servers or caches are the main nodes to ConEx enable? > It also needs to be made clear what it means to ConEx enable a > network (ie place policy / audit functions at its edges). > 3.1 ConEx as a basis for traffic management >=20 > I don't think we should be embarrassed to say that ConEx might be > useful to DPI in the shorter term. Then, longer term, it provides an > evolution path to achieve the main traffic management objectives of > DPI, but in a neutral way. >=20 > This agnosticism is an incremental deployment strength of ConEx (when > I first introduced re-ECN to the IETF, I described its benefits for > network operators with either conservative or liberal policies - I > was thinking of cellular walled gardens as the conservative case). >=20 > ConEx information can be used in two different ways, perhaps both at > the same time on different traffic: > a) per flow policy-based traffic management (enhancing DPI) > b) bulk packet traffic management (replacing DPI) >=20 > Why ConEx helps DPI: DPI is effectively used for yield management, > optimising revenue vs cost on a per-session basis. However, currently > DPI only has cost information based on inference of likely future > flow volume based on application type. ConEx would provide real-time > cost information, so that this yield management could be based on > actual network conditions, not guesses and inferences. >=20 > As you say, longer term ConEx allows the PCC architecture to be > revisted. ConEx could be used to manage all traffic; except 'opt-in' > traffic where the user equipment or server explicitly signals to the > mobile network on a per-session basis. >=20 > I predict that the transition from a) to b) will occur as competition > commoditises the session-based approach. Per-session yield management > only makes sense while excess profits can be extracted from different > sessions. >=20 > 3.2. CONEX to incentivize scavenger transports >=20 > "the mobile communication network will be used like any other access > network, " > This is unclear to those who don't know how a mobile network > currently tries to work: identifying all this traffic and trying to > handle it all differently. >=20 > The second para is unclear and vague. Why will it eventually be > difficult to distinguish the different apps? What exactly is > reflected by current DPI activities? >=20 > 3.3. Accounting for Congestion Volume >=20 > This section is the first time received and sent are distinguished. > This ought to have been already said earlier. >=20 > 3.4 ConEx as a form of differential QoS >=20 > The point needs to be made here that ConEx info can be used in two > different ways: > a) as additional info to help the network to impose different QoS for > different sessions > b) so that the network can allow user equipment to take different > amounts of bandwidth in response to congestion, but still enforce > overall limits on the contribution to congestion. >=20 > This is a similar flow/bulk choice as discussed for DPI, which I > think could be brought out more as a theme throughout the document. >=20 > 3.5 Partial vs. Full Deployment >=20 > para1: conex-abstract-mech says the aim is for ConEx to be initially > deployed solely on the sender. As well as the case of the > ConEx-enabled UE (presumably as sender), this doc also needs to > consider the much more prevalent case of a server or cache as sender, > particularly a server/cache directly connected to the mobile network, > which would be a very plausible deployment case. >=20 > para2: Roaming: It is relatively easy to shift the state associated > with a policy device as a user roams. This is already done when the > state associated with a user's account is shifted during a hand-over. > You may want to refer to this paper on the design of a distributed > policer: >=20 > Raghavan, B., Vishwanath, K., Ramabhadran, S., Yocum, K. & Snoeren, > A.C., "Cloud control with distributed rate limiting," Proc. ACM > SIGCOMM'07, Computer Communication Review 37(4):337--348 ACM (2007) > DOI: http://doi.acm.org/10.1145/1282427.1282419 >=20 > para3: It is right to mention that traffic offload may move the > attachment point and therefore shift where policy has to be monitored > and enforced. But it should also be pointed out that ConEx > information would be likely to drive decisions to offload traffic in > the first place, and lack of ConEx makes such decisions harder. >=20 > 4.1 Possible Deployment Scenarios >=20 > I suggest an additional scenario 3) that is perhaps a more likely > deployment. The sender supports ConEx and offers e2e ConEx info to > nodes on the network path, but not all the networks on the path use > the information or audit it. >=20 > Given we are likely to have a variant of ConEx that works with > existing receivers, this will be an important partial deployment > scenario. >=20 > " the case when CONEX is only implemented in a few > networks, or when operators decide to not expose and account for > congestion for inter-domain traffic." >=20 > To be clear, operators cannot decide to not expose ConEx information > if senders expose it. OK, the operator might bleach ConEx > information, but this may break e2e authentication and consequently > be considered somewhat equivalent to sending TCP resets to p2p > applications >:-} >=20 > Perhaps you intended to talk about operators deciding not to expose > ECN inter-domain? >=20 > 4.2. Implementing CONEX Functions in the EPS >=20 > ConEx function placement: > - First, you need to say which function you are talking about. I > assume you mean the policy function. > - Second, ConEx information is unchanged along the whole path, so > reading ConEx information should be placement-agnostic along the path. > - Third, placement is sensitive to ECN (or drop) information, which > does change along the path. But, importantly, the operator can use > tunnelling to preserve the ECN information as it was at a remote > upstream point, which will be frozen in the inner header of the > tunnel. Therefore, again, reading ECN info can be placement-agnostic > along the path. > - Fourth, although monitoring information can be placement-agnostic, > as you say, the action as a result will be placement-sensitive. > - Fifth, however, a case not considered is where a rudimentary > policing function (e.g. bulk) is placed close to the edge, then a > richer (e.g. per-flow) policing function is placed in a more > centralised location. The outer policing function would protect > sufficiently against unresponsive sources, while the inner policing > function takes advantage of economies of scale for managing such > complex policies. >=20 > Downlink policers at borders: Ought to mention the possibility of > ConEx monitoring function at borders driving out-of-band mechanisms > rather than direct policing intervention, eg. a border contract with > penalties based on ConEx info. >=20 > 5. Implications for ConEx > " the mobile network may encounter > longer delay and higher loss rate but most of the flows are > short- > lived. " > I don't understand the connection between the two parts of this > sentence. Why the word 'but'? In all networks, most flows are > short-lived, and the Credit packets in ConEx are designed to provide > the right incentives precisely for this case. What's different about > mobile networks here? >=20 > Tunnelling: Could refer to draft-briscoe-tsvwg-ecn-encap-guidelines, > although that only deals with tunnelling ECN, not ConEx. >=20 > Editorial > --------- >=20 > 1. Intro > s/CONEX, as described in [I-D.ietf-conex-concepts-uses] is a technology > to/ > /CONEX, as described in [I-D.ietf-conex-concepts-uses], is a > technology to/ >=20 > 2. Overview of 3GPPP... > Features described but not labelled in Fig 1: > EPC, eNB, P-GW, > s/GWs/gateways/ >=20 > 3. ConEx Use Cases > s/extend/extent/ >=20 > 3.1 > s/create a certain dynamics/ > /create certain dynamics/ >=20 > s/for bearers establishment/ > /for bearer establishment/ >=20 > Expand 'PDN'. >=20 > s/Previously more static approach ... have been applied/ > /Previously more static approaches ... have been applied/ >=20 > 3.6 > s/the 3GPP EPS in a system architecture that/ > /the 3GPP EPS is a system architecture that/ >=20 > s/such as an LTE mobile communication networks/ > /such as an LTE mobile communication network/ >=20 > 4.1 Possible Deployment Scenarios > para2: would be useful to break down into enumerated bullets > (especially if you add the 3rd scenario I suggest above) >=20 > 4.2. Implementing CONEX Functions in the EPS > s/re-act/react/ >=20 > s/based on function related/ > /based on a function related/ >=20 > " implementations of CONEX may require the network to enforce > proper > congestion contribution declaration (i.e., as droppers in the > Re- > ECN proposal). > " > Ought to now reference the new terminology 'audit function' in > conex-abstract-mech. >=20 > HTH >=20 > Thankyou again, >=20 >=20 > Bob >=20 >=20 > ________________________________________________________________ > Bob Briscoe, BT Innovate & Design From bob.briscoe@bt.com Wed Apr 6 08:44:11 2011 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 2AA2A3A6949 for ; Wed, 6 Apr 2011 08:44:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.486 X-Spam-Level: X-Spam-Status: No, score=-3.486 tagged_above=-999 required=5 tests=[AWL=0.113, 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 miWLZLd3cRxn for ; Wed, 6 Apr 2011 08:44:10 -0700 (PDT) Received: from smtp2.smtp.bt.com (smtp2.smtp.bt.com [217.32.164.150]) by core3.amsl.com (Postfix) with ESMTP id 5A7D73A6819 for ; Wed, 6 Apr 2011 08:44:10 -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); Wed, 6 Apr 2011 16:45:53 +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); Wed, 6 Apr 2011 16:45:53 +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 1302104751811; Wed, 6 Apr 2011 16:45:51 +0100 Received: from MUT.jungle.bt.co.uk ([10.73.61.35]) by bagheera.jungle.bt.co.uk (8.13.5/8.12.8) with ESMTP id p36Fjode022779; Wed, 6 Apr 2011 16:45:51 +0100 Message-Id: <201104061545.p36Fjode022779@bagheera.jungle.bt.co.uk> X-Mailer: QUALCOMM Windows Eudora Version 7.1.0.9 Date: Wed, 06 Apr 2011 16:45:48 +0100 To: Toby Moncaster From: Bob Briscoe In-Reply-To: <232AFD59-B6E6-4338-8AB0-0175AE72B712@g11.org.uk> References: <002501cbf2e7$67bf5270$373df750$@com> <232AFD59-B6E6-4338-8AB0-0175AE72B712@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: 06 Apr 2011 15:45:53.0422 (UTC) FILETIME=[B61FF2E0:01CBF471] Cc: conex@ietf.org Subject: Re: [conex] giving up as editor of use draft-ietf-conex-concepts-uses 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, 06 Apr 2011 15:44:11 -0000 Toby, I'd like to publicly thank you for your contribution and I'm glad to see that you are still open to contributing in future. This is an unfortunate situation we have got into. The problem we have here is far from simple. Not least, there are different misconceptions that different readers hold with great conviction, which we somehow have to negate before we actually get to what we want to say. Thank you again. Bob ________________________________________________________________ Bob Briscoe, BT Innovate & Design From marcelo@it.uc3m.es Wed Apr 6 12:15:50 2011 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 836003A67E6 for ; Wed, 6 Apr 2011 12:15:50 -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 G0TtYvmrlOP1 for ; Wed, 6 Apr 2011 12:15:49 -0700 (PDT) Received: from smtp01.uc3m.es (smtp01.uc3m.es [163.117.176.131]) by core3.amsl.com (Postfix) with ESMTP id 358813A63EB for ; Wed, 6 Apr 2011 12:15:48 -0700 (PDT) X-uc3m-safe: yes Received: from marcelo-bagnulos-macbook-pro-2.local (192.50.22.95.dynamic.jazztel.es [95.22.50.192]) (using TLSv1 with cipher AES256-SHA (256/256 bits)) (No client certificate requested) by smtp01.uc3m.es (Postfix) with ESMTP id 89D02C27F2F for ; Wed, 6 Apr 2011 21:17:31 +0200 (CEST) Message-ID: <4D9CBC45.40802@it.uc3m.es> Date: Wed, 06 Apr 2011 21:17:25 +0200 From: marcelo bagnulo braun User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.5; es-ES; rv:1.9.2.15) Gecko/20110303 Thunderbird/3.1.9 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.5.0.1024-18058.000 Subject: [conex] Next steps with the use case document 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, 06 Apr 2011 19:15:50 -0000 The use case document is a critical document for conex as its goal is to explain to the IETF community and beyond why conex is useful. There is a great deal of confusion in the community around conex and this draft is key to deal with that. Because conex concepts and use cases are hard to grasp, the task of writing this document is inherently difficult. We are now late meeting our target date for delivering this document. The chairs, in consultation with the AD, conclude that a reduction in the number of editors is in order. As such, we will be reducing the editorial team for the document to Rich Woundy and Bob Bricoe. We will also send a proposal for concrete next steps with the document shortly. Please note that we appreciate the efforts of the previous editors and we certainly hope to them as contributors. Thank you. Regards, Nandita and marcelo From john@jlc.net Wed Apr 6 12:25:43 2011 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 AC4BF3A67E6 for ; Wed, 6 Apr 2011 12:25:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.507 X-Spam-Level: X-Spam-Status: No, score=-106.507 tagged_above=-999 required=5 tests=[AWL=0.092, 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 aOxDxZSYvvec for ; Wed, 6 Apr 2011 12:25:34 -0700 (PDT) Received: from mailhost.jlc.net (mailhost.jlc.net [199.201.159.4]) by core3.amsl.com (Postfix) with ESMTP id 91EE53A63EB for ; Wed, 6 Apr 2011 12:25:28 -0700 (PDT) Received: by mailhost.jlc.net (Postfix, from userid 104) id 9F7F733C26; Wed, 6 Apr 2011 15:27:01 -0400 (EDT) Date: Wed, 6 Apr 2011 15:27:01 -0400 From: John Leslie To: conex@ietf.org Message-ID: <20110406192701.GF24474@verdi> References: <004001cbf3a5$02b6a9f0$0823fdd0$@com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <004001cbf3a5$02b6a9f0$0823fdd0$@com> User-Agent: Mutt/1.4.1i Subject: Re: [conex] my personal views on draft-ietf-conex-concepts-uses 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, 06 Apr 2011 19:25:44 -0000 Toby Moncaster wrote: > > - Re-write the introduction of the draft to provide a clear > motivation for ConEx > > - Write a section explaining what Conex is and (importantly) what it > isn't. This needs to contrast it to alternative approaches (such as > over-provisioning) and show how those alternative approaches are > flawed. > > - Then have a short section using a single network deployment as an > example of how ConEx can operate (for instance, using ConEx as a > mechanism to control the usage of a resource-constrained shared > network such as those that are provided for students on university > campuses). This should be explained in terms of familiar concepts > (the approach taken in [policing freedom], where the policer is > described in terms of a token bucket). > > - Then give a detailed use case for the "charter scenario" of partial > deployment with only sender and sender's network ConEx-enabled. This > needs to show how (for instance) the sender's network can use ConEx > to ensure that user's are not contributing to local congestion and > are thus not causing other users to suffer a degradation in service. > > - Finally have a complete section on partial deployment models (the > third bullet on Bob's list). This would look at the different > arrangements of networks (sender, core, receiver), what each network > needs to do about conex and what advantages it gets through being > conex aware. > > Such a document would best be called "ConEx Concepts and Motivations". > By limiting the use cases described in the document it allows people > to focus on what ConEx is actually doing and how it works. Until they > understand that, there is no point trying to convince them of the huge > range of uses to which it can be put. I agree with Toby. -- John Leslie From karagian@cs.utwente.nl Thu Apr 7 02:02:34 2011 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 47A1A3A68DF for ; Thu, 7 Apr 2011 02:02:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.203 X-Spam-Level: X-Spam-Status: No, score=-0.203 tagged_above=-999 required=5 tests=[AWL=0.300, BAYES_00=-2.599, HELO_EQ_NL=0.55, HOST_EQ_NL=1.545, 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 MEdbal6ekPKe for ; Thu, 7 Apr 2011 02:02:27 -0700 (PDT) Received: from denhaag.ewi.utwente.nl (denhaag.ewi.utwente.nl [130.89.10.11]) by core3.amsl.com (Postfix) with ESMTP id 59EB83A69B6 for ; Thu, 7 Apr 2011 02:02:26 -0700 (PDT) Received: from ewi977 (ewi977.ewi.utwente.nl [130.89.12.129]) by denhaag.ewi.utwente.nl (8.13.6/8.13.6) with ESMTP id p3793QJD026348; Thu, 7 Apr 2011 11:03:29 +0200 (MEST) From: "Georgios Karagiannis" To: "'Toby Moncaster'" , References: <004001cbf3a5$02b6a9f0$0823fdd0$@com> Date: Thu, 7 Apr 2011 11:03:50 +0200 Message-ID: <8B2095B2FFB946C0A407F70729F556D6@dynamic.ewi.utwente.nl> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_000C_01CBF513.7C8CD820" X-Mailer: Microsoft Office Outlook 11 In-Reply-To: <004001cbf3a5$02b6a9f0$0823fdd0$@com> X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.5994 Thread-Index: AcvzpQJF0+TsC/rJSGW3sBHbODrp7gBXZi+A X-Scanned-By: MIMEDefang 2.52 on 130.89.10.11 X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-3.0rc3 (denhaag.ewi.utwente.nl [130.89.10.11]); Thu, 07 Apr 2011 11:03:39 +0200 (MEST) Subject: Re: [conex] my personal views on draft-ietf-conex-concepts-uses 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, 07 Apr 2011 09:02:34 -0000 This is a multi-part message in MIME format. ------=_NextPart_000_000C_01CBF513.7C8CD820 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Hi all I agree with the opinion of Toby on having a draft that will focus on ConEx Concepts and Motivations. Best regards, Georgios _____ From: conex-bounces@ietf.org [mailto:conex-bounces@ietf.org] On Behalf Of Toby Moncaster Sent: dinsdag 5 april 2011 17:21 To: conex@ietf.org Subject: [conex] my personal views on draft-ietf-conex-concepts-uses Hi All, As I am no longer editor of draft-ietf-conex-concepts-uses I can express my views on the document as an individual (rather than as the representative of the of the co-authors). Having had a thorough re-think about how best to progress ConEx through the IETF, I have come to the conclusion that the current draft is failing because it tries to do too much for a single document. In its current form, the document is doing two things. It seeks to explain the rationale of ConEx and it tries to give a list of use cases where ConEx seems to add most value. I now think these two parts can't exist in a single document since the latter tends to distract attention from the former. Marcelo ad Nandita have lofty ambitions for this document, which should serve as the ambassador for ConEx. This should be the document that silences our critics, or at least shows them that their fears about ConEx are unfounded. It should also act to enthuse the developer, vendor and operator communities to start working on ConEx and thus start the ball rolling for eventual deployment. So my proposal to the new editing team is as follows. . Re-write the introduction of the draft to provide a clear motivation for ConEx . Write a section explaining what Conex is and (importantly) what it isn't. This needs to contrast it to alternative approaches (such as over-provisioning) and show how those alternative approaches are flawed. . Then have a short section using a single network deployment as an example of how ConEx can operate (for instance, using ConEx as a mechanism to control the usage of a resource-constrained shared network such as those that are provided for students on university campuses). This should be explained in terms of familiar concepts (the approach taken in [policing freedom], where the policer is described in terms of a token bucket). . Then give a detailed use case for the "charter scenario" of partial deployment with only sender and sender's network ConEx-enabled. This needs to show how (for instance) the sender's network can use ConEx to ensure that user's are not contributing to local congestion and are thus not causing other users to suffer a degradation in service. . Finally have a complete section on partial deployment models (the third bullet on Bob's list). This would look at the different arrangements of networks (sender, core, receiver), what each network needs to do about conex and what advantages it gets through being conex aware. Such a document would best be called "ConEx Concepts and Motivations". By limiting the use cases described in the document it allows people to focus on what ConEx is actually doing and how it works. Until they understand that, there is no point trying to convince them of the huge range of uses to which it can be put. Then we can create a separate document bringing together all the other use cases and incorporating some of the individual work that has been contributed to ConEx. That document can be published a bit later than the other one and it can then assume that people are able to understand ConEx properly. ------=_NextPart_000_000C_01CBF513.7C8CD820 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hi all

I agree with the opinion of Toby on having a draft that will focus on = ConEx=20 Concepts and Motivations. =

Best regards,

Georgios


From: conex-bounces@ietf.org=20 [mailto:conex-bounces@ietf.org] On Behalf Of Toby=20 Moncaster
Sent: dinsdag 5 april 2011 17:21
To:=20 conex@ietf.org
Subject: [conex] my personal views on=20 draft-ietf-conex-concepts-uses

Hi All,

 

As I am no longer editor of = draft-ietf-conex-concepts-uses=20 I can express my views on the document as an individual (rather than = as the=20 representative of the of the co-authors).

 

Having had a thorough re-think about how best to = progress=20 ConEx through the IETF, I have come to the conclusion that the current = draft=20 is failing because it tries to do too much for a single document. In = its=20 current form, the document is doing two things. It seeks to explain = the=20 rationale of ConEx and it tries to give a list of use cases where = ConEx seems=20 to add most value. I now think these two parts can’t exist in a = single=20 document since the latter tends to distract attention from the=20 former.

 

Marcelo ad Nandita have lofty ambitions for this = document,=20 which should serve as the ambassador for ConEx. This should be the = document=20 that silences our critics, or at least shows them that their fears = about ConEx=20 are unfounded. It should also act to enthuse the developer, vendor and = operator communities to start working on ConEx and thus start the ball = rolling=20 for eventual deployment.

 

So my proposal to the new editing team is as = follows.=20

·        =20 Re-write  the introduction of the = draft to=20 provide a clear motivation for ConEx

·        =20 Write a section explaining what Conex = is and=20 (importantly) what it isn’t. This needs to contrast it to = alternative=20 approaches (such as over-provisioning) and show how those alternative=20 approaches are flawed.

·        =20 Then have a short section using a = single=20 network deployment as an example of how ConEx can operate (for = instance, using=20 ConEx as a mechanism to control the usage of a resource-constrained = shared=20 network such as those that are provided for students on university = campuses).=20 This should be explained in terms of familiar concepts (the approach = taken in=20 [policing freedom], where the policer is described in terms of a token = bucket).

·        =20 Then give a detailed use case for the = “charter=20 scenario” of partial deployment with only sender and = sender’s network=20 ConEx-enabled. This needs to show how (for instance) the = sender’s network can=20 use ConEx to ensure that user’s are not contributing to local = congestion and=20 are thus not causing other users to suffer a degradation in=20 service.

·        =20  Finally have a complete section = on=20 partial deployment models (the third bullet on Bob’s list). This = would look at=20 the different arrangements of networks (sender, core, receiver), what = each=20 network needs to do about conex and what advantages it gets through = being=20 conex aware.

 

Such a document would best be called “ConEx = Concepts and=20 Motivations”. By limiting the use cases described in the = document it allows=20 people to focus on what ConEx is actually doing and how it works. = Until they=20 understand that, there is no point trying to convince them of the huge = range=20 of uses to which it can be put.

 

Then we can create a separate document bringing = together=20 all the other use cases and incorporating some of the individual work = that has=20 been contributed to ConEx. That document can be published a bit later = than the=20 other one and it can then assume that people are able to understand = ConEx=20 properly.

------=_NextPart_000_000C_01CBF513.7C8CD820-- From bob.briscoe@bt.com Thu Apr 7 04:45:51 2011 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 415973A6907 for ; Thu, 7 Apr 2011 04:45:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.992 X-Spam-Level: X-Spam-Status: No, score=-2.992 tagged_above=-999 required=5 tests=[AWL=-0.385, BAYES_00=-2.599, DATE_IN_PAST_12_24=0.992, 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 4QI-Jf+cJPsX for ; Thu, 7 Apr 2011 04:45:49 -0700 (PDT) Received: from smtp3.smtp.bt.com (smtp3.smtp.bt.com [217.32.164.138]) by core3.amsl.com (Postfix) with ESMTP id 972DD3A6904 for ; Thu, 7 Apr 2011 04:45:48 -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); Thu, 7 Apr 2011 12:47:31 +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); Thu, 7 Apr 2011 12:47:31 +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 1302176849997; Thu, 7 Apr 2011 12:47:29 +0100 Received: from MUT.jungle.bt.co.uk ([10.73.211.28]) by bagheera.jungle.bt.co.uk (8.13.5/8.12.8) with ESMTP id p37BlP3G026341; Thu, 7 Apr 2011 12:47:27 +0100 Message-Id: <201104071147.p37BlP3G026341@bagheera.jungle.bt.co.uk> X-Mailer: QUALCOMM Windows Eudora Version 7.1.0.9 Date: Wed, 06 Apr 2011 22:16:18 +0100 To: "Mcdysan, David E" From: Bob Briscoe In-Reply-To: References: <201104060039.48305.mirja.kuehlewind@ikr.uni-stuttgart.de> 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: 07 Apr 2011 11:47:31.0611 (UTC) FILETIME=[93FE86B0:01CBF519] Cc: "conex@ietf.org" Subject: Re: [conex] comments/suggestions on draft-ietf-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: Thu, 07 Apr 2011 11:45:51 -0000 David, I had meant to say earlier that I don't think=20 self-congestion is a good term for this concept.=20 The words self-congestion suggest your own=20 activity is congesting yourself, which might mean=20 you are overloading your own DSL line, or your own home network. When your own actions have taken you out of=20 contract with a policy enforcing device which is=20 discarding your traffic, that is not congestion=20 so congestion is a bad word to use for it. And=20 the discards are only indirectly caused by the=20 self, so self is not a good word either. Policy-drop or policy-induced discard or some=20 similar phrase would be a better term for this. I'm currently offline, so I cannot search to see=20 if there is already a commonly used term for this. Bob At 14:56 06/04/2011, Mcdysan, David E wrote: >Hi Mirja, > >Thank you for the feedback. > >A definition of "self congestion" was added to section 1 of use-cases-01 >as follows: > > Congestion takes two distinct forms. The first results from the > interaction of traffic from one set of users with traffic from other > users, causing in a reduction in service (a cost) for all of them. > the second, often referred to as "self-congestion", occurs when an > increase in traffic from a single user causes that user to suffer a > worse service (for instance because their traffic is being "shaped" > by their ISP, or because they have an excessively large buffer in > their home router). ConEx is principally interested in the first > form of congestion since it involves informing those other users of > the impact you expect to have on them. > >Editorially, possibly the description of these terms should be in >definitions, but as I mentioned in Prague this was new text that the wg >should review. > >Thanks, > >Dave > >On Tuesday4/5/11 6:39 PM, "Mirja Kuehlewind" > wrote: > > >Hi Dave, > > > >thx, I really like your text proposal. I guess the term 'self congestion' > >needs to be defined as well...? But otherwise this text make the use case > >very clear to me! > > > >Mirja > > > > > >On Monday 04 April 2011 14:07:13 Mcdysan, David E wrote: > >> As I mentioned in the status presentation last Thursday, I planned to > >>send > >> a paragraph to the conex wg list with proposed text for an additional > >> paragraph to be placed at the end of section 5.1. > >> > >> I am responding to point 1 Alissas' Email on this subject, since I= think > >> her note summarizes wg consensus on this topic well. (Also note that > >>this > >> closely aligns with the text cited from the reference [Bauer09]). > >> > >> The remainder of section 6 relating to this topic would be removed,= with > >> discussion required to determine whether the wg sees value in keeping > >> section 6.2 (possibly in an Appendix), or removing that as well. The > >> formulation of this approach by Toby helped me better understand conex, > >> but if that is not wg consensus, then so be it. > >> > >> "Traffic measurements over time scales longer than that of > >> policers/shapers involving conex information can be used to adjust the > >> token bucket parameters of these policers and adjust parameters of > >> shapers. These longer time scale conex related measurements can also > >> provide other uses [Bauer09, pg.18-19], such as; achieve better > >> understanding user traffic requirements, provide a better basis for > >> planning investments, enable better service customization, or achieve > >> better matching of costs and usage. When measurement is done in a > >>network > >> element that implements a shaper, the amount which self congestion > >> contributes to overall congestion may be estimated for similar uses. > >>These > >> traffic management techniques employing conex information may help > >>address > >> the challenging problem where a small percentage of users (e.g., 20%) > >> generate a large portion of the traffic (e.g., 80%) [Varian09]. " > >> > >> > >> Also, based upon some misunderstanding of terminology that was apparent > >>on > >> the list, I propose that the RFC 2475 definition of "shaper" be added= to > >> section 3.1, existing approaches. > >> > >> Thanks, > >> > >> Dave > >> > >> On Friday3/25/11 4:37 AM, "Alissa Cooper" wrote: > >> >In my reading of section 6, it presents 2 distinct issues: > >> > > >> >1) Long time scales: A use case (or perhaps a few variations on the > >> >same use case) for the conex signal as currently described in= abstract- > >> >mech, wherein conex helps network operators to manage congestion, > >> >conduct traffic shaping, and capacity-plan over periods much longer > >> >than network speeds (e.g., minutes/hours/days/months) > >> > > >> >2) Shaper presence: A suggestion that conex could signal the presence > >> >of a traffic shaper (in addition to or instead of how the conex signal > >> >is currently described in abstract-mech) and a use case for such a > >> >signal wherein recipients of the signal can use it to request that > >> >sender's traffic shaper parameters be altered > >> > > >> >I think the issue of long time scales, which is described in the > >> >introductory text to section 6 and briefly in 6.1 and 6.2, could > >> >instead be succinctly addressed by adding a couple of sentences to 5.1 > >> >to explain that the use of conex for managing "heavy" users could > >> >occur over shorter or longer time scales and could have the added > >> >affect of helping operators to do longer-term capacity planning. > >> > > >> >Signaling the presence of a shaper seems to me to be a separate animal > >> >altogether, and one over which there is some obvious disagreement. But > >> >at least half of section 6 seems to be devoted to the idea that > >> >operators would have uses for aggregating conex information over long > >> >time frames, and I think those uses could be incorporated with a brief > >> >addition to section 5.1. > >> > > >> >Alissa > >> > > >> >On Mar 17, 2011, at 12:25 PM, Mcdysan, David E wrote: > >> >> Hi Nandita, > >> >> > >> >> A few responses to your questions on the new section in line below > >> >> prefixed by DM which were previously posted to the list that I > >> >> believe (at least partially) address your comments. > >> >> > >> >> I propose that the working group work toward how to organize/merge/ > >> >> move the new text better into the existing outline. > >> >> > >> >> Thanks, > >> >> > >> >> Dave > >> >> > >> >> From: Nandita Dukkipati > >> >> Date: Thu, 17 Mar 2011 03:28:25 -0400 > >> >> To: Toby Moncaster , John Leslie , > >> >> Bob Briscoe , "Woundy, Richard" > >> >> >> >> > >> >> >, David McDysan > >> >> > >> >> Cc: "conex@ietf.org" > >> >> Subject: comments/suggestions on draft-ietf-conex-concepts-uses-01 > >> >> > >> >> On reading the latest draft, I have three high level comments > >> >> roughly in the following order of importance- > >> >> > >> >> *** > >> >> Statistical Multiplexing over different timescales. > >> >> This reads like a rambling story. I have read and re-read it, and I > >> >> am still left wondering - > >> >> * What is _the_ main point? How about starting the section by > >> >> stating your main point upfront as opposed leaving it to the reader > >> >> to figure it out. > >> >> > >> >> DM - From my 3/10/11 on the list > >> >> > >> >> 1) A few "heavy" users generate most of the traffic and service > >> >> providers > >> >> want to better assign the cost (of provisioning an upgrade) for the > >> >> time > >> >> when congestion is anticipated to occur. Existing mechanisms, flat > >> >> rate, > >> >> bandwidth tier shapers, and usage tiers do not completely address= the > >> >> service provider objective and/or are not popular with users. > >> >> > >> >> 2) In some service provider networks shapers are implemented to > >> >> limit the > >> >> maximum bandwidth per user. Although overflow or marking in the > >>shaper > >> >> queue appears as congestion to the receiver, this "self-congestion" > >> >> differs from congestion of a shared resource since a remedy could be > >> >> to > >> >> indicate to the user that changing the shaper rate (i.e., "go > >>faster") > >> >> would alleviate "self-congestion." > >> >> > >> >> * Why and how is this use case distinct from that of traffic > >> >> management which already seems to have a broad scope? Is it really > >> >> distinct? > >> >> > >> >> DM - From my 3/11/11 post to the list > >> >> > >> >> Editorially, this (section 5.1) could be a place to state the > >> >> problem with an additional > >> >> reference to [Varian]. > >> >> > >> >> Editorially, bandwidth tier pricing could be added to section 3.1, > >> >> Existing approaches. > >> >> > >> >> I am now thinking that editorially a separate section is not a good > >> >> idea, > >> >> since the points can be merged into the existing outline, in at > >> >> least the > >> >> places mentioned above. > >> >> > >> >> I think adding that the use case needs to meet service provider > >> >> economic > >> >> congestion needs as well as be acceptable to users is an important > >> >> point > >> >> not in the current text. Traffic management (aka policing) may have > >> >> the > >> >> problem that it may not be popular with user. There has already been > >> >> negative feedback on the list regarding policing (IMO, Traffic > >> >> management > >> >> is a better term). > >> >> > >> >> > >> >> * [minor] Why not make this use case a part of Sec. 5? > >> >> > >> >> DM =AD the minutes recorded adding the agreement to add this as a= new > >> >> section. (A new subsection, and or merging thoughts with other use > >> >> cases (e.g., as suggested above) is what I believe the wg needs to > >> >> discuss. > >> >> > >> >> *** > >> >> Partial versus full deployment. > >> >> Clearly, it belongs to this draft. But why is it a part of use > >> >> cases? Looks out of place to me. > >> >> > >> >> *** > >> >> Sec 4. Exposing congestion. > >> >> =B3We argue that congestion needs.... More specifically, a network > >> >> needs to be able to measure how much congestion any particular > >> >> traffic expects to cause between the monitoring point in the network > >> >> and the destination ("rest-of-path congestion"). This would be a new > >> >> capability.=B2 > >> >> > >> >> Could you add more clarity and explanation on why local congestion > >> >> information at any given node is not sufficient. Why does a node > >> >> require congestion information from a monitoring point to the > >> >> destination to be able to manage its own congestion? A succinct > >> >> explanation and/or an example will go a long way. > >> >> > >> >> _______________________________________________ > >> >> conex mailing list > >> >> conex@ietf.org > >> >> https://www.ietf.org/mailman/listinfo/conex > >> > >> _______________________________________________ > >> conex mailing list > >> conex@ietf.org > >> https://www.ietf.org/mailman/listinfo/conex > > > > > > > >-- > >------------------------------------------------------------------- > >Dipl.-Ing. Mirja K=FChlewind > >Institute of Communication Networks and Computer Engineering (IKR) > >University of Stuttgart, Germany > >Pfaffenwaldring 47, D-70569 Stuttgart > > > >tel: +49(0)711/685-67973 > >email: mirja.kuehlewind@ikr.uni-stuttgart.de > >web: www.ikr.uni-stuttgart.de > >------------------------------------------------------------------- > >_______________________________________________ >conex mailing list >conex@ietf.org >https://www.ietf.org/mailman/listinfo/conex ________________________________________________________________ Bob Briscoe, BT Innovate & Design =20 From bob.briscoe@bt.com Thu Apr 7 07:33:46 2011 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 08A5428C11F for ; Thu, 7 Apr 2011 07:33:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.481 X-Spam-Level: X-Spam-Status: No, score=-3.481 tagged_above=-999 required=5 tests=[AWL=0.118, 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 GFe7xfAEkPQU for ; Thu, 7 Apr 2011 07:33:44 -0700 (PDT) Received: from smtp1.smtp.bt.com (smtp1.smtp.bt.com [217.32.164.137]) by core3.amsl.com (Postfix) with ESMTP id 5B47628C0F4 for ; Thu, 7 Apr 2011 07:33: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); Thu, 7 Apr 2011 15:35:27 +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); Thu, 7 Apr 2011 15:35:25 +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 1302186924340; Thu, 7 Apr 2011 15:35:24 +0100 Received: from MUT.jungle.bt.co.uk ([10.73.211.28]) by bagheera.jungle.bt.co.uk (8.13.5/8.12.8) with ESMTP id p37EZMK8026909; Thu, 7 Apr 2011 15:35:22 +0100 Message-Id: <201104071435.p37EZMK8026909@bagheera.jungle.bt.co.uk> X-Mailer: QUALCOMM Windows Eudora Version 7.1.0.9 Date: Thu, 07 Apr 2011 15:35:22 +0100 To: Toby Moncaster From: Bob Briscoe In-Reply-To: <004001cbf3a5$02b6a9f0$0823fdd0$@com> References: <004001cbf3a5$02b6a9f0$0823fdd0$@com> 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: 07 Apr 2011 14:35:25.0579 (UTC) FILETIME=[088C0DB0:01CBF531] Cc: conex@ietf.org Subject: Re: [conex] my personal views on draft-ietf-conex-concepts-uses 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, 07 Apr 2011 14:33:46 -0000 Toby, (& Mirja, John, Georgios) I want to take one step back before deciding=20 whether to split this into two (and if so, how to split it). Firstly, in Prague, we identified two very=20 different things that can both be ambiguously called use-cases: a) Uses to which ConEx can be put (traffic=20 management, incentivising scavenger, differential QoS, etc) b) Deployment arrangements (the single network=20 scenario in the charter, mobile, data centre, etc) When you suggest we should remove discussion of=20 use-cases, you seem to be talking about removing=20 a). Correct? I want to argue that a) should be=20 in, but b) should be cut-down - mostly to a list of pointers to other= docs... The co-authors who were in Prague (Rich, David &=20 I) got together and did a similar 'drains up'=20 exercise on the structure of this doc. Firstly,=20 we realised that the doc should start with high=20 level material similar to that used in early ConEx BoFs etc. In particular: - Rich Woundy did a presentation at the GIIC=20 workshop on capacity sharing that listed what=20 Comcast's fairshare could do, but also what it=20 could not do and what ConEx provided (slide 13 of=20 http://giic.org/pdf/GIIC-CapShare-01-Woundy-Comcast.pdf). - Alissa Cooper's presentation at the IETF ConEx=20 BoF had a good list of ConEx benefits (last slide=20 here: ). We came up with the following elements that need=20 to be articulated, whether in one or in more=20 documents. I've embellished the list with numbers=20 that refer to existing sections in conex-concepts-uses-01 A. The Apparent Problems (1 & tba) & the Underlying Problem (tba) B. Misconceptions (tba) and problems with other approaches (incl Rich's= list) C. ConEx Concepts (2, 5.3) and what ConEx is not (tba) D. ConEx Uses & Benefits (5.1, 5.2, 5.4 & Alissa's list) E. Deployment arrangements (5.5 & tba) F. Potential Issues (7) If we have anything about deployment=20 arrangements, we have to make space to describe=20 and motivate the components (but at much higher=20 level than in conex-abstract-mech). So, for deployment arrangements, I see two possible alternatives: i) A rudimentary section: - a very high level discription of the components=20 in abstract-mech and where they would be placed=20 in the charter deployment arrangement - one sentence bullets describing other=20 deployment arrangements, with refs to other docs for each. ii) An extremely rudimentary section: - one sentence bullets describing other=20 deployment arrangements, with refs to other docs=20 for each (including someone writing another doc about the chartered= scenario). On balance, I prefer i), to make this document=20 sufficiently self-contained. But I'm aware it=20 will make the doc a couple of pages longer. Bob At 16:20 05/04/2011, Toby Moncaster wrote: >Content-Type: multipart/alternative; > boundary=3D"----=3D_NextPart_000_0041_01CBF3AD.647B3900" >Content-Language: en-gb > >Hi All, > >As I am no longer editor of=20 >draft-ietf-conex-concepts-uses I can express my=20 >views on the document as an individual (rather=20 >than as the representative of the of the co-authors). > >Having had a thorough re-think about how best to=20 >progress ConEx through the IETF, I have come to=20 >the conclusion that the current draft is failing=20 >because it tries to do too much for a single=20 >document. In its current form, the document is=20 >doing two things. It seeks to explain the=20 >rationale of ConEx and it tries to give a list=20 >of use cases where ConEx seems to add most=20 >value. I now think these two parts can=92t exist=20 >in a single document since the latter tends to=20 >distract attention from the former. > >Marcelo ad Nandita have lofty ambitions for this=20 >document, which should serve as the ambassador=20 >for ConEx. This should be the document that=20 >silences our critics, or at least shows them=20 >that their fears about ConEx are unfounded. It=20 >should also act to enthuse the developer, vendor=20 >and operator communities to start working on=20 >ConEx and thus start the ball rolling for eventual deployment. > >So my proposal to the new editing team is as follows. >=B7 Re-write the introduction of the=20 >draft to provide a clear motivation for ConEx >=B7 Write a section explaining what Conex=20 >is and (importantly) what it isn=92t. This needs=20 >to contrast it to alternative approaches (such=20 >as over-provisioning) and show how those alternative approaches are flawed. >=B7 Then have a short section using a=20 >single network deployment as an example of how=20 >ConEx can operate (for instance, using ConEx as=20 >a mechanism to control the usage of a=20 >resource-constrained shared network such as=20 >those that are provided for students on=20 >university campuses). This should be explained=20 >in terms of familiar concepts (the approach=20 >taken in [policing freedom], where the policer=20 >is described in terms of a token bucket). >=B7 Then give a detailed use case for the=20 >=93charter scenario=94 of partial deployment with=20 >only sender and sender=92s network ConEx-enabled.=20 >This needs to show how (for instance) the=20 >sender=92s network can use ConEx to ensure that=20 >user=92s are not contributing to local congestion=20 >and are thus not causing other users to suffer a degradation in service. >=B7 Finally have a complete section on=20 >partial deployment models (the third bullet on=20 >Bob=92s list). This would look at the different=20 >arrangements of networks (sender, core,=20 >receiver), what each network needs to do about=20 >conex and what advantages it gets through being conex aware. > >Such a document would best be called =93ConEx=20 >Concepts and Motivations=94. By limiting the use=20 >cases described in the document it allows people=20 >to focus on what ConEx is actually doing and how=20 >it works. Until they understand that, there is=20 >no point trying to convince them of the huge=20 >range of uses to which it can be put. > >Then we can create a separate document bringing=20 >together all the other use cases and=20 >incorporating some of the individual work that=20 >has been contributed to ConEx. That document can=20 >be published a bit later than the other one and=20 >it can then assume that people are able to understand ConEx properly. >_______________________________________________ >conex mailing list >conex@ietf.org >https://www.ietf.org/mailman/listinfo/conex ________________________________________________________________ Bob Briscoe, BT Innovate & Design=20 From john@jlc.net Thu Apr 7 08:20:45 2011 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 E553B28C0F8 for ; Thu, 7 Apr 2011 08:20:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.551 X-Spam-Level: X-Spam-Status: No, score=-106.551 tagged_above=-999 required=5 tests=[AWL=0.048, 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 CLrykqh5AjIG for ; Thu, 7 Apr 2011 08:20:43 -0700 (PDT) Received: from mailhost.jlc.net (mailhost.jlc.net [199.201.159.4]) by core3.amsl.com (Postfix) with ESMTP id 0AB2728C0E6 for ; Thu, 7 Apr 2011 08:20:43 -0700 (PDT) Received: by mailhost.jlc.net (Postfix, from userid 104) id C50AE33C27; Thu, 7 Apr 2011 11:22:27 -0400 (EDT) Date: Thu, 7 Apr 2011 11:22:27 -0400 From: John Leslie To: Bob Briscoe Message-ID: <20110407152227.GJ24474@verdi> References: <004001cbf3a5$02b6a9f0$0823fdd0$@com> <201104071435.p37EZMK8026909@bagheera.jungle.bt.co.uk> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <201104071435.p37EZMK8026909@bagheera.jungle.bt.co.uk> User-Agent: Mutt/1.4.1i Cc: conex@ietf.org Subject: [conex] Splitting concepts-uses 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, 07 Apr 2011 15:20:46 -0000 Bob Briscoe wrote: > > I want to take one step back before deciding > whether to split this into two (and if so, how to split it). > > Firstly, in Prague, we identified two very > different things that can both be ambiguously called use-cases: > > a) Uses to which ConEx can be put (traffic management, > incentivising scavenger, differential QoS, etc) This is what we've been calling use cases. > b) Deployment arrangements (the single network scenario > in the charter, mobile, data centre, etc) This we've been calling usage scenarios. > When you suggest we should remove discussion of > use-cases, you seem to be talking about removing > a). Correct? Yes. > I want to argue that a) should be in, but b) should be cut-down - > mostly to a list of pointers to other docs... Feel free to argue... > The co-authors who were in Prague (Rich, David & I) > got together and did a similar 'drains up' > exercise on the structure of this doc. Firstly, > we realised that the doc should start with high > level material similar to that used in early > ConEx BoFs etc. In particular: > > - Rich Woundy did a presentation at the GIIC > workshop on capacity sharing that listed what > Comcast's fairshare could do, but also what it > could not do and what ConEx provided (slide 13 of > http://giic.org/pdf/GIIC-CapShare-01-Woundy-Comcast.pdf). That's pretty heavy on Comcast's current FairShare... It does list Advantages of re-ECN over FairShare: - Re-ECN enables end-to-end congestion management - Re-ECN enables end-to-end congestion management - Re-ECN signals the presence of congestion to user applications and to all devices on the network path - Re-ECN enables additional user and/or application responses to congestion - Re-ECN enables DDoSmitigation and other capabilities I'm not sure these are the correct things to list in conex-concepts In particular, we as authors agreed to defer discussion of DDoS. > - Alissa Cooper's presentation at the IETF ConEx > BoF had a good list of ConEx benefits (last slide > here: ). That lists Benefits of congestion exposure: - Incentivizes reduced-congestion protocols like LEDBAT - Exposes congestion end-to-end, across network borders - Provides transparancy at every network node - Also good for capacity planning - Avoids cat-and-mouse with apps developers, other drawbacks of application-based approaches - Any-to-any traffic: enables Internet-wide solutions This doesn't strike me as the best introduction for conex-concepts. It lists where we'd like to get, rather than actual concepts of what we propose to do. > We came up with the following elements that need > to be articulated, whether in one or in more > documents. I've embellished the list with numbers > that refer to existing sections in conex-concepts-uses-01 > > A. The Apparent Problems (1 & tba) & the Underlying Problem (tba) I think the apparent & underlying probems are better understood today than they were at IETF-77. We need to elaborate what we hope to _do_. > B. Misconceptions (tba) and problems with other approaches (incl > Rich's list) I know you disagree with me here, but experience suggests that a list of "misconceptions" is an _excellent_ way to lose an audience. > C. ConEx Concepts (2, 5.3) and what ConEx is not (tba) We need to get text talking about what ConEx _is_. The universe of what ConEx is-not is just too large. (Again, I know you disagree with me.) > D. ConEx Uses & Benefits (5.1, 5.2, 5.4 & Alissa's list) This is getting beyond what Toby proposed. I'm waiting for your argument why it needs to be in the same document... > E. Deployment arrangements (5.5 & tba) > F. Potential Issues (7) (No comment.) > If we have anything about deployment > arrangements, we have to make space to describe > and motivate the components (but at much higher > level than in conex-abstract-mech). > > So, for deployment arrangements, I see two possible alternatives: > > i) A rudimentary section: > - a very high level discription of the components > in abstract-mech and where they would be placed > in the charter deployment arrangement > - one sentence bullets describing other > deployment arrangements, with refs to other docs for each. > > ii) An extremely rudimentary section: > - one sentence bullets describing other > deployment arrangements, with refs to other docs > for each (including someone writing another doc > about the chartered scenario). > > On balance, I prefer i), to make this document > sufficiently self-contained. But I'm aware it > will make the doc a couple of pages longer. I think we agree that deployment scenarios don't belong in the first-document Toby proposes. (Did I miss your argument why Uses & Benefits _do_ belong there?) -- John Leslie From richard_woundy@cable.comcast.com Thu Apr 7 09:06:01 2011 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 E5FF928C0F1 for ; Thu, 7 Apr 2011 09:06:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.173 X-Spam-Level: X-Spam-Status: No, score=-106.173 tagged_above=-999 required=5 tests=[AWL=2.290, BAYES_00=-2.599, HELO_EQ_MODEMCABLE=0.768, HOST_EQ_MODEMCABLE=1.368, RCVD_IN_DNSWL_HI=-8, 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 aM5TqtrOPSTS for ; Thu, 7 Apr 2011 09:06:00 -0700 (PDT) Received: from pacdcimo01.cable.comcast.com (PacdcIMO01.cable.comcast.com [24.40.8.145]) by core3.amsl.com (Postfix) with ESMTP id 38A2E3A67FB for ; Thu, 7 Apr 2011 09:06:00 -0700 (PDT) Received: from ([24.40.55.42]) by pacdcimo01.cable.comcast.com with ESMTP with TLS id 5503620.119008943; Thu, 07 Apr 2011 12:07:41 -0400 Received: from PACDCEXMB05.cable.comcast.com ([fe80::a5b0:e5c4:df1b:2367]) by PACDCEXHUB01.cable.comcast.com ([fe80::d1e7:20b5:9b63:21a6%12]) with mapi id 14.01.0270.001; Thu, 7 Apr 2011 12:07:37 -0400 From: "Woundy, Richard" To: John Leslie , Bob Briscoe Thread-Topic: [conex] Splitting concepts-uses Thread-Index: AQHL9TehdPh+kc1Gt0aR8lu0lv7UIZRSiehw Date: Thu, 7 Apr 2011 16:07:37 +0000 Message-ID: <1CA25301D2219F40B3AA37201F0EACD1134DE84A@PACDCEXMB05.cable.comcast.com> References: <004001cbf3a5$02b6a9f0$0823fdd0$@com> <201104071435.p37EZMK8026909@bagheera.jungle.bt.co.uk> <20110407152227.GJ24474@verdi> In-Reply-To: <20110407152227.GJ24474@verdi> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [147.191.223.245] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "conex@ietf.org" Subject: Re: [conex] Splitting concepts-uses 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, 07 Apr 2011 16:06:02 -0000 Do we have an agreed path forward on what to do with the concepts-use cases= document? I worry that we do not. > That's pretty heavy on Comcast's current FairShare... In Conex, I have tried to avoid spending too much time discussing FairShare= . The purpose of Conex isn't to promote FairShare, in my view. However, FairShare is documented (RFC 6057), and goes about as far as one c= an go with congestion management using current specifications and deploymen= ts. So it is one baseline to defend why we need Conex. But that's why I wanted to include Alissa's discussion of other alternative= s (throwing capacity at the problem, and volume-based / rate-based / applic= ation-based approaches). > In particular, we as authors agreed to defer discussion of DDoS. Yes, that was always understood. -- Rich -----Original Message----- From: conex-bounces@ietf.org [mailto:conex-bounces@ietf.org] On Behalf Of J= ohn Leslie Sent: Thursday, April 07, 2011 11:22 AM To: Bob Briscoe Cc: conex@ietf.org Subject: [conex] Splitting concepts-uses Bob Briscoe wrote: >=20 > I want to take one step back before deciding=20 > whether to split this into two (and if so, how to split it). >=20 > Firstly, in Prague, we identified two very=20 > different things that can both be ambiguously called use-cases: >=20 > a) Uses to which ConEx can be put (traffic management, > incentivising scavenger, differential QoS, etc) This is what we've been calling use cases. > b) Deployment arrangements (the single network scenario > in the charter, mobile, data centre, etc) This we've been calling usage scenarios. > When you suggest we should remove discussion of=20 > use-cases, you seem to be talking about removing=20 > a). Correct? Yes. > I want to argue that a) should be in, but b) should be cut-down - > mostly to a list of pointers to other docs... Feel free to argue... > The co-authors who were in Prague (Rich, David & I) > got together and did a similar 'drains up'=20 > exercise on the structure of this doc. Firstly,=20 > we realised that the doc should start with high=20 > level material similar to that used in early > ConEx BoFs etc. In particular: >=20 > - Rich Woundy did a presentation at the GIIC=20 > workshop on capacity sharing that listed what=20 > Comcast's fairshare could do, but also what it=20 > could not do and what ConEx provided (slide 13 of=20 > http://giic.org/pdf/GIIC-CapShare-01-Woundy-Comcast.pdf). That's pretty heavy on Comcast's current FairShare... It does list Advantages of re-ECN over FairShare: - Re-ECN enables end-to-end congestion management=20 - Re-ECN enables end-to-end congestion management=20 - Re-ECN signals the presence of congestion to user=20 applications and to all devices on the network path=20 - Re-ECN enables additional user and/or application=20 responses to congestion=20 - Re-ECN enables DDoSmitigation and other capabilities I'm not sure these are the correct things to list in conex-concepts In particular, we as authors agreed to defer discussion of DDoS. > - Alissa Cooper's presentation at the IETF ConEx=20 > BoF had a good list of ConEx benefits (last slide=20 > here: ). That lists Benefits of congestion exposure: - Incentivizes reduced-congestion protocols like LEDBAT - Exposes congestion end-to-end, across network borders - Provides transparancy at every network node - Also good for capacity planning - Avoids cat-and-mouse with apps developers, other drawbacks of application-based approaches - Any-to-any traffic: enables Internet-wide solutions This doesn't strike me as the best introduction for conex-concepts. It lists where we'd like to get, rather than actual concepts of what we propose to do. > We came up with the following elements that need=20 > to be articulated, whether in one or in more=20 > documents. I've embellished the list with numbers=20 > that refer to existing sections in conex-concepts-uses-01 >=20 > A. The Apparent Problems (1 & tba) & the Underlying Problem (tba) I think the apparent & underlying probems are better understood today than they were at IETF-77. We need to elaborate what we hope to _do_. > B. Misconceptions (tba) and problems with other approaches (incl > Rich's list) I know you disagree with me here, but experience suggests that a list of "misconceptions" is an _excellent_ way to lose an audience. > C. ConEx Concepts (2, 5.3) and what ConEx is not (tba) We need to get text talking about what ConEx _is_. The universe of what ConEx is-not is just too large. (Again, I know you disagree with me.) > D. ConEx Uses & Benefits (5.1, 5.2, 5.4 & Alissa's list) This is getting beyond what Toby proposed. I'm waiting for your argument why it needs to be in the same document... > E. Deployment arrangements (5.5 & tba) > F. Potential Issues (7) (No comment.) > If we have anything about deployment=20 > arrangements, we have to make space to describe=20 > and motivate the components (but at much higher=20 > level than in conex-abstract-mech). >=20 > So, for deployment arrangements, I see two possible alternatives: >=20 > i) A rudimentary section: > - a very high level discription of the components=20 > in abstract-mech and where they would be placed=20 > in the charter deployment arrangement > - one sentence bullets describing other=20 > deployment arrangements, with refs to other docs for each. >=20 > ii) An extremely rudimentary section: > - one sentence bullets describing other=20 > deployment arrangements, with refs to other docs=20 > for each (including someone writing another doc > about the chartered scenario). >=20 > On balance, I prefer i), to make this document=20 > sufficiently self-contained. But I'm aware it=20 > will make the doc a couple of pages longer. I think we agree that deployment scenarios don't belong in the first-document Toby proposes. (Did I miss your argument why Uses & Benefits _do_ belong there?) -- John Leslie _______________________________________________ conex mailing list conex@ietf.org https://www.ietf.org/mailman/listinfo/conex From toby@moncaster.com Thu Apr 7 09:26:49 2011 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 A9BB128C121 for ; Thu, 7 Apr 2011 09:26:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.158 X-Spam-Level: X-Spam-Status: No, score=-2.158 tagged_above=-999 required=5 tests=[AWL=0.091, 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 tj13802szPzv for ; Thu, 7 Apr 2011 09:26:48 -0700 (PDT) Received: from moutng.kundenserver.de (moutng.kundenserver.de [212.227.126.187]) by core3.amsl.com (Postfix) with ESMTP id DC6B728C102 for ; Thu, 7 Apr 2011 09:26:47 -0700 (PDT) Received: from TobysHP (host81-158-50-55.range81-158.btcentralplus.com [81.158.50.55]) by mrelayeu.kundenserver.de (node=mreu2) with ESMTP (Nemesis) id 0LwVC7-1PrQZj26Sl-018GKU; Thu, 07 Apr 2011 18:28:25 +0200 From: "Toby Moncaster" To: "'Bob Briscoe'" References: <004001cbf3a5$02b6a9f0$0823fdd0$@com> <201104071435.p37EZMK8026909@bagheera.jungle.bt.co.uk> In-Reply-To: <201104071435.p37EZMK8026909@bagheera.jungle.bt.co.uk> Date: Thu, 7 Apr 2011 17:28:21 +0100 Message-ID: <004a01cbf540$d032e6e0$7098b4a0$@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: Acv1MQjMgbC9/YTHQceAVqfQGpzimwACmecw Content-Language: en-gb X-Provags-ID: V02:K0:X7ImNSNP9iNYG0w9UxwhYxV9un1aEzg1UHxivyBd7k+ bPSzuznRoYOprBGBMXNndY1hxfb8LMZLE0URDb3uMYiBzVDfJI FRKRXjogmiQtRs6TA3jLvfkApa/EYuwF1BtPV4aTNutuesPIFt pXg/ExfBx258hAMcGIU5qdM5d0zavE7yZOnfMga6ZvSeNFz9TC Ux3J8+FLhLMkAkDd8hXhrpd5kyb6/yUVOTye6UdHvA= Cc: conex@ietf.org Subject: Re: [conex] my personal views on draft-ietf-conex-concepts-uses 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, 07 Apr 2011 16:26:49 -0000 I am purposely replying to Bob's email, not to John's response. I will reply to John's email separately... > -----Original Message----- > From: Bob Briscoe [mailto:bob.briscoe@bt.com] > Sent: 07 April 2011 15:35 > To: Toby Moncaster > Cc: conex@ietf.org; Mirja Kuehlewind; John Leslie; Georgios Karagiannis > Subject: Re: [conex] my personal views on draft-ietf-conex-concepts- > uses > > Toby, (& Mirja, John, Georgios) > > I want to take one step back before deciding > whether to split this into two (and if so, how to split it). I am (I think) arguing that we need to concentrate on doing ConEx in little chunks (the horrid MBA phrase seems to be baby steps). We have a very restrictive charter at present, reflecting a good deal of scepticism on the part of the IESG. So what we need to do is show how even that limited form of ConEx is worth doing, not by arguing for philanthropic deployment, but by showing how (say) an ISP can better manage their own customers' traffic > > Firstly, in Prague, we identified two very > different things that can both be ambiguously called use-cases: > a) Uses to which ConEx can be put (traffic > management, incentivising scavenger, differential QoS, etc) > b) Deployment arrangements (the single network > scenario in the charter, mobile, data centre, etc) This confusion has been reigning for some months now, and there have been discussions about it in the past. Really the charter should be changed. Currently it says: " It is believed that the CONEX mechanism will be useful as a generative technology that can be applied as a key element of congestion management solutions in a wide variety of use cases. 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." Which uses "use case" where it should say "usage scenario" or similar. > > When you suggest we should remove discussion of > use-cases, you seem to be talking about removing > a). Correct? I want to argue that a) should be > in, but b) should be cut-down - mostly to a list of pointers to other > docs... I am arguing that we should remove large parts of a), just keeping sufficient to be able to accurately explain how ConEx achieves things that are beyond current capabilities. I was envisaging doing this using 1 or 2 simple scenarios (such as FairShare vs ConEx policing). As things stand, we already have lots of "use cases" for ConEx that go beyond the current charter. And lots that are being deferred to individual drafts, etc. What this document has to do is convince people that deploying the limited version of ConEx enshrined within the charter will give them a benefit. Telling them "it would be brilliant if lots of networks all did this" is translated by some people into "it must be useless if only 1 network does this" > > The co-authors who were in Prague (Rich, David & > I) got together and did a similar 'drains up' > exercise on the structure of this doc. Firstly, > we realised that the doc should start with high > level material similar to that used in early ConEx BoFs etc. I would sound a definite note of caution. In total it took 3 BoFs and countless fringe meetings to get ConEx chartered. That does suggest that at least some of the explaining we did early on was confusing people. I believe the current draft (the one the WGCs are so worried by) suffers from over-explaining in many cases. All too often we have tended to respond to a few people questioning what we meant by adding more detail, tightening up a definition or adding new text. What we need to do is get to the bottom of why so many people are confused in the first place. > In > particular: > - Rich Woundy did a presentation at the GIIC > workshop on capacity sharing that listed what > Comcast's fairshare could do, but also what it > could not do and what ConEx provided (slide 13 of > http://giic.org/pdf/GIIC-CapShare-01-Woundy-Comcast.pdf). > - Alissa Cooper's presentation at the IETF ConEx > BoF had a good list of ConEx benefits (last slide > here: ). The problem with both these lists is that they don't make it clear why you want to do those things. Some people who claim over-provisioning is the panacea for everything might wonder why you want to do this at all, as they argue congestion is a transient event that can be effectively ignored. > > > We came up with the following elements that need > to be articulated, whether in one or in more > documents. I've embellished the list with numbers > that refer to existing sections in conex-concepts-uses-01 > > A. The Apparent Problems (1 & tba) & the Underlying Problem (tba) > B. Misconceptions (tba) and problems with other approaches (incl Rich's > list) > C. ConEx Concepts (2, 5.3) and what ConEx is not (tba) We need to be careful how we express "what ConEx is not". There are two elements to these: avoiding misconceptions about what it is and providing people with a familiar framework to enable them to grasp what ConEx actually is. The second aspect is useful. Clearly the description of the policer in [policing freedom] allowed a lot of people to understand what we were describing. But the list of misconceptions is so long that trying to cover all of them would be impossible. Much better to pick a couple and stick to them. I would argue the biggest ones (that keep cropping up) are: "ConEx needs per-flow state" and "ConEx requires every node to be updated". > D. ConEx Uses & Benefits (5.1, 5.2, 5.4 & Alissa's list) > E. Deployment arrangements (5.5 & tba) > F. Potential Issues (7) > > If we have anything about deployment > arrangements, we have to make space to describe > and motivate the components (but at much higher > level than in conex-abstract-mech). > > So, for deployment arrangements, I see two possible alternatives: > > i) A rudimentary section: > - a very high level discription of the components > in abstract-mech and where they would be placed > in the charter deployment arrangement > - one sentence bullets describing other > deployment arrangements, with refs to other docs for each. > > ii) An extremely rudimentary section: > - one sentence bullets describing other > deployment arrangements, with refs to other docs > for each (including someone writing another doc about the chartered > scenario). > > On balance, I prefer i), to make this document > sufficiently self-contained. But I'm aware it > will make the doc a couple of pages longer. I agree that i) seems the more sensible of the two approaches, but keeping the high level descriptions to a line each, keeping it all as brief as possible and limiting the amount of referencing to what is essential. > > > Bob > > > At 16:20 05/04/2011, Toby Moncaster wrote: > >Content-Type: multipart/alternative; > > boundary="----=_NextPart_000_0041_01CBF3AD.647B3900" > >Content-Language: en-gb > > > >Hi All, > > > >As I am no longer editor of > >draft-ietf-conex-concepts-uses I can express my > >views on the document as an individual (rather > >than as the representative of the of the co-authors). > > > >Having had a thorough re-think about how best to > >progress ConEx through the IETF, I have come to > >the conclusion that the current draft is failing > >because it tries to do too much for a single > >document. In its current form, the document is > >doing two things. It seeks to explain the > >rationale of ConEx and it tries to give a list > >of use cases where ConEx seems to add most > >value. I now think these two parts can't exist > >in a single document since the latter tends to > >distract attention from the former. > > > >Marcelo ad Nandita have lofty ambitions for this > >document, which should serve as the ambassador > >for ConEx. This should be the document that > >silences our critics, or at least shows them > >that their fears about ConEx are unfounded. It > >should also act to enthuse the developer, vendor > >and operator communities to start working on > >ConEx and thus start the ball rolling for eventual deployment. > > > >So my proposal to the new editing team is as follows. > >. Re-write the introduction of the > >draft to provide a clear motivation for ConEx > >. Write a section explaining what Conex > >is and (importantly) what it isn't. This needs > >to contrast it to alternative approaches (such > >as over-provisioning) and show how those alternative approaches are > flawed. > >. Then have a short section using a > >single network deployment as an example of how > >ConEx can operate (for instance, using ConEx as > >a mechanism to control the usage of a > >resource-constrained shared network such as > >those that are provided for students on > >university campuses). This should be explained > >in terms of familiar concepts (the approach > >taken in [policing freedom], where the policer > >is described in terms of a token bucket). > >. Then give a detailed use case for the > >"charter scenario" of partial deployment with > >only sender and sender's network ConEx-enabled. > >This needs to show how (for instance) the > >sender's network can use ConEx to ensure that > >user's are not contributing to local congestion > >and are thus not causing other users to suffer a degradation in > service. > >. Finally have a complete section on > >partial deployment models (the third bullet on > >Bob's list). This would look at the different > >arrangements of networks (sender, core, > >receiver), what each network needs to do about > >conex and what advantages it gets through being conex aware. > > > >Such a document would best be called "ConEx > >Concepts and Motivations". By limiting the use > >cases described in the document it allows people > >to focus on what ConEx is actually doing and how > >it works. Until they understand that, there is > >no point trying to convince them of the huge > >range of uses to which it can be put. > > > >Then we can create a separate document bringing > >together all the other use cases and > >incorporating some of the individual work that > >has been contributed to ConEx. That document can > >be published a bit later than the other one and > >it can then assume that people are able to understand ConEx properly. > >_______________________________________________ > >conex mailing list > >conex@ietf.org > >https://www.ietf.org/mailman/listinfo/conex > > ________________________________________________________________ > Bob Briscoe, BT Innovate & Design From toby@moncaster.com Thu Apr 7 09:27:29 2011 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 05D4928C111 for ; Thu, 7 Apr 2011 09:27:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.162 X-Spam-Level: X-Spam-Status: No, score=-2.162 tagged_above=-999 required=5 tests=[AWL=0.087, 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 yP-oB2eAZad1 for ; Thu, 7 Apr 2011 09:27:27 -0700 (PDT) Received: from moutng.kundenserver.de (moutng.kundenserver.de [212.227.17.10]) by core3.amsl.com (Postfix) with ESMTP id A050528C102 for ; Thu, 7 Apr 2011 09:27:27 -0700 (PDT) Received: from TobysHP (host81-158-50-55.range81-158.btcentralplus.com [81.158.50.55]) by mrelayeu.kundenserver.de (node=mreu4) with ESMTP (Nemesis) id 0MJZaJ-1Q5xCo1SqB-0036uT; Thu, 07 Apr 2011 18:29:09 +0200 From: "Toby Moncaster" To: "'John Leslie'" , "'Bob Briscoe'" References: <004001cbf3a5$02b6a9f0$0823fdd0$@com> <201104071435.p37EZMK8026909@bagheera.jungle.bt.co.uk> <20110407152227.GJ24474@verdi> In-Reply-To: <20110407152227.GJ24474@verdi> Date: Thu, 7 Apr 2011 17:29:06 +0100 Message-ID: <004b01cbf540$ea67bbd0$bf373370$@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: Acv1N58D76ksBxSoQJS9Raba2rAFyQABKEgg Content-Language: en-gb X-Provags-ID: V02:K0:Lj/wp6Zo4Gg7yEkKQ5cT1uX3zcqwpbTncIs2Qf0IcAN Hho0MwXhFtn88gc5QOL7n+XPtPqePwMfVy5b/WzFVfrqNS2Gzv aVaQTGiIoyrU6HL3F1d+LJDcSFDJba9VGyIOFd7k8aFYMUgbj0 x271kdI9Op5BUulV5tBMQggRenReBo5dDLuXf9jCwOkBG2n27S YgJF04BOsmCgWsAm52OlmnAdA5YmaWTeOQ3aJys++o= Cc: conex@ietf.org Subject: Re: [conex] Splitting concepts-uses 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, 07 Apr 2011 16:27:29 -0000 And a reply to John's email > -----Original Message----- > From: conex-bounces@ietf.org [mailto:conex-bounces@ietf.org] On Behalf > Of John Leslie > Sent: 07 April 2011 16:22 > To: Bob Briscoe > Cc: conex@ietf.org > Subject: [conex] Splitting concepts-uses > > Bob Briscoe wrote: > > > > I want to take one step back before deciding > > whether to split this into two (and if so, how to split it). > > > > Firstly, in Prague, we identified two very > > different things that can both be ambiguously called use-cases: > > > > a) Uses to which ConEx can be put (traffic management, > > incentivising scavenger, differential QoS, etc) > > This is what we've been calling use cases. > > > b) Deployment arrangements (the single network scenario > > in the charter, mobile, data centre, etc) > > This we've been calling usage scenarios. The confusion seems to have crept in because of bad wording in the charter (which confuses the two concepts) > > > When you suggest we should remove discussion of > > use-cases, you seem to be talking about removing > > a). Correct? > > Yes. See other reply -- I want to remove large chunks of this but not all. > > > I want to argue that a) should be in, but b) should be cut-down - > > mostly to a list of pointers to other docs... > > Feel free to argue... > > > The co-authors who were in Prague (Rich, David & I) > > got together and did a similar 'drains up' > > exercise on the structure of this doc. Firstly, > > we realised that the doc should start with high > > level material similar to that used in early > > ConEx BoFs etc. In particular: > > > > - Rich Woundy did a presentation at the GIIC > > workshop on capacity sharing that listed what > > Comcast's fairshare could do, but also what it > > could not do and what ConEx provided (slide 13 of > > http://giic.org/pdf/GIIC-CapShare-01-Woundy-Comcast.pdf). > > That's pretty heavy on Comcast's current FairShare... One could use that as an example of what ConEx isn't perhaps. It does nicely fit the charter scenario... > > It does list Advantages of re-ECN over FairShare: > - Re-ECN enables end-to-end congestion management > - Re-ECN enables end-to-end congestion management > - Re-ECN signals the presence of congestion to user > applications and to all devices on the network path > - Re-ECN enables additional user and/or application > responses to congestion > - Re-ECN enables DDoSmitigation and other capabilities > > I'm not sure these are the correct things to list in conex-concepts > In particular, we as authors agreed to defer discussion of DDoS. The decision to defer DDoS was ratified by the WG and Marcelo... The problem with this list is that it is not telling you /why/ you want to do those things. > > > - Alissa Cooper's presentation at the IETF ConEx > > BoF had a good list of ConEx benefits (last slide > > here: ). > > That lists Benefits of congestion exposure: > - Incentivizes reduced-congestion protocols like LEDBAT > - Exposes congestion end-to-end, across network borders > - Provides transparancy at every network node > - Also good for capacity planning > - Avoids cat-and-mouse with apps developers, other > drawbacks of application-based approaches > - Any-to-any traffic: enables Internet-wide solutions > > This doesn't strike me as the best introduction for conex-concepts. > It lists where we'd like to get, rather than actual concepts of what > we propose to do. That list (or parts of it at any rate) may be useful, particularly in the conclusions to the document. We can also put it upside down and use these as ways that current approaches are flawed. > > > We came up with the following elements that need > > to be articulated, whether in one or in more > > documents. I've embellished the list with numbers > > that refer to existing sections in conex-concepts-uses-01 > > > > A. The Apparent Problems (1 & tba) & the Underlying Problem (tba) > > I think the apparent & underlying probems are better understood > today than they were at IETF-77. We need to elaborate what we hope > to _do_. > > > B. Misconceptions (tba) and problems with other approaches (incl > > Rich's list) > > I know you disagree with me here, but experience suggests that a > list of "misconceptions" is an _excellent_ way to lose an audience. We certainly don't want this to turn into something that can be misconstrued as "getting at" any group in the IETF. The problem with trying to list the misconceptions is that there are so many of them. This also applies to listing "what ConEx isn't" > > > C. ConEx Concepts (2, 5.3) and what ConEx is not (tba) > > We need to get text talking about what ConEx _is_. The universe > of what ConEx is-not is just too large. (Again, I know you disagree > with me.) See other reply > > > D. ConEx Uses & Benefits (5.1, 5.2, 5.4 & Alissa's list) Benefits might belong, but putting in too many use cases just seems to distract and lead to people getting the wrong end of the stick. > > This is getting beyond what Toby proposed. I'm waiting for your > argument why it needs to be in the same document... > > > E. Deployment arrangements (5.5 & tba) > > F. Potential Issues (7) These need to be looked at again in detail. If the document is meant to be about motivations for ConEx, then this section needs to be about the opposite (demotivations as you might put it) > > (No comment.) > > > If we have anything about deployment > > arrangements, we have to make space to describe > > and motivate the components (but at much higher > > level than in conex-abstract-mech). > > > > So, for deployment arrangements, I see two possible alternatives: > > > > i) A rudimentary section: > > - a very high level discription of the components > > in abstract-mech and where they would be placed > > in the charter deployment arrangement > > - one sentence bullets describing other > > deployment arrangements, with refs to other docs for each. > > > > ii) An extremely rudimentary section: > > - one sentence bullets describing other > > deployment arrangements, with refs to other docs > > for each (including someone writing another doc > > about the chartered scenario). > > > > On balance, I prefer i), to make this document > > sufficiently self-contained. But I'm aware it > > will make the doc a couple of pages longer. > > I think we agree that deployment scenarios don't belong in the > first-document Toby proposes. See other reply > > (Did I miss your argument why Uses & Benefits _do_ belong there?) > > -- > John Leslie > _______________________________________________ > conex mailing list > conex@ietf.org > https://www.ietf.org/mailman/listinfo/conex From karagian@cs.utwente.nl Thu Apr 7 11:54:51 2011 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 166923A69D1 for ; Thu, 7 Apr 2011 11:54:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.677 X-Spam-Level: X-Spam-Status: No, score=0.677 tagged_above=-999 required=5 tests=[AWL=-0.215, BAYES_00=-2.599, HELO_EQ_NL=0.55, HOST_EQ_NL=1.545, MIME_QP_LONG_LINE=1.396] 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 LbwmBdXaTscL for ; Thu, 7 Apr 2011 11:54:49 -0700 (PDT) Received: from denhaag.ewi.utwente.nl (denhaag.ewi.utwente.nl [130.89.10.11]) by core3.amsl.com (Postfix) with ESMTP id 433CA3A6A14 for ; Thu, 7 Apr 2011 11:54:48 -0700 (PDT) Received: from webmail.cs.utwente.nl (janus.ewi.utwente.nl [130.89.10.26]) by denhaag.ewi.utwente.nl (8.13.6/8.13.6) with SMTP id p37Ito5n005330; Thu, 7 Apr 2011 20:55:50 +0200 (MEST) Received: from 84.82.109.231 (auth. user karagian@imap1.ewi.utwente.nl) by webmail.cs.utwente.nl with HTTP; Thu, 07 Apr 2011 18:56:22 +0000 To: "Bob Briscoe" , "Toby Moncaster" Date: Thu, 07 Apr 2011 18:56:21 +0000 X-Mailer: IlohaMail/0.8.13 (On: webmail.cs.utwente.nl) Message-ID: In-Reply-To: <201104071435.p37EZMK8026909@bagheera.jungle.bt.co.uk> From: "Georgios Karagiannis" Bounce-To: "Georgios Karagiannis" Errors-To: "Georgios Karagiannis" MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable X-Scanned-By: MIMEDefang 2.52 on 130.89.10.11 X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-3.0rc3 (denhaag.ewi.utwente.nl [130.89.10.11]); Thu, 07 Apr 2011 20:56:00 +0200 (MEST) Cc: "conex@ietf.org" Subject: Re: [conex] my personal views on draft-ietf-conex-concepts-uses 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, 07 Apr 2011 18:54:51 -0000 Hi Bob We could have two drafts: In my opinion it is important to have a draft that motivates the need of the solutions provided by Conex. In order to accomplish this it is important, in my opinion, to explain and compare at least: * a current end to end use case/scenario that uses per flow state in network entities that are able of providing policing and auditing/dropping features * a Conex end to end use case/scenario that provides similar policing and auditing/dropping features. Another draft that describes possible Conex use cases/scenarios. Best regards, Georgios On 4/7/2011, "Bob Briscoe" wrote: >Toby, (& Mirja, John, Georgios) > >I want to take one step back before deciding=20 >whether to split this into two (and if so, how to split it). > >Firstly, in Prague, we identified two very=20 >different things that can both be ambiguously called use-cases: >a) Uses to which ConEx can be put (traffic=20 >management, incentivising scavenger, differential QoS, etc) >b) Deployment arrangements (the single network=20 >scenario in the charter, mobile, data centre, etc) > >When you suggest we should remove discussion of=20 >use-cases, you seem to be talking about removing=20 >a). Correct? I want to argue that a) should be=20 >in, but b) should be cut-down - mostly to a list of pointers to other docs..= . > >The co-authors who were in Prague (Rich, David &=20 >I) got together and did a similar 'drains up'=20 >exercise on the structure of this doc. Firstly,=20 >we realised that the doc should start with high=20 >level material similar to that used in early ConEx BoFs etc. In particular: >- Rich Woundy did a presentation at the GIIC=20 >workshop on capacity sharing that listed what=20 >Comcast's fairshare could do, but also what it=20 >could not do and what ConEx provided (slide 13 of=20 >http://giic.org/pdf/GIIC-CapShare-01-Woundy-Comcast.pdf). >- Alissa Cooper's presentation at the IETF ConEx=20 >BoF had a good list of ConEx benefits (last slide=20 >here: ). > > >We came up with the following elements that need=20 >to be articulated, whether in one or in more=20 >documents. I've embellished the list with numbers=20 >that refer to existing sections in conex-concepts-uses-01 > >A. The Apparent Problems (1 & tba) & the Underlying Problem (tba) >B. Misconceptions (tba) and problems with other approaches (incl Rich's list= ) >C. ConEx Concepts (2, 5.3) and what ConEx is not (tba) >D. ConEx Uses & Benefits (5.1, 5.2, 5.4 & Alissa's list) >E. Deployment arrangements (5.5 & tba) >F. Potential Issues (7) > >If we have anything about deployment=20 >arrangements, we have to make space to describe=20 >and motivate the components (but at much higher=20 >level than in conex-abstract-mech). > >So, for deployment arrangements, I see two possible alternatives: > >i) A rudimentary section: >- a very high level discription of the components=20 >in abstract-mech and where they would be placed=20 >in the charter deployment arrangement >- one sentence bullets describing other=20 >deployment arrangements, with refs to other docs for each. > >ii) An extremely rudimentary section: >- one sentence bullets describing other=20 >deployment arrangements, with refs to other docs=20 >for each (including someone writing another doc about the chartered scenario= ). > >On balance, I prefer i), to make this document=20 >sufficiently self-contained. But I'm aware it=20 >will make the doc a couple of pages longer. > > >Bob > > >At 16:20 05/04/2011, Toby Moncaster wrote: >>Content-Type: multipart/alternative; >> boundary=3D"----=3D_NextPart_000_0041_01CBF3AD.647B3900" >>Content-Language: en-gb >> >>Hi All, >> >>As I am no longer editor of=20 >>draft-ietf-conex-concepts-uses I can express my=20 >>views on the document as an individual (rather=20 >>than as the representative of the of the co-authors). >> >>Having had a thorough re-think about how best to=20 >>progress ConEx through the IETF, I have come to=20 >>the conclusion that the current draft is failing=20 >>because it tries to do too much for a single=20 >>document. In its current form, the document is=20 >>doing two things. It seeks to explain the=20 >>rationale of ConEx and it tries to give a list=20 >>of use cases where ConEx seems to add most=20 >>value. I now think these two parts can=92t exist=20 >>in a single document since the latter tends to=20 >>distract attention from the former. >> >>Marcelo ad Nandita have lofty ambitions for this=20 >>document, which should serve as the ambassador=20 >>for ConEx. This should be the document that=20 >>silences our critics, or at least shows them=20 >>that their fears about ConEx are unfounded. It=20 >>should also act to enthuse the developer, vendor=20 >>and operator communities to start working on=20 >>ConEx and thus start the ball rolling for eventual deployment. >> >>So my proposal to the new editing team is as follows. >>=B7 Re-write the introduction of the=20 >>draft to provide a clear motivation for ConEx >>=B7 Write a section explaining what Conex=20 >>is and (importantly) what it isn=92t. This needs=20 >>to contrast it to alternative approaches (such=20 >>as over-provisioning) and show how those alternative approaches are flawed. >>=B7 Then have a short section using a=20 >>single network deployment as an example of how=20 >>ConEx can operate (for instance, using ConEx as=20 >>a mechanism to control the usage of a=20 >>resource-constrained shared network such as=20 >>those that are provided for students on=20 >>university campuses). This should be explained=20 >>in terms of familiar concepts (the approach=20 >>taken in [policing freedom], where the policer=20 >>is described in terms of a token bucket). >>=B7 Then give a detailed use case for the=20 >>=93charter scenario=94 of partial deployment with=20 >>only sender and sender=92s network ConEx-enabled.=20 >>This needs to show how (for instance) the=20 >>sender=92s network can use ConEx to ensure that=20 >>user=92s are not contributing to local congestion=20 >>and are thus not causing other users to suffer a degradation in service. >>=B7 Finally have a complete section on=20 >>partial deployment models (the third bullet on=20 >>Bob=92s list). This would look at the different=20 >>arrangements of networks (sender, core,=20 >>receiver), what each network needs to do about=20 >>conex and what advantages it gets through being conex aware. >> >>Such a document would best be called =93ConEx=20 >>Concepts and Motivations=94. By limiting the use=20 >>cases described in the document it allows people=20 >>to focus on what ConEx is actually doing and how=20 >>it works. Until they understand that, there is=20 >>no point trying to convince them of the huge=20 >>range of uses to which it can be put. >> >>Then we can create a separate document bringing=20 >>together all the other use cases and=20 >>incorporating some of the individual work that=20 >>has been contributed to ConEx. That document can=20 >>be published a bit later than the other one and=20 >>it can then assume that people are able to understand ConEx properly. >>_______________________________________________ >>conex mailing list >>conex@ietf.org >>https://www.ietf.org/mailman/listinfo/conex > >________________________________________________________________ >Bob Briscoe, BT Innovate & Design=20 From lists@syshex.com Thu Apr 7 21:44:37 2011 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 853EE28C0FE for ; Thu, 7 Apr 2011 21:44:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.299 X-Spam-Level: X-Spam-Status: No, score=-3.299 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, MIME_8BIT_HEADER=0.3, 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 JSMFk70o5YOi for ; Thu, 7 Apr 2011 21:44:37 -0700 (PDT) Received: from mail-iy0-f172.google.com (mail-iy0-f172.google.com [209.85.210.172]) by core3.amsl.com (Postfix) with ESMTP id E646B28C0FA for ; Thu, 7 Apr 2011 21:44:36 -0700 (PDT) Received: by iye19 with SMTP id 19so3850573iye.31 for ; Thu, 07 Apr 2011 21:46:21 -0700 (PDT) Received: by 10.231.53.76 with SMTP id l12mr1737313ibg.119.1302237981374; Thu, 07 Apr 2011 21:46:21 -0700 (PDT) Received: from localhost ([136.187.112.83]) by mx.google.com with ESMTPS id i3sm1603290iby.6.2011.04.07.21.46.18 (version=TLSv1/SSLv3 cipher=OTHER); Thu, 07 Apr 2011 21:46:19 -0700 (PDT) Content-Type: text/plain; charset=UTF-8 From: =?utf-8?q?Jo=C3=A3o_Taveira_Ara=C3=BAjo?= To: conex In-reply-to: <20110407152227.GJ24474@verdi> References: <004001cbf3a5$02b6a9f0$0823fdd0$@com> <201104071435.p37EZMK8026909@bagheera.jungle.bt.co.uk> <20110407152227.GJ24474@verdi> Date: Fri, 08 Apr 2011 13:46:15 +0900 Message-Id: <1302235376-sup-2900@moonloop.syshex.com> User-Agent: Sup/0.11 Content-Transfer-Encoding: 8bit Subject: Re: [conex] Splitting concepts-uses 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, 08 Apr 2011 04:44:37 -0000 Hi, Excerpts from John Leslie's message of Fri Apr 08 00:22:27 +0900 2011: > > B. Misconceptions (tba) and problems with other approaches (incl > > Rich's list) > > I know you disagree with me here, but experience suggests that a > list of "misconceptions" is an _excellent_ way to lose an audience. I'd just like to emphasize this point and agree with John here. It doesn't seem appropriate to include a list of misconceptions on the very document responsible for introducing the concepts behind conex to an unfamiliar audience. Yes, there is a lot of baggage and experience from trying to explain re-ECN which gives us some intuition on what questions are most likely to come up, but we should use that to flesh out the text and make those points clear. In my opinion having a section on misconceptions feels like historical revisionism and would likely increase skepticism rather than instill confidence. Cheers, Joao. From philip.eardley@bt.com Fri Apr 8 02:39:10 2011 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 2C1613A69EE for ; Fri, 8 Apr 2011 02:39:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.645 X-Spam-Level: X-Spam-Status: No, score=-101.645 tagged_above=-999 required=5 tests=[AWL=-0.199, BAYES_00=-2.599, HELO_MISMATCH_COM=0.553, J_CHICKENPOX_51=0.6, 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 QRI7wcDM-k+g for ; Fri, 8 Apr 2011 02:39:08 -0700 (PDT) Received: from smtpe1.intersmtp.com (smtp62.intersmtp.COM [62.239.224.235]) by core3.amsl.com (Postfix) with ESMTP id 70C753A6971 for ; Fri, 8 Apr 2011 02:39:08 -0700 (PDT) Received: from EVMHT65-UKRD.domain1.systemhost.net (10.36.3.102) by RDW083A006ED62.smtp-e2.hygiene.service (10.187.98.11) with Microsoft SMTP Server (TLS) id 8.3.106.1; Fri, 8 Apr 2011 10:40:53 +0100 Received: from EMV65-UKRD.domain1.systemhost.net ([169.254.2.166]) by EVMHT65-UKRD.domain1.systemhost.net ([10.36.3.102]) with mapi; Fri, 8 Apr 2011 10:40:52 +0100 From: To: , Date: Fri, 8 Apr 2011 10:40:51 +0100 Thread-Topic: [conex] my personal views on draft-ietf-conex-concepts-uses Thread-Index: Acv1MQ7gvOOQPDr6THKGay8UCA5EiAAl3sdA Message-ID: <9510D26531EF184D9017DF24659BB87F3290214949@EMV65-UKRD.domain1.systemhost.net> References: <004001cbf3a5$02b6a9f0$0823fdd0$@com> <201104071435.p37EZMK8026909@bagheera.jungle.bt.co.uk> In-Reply-To: <201104071435.p37EZMK8026909@bagheera.jungle.bt.co.uk> Accept-Language: en-US, en-GB Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US, en-GB Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: conex@ietf.org Subject: Re: [conex] my personal views on draft-ietf-conex-concepts-uses 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, 08 Apr 2011 09:39:10 -0000 Personally I think another good starting point is the technical plenary pre= sentations [the tech plenary in Maastricht(?) on Economics of Congestion]. = As far as I could tell, the audience understood the argument, even if some = disagreed with it (and at some conex presentations my impression is that so= me people haven't understood the argument). I also think it is better to start by giving people the "main point" and th= en work through issues and arguments supporting it. By "main point" I mean = something like 'what idea are you trying to embed in the reader's brain'. 1= -2 pages motivational pages before the "main point" is ok, but lengthy disc= ussions of related work & issues before the "main point" will tend to mean = the average reader either gets bored or forgets what the main point is. (of= course the "average reader" here means me!). so for instance explain the u= se cases, then the comparison with today's approaches and perhaps why the u= se case is useful. I draw an analogy with writing a paper, where related w= ork (in my opinion) belongs at the end.=20 So what are the main point(s?=20 I think one main point is 'enabling IP nodes to see information about whole= -path congestion enables some very interesting uses'.=20 Another one is 'there is at least one reasonable deployment arrangement' (r= easonable meaning incremental and motivated for the party(s) deploying).=20 Each of these main points can be treated separately. Getting these main points right is quite tricky, and I'm not sure I got the= m right (but after some thought I didn't write 'conex has some interesting = use cases'). But i think it would help to decide what they are before writi= ng.=20 Another question is whether the doc is standalone? Can the reader to be ref= erred to the abstract mechanism i-d, or does this doc need to include conex= 's "protocol model", as per rfc4101: "a short description of the system in = overview form ... to answer three basic questions: 1. What problem is the p= rotocol trying to achieve? 2. What messages are being transmitted and what = do they mean? 3. What are the important, but unobvious, features of the pro= tocol?" If the doc is standalone, then a protocol model could be the first section Anyway, I suspect the authors have more than enough advice!! Best wishes Phil/ =20 -----Original Message----- From: conex-bounces@ietf.org [mailto:conex-bounces@ietf.org] On Behalf Of B= ob Briscoe Sent: 07 April 2011 15:35 To: Toby Moncaster Cc: conex@ietf.org Subject: Re: [conex] my personal views on draft-ietf-conex-concepts-uses Toby, (& Mirja, John, Georgios) I want to take one step back before deciding=20 whether to split this into two (and if so, how to split it). Firstly, in Prague, we identified two very=20 different things that can both be ambiguously called use-cases: a) Uses to which ConEx can be put (traffic=20 management, incentivising scavenger, differential QoS, etc) b) Deployment arrangements (the single network=20 scenario in the charter, mobile, data centre, etc) When you suggest we should remove discussion of=20 use-cases, you seem to be talking about removing=20 a). Correct? I want to argue that a) should be=20 in, but b) should be cut-down - mostly to a list of pointers to other docs.= .. The co-authors who were in Prague (Rich, David &=20 I) got together and did a similar 'drains up'=20 exercise on the structure of this doc. Firstly,=20 we realised that the doc should start with high=20 level material similar to that used in early ConEx BoFs etc. In particular: - Rich Woundy did a presentation at the GIIC=20 workshop on capacity sharing that listed what=20 Comcast's fairshare could do, but also what it=20 could not do and what ConEx provided (slide 13 of=20 http://giic.org/pdf/GIIC-CapShare-01-Woundy-Comcast.pdf). - Alissa Cooper's presentation at the IETF ConEx=20 BoF had a good list of ConEx benefits (last slide=20 here: ). We came up with the following elements that need=20 to be articulated, whether in one or in more=20 documents. I've embellished the list with numbers=20 that refer to existing sections in conex-concepts-uses-01 A. The Apparent Problems (1 & tba) & the Underlying Problem (tba) B. Misconceptions (tba) and problems with other approaches (incl Rich's lis= t) C. ConEx Concepts (2, 5.3) and what ConEx is not (tba) D. ConEx Uses & Benefits (5.1, 5.2, 5.4 & Alissa's list) E. Deployment arrangements (5.5 & tba) F. Potential Issues (7) If we have anything about deployment=20 arrangements, we have to make space to describe=20 and motivate the components (but at much higher=20 level than in conex-abstract-mech). So, for deployment arrangements, I see two possible alternatives: i) A rudimentary section: - a very high level discription of the components=20 in abstract-mech and where they would be placed=20 in the charter deployment arrangement - one sentence bullets describing other=20 deployment arrangements, with refs to other docs for each. ii) An extremely rudimentary section: - one sentence bullets describing other=20 deployment arrangements, with refs to other docs=20 for each (including someone writing another doc about the chartered scenari= o). On balance, I prefer i), to make this document=20 sufficiently self-contained. But I'm aware it=20 will make the doc a couple of pages longer. Bob At 16:20 05/04/2011, Toby Moncaster wrote: >Content-Type: multipart/alternative; > boundary=3D"----=3D_NextPart_000_0041_01CBF3AD.647B3900" >Content-Language: en-gb > >Hi All, > >As I am no longer editor of=20 >draft-ietf-conex-concepts-uses I can express my=20 >views on the document as an individual (rather=20 >than as the representative of the of the co-authors). > >Having had a thorough re-think about how best to=20 >progress ConEx through the IETF, I have come to=20 >the conclusion that the current draft is failing=20 >because it tries to do too much for a single=20 >document. In its current form, the document is=20 >doing two things. It seeks to explain the=20 >rationale of ConEx and it tries to give a list=20 >of use cases where ConEx seems to add most=20 >value. I now think these two parts can't exist=20 >in a single document since the latter tends to=20 >distract attention from the former. > >Marcelo ad Nandita have lofty ambitions for this=20 >document, which should serve as the ambassador=20 >for ConEx. This should be the document that=20 >silences our critics, or at least shows them=20 >that their fears about ConEx are unfounded. It=20 >should also act to enthuse the developer, vendor=20 >and operator communities to start working on=20 >ConEx and thus start the ball rolling for eventual deployment. > >So my proposal to the new editing team is as follows. >* Re-write the introduction of the=20 >draft to provide a clear motivation for ConEx >* Write a section explaining what Conex=20 >is and (importantly) what it isn't. This needs=20 >to contrast it to alternative approaches (such=20 >as over-provisioning) and show how those alternative approaches are flawed= . >* Then have a short section using a=20 >single network deployment as an example of how=20 >ConEx can operate (for instance, using ConEx as=20 >a mechanism to control the usage of a=20 >resource-constrained shared network such as=20 >those that are provided for students on=20 >university campuses). This should be explained=20 >in terms of familiar concepts (the approach=20 >taken in [policing freedom], where the policer=20 >is described in terms of a token bucket). >* Then give a detailed use case for the=20 >"charter scenario" of partial deployment with=20 >only sender and sender's network ConEx-enabled.=20 >This needs to show how (for instance) the=20 >sender's network can use ConEx to ensure that=20 >user's are not contributing to local congestion=20 >and are thus not causing other users to suffer a degradation in service. >* Finally have a complete section on=20 >partial deployment models (the third bullet on=20 >Bob's list). This would look at the different=20 >arrangements of networks (sender, core,=20 >receiver), what each network needs to do about=20 >conex and what advantages it gets through being conex aware. > >Such a document would best be called "ConEx=20 >Concepts and Motivations". By limiting the use=20 >cases described in the document it allows people=20 >to focus on what ConEx is actually doing and how=20 >it works. Until they understand that, there is=20 >no point trying to convince them of the huge=20 >range of uses to which it can be put. > >Then we can create a separate document bringing=20 >together all the other use cases and=20 >incorporating some of the individual work that=20 >has been contributed to ConEx. That document can=20 >be published a bit later than the other one and=20 >it can then assume that people are able to understand ConEx properly. >_______________________________________________ >conex mailing list >conex@ietf.org >https://www.ietf.org/mailman/listinfo/conex ________________________________________________________________ Bob Briscoe, BT Innovate & Design=20 _______________________________________________ conex mailing list conex@ietf.org https://www.ietf.org/mailman/listinfo/conex From philip.eardley@bt.com Fri Apr 8 08:00:55 2011 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 DFA553A6876 for ; Fri, 8 Apr 2011 08:00:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.339 X-Spam-Level: X-Spam-Status: No, score=-101.339 tagged_above=-999 required=5 tests=[AWL=-0.493, BAYES_00=-2.599, HELO_MISMATCH_COM=0.553, J_CHICKENPOX_51=0.6, J_CHICKENPOX_72=0.6, 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 zyBVTPZ33gYE for ; Fri, 8 Apr 2011 08:00:54 -0700 (PDT) Received: from smtpe1.intersmtp.com (smtp64.intersmtp.COM [62.239.224.237]) by core3.amsl.com (Postfix) with ESMTP id 234CE3A67CF for ; Fri, 8 Apr 2011 08:00:54 -0700 (PDT) Received: from EVMHT66-UKRD.domain1.systemhost.net (10.36.3.103) by RDW083A008ED64.smtp-e4.hygiene.service (10.187.98.13) with Microsoft SMTP Server (TLS) id 8.3.106.1; Fri, 8 Apr 2011 16:02:38 +0100 Received: from EMV65-UKRD.domain1.systemhost.net ([169.254.2.166]) by EVMHT66-UKRD.domain1.systemhost.net ([10.36.3.103]) with mapi; Fri, 8 Apr 2011 16:02:38 +0100 From: To: , Date: Fri, 8 Apr 2011 16:02:36 +0100 Thread-Topic: [conex] my personal views on draft-ietf-conex-concepts-uses Thread-Index: Acv1MQ7gvOOQPDr6THKGay8UCA5EiAAl3sdAAA0FzvA= Message-ID: <9510D26531EF184D9017DF24659BB87F32902FA7E3@EMV65-UKRD.domain1.systemhost.net> References: <004001cbf3a5$02b6a9f0$0823fdd0$@com> <201104071435.p37EZMK8026909@bagheera.jungle.bt.co.uk> <9510D26531EF184D9017DF24659BB87F3290214949@EMV65-UKRD.domain1.systemhost.net> In-Reply-To: <9510D26531EF184D9017DF24659BB87F3290214949@EMV65-UKRD.domain1.systemhost.net> Accept-Language: en-US, en-GB Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US, en-GB Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: conex@ietf.org Subject: Re: [conex] my personal views on draft-ietf-conex-concepts-uses 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, 08 Apr 2011 15:00:56 -0000 Also, in the Use Cases section, i think you should distinguish between the = use case and the side impacts. For example: Use case: On a fast timescale (msecs to secs) the operator uses conex infor= mation to inform its per-customer traffic management How: operator installs a token bucket policer per customer (rate of conex m= arks, burst size) Side impacts: end customer differentiates QoS amongst their apps (and conse= quently also motivates them to use scavenger) Benefits compared with current solutions: (Comcast Fairshare)=20 Phil/ -----Original Message----- From: conex-bounces@ietf.org [mailto:conex-bounces@ietf.org] On Behalf Of p= hilip.eardley@bt.com Sent: 08 April 2011 10:41 To: Briscoe,RJ,Bob,DES8 R; toby@moncaster.com Cc: conex@ietf.org Subject: Re: [conex] my personal views on draft-ietf-conex-concepts-uses Personally I think another good starting point is the technical plenary pre= sentations [the tech plenary in Maastricht(?) on Economics of Congestion]. = As far as I could tell, the audience understood the argument, even if some = disagreed with it (and at some conex presentations my impression is that so= me people haven't understood the argument). I also think it is better to start by giving people the "main point" and th= en work through issues and arguments supporting it. By "main point" I mean = something like 'what idea are you trying to embed in the reader's brain'. 1= -2 pages motivational pages before the "main point" is ok, but lengthy disc= ussions of related work & issues before the "main point" will tend to mean = the average reader either gets bored or forgets what the main point is. (of= course the "average reader" here means me!). so for instance explain the u= se cases, then the comparison with today's approaches and perhaps why the u= se case is useful. I draw an analogy with writing a paper, where related w= ork (in my opinion) belongs at the end.=20 So what are the main point(s?=20 I think one main point is 'enabling IP nodes to see information about whole= -path congestion enables some very interesting uses'.=20 Another one is 'there is at least one reasonable deployment arrangement' (r= easonable meaning incremental and motivated for the party(s) deploying).=20 Each of these main points can be treated separately. Getting these main points right is quite tricky, and I'm not sure I got the= m right (but after some thought I didn't write 'conex has some interesting = use cases'). But i think it would help to decide what they are before writi= ng.=20 Another question is whether the doc is standalone? Can the reader to be ref= erred to the abstract mechanism i-d, or does this doc need to include conex= 's "protocol model", as per rfc4101: "a short description of the system in = overview form ... to answer three basic questions: 1. What problem is the p= rotocol trying to achieve? 2. What messages are being transmitted and what = do they mean? 3. What are the important, but unobvious, features of the pro= tocol?" If the doc is standalone, then a protocol model could be the first section Anyway, I suspect the authors have more than enough advice!! Best wishes Phil/ =20 -----Original Message----- From: conex-bounces@ietf.org [mailto:conex-bounces@ietf.org] On Behalf Of B= ob Briscoe Sent: 07 April 2011 15:35 To: Toby Moncaster Cc: conex@ietf.org Subject: Re: [conex] my personal views on draft-ietf-conex-concepts-uses Toby, (& Mirja, John, Georgios) I want to take one step back before deciding=20 whether to split this into two (and if so, how to split it). Firstly, in Prague, we identified two very=20 different things that can both be ambiguously called use-cases: a) Uses to which ConEx can be put (traffic=20 management, incentivising scavenger, differential QoS, etc) b) Deployment arrangements (the single network=20 scenario in the charter, mobile, data centre, etc) When you suggest we should remove discussion of=20 use-cases, you seem to be talking about removing=20 a). Correct? I want to argue that a) should be=20 in, but b) should be cut-down - mostly to a list of pointers to other docs.= .. The co-authors who were in Prague (Rich, David &=20 I) got together and did a similar 'drains up'=20 exercise on the structure of this doc. Firstly,=20 we realised that the doc should start with high=20 level material similar to that used in early ConEx BoFs etc. In particular: - Rich Woundy did a presentation at the GIIC=20 workshop on capacity sharing that listed what=20 Comcast's fairshare could do, but also what it=20 could not do and what ConEx provided (slide 13 of=20 http://giic.org/pdf/GIIC-CapShare-01-Woundy-Comcast.pdf). - Alissa Cooper's presentation at the IETF ConEx=20 BoF had a good list of ConEx benefits (last slide=20 here: ). We came up with the following elements that need=20 to be articulated, whether in one or in more=20 documents. I've embellished the list with numbers=20 that refer to existing sections in conex-concepts-uses-01 A. The Apparent Problems (1 & tba) & the Underlying Problem (tba) B. Misconceptions (tba) and problems with other approaches (incl Rich's lis= t) C. ConEx Concepts (2, 5.3) and what ConEx is not (tba) D. ConEx Uses & Benefits (5.1, 5.2, 5.4 & Alissa's list) E. Deployment arrangements (5.5 & tba) F. Potential Issues (7) If we have anything about deployment=20 arrangements, we have to make space to describe=20 and motivate the components (but at much higher=20 level than in conex-abstract-mech). So, for deployment arrangements, I see two possible alternatives: i) A rudimentary section: - a very high level discription of the components=20 in abstract-mech and where they would be placed=20 in the charter deployment arrangement - one sentence bullets describing other=20 deployment arrangements, with refs to other docs for each. ii) An extremely rudimentary section: - one sentence bullets describing other=20 deployment arrangements, with refs to other docs=20 for each (including someone writing another doc about the chartered scenari= o). On balance, I prefer i), to make this document=20 sufficiently self-contained. But I'm aware it=20 will make the doc a couple of pages longer. Bob At 16:20 05/04/2011, Toby Moncaster wrote: >Content-Type: multipart/alternative; > boundary=3D"----=3D_NextPart_000_0041_01CBF3AD.647B3900" >Content-Language: en-gb > >Hi All, > >As I am no longer editor of=20 >draft-ietf-conex-concepts-uses I can express my=20 >views on the document as an individual (rather=20 >than as the representative of the of the co-authors). > >Having had a thorough re-think about how best to=20 >progress ConEx through the IETF, I have come to=20 >the conclusion that the current draft is failing=20 >because it tries to do too much for a single=20 >document. In its current form, the document is=20 >doing two things. It seeks to explain the=20 >rationale of ConEx and it tries to give a list=20 >of use cases where ConEx seems to add most=20 >value. I now think these two parts can't exist=20 >in a single document since the latter tends to=20 >distract attention from the former. > >Marcelo ad Nandita have lofty ambitions for this=20 >document, which should serve as the ambassador=20 >for ConEx. This should be the document that=20 >silences our critics, or at least shows them=20 >that their fears about ConEx are unfounded. It=20 >should also act to enthuse the developer, vendor=20 >and operator communities to start working on=20 >ConEx and thus start the ball rolling for eventual deployment. > >So my proposal to the new editing team is as follows. >* Re-write the introduction of the=20 >draft to provide a clear motivation for ConEx >* Write a section explaining what Conex=20 >is and (importantly) what it isn't. This needs=20 >to contrast it to alternative approaches (such=20 >as over-provisioning) and show how those alternative approaches are flawed= . >* Then have a short section using a=20 >single network deployment as an example of how=20 >ConEx can operate (for instance, using ConEx as=20 >a mechanism to control the usage of a=20 >resource-constrained shared network such as=20 >those that are provided for students on=20 >university campuses). This should be explained=20 >in terms of familiar concepts (the approach=20 >taken in [policing freedom], where the policer=20 >is described in terms of a token bucket). >* Then give a detailed use case for the=20 >"charter scenario" of partial deployment with=20 >only sender and sender's network ConEx-enabled.=20 >This needs to show how (for instance) the=20 >sender's network can use ConEx to ensure that=20 >user's are not contributing to local congestion=20 >and are thus not causing other users to suffer a degradation in service. >* Finally have a complete section on=20 >partial deployment models (the third bullet on=20 >Bob's list). This would look at the different=20 >arrangements of networks (sender, core,=20 >receiver), what each network needs to do about=20 >conex and what advantages it gets through being conex aware. > >Such a document would best be called "ConEx=20 >Concepts and Motivations". By limiting the use=20 >cases described in the document it allows people=20 >to focus on what ConEx is actually doing and how=20 >it works. Until they understand that, there is=20 >no point trying to convince them of the huge=20 >range of uses to which it can be put. > >Then we can create a separate document bringing=20 >together all the other use cases and=20 >incorporating some of the individual work that=20 >has been contributed to ConEx. That document can=20 >be published a bit later than the other one and=20 >it can then assume that people are able to understand ConEx properly. >_______________________________________________ >conex mailing list >conex@ietf.org >https://www.ietf.org/mailman/listinfo/conex ________________________________________________________________ Bob Briscoe, BT Innovate & Design=20 _______________________________________________ conex mailing list conex@ietf.org https://www.ietf.org/mailman/listinfo/conex _______________________________________________ conex mailing list conex@ietf.org https://www.ietf.org/mailman/listinfo/conex From bob.briscoe@bt.com Thu Apr 14 09:22:51 2011 Return-Path: X-Original-To: conex@ietfc.amsl.com Delivered-To: conex@ietfc.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfc.amsl.com (Postfix) with ESMTP id 1F70EE08A9 for ; Thu, 14 Apr 2011 09:22:51 -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 ([208.66.40.236]) by localhost (ietfc.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 8dkBDnQpr31r for ; Thu, 14 Apr 2011 09:22:50 -0700 (PDT) Received: from smtp1.smtp.bt.com (smtp1.smtp.bt.com [217.32.164.137]) by ietfc.amsl.com (Postfix) with ESMTP id 2C196E08A6 for ; Thu, 14 Apr 2011 09:22:47 -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); Thu, 14 Apr 2011 17:22:45 +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); Thu, 14 Apr 2011 17:22:45 +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 1302798163563; Thu, 14 Apr 2011 17:22:43 +0100 Received: from MUT.jungle.bt.co.uk ([10.142.194.76]) by bagheera.jungle.bt.co.uk (8.13.5/8.12.8) with ESMTP id p3EGMcDh032032; Thu, 14 Apr 2011 17:22:41 +0100 Message-Id: <201104141622.p3EGMcDh032032@bagheera.jungle.bt.co.uk> X-Mailer: QUALCOMM Windows Eudora Version 7.1.0.9 Date: Thu, 14 Apr 2011 17:22:30 +0100 To: Suresh KRISHNAN 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: 14 Apr 2011 16:22:45.0180 (UTC) FILETIME=[2FBD6FC0:01CBFAC0] Cc: ConEx IETF list Subject: [conex] DDoS and ConEx-awareness in the forwarding plane X-BeenThere: conex@ietf.org X-Mailman-Version: 2.1.12 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, 14 Apr 2011 16:22:51 -0000 Suresh, Something is bugging me about using a destination option as the ConEx v6 encoding. I'm worried about how many cycles it would take for general forwarding machinery (if suitably modified) to find the ConEx destination option. Let me explain why I'm asking... Recently, I have emphasised (for Mike Abrahamsson) that every queue is NOT intended to police traffic using ConEx info. However,... at the risk of confusing matters, one day ConEx info could OPTIONALLY be used at any queue - at least at any L3 queue. Not for policing, but for preferential discard. This should quite strongly insulate responsive traffic from unresponsive flooding traffic (see background below). I don't imagine ConEx awareness would be deployed in forwarding hardware until some time after ConEx had been deployed for more general traffic management purposes at the 'edge' of a network. But we ought not to forget the possibility of this when choosing the encoding. Bob Background ---------- Within a Diffserv class, discard order would be: 1. discard Non-ConEx traffic first* 2. then discard ConEx Unmarked 3. and lastly discard Re-Echo and Credit marked ConEx traffic. (* = leaving a min rate to prevent starvation of genuine non-ConEx sources) Reasoning: if DDoS was causing heavy congestion there would be lots of loss (or ECN marking). So well-behaved responsive sources would slow down and send most packets with a ConEx Re-Echo marking. An attack source by definition would not reduce its rate in response to the congestion. For ConEx marking, it could adopt three strategies (or a hybrid): a) not use ConEx (then the queue drops it by rule 1) b) use ConEx, but not Re-Echo congestion (then the queue drops it by rule 2) c) use ConEx properly Re-Echoing congestion (then the congestion policer quickly exhausts its allowance and the attack source gets strongly throttled). This Preferential Drop behaviour was documented in the re-ECN spec, although we never implemented a queue to evaluate it: Bob [PS. For the avoidance of doubt, this email is not about whether we should write up a DDoS use-case. It is about whether our choice of encoding would prevent us being able to use CoNEx against DDoS in future.] ________________________________________________________________ Bob Briscoe, BT Innovate & Design From suresh.krishnan@ericsson.com Fri Apr 15 16:00:27 2011 Return-Path: X-Original-To: conex@ietfc.amsl.com Delivered-To: conex@ietfc.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfc.amsl.com (Postfix) with ESMTP id 6AD6CE067E for ; Fri, 15 Apr 2011 16:00:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -104.799 X-Spam-Level: X-Spam-Status: No, score=-104.799 tagged_above=-999 required=5 tests=[AWL=1.800, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([208.66.40.236]) by localhost (ietfc.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id KEqqrtQJXCeD for ; Fri, 15 Apr 2011 16:00:26 -0700 (PDT) Received: from imr4.ericy.com (imr4.ericy.com [198.24.6.8]) by ietfc.amsl.com (Postfix) with ESMTP id CBC6FE0665 for ; Fri, 15 Apr 2011 16:00:26 -0700 (PDT) Received: from eusaamw0711.eamcs.ericsson.se ([147.117.20.178]) by imr4.ericy.com (8.14.3/8.14.3/Debian-9.1ubuntu1) with ESMTP id p3FN0Mmn010735; Fri, 15 Apr 2011 18:00:24 -0500 Received: from [142.133.10.107] (147.117.20.213) by eusaamw0711.eamcs.ericsson.se (147.117.20.179) with Microsoft SMTP Server id 8.3.137.0; Fri, 15 Apr 2011 19:00:17 -0400 Message-ID: <4DA8CDE6.8060405@ericsson.com> Date: Fri, 15 Apr 2011 18:59:50 -0400 From: Suresh Krishnan User-Agent: Thunderbird 2.0.0.24 (X11/20101027) MIME-Version: 1.0 To: Bob Briscoe References: <201104141622.p3EGMcDh032032@bagheera.jungle.bt.co.uk> In-Reply-To: <201104141622.p3EGMcDh032032@bagheera.jungle.bt.co.uk> Content-Type: text/plain; charset="ISO-8859-1"; format=flowed Content-Transfer-Encoding: 7bit Cc: ConEx IETF list Subject: Re: [conex] DDoS and ConEx-awareness in the forwarding plane X-BeenThere: conex@ietf.org X-Mailman-Version: 2.1.12 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, 15 Apr 2011 23:00:27 -0000 Hi Bob, On 11-04-14 12:22 PM, Bob Briscoe wrote: > Suresh, > > Something is bugging me about using a destination option as the ConEx > v6 encoding. I'm worried about how many cycles it would take for > general forwarding machinery (if suitably modified) to find the ConEx > destination option. Given the current number of destination options, it would not take a node too many extra cycles to find a destination option. What would worry me more is how this destination option search can be used against the *conex node* itself by sending it a datagram stuffed to the gills with destination options. In this regard, I share your concern. As I said before, destination options are not the best alternative. They are simply the best alternative with any chance of adoption. I have a possible mitigation in mind, but I need to verify if I am way out of line. What I was thinking about was to restrict the conex-aware senders to always insert the conex destination option as the first destination option if it is present at all. I think this would take care of all my DDoS concerns and your processing load concerns. What do you think. Thanks Suresh From swmike@swm.pp.se Fri Apr 15 20:51:00 2011 Return-Path: X-Original-To: conex@ietfc.amsl.com Delivered-To: conex@ietfc.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfc.amsl.com (Postfix) with ESMTP id E84D3E06C7 for ; Fri, 15 Apr 2011 20:51:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.59 X-Spam-Level: X-Spam-Status: No, score=-2.59 tagged_above=-999 required=5 tests=[AWL=0.009, BAYES_00=-2.599] Received: from mail.ietf.org ([208.66.40.236]) by localhost (ietfc.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id aOh9bht9nDi8 for ; Fri, 15 Apr 2011 20:51:00 -0700 (PDT) Received: from uplift.swm.pp.se (ipv6.swm.pp.se [IPv6:2a00:801::f]) by ietfc.amsl.com (Postfix) with ESMTP id 512C8E06C4 for ; Fri, 15 Apr 2011 20:51:00 -0700 (PDT) Received: by uplift.swm.pp.se (Postfix, from userid 501) id 4CFDD9C; Sat, 16 Apr 2011 05:50:58 +0200 (CEST) Received: from localhost (localhost [127.0.0.1]) by uplift.swm.pp.se (Postfix) with ESMTP id 46A019A; Sat, 16 Apr 2011 05:50:58 +0200 (CEST) Date: Sat, 16 Apr 2011 05:50:58 +0200 (CEST) From: Mikael Abrahamsson To: Bob Briscoe In-Reply-To: <201104141622.p3EGMcDh032032@bagheera.jungle.bt.co.uk> Message-ID: References: <201104141622.p3EGMcDh032032@bagheera.jungle.bt.co.uk> User-Agent: Alpine 2.00 (DEB 1167 2008-08-23) Organization: People's Front Against WWW MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Cc: ConEx IETF list Subject: Re: [conex] DDoS and ConEx-awareness in the forwarding plane X-BeenThere: conex@ietf.org X-Mailman-Version: 2.1.12 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, 16 Apr 2011 03:51:01 -0000 On Thu, 14 Apr 2011, Bob Briscoe wrote: > This should quite strongly insulate responsive traffic from unresponsive > flooding traffic (see background below). How would the node know that the traffic is responsive without keeping flow state? > 3. and lastly discard Re-Echo and Credit marked ConEx traffic. This makes sure all DDoS traffic will be marked as such. The people making these tools are not stupid (well, some are, but there are very clever people as well). -- Mikael Abrahamsson email: swmike@swm.pp.se From bob.briscoe@bt.com Sat Apr 16 04:11:06 2011 Return-Path: X-Original-To: conex@ietfc.amsl.com Delivered-To: conex@ietfc.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfc.amsl.com (Postfix) with ESMTP id DCAD6E066F for ; Sat, 16 Apr 2011 04:11:06 -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 ([208.66.40.236]) by localhost (ietfc.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Jj9H7+8bxdhE for ; Sat, 16 Apr 2011 04:11:06 -0700 (PDT) Received: from smtp4.smtp.bt.com (smtp4.smtp.bt.com [217.32.164.151]) by ietfc.amsl.com (Postfix) with ESMTP id 20891E066E for ; Sat, 16 Apr 2011 04:11:06 -0700 (PDT) Received: from i2kc06-ukbr.domain1.systemhost.net ([193.113.197.70]) by smtp4.smtp.bt.com with Microsoft SMTPSVC(6.0.3790.4675); Sat, 16 Apr 2011 12:11:05 +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); Sat, 16 Apr 2011 12:11:04 +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 1302952263429; Sat, 16 Apr 2011 12:11:03 +0100 Received: from MUT.jungle.bt.co.uk ([10.73.192.35]) by bagheera.jungle.bt.co.uk (8.13.5/8.12.8) with ESMTP id p3GBB2ZQ007060; Sat, 16 Apr 2011 12:11:02 +0100 Message-Id: <201104161111.p3GBB2ZQ007060@bagheera.jungle.bt.co.uk> X-Mailer: QUALCOMM Windows Eudora Version 7.1.0.9 Date: Sat, 16 Apr 2011 12:11:02 +0100 To: Suresh Krishnan From: Bob Briscoe In-Reply-To: <4DA8CDE6.8060405@ericsson.com> References: <201104141622.p3EGMcDh032032@bagheera.jungle.bt.co.uk> <4DA8CDE6.8060405@ericsson.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: 16 Apr 2011 11:11:04.0519 (UTC) FILETIME=[FA1A8570:01CBFC26] Cc: ConEx IETF list Subject: Re: [conex] DDoS and ConEx-awareness in the forwarding plane X-BeenThere: conex@ietf.org X-Mailman-Version: 2.1.12 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, 16 Apr 2011 11:11:07 -0000 Suresh, At 23:59 15/04/2011, Suresh Krishnan wrote: >Hi Bob, > >On 11-04-14 12:22 PM, Bob Briscoe wrote: >>Suresh, >>Something is bugging me about using a destination option as the >>ConEx v6 encoding. I'm worried about how many cycles it would take >>for general forwarding machinery (if suitably modified) to find the >>ConEx destination option. > >Given the current number of destination options, it would not take a >node too many extra cycles to find a destination option. What would >worry me more is how this destination option search can be used >against the *conex node* itself by sending it a datagram stuffed to >the gills with destination options. In this regard, I share your >concern. As I said before, destination options are not the best >alternative. They are simply the best alternative with any chance of adoption. > >I have a possible mitigation in mind, but I need to verify if I am >way out of line. What I was thinking about was to restrict the >conex-aware senders to always insert the conex destination option as >the first destination option if it is present at all. I think this >would take care of all my DDoS concerns and your processing load >concerns. What do you think. This would solve our problem, but potentially create a problem for someone else in the future who also needs to be first. However, as we're the first one to want to solve the problem of needing non-critical options that are readable at L3, I guess we have no other option (sorry for the pun). Bob >Thanks >Suresh ________________________________________________________________ Bob Briscoe, BT Innovate & Design From bob.briscoe@bt.com Sat Apr 16 04:37:27 2011 Return-Path: X-Original-To: conex@ietfc.amsl.com Delivered-To: conex@ietfc.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfc.amsl.com (Postfix) with ESMTP id 1B264E06B9 for ; Sat, 16 Apr 2011 04:37:27 -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 ([208.66.40.236]) by localhost (ietfc.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id vTRQ-8TeNsBR for ; Sat, 16 Apr 2011 04:37:26 -0700 (PDT) Received: from smtp1.smtp.bt.com (smtp1.smtp.bt.com [217.32.164.137]) by ietfc.amsl.com (Postfix) with ESMTP id 333E9E0694 for ; Sat, 16 Apr 2011 04:37:25 -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, 16 Apr 2011 12:37:25 +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, 16 Apr 2011 12:37:25 +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 1302953843507; Sat, 16 Apr 2011 12:37:23 +0100 Received: from MUT.jungle.bt.co.uk ([10.73.192.35]) by bagheera.jungle.bt.co.uk (8.13.5/8.12.8) with ESMTP id p3GBbKam007116; Sat, 16 Apr 2011 12:37:20 +0100 Message-Id: <201104161137.p3GBbKam007116@bagheera.jungle.bt.co.uk> X-Mailer: QUALCOMM Windows Eudora Version 7.1.0.9 Date: Sat, 16 Apr 2011 12:37:16 +0100 To: Mikael Abrahamsson From: Bob Briscoe In-Reply-To: References: <201104141622.p3EGMcDh032032@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: 16 Apr 2011 11:37:25.0060 (UTC) FILETIME=[A82DF040:01CBFC2A] Cc: ConEx IETF list Subject: Re: [conex] DDoS and ConEx-awareness in the forwarding plane X-BeenThere: conex@ietf.org X-Mailman-Version: 2.1.12 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, 16 Apr 2011 11:37:27 -0000 Mikael, At 04:50 16/04/2011, Mikael Abrahamsson wrote: >On Thu, 14 Apr 2011, Bob Briscoe wrote: > >>This should quite strongly insulate responsive traffic from >>unresponsive flooding traffic (see background below). > >How would the node know that the traffic is responsive without >keeping flow state? I explained how it works in the "(see background below)" part of the original posting that you have snipped. Nothing there needs flow state. Which part are you implying needs flow state? (note a robust audit function does require flow state, but the DDoS mitigation aspect of the protocol works without that). >>3. and lastly discard Re-Echo and Credit marked ConEx traffic. > >This makes sure all DDoS traffic will be marked as such. The people >making these tools are not stupid (well, some are, but there are >very clever people as well). Please re-read what I carefully wrote lower down the original posting. It caters for the cases where DDoS traffic is and is not marked correctly (cases b & c). In one case it gets caught at a bulk congestion policer. In the other case it gets caught at the bulk preferential drop in the queue. I don't mind valid criticism if you've read the material. (BTW, this went through a year of review by DDoS researchers before I brought it to the IETF.) Bob >-- >Mikael Abrahamsson email: swmike@swm.pp.se ________________________________________________________________ Bob Briscoe, BT Innovate & Design From toby@moncaster.com Sat Apr 16 06:13:57 2011 Return-Path: X-Original-To: conex@ietfc.amsl.com Delivered-To: conex@ietfc.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfc.amsl.com (Postfix) with ESMTP id B63A0E06AF for ; Sat, 16 Apr 2011 06:13:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.249 X-Spam-Level: X-Spam-Status: No, score=-2.249 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_DE=0.35] Received: from mail.ietf.org ([208.66.40.236]) by localhost (ietfc.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id pjVGcPLk-MSA for ; Sat, 16 Apr 2011 06:13:57 -0700 (PDT) Received: from moutng.kundenserver.de (moutng.kundenserver.de [212.227.126.171]) by ietfc.amsl.com (Postfix) with ESMTP id BE7EAE06A0 for ; Sat, 16 Apr 2011 06:13:56 -0700 (PDT) Received: from TobysHP (host86-136-244-185.range86-136.btcentralplus.com [86.136.244.185]) by mrelayeu.kundenserver.de (node=mreu0) with ESMTP (Nemesis) id 0Lfnn4-1PVixs437S-00pWDw; Sat, 16 Apr 2011 15:13:55 +0200 From: "Toby Moncaster" To: "'Bob Briscoe'" References: <201104141622.p3EGMcDh032032@bagheera.jungle.bt.co.uk> <201104161137.p3GBbKam007116@bagheera.jungle.bt.co.uk> In-Reply-To: <201104161137.p3GBbKam007116@bagheera.jungle.bt.co.uk> Date: Sat, 16 Apr 2011 14:13:52 +0100 Message-ID: <001101cbfc38$2238b160$66aa1420$@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: Acv8Kqu4ANihr5aUSlCFpyytORM9mQADIhlA Content-Language: en-gb X-Provags-ID: V02:K0:C2Q+3veN0jsdBu6CqE0lis4nfFze0UA9KOa+t3MaEQL +AebarJEgUrqVS80MZ0T7HJfC6EM0IMRnHGrJKdAB+IKXCzxaM v6QRkBYVI1gZKfHdOzMvYZxHwGItAxy4CO/KaK+P+i1jPvNL5h OQC9R364d+Yw4mx3JRljGfKlYDBQ3jWde25PsOZV1QMEqYnkbg S7GIFnGwMDlS+pHUbtf7M9w/RksiX79ZZLP35nLrdc= Cc: conex@ietf.org Subject: Re: [conex] DDoS and ConEx-awareness in the forwarding plane X-BeenThere: conex@ietf.org X-Mailman-Version: 2.1.12 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, 16 Apr 2011 13:13:57 -0000 Trying to recap: preferential drop gives priority to marked traffic. Also, ISPs are expected to be policing/rate limiting/whatever marked traffic at the access. This means any DDoS host can't send unmarked traffic (because it will get preferentially dropped as soon as a node starts to congest) and if it sends marked traffic it gets limited by the policing function at the access. Hence the impact of the DDoS traffic is significantly limited at the first congested node along the path... This requires no auditing, indeed the preferential drop actually reduces the need for audit since it provides an incentive to mark traffic during congestion... Is that a fair summary? Toby > -----Original Message----- > From: conex-bounces@ietf.org [mailto:conex-bounces@ietf.org] On Behalf > Of Bob Briscoe > Sent: 16 April 2011 12:37 > To: Mikael Abrahamsson > Cc: ConEx IETF list > Subject: Re: [conex] DDoS and ConEx-awareness in the forwarding plane > > Mikael, > > At 04:50 16/04/2011, Mikael Abrahamsson wrote: > >On Thu, 14 Apr 2011, Bob Briscoe wrote: > > > >>This should quite strongly insulate responsive traffic from > >>unresponsive flooding traffic (see background below). > > > >How would the node know that the traffic is responsive without > >keeping flow state? > > I explained how it works in the "(see background below)" part of the > original posting that you have snipped. > > Nothing there needs flow state. Which part are you implying needs flow > state? > > (note a robust audit function does require flow state, but the DDoS > mitigation aspect of the protocol works without that). > > > >>3. and lastly discard Re-Echo and Credit marked ConEx traffic. > > > >This makes sure all DDoS traffic will be marked as such. The people > >making these tools are not stupid (well, some are, but there are > >very clever people as well). > > Please re-read what I carefully wrote lower down the original posting. > > It caters for the cases where DDoS traffic is and is not marked > correctly (cases b & c). In one case it gets caught at a bulk > congestion policer. In the other case it gets caught at the bulk > preferential drop in the queue. > > I don't mind valid criticism if you've read the material. > > (BTW, this went through a year of review by DDoS researchers before I > brought it to the IETF.) > > > Bob > > > >-- > >Mikael Abrahamsson email: swmike@swm.pp.se > > ________________________________________________________________ > Bob Briscoe, BT Innovate & Design > > _______________________________________________ > conex mailing list > conex@ietf.org > https://www.ietf.org/mailman/listinfo/conex From swmike@swm.pp.se Sat Apr 16 06:33:21 2011 Return-Path: X-Original-To: conex@ietfc.amsl.com Delivered-To: conex@ietfc.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfc.amsl.com (Postfix) with ESMTP id 50E88E06B5 for ; Sat, 16 Apr 2011 06:33:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.591 X-Spam-Level: X-Spam-Status: No, score=-2.591 tagged_above=-999 required=5 tests=[AWL=0.008, BAYES_00=-2.599] Received: from mail.ietf.org ([208.66.40.236]) by localhost (ietfc.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id F+vAn2vrnCfI for ; Sat, 16 Apr 2011 06:33:20 -0700 (PDT) Received: from uplift.swm.pp.se (ipv6.swm.pp.se [IPv6:2a00:801::f]) by ietfc.amsl.com (Postfix) with ESMTP id BBBB9E06BF for ; Sat, 16 Apr 2011 06:33:20 -0700 (PDT) Received: by uplift.swm.pp.se (Postfix, from userid 501) id 00F3E9C; Sat, 16 Apr 2011 15:33:19 +0200 (CEST) Received: from localhost (localhost [127.0.0.1]) by uplift.swm.pp.se (Postfix) with ESMTP id F095F9A; Sat, 16 Apr 2011 15:33:19 +0200 (CEST) Date: Sat, 16 Apr 2011 15:33:19 +0200 (CEST) From: Mikael Abrahamsson To: Bob Briscoe In-Reply-To: <201104161137.p3GBbKam007116@bagheera.jungle.bt.co.uk> Message-ID: References: <201104141622.p3EGMcDh032032@bagheera.jungle.bt.co.uk> <201104161137.p3GBbKam007116@bagheera.jungle.bt.co.uk> User-Agent: Alpine 2.00 (DEB 1167 2008-08-23) Organization: People's Front Against WWW MIME-Version: 1.0 Content-Type: TEXT/PLAIN; format=flowed; charset=US-ASCII Cc: ConEx IETF list Subject: Re: [conex] DDoS and ConEx-awareness in the forwarding plane X-BeenThere: conex@ietf.org X-Mailman-Version: 2.1.12 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, 16 Apr 2011 13:33:21 -0000 On Sat, 16 Apr 2011, Bob Briscoe wrote: > Nothing there needs flow state. Which part are you implying needs flow > state? The part where the source isn't on a conex aware network and thus there is no ingress policer, but the node still uses Conex markings in the traffic it generates. > (BTW, this went through a year of review by DDoS researchers before I > brought it to the IETF.) Well, again, I might miss the point totally. I still don't understand how this is supposed to work in the real world. For me it's still a lot of hand-waving and high-level. -- Mikael Abrahamsson email: swmike@swm.pp.se From swmike@swm.pp.se Sat Apr 16 06:36:04 2011 Return-Path: X-Original-To: conex@ietfc.amsl.com Delivered-To: conex@ietfc.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfc.amsl.com (Postfix) with ESMTP id 0DE9DE06B5 for ; Sat, 16 Apr 2011 06:36:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.591 X-Spam-Level: X-Spam-Status: No, score=-2.591 tagged_above=-999 required=5 tests=[AWL=0.008, BAYES_00=-2.599] Received: from mail.ietf.org ([208.66.40.236]) by localhost (ietfc.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id H6XpWxLJVfHU for ; Sat, 16 Apr 2011 06:36:03 -0700 (PDT) Received: from uplift.swm.pp.se (ipv6.swm.pp.se [IPv6:2a00:801::f]) by ietfc.amsl.com (Postfix) with ESMTP id 78BCFE06B9 for ; Sat, 16 Apr 2011 06:36:03 -0700 (PDT) Received: by uplift.swm.pp.se (Postfix, from userid 501) id 9306B9C; Sat, 16 Apr 2011 15:36:02 +0200 (CEST) Received: from localhost (localhost [127.0.0.1]) by uplift.swm.pp.se (Postfix) with ESMTP id 8DF7A9A; Sat, 16 Apr 2011 15:36:02 +0200 (CEST) Date: Sat, 16 Apr 2011 15:36:02 +0200 (CEST) From: Mikael Abrahamsson To: Toby Moncaster In-Reply-To: <001101cbfc38$2238b160$66aa1420$@com> Message-ID: References: <201104141622.p3EGMcDh032032@bagheera.jungle.bt.co.uk> <201104161137.p3GBbKam007116@bagheera.jungle.bt.co.uk> <001101cbfc38$2238b160$66aa1420$@com> User-Agent: Alpine 2.00 (DEB 1167 2008-08-23) Organization: People's Front Against WWW MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Cc: conex@ietf.org Subject: Re: [conex] DDoS and ConEx-awareness in the forwarding plane X-BeenThere: conex@ietf.org X-Mailman-Version: 2.1.12 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, 16 Apr 2011 13:36:04 -0000 On Sat, 16 Apr 2011, Toby Moncaster wrote: > This means any DDoS host can't send unmarked traffic (because it will get > preferentially dropped as soon as a node starts to congest) RFC2827 is now over 10 years old, I would imagine the original document is a lot older. Still a lot of networks do not do basic ingress filtering towards their customers, enabling spoofed packets to get through. I'm sceptical that they would implement a conex policer, at least not all of them. -- Mikael Abrahamsson email: swmike@swm.pp.se From toby@moncaster.com Sat Apr 16 06:46:58 2011 Return-Path: X-Original-To: conex@ietfc.amsl.com Delivered-To: conex@ietfc.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfc.amsl.com (Postfix) with ESMTP id 58F4FE0710 for ; Sat, 16 Apr 2011 06:46:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.249 X-Spam-Level: X-Spam-Status: No, score=-2.249 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_DE=0.35] Received: from mail.ietf.org ([208.66.40.236]) by localhost (ietfc.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id e7VRgcRH4da0 for ; Sat, 16 Apr 2011 06:46:57 -0700 (PDT) Received: from moutng.kundenserver.de (moutng.kundenserver.de [212.227.126.171]) by ietfc.amsl.com (Postfix) with ESMTP id 6C98CE06B5 for ; Sat, 16 Apr 2011 06:46:57 -0700 (PDT) Received: from TobysHP (host86-136-244-185.range86-136.btcentralplus.com [86.136.244.185]) by mrelayeu.kundenserver.de (node=mrbap0) with ESMTP (Nemesis) id 0MZfTi-1QSCRd0Wz8-00L9kJ; Sat, 16 Apr 2011 15:46:55 +0200 From: "Toby Moncaster" To: "'Mikael Abrahamsson'" References: <201104141622.p3EGMcDh032032@bagheera.jungle.bt.co.uk> <201104161137.p3GBbKam007116@bagheera.jungle.bt.co.uk> <001101cbfc38$2238b160$66aa1420$@com> In-Reply-To: Date: Sat, 16 Apr 2011 14:46:52 +0100 Message-ID: <001201cbfc3c$be90f780$3bb2e680$@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: Acv8OzrNAYyAH0gjQCCYGe8jqtepWQAALFFg Content-Language: en-gb X-Provags-ID: V02:K0:XcskYuHwBs31OmmIuwxZuRXHkeOVtjHlw07iroNI/Be vdkKajzX16O3Kt/q6L8i1WW9pXzAqUzNiSaDFHZ0a6Q0fb/Yd0 cePHyfq54qj3doTHXniWKyf1nsaU1w4X9fcaLNJgAAHcVYmUKZ NVcB5SxxCWYTINih0LvvRGVQbP/kjptc9xlpMWjnFKzlq5fXoj +TLuTpGvyVdIiVS4VIbAKUtlC6Q+pJs3ayFl6SHMMw= Cc: conex@ietf.org Subject: Re: [conex] DDoS and ConEx-awareness in the forwarding plane X-BeenThere: conex@ietf.org X-Mailman-Version: 2.1.12 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, 16 Apr 2011 13:46:58 -0000 > -----Original Message----- > From: Mikael Abrahamsson [mailto:swmike@swm.pp.se] > Sent: 16 April 2011 14:36 > To: Toby Moncaster > Cc: 'Bob Briscoe'; conex@ietf.org > Subject: Re: [conex] DDoS and ConEx-awareness in the forwarding plane > > On Sat, 16 Apr 2011, Toby Moncaster wrote: > > > This means any DDoS host can't send unmarked traffic (because it will > get > > preferentially dropped as soon as a node starts to congest) > > RFC2827 is now over 10 years old, I would imagine the original document > is > a lot older. > > Still a lot of networks do not do basic ingress filtering towards their > customers, enabling spoofed packets to get through. > > I'm sceptical that they would implement a conex policer, at least not > all > of them. No, not all of them will implement it, but the any that do so will see the benefit -- remember that ConEx is destined for experimental track in the first instance, precisely because some people are sceptical about its effectiveness. Incidentally, I take it you aren't proposing that the IETF only produce work that is guaranteed to be adopted by all operators? If so we may as well pack up and go home because there are always operators that will try and limp along with older equipment! Incidentally, I know I keep referring people to it, but do read "Why the Internet only just works" by Mark Handley . It gives a very good explanation of how and why the Internet has tended to stagnate in recent years. Toby > > -- > Mikael Abrahamsson email: swmike@swm.pp.se From swmike@swm.pp.se Sat Apr 16 07:59:27 2011 Return-Path: X-Original-To: conex@ietfc.amsl.com Delivered-To: conex@ietfc.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfc.amsl.com (Postfix) with ESMTP id 68FFDE069A for ; Sat, 16 Apr 2011 07:59:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.291 X-Spam-Level: X-Spam-Status: No, score=-2.291 tagged_above=-999 required=5 tests=[AWL=-0.292, BAYES_00=-2.599, J_CHICKENPOX_42=0.6] Received: from mail.ietf.org ([208.66.40.236]) by localhost (ietfc.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id z-+ZccMMhDxP for ; Sat, 16 Apr 2011 07:59:26 -0700 (PDT) Received: from uplift.swm.pp.se (ipv6.swm.pp.se [IPv6:2a00:801::f]) by ietfc.amsl.com (Postfix) with ESMTP id 9F215E0685 for ; Sat, 16 Apr 2011 07:59:26 -0700 (PDT) Received: by uplift.swm.pp.se (Postfix, from userid 501) id A91649C; Sat, 16 Apr 2011 16:59:24 +0200 (CEST) Received: from localhost (localhost [127.0.0.1]) by uplift.swm.pp.se (Postfix) with ESMTP id A46D99A; Sat, 16 Apr 2011 16:59:24 +0200 (CEST) Date: Sat, 16 Apr 2011 16:59:24 +0200 (CEST) From: Mikael Abrahamsson To: Toby Moncaster In-Reply-To: <001201cbfc3c$be90f780$3bb2e680$@com> Message-ID: References: <201104141622.p3EGMcDh032032@bagheera.jungle.bt.co.uk> <201104161137.p3GBbKam007116@bagheera.jungle.bt.co.uk> <001101cbfc38$2238b160$66aa1420$@com> <001201cbfc3c$be90f780$3bb2e680$@com> User-Agent: Alpine 2.00 (DEB 1167 2008-08-23) Organization: People's Front Against WWW MIME-Version: 1.0 Content-Type: TEXT/PLAIN; format=flowed; charset=US-ASCII Cc: conex@ietf.org Subject: Re: [conex] DDoS and ConEx-awareness in the forwarding plane X-BeenThere: conex@ietf.org X-Mailman-Version: 2.1.12 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, 16 Apr 2011 14:59:27 -0000 On Sat, 16 Apr 2011, Toby Moncaster wrote: > No, not all of them will implement it, but the any that do so will see > the benefit -- remember that ConEx is destined for experimental track in > the first instance, precisely because some people are sceptical about > its effectiveness. Ok, let's back up a bit. I'm saying that any DDoS:er with any kind of skill will set the correct connex options to get the highest impact of his DDoS. I'm also saying DDoS Zombies will exist on all networks, both CONEX enabled and non-CONEX enabled. Last I heard the proposal was also to use destination options to carry the conex information? So a non-conex source network with a host sending conex marked traffic will not have well-behaving flows, because the flows are completely under the sender machine control, not any conex mechanism in that network. Since destination options are used, I have a hard time imagining that the border router between the conex network and the non-conex network would change the conex destination options on the packets? > Incidentally, I take it you aren't proposing that the IETF only produce work > that is guaranteed to be adopted by all operators? If so we may as well pack > up and go home because there are always operators that will try and limp > along with older equipment! No, but I'm proposing that the fact that 100% penetration by conex is never going to happen is taken into account when writing text. > Incidentally, I know I keep referring people to it, but do read "Why the > Internet only just works" by Mark Handley > . It > gives a very good explanation of how and why the Internet has tended to > stagnate in recent years. There is nothing in there that was any news to me. What's your point? -- Mikael Abrahamsson email: swmike@swm.pp.se From john@jlc.net Sat Apr 16 15:15:19 2011 Return-Path: X-Original-To: conex@ietfc.amsl.com Delivered-To: conex@ietfc.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfc.amsl.com (Postfix) with ESMTP id 726A3E0673 for ; Sat, 16 Apr 2011 15:15:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.029 X-Spam-Level: X-Spam-Status: No, score=-106.029 tagged_above=-999 required=5 tests=[AWL=-0.030, BAYES_00=-2.599, J_CHICKENPOX_42=0.6, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([208.66.40.236]) by localhost (ietfc.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id oP-j0YxswRXp for ; Sat, 16 Apr 2011 15:15:18 -0700 (PDT) Received: from mailhost.jlc.net (mailhost.jlc.net [199.201.159.4]) by ietfc.amsl.com (Postfix) with ESMTP id 959EDE074C for ; Sat, 16 Apr 2011 15:15:18 -0700 (PDT) Received: by mailhost.jlc.net (Postfix, from userid 104) id 8DDE133C22; Sat, 16 Apr 2011 18:15:18 -0400 (EDT) Date: Sat, 16 Apr 2011 18:15:18 -0400 From: John Leslie To: Mikael Abrahamsson Message-ID: <20110416221518.GE64981@verdi> References: <201104141622.p3EGMcDh032032@bagheera.jungle.bt.co.uk> <201104161137.p3GBbKam007116@bagheera.jungle.bt.co.uk> <001101cbfc38$2238b160$66aa1420$@com> <001201cbfc3c$be90f780$3bb2e680$@com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.4.1i Cc: conex@ietf.org Subject: Re: [conex] DDoS and ConEx-awareness in the forwarding plane X-BeenThere: conex@ietf.org X-Mailman-Version: 2.1.12 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, 16 Apr 2011 22:15:19 -0000 Mikael Abrahamsson wrote: > > I'm saying that any DDoS:er with any kind of skill will set the correct > conex options to get the highest impact of his DDoS. I'm also saying DDoS > Zombies will exist on all networks, both CONEX enabled and non-CONEX > enabled. Last I heard the proposal was also to use destination options to > carry the conex information? Yes. > So a non-conex source network with a host sending conex marked traffic > will not have well-behaving flows, because the flows are completely under > the sender machine control, not any conex mechanism in that network. Yes. > Since destination options are used, I have a hard time imagining that the > border router between the conex network and the non-conex network would > change the conex destination options on the packets? Nonetheless, it could... Actually, I'd like to digress on that: I envision an experimental phase where few if any backbone routers are at all ConEx-aware. Instead, I expect separate boxes for auditing / policing functions. It's entirely practical to build such boxes rather cheaply at gigabit-ethernet speeds, to evaluate any number of IPv6 extension headers. These could run at wire-speed, changing anything within the ConEx destination options header that may need changing, with the only practical issue being jitter in the time before a decision to drop can be made. As a practical matter, 1500-byte packets at gig-E speed can't cause more than 12 microseconds of jitter -- this isn't likely to be a problem during the experimental period (though I could imagine a future where it might become a problem). >... I'm proposing that the fact that 100% penetration by conex is > never going to happen is taken into account when writing text. To be fair, we don't expect this DDoS use-case to be in our initial document at all. Nonetheless, I'd be delighted to discuss a DDoS use case on-list. Fundamentally, at any peering point there could be a default policy on accepting ConEx marking (in the absence of actual contractual policy) which limits (by any of several algorithms) the number of congestion- expected marks you accept to just a bit more than the number you send. In essence, you would apply the same allowance-based rule you would apply to a direct customer (in the absence of a contractual agreement to pay for excess marks). This means that the congestion-expected marks from DDoS-bots would disappear -- and peers sending well-behaved traffic would get preferred forwarding. (Granted, well-behaved customers of peers that also send bad traffic _wouldn't_ get preferred forwarding; but they're not _your_ customers, so you have no obligation to give them preferred forwarding: their beef is with their upstream.) (Also, if you wish to give _your_ customer the benefit of preferred forwarding toward them from certain sources, you could work out some stateful deep-packet-inspection scheme to do so -- but that's NOT a ConEx problem.) -- John Leslie From dave.mcdysan@verizon.com Mon Apr 18 07:05:20 2011 Return-Path: X-Original-To: conex@ietfc.amsl.com Delivered-To: conex@ietfc.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfc.amsl.com (Postfix) with ESMTP id BB066E0700 for ; Mon, 18 Apr 2011 07:05:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.29 X-Spam-Level: X-Spam-Status: No, score=-3.29 tagged_above=-999 required=5 tests=[AWL=0.309, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([208.66.40.236]) by localhost (ietfc.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id G2V1QMMTcqsY for ; Mon, 18 Apr 2011 07:05:16 -0700 (PDT) Received: from sacmail2.verizon.com (sacmail2.verizon.com [192.76.84.41]) by ietfc.amsl.com (Postfix) with ESMTP id A0826E06D6 for ; Mon, 18 Apr 2011 07:05:16 -0700 (PDT) Received: from fldsmtpi02.verizon.com (fldsmtpi02.verizon.com [166.68.71.144]) by sacmail2.verizon.com (8.13.7+Sun/8.13.3) with ESMTP id p3IE4oPS014885 for ; Mon, 18 Apr 2011 10:05:07 -0400 (EDT) From: "Mcdysan, David E" X-IronPort-AV: E=Sophos;i="4.64,232,1301875200"; d="scan'208";a="32448400" Received: from fhdp1lumxc7hb04.verizon.com (HELO FHDP1LUMXC7HB04.us.one.verizon.com) ([166.68.59.191]) by fldsmtpi02.verizon.com with ESMTP; 18 Apr 2011 14:04:50 +0000 Received: from fhdp1lumxc7v11.us.one.verizon.com ([169.254.1.15]) by FHDP1LUMXC7HB04.us.one.verizon.com ([2002:a644:3bbf::a644:3bbf]) with mapi; Mon, 18 Apr 2011 10:04:50 -0400 To: Bob Briscoe Date: Mon, 18 Apr 2011 10:04:46 -0400 Thread-Topic: [conex] comments/suggestions on draft-ietf-conex-concepts-uses-01 Thread-Index: Acv90ZQ/r7pTKyFsQhC4W4Z+bl2VxQ== Message-ID: In-Reply-To: <201104071147.p37BlP3G026341@bagheera.jungle.bt.co.uk> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.1.0.101012 acceptlanguage: en-US Content-Type: text/plain; charset="windows-1254" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "conex@ietf.org" Subject: Re: [conex] comments/suggestions on draft-ietf-conex-concepts-uses-01 X-BeenThere: conex@ietf.org X-Mailman-Version: 2.1.12 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, 18 Apr 2011 14:05:20 -0000 Hi Bob, Responses in line below. Thanks, Dave On Wednesday4/6/11 5:16 PM, "Bob Briscoe" wrote: >David, > >I had meant to say earlier that I don't think >self-congestion is a good term for this concept. >The words self-congestion suggest your own >activity is congesting yourself, which might mean >you are overloading your own DSL line, or your own home network. Those are cases that the term was intended to cover. > >When your own actions have taken you out of >contract with a policy enforcing device which is >discarding your traffic, that is not congestion >so congestion is a bad word to use for it. And >the discards are only indirectly caused by the >self, so self is not a good word either. > >Policy-drop or policy-induced discard or some >similar phrase would be a better term for this. > >I'm currently offline, so I cannot search to see >if there is already a commonly used term for this. Using another term is fine with me, but please put the term in the definitions section of the draft and change the references from "self congestion" to the new term. > >Bob > >At 14:56 06/04/2011, Mcdysan, David E wrote: >>Hi Mirja, >> >>Thank you for the feedback. >> >>A definition of "self congestion" was added to section 1 of use-cases-01 >>as follows: >> >> Congestion takes two distinct forms. The first results from the >> interaction of traffic from one set of users with traffic from other >> users, causing in a reduction in service (a cost) for all of them. >> the second, often referred to as "self-congestion", occurs when an >> increase in traffic from a single user causes that user to suffer a >> worse service (for instance because their traffic is being "shaped" >> by their ISP, or because they have an excessively large buffer in >> their home router). ConEx is principally interested in the first >> form of congestion since it involves informing those other users of >> the impact you expect to have on them. >> >>Editorially, possibly the description of these terms should be in >>definitions, but as I mentioned in Prague this was new text that the wg >>should review. >> >>Thanks, >> >>Dave >> >>On Tuesday4/5/11 6:39 PM, "Mirja Kuehlewind" >> wrote: >> >> >Hi Dave, >> > >> >thx, I really like your text proposal. I guess the term 'self >>congestion' >> >needs to be defined as well...? But otherwise this text make the use >>case >> >very clear to me! >> > >> >Mirja >> > >> > >> >On Monday 04 April 2011 14:07:13 Mcdysan, David E wrote: >> >> As I mentioned in the status presentation last Thursday, I planned to >> >>send >> >> a paragraph to the conex wg list with proposed text for an additional >> >> paragraph to be placed at the end of section 5.1. >> >> >> >> I am responding to point 1 Alissas' Email on this subject, since I >>think >> >> her note summarizes wg consensus on this topic well. (Also note that >> >>this >> >> closely aligns with the text cited from the reference [Bauer09]). >> >> >> >> The remainder of section 6 relating to this topic would be removed, >>with >> >> discussion required to determine whether the wg sees value in keeping >> >> section 6.2 (possibly in an Appendix), or removing that as well. The >> >> formulation of this approach by Toby helped me better understand >>conex, >> >> but if that is not wg consensus, then so be it. >> >> >> >> "Traffic measurements over time scales longer than that of >> >> policers/shapers involving conex information can be used to adjust >>the >> >> token bucket parameters of these policers and adjust parameters of >> >> shapers. These longer time scale conex related measurements can also >> >> provide other uses [Bauer09, pg.18-19], such as; achieve better >> >> understanding user traffic requirements, provide a better basis for >> >> planning investments, enable better service customization, or achieve >> >> better matching of costs and usage. When measurement is done in a >> >>network >> >> element that implements a shaper, the amount which self congestion >> >> contributes to overall congestion may be estimated for similar uses. >> >>These >> >> traffic management techniques employing conex information may help >> >>address >> >> the challenging problem where a small percentage of users (e.g., 20%) >> >> generate a large portion of the traffic (e.g., 80%) [Varian09]. " >> >> >> >> >> >> Also, based upon some misunderstanding of terminology that was >>apparent >> >>on >> >> the list, I propose that the RFC 2475 definition of "shaper" be >>added to >> >> section 3.1, existing approaches. >> >> >> >> Thanks, >> >> >> >> Dave >> >> >> >> On Friday3/25/11 4:37 AM, "Alissa Cooper" wrote: >> >> >In my reading of section 6, it presents 2 distinct issues: >> >> > >> >> >1) Long time scales: A use case (or perhaps a few variations on the >> >> >same use case) for the conex signal as currently described in >>abstract- >> >> >mech, wherein conex helps network operators to manage congestion, >> >> >conduct traffic shaping, and capacity-plan over periods much longer >> >> >than network speeds (e.g., minutes/hours/days/months) >> >> > >> >> >2) Shaper presence: A suggestion that conex could signal the >>presence >> >> >of a traffic shaper (in addition to or instead of how the conex >>signal >> >> >is currently described in abstract-mech) and a use case for such a >> >> >signal wherein recipients of the signal can use it to request that >> >> >sender's traffic shaper parameters be altered >> >> > >> >> >I think the issue of long time scales, which is described in the >> >> >introductory text to section 6 and briefly in 6.1 and 6.2, could >> >> >instead be succinctly addressed by adding a couple of sentences to >>5.1 >> >> >to explain that the use of conex for managing "heavy" users could >> >> >occur over shorter or longer time scales and could have the added >> >> >affect of helping operators to do longer-term capacity planning. >> >> > >> >> >Signaling the presence of a shaper seems to me to be a separate >>animal >> >> >altogether, and one over which there is some obvious disagreement. >>But >> >> >at least half of section 6 seems to be devoted to the idea that >> >> >operators would have uses for aggregating conex information over >>long >> >> >time frames, and I think those uses could be incorporated with a >>brief >> >> >addition to section 5.1. >> >> > >> >> >Alissa >> >> > >> >> >On Mar 17, 2011, at 12:25 PM, Mcdysan, David E wrote: >> >> >> Hi Nandita, >> >> >> >> >> >> A few responses to your questions on the new section in line below >> >> >> prefixed by DM which were previously posted to the list that I >> >> >> believe (at least partially) address your comments. >> >> >> >> >> >> I propose that the working group work toward how to >>organize/merge/ >> >> >> move the new text better into the existing outline. >> >> >> >> >> >> Thanks, >> >> >> >> >> >> Dave >> >> >> >> >> >> From: Nandita Dukkipati >> >> >> Date: Thu, 17 Mar 2011 03:28:25 -0400 >> >> >> To: Toby Moncaster , John Leslie >>, >> >> >> Bob Briscoe , "Woundy, Richard" >> >> >>> >> >> >> >> >> >, David McDysan >> >> >> >> >> >> Cc: "conex@ietf.org" >> >> >> Subject: comments/suggestions on draft-ietf-conex-concepts-uses-01 >> >> >> >> >> >> On reading the latest draft, I have three high level comments >> >> >> roughly in the following order of importance- >> >> >> >> >> >> *** >> >> >> Statistical Multiplexing over different timescales. >> >> >> This reads like a rambling story. I have read and re-read it, and >>I >> >> >> am still left wondering - >> >> >> * What is _the_ main point? How about starting the section by >> >> >> stating your main point upfront as opposed leaving it to the >>reader >> >> >> to figure it out. >> >> >> >> >> >> DM - From my 3/10/11 on the list >> >> >> >> >> >> 1) A few "heavy" users generate most of the traffic and service >> >> >> providers >> >> >> want to better assign the cost (of provisioning an upgrade) for >>the >> >> >> time >> >> >> when congestion is anticipated to occur. Existing mechanisms, flat >> >> >> rate, >> >> >> bandwidth tier shapers, and usage tiers do not completely address >>the >> >> >> service provider objective and/or are not popular with users. >> >> >> >> >> >> 2) In some service provider networks shapers are implemented to >> >> >> limit the >> >> >> maximum bandwidth per user. Although overflow or marking in the >> >>shaper >> >> >> queue appears as congestion to the receiver, this >>"self-congestion" >> >> >> differs from congestion of a shared resource since a remedy could >>be >> >> >> to >> >> >> indicate to the user that changing the shaper rate (i.e., "go >> >>faster") >> >> >> would alleviate "self-congestion." >> >> >> >> >> >> * Why and how is this use case distinct from that of traffic >> >> >> management which already seems to have a broad scope? Is it really >> >> >> distinct? >> >> >> >> >> >> DM - From my 3/11/11 post to the list >> >> >> >> >> >> Editorially, this (section 5.1) could be a place to state the >> >> >> problem with an additional >> >> >> reference to [Varian]. >> >> >> >> >> >> Editorially, bandwidth tier pricing could be added to section 3.1, >> >> >> Existing approaches. >> >> >> >> >> >> I am now thinking that editorially a separate section is not a >>good >> >> >> idea, >> >> >> since the points can be merged into the existing outline, in at >> >> >> least the >> >> >> places mentioned above. >> >> >> >> >> >> I think adding that the use case needs to meet service provider >> >> >> economic >> >> >> congestion needs as well as be acceptable to users is an important >> >> >> point >> >> >> not in the current text. Traffic management (aka policing) may >>have >> >> >> the >> >> >> problem that it may not be popular with user. There has already >>been >> >> >> negative feedback on the list regarding policing (IMO, Traffic >> >> >> management >> >> >> is a better term). >> >> >> >> >> >> >> >> >> * [minor] Why not make this use case a part of Sec. 5? >> >> >> >> >> >> DM =AD the minutes recorded adding the agreement to add this as a >>new >> >> >> section. (A new subsection, and or merging thoughts with other use >> >> >> cases (e.g., as suggested above) is what I believe the wg needs to >> >> >> discuss. >> >> >> >> >> >> *** >> >> >> Partial versus full deployment. >> >> >> Clearly, it belongs to this draft. But why is it a part of use >> >> >> cases? Looks out of place to me. >> >> >> >> >> >> *** >> >> >> Sec 4. Exposing congestion. >> >> >> =B3We argue that congestion needs.... More specifically, a network >> >> >> needs to be able to measure how much congestion any particular >> >> >> traffic expects to cause between the monitoring point in the >>network >> >> >> and the destination ("rest-of-path congestion"). This would be a >>new >> >> >> capability.=B2 >> >> >> >> >> >> Could you add more clarity and explanation on why local congestion >> >> >> information at any given node is not sufficient. Why does a node >> >> >> require congestion information from a monitoring point to the >> >> >> destination to be able to manage its own congestion? A succinct >> >> >> explanation and/or an example will go a long way. >> >> >> >> >> >> _______________________________________________ >> >> >> conex mailing list >> >> >> conex@ietf.org >> >> >> https://www.ietf.org/mailman/listinfo/conex >> >> >> >> _______________________________________________ >> >> conex mailing list >> >> conex@ietf.org >> >> https://www.ietf.org/mailman/listinfo/conex >> > >> > >> > >> >-- >> >------------------------------------------------------------------- >> >Dipl.-Ing. Mirja K=FChlewind >> >Institute of Communication Networks and Computer Engineering (IKR) >> >University of Stuttgart, Germany >> >Pfaffenwaldring 47, D-70569 Stuttgart >> > >> >tel: +49(0)711/685-67973 >> >email: mirja.kuehlewind@ikr.uni-stuttgart.de >> >web: www.ikr.uni-stuttgart.de >> >------------------------------------------------------------------- >> >>_______________________________________________ >>conex mailing list >>conex@ietf.org >>https://www.ietf.org/mailman/listinfo/conex > >________________________________________________________________ >Bob Briscoe, BT Innovate & Design > From marcelo@it.uc3m.es Wed Apr 27 11:34:25 2011 Return-Path: X-Original-To: conex@ietfa.amsl.com Delivered-To: conex@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0EFC6E076E for ; Wed, 27 Apr 2011 11:34:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.531 X-Spam-Level: X-Spam-Status: No, score=-106.531 tagged_above=-999 required=5 tests=[AWL=0.068, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Pe1HDaGJZopc for ; Wed, 27 Apr 2011 11:34:24 -0700 (PDT) Received: from smtp03.uc3m.es (smtp03.uc3m.es [163.117.176.133]) by ietfa.amsl.com (Postfix) with ESMTP id 5A77DE0754 for ; Wed, 27 Apr 2011 11:34:23 -0700 (PDT) X-uc3m-safe: yes Received: from marcelo-bagnulos-macbook-pro-2.local (68.31.18.95.dynamic.jazztel.es [95.18.31.68]) (using TLSv1 with cipher AES256-SHA (256/256 bits)) (No client certificate requested) by smtp03.uc3m.es (Postfix) with ESMTP id 357C37FA2FC for ; Wed, 27 Apr 2011 20:34:20 +0200 (CEST) Message-ID: <4DB861AA.3080602@it.uc3m.es> Date: Wed, 27 Apr 2011 20:34:18 +0200 From: marcelo bagnulo braun User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.5; es-ES; rv:1.9.2.15) Gecko/20110303 Thunderbird/3.1.9 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.5.0.1024-18102.000 Subject: [conex] draft minutes X-BeenThere: conex@ietf.org X-Mailman-Version: 2.1.12 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, 27 Apr 2011 18:34:25 -0000 posted at http://www.ietf.org/proceedings/80/minutes/conex.txt send comments if you want to change anything thanks Alissa for taking the notes Regards, marcelo