From philip.eardley@bt.com Tue Jan 5 03:44:11 2010 Return-Path: X-Original-To: re-ecn@core3.amsl.com Delivered-To: re-ecn@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 263223A684D for ; Tue, 5 Jan 2010 03:44:11 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.11 X-Spam-Level: X-Spam-Status: No, score=-2.11 tagged_above=-999 required=5 tests=[BAYES_05=-1.11, 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 oWrU4So9qLLj for ; Tue, 5 Jan 2010 03:44:09 -0800 (PST) Received: from smtp3.smtp.bt.com (smtp3.smtp.bt.com [217.32.164.138]) by core3.amsl.com (Postfix) with ESMTP id 8F4433A659B for ; Tue, 5 Jan 2010 03:44:05 -0800 (PST) Received: from E03MVB1-UKBR.domain1.systemhost.net ([193.113.197.109]) by smtp3.smtp.bt.com with Microsoft SMTPSVC(6.0.3790.3959); Tue, 5 Jan 2010 11:44:03 +0000 x-mimeole: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Tue, 5 Jan 2010 11:44:02 -0000 Message-ID: <4A916DBC72536E419A0BD955EDECEDEC06363C14@E03MVB1-UKBR.domain1.systemhost.net> In-Reply-To: <201001041842.o04Iglel023891@bagheera.jungle.bt.co.uk> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [re-ECN] Complete draft Charter for proposed CONEX WG Thread-Index: AcqNbbomb48xLN3ETWWIWcBTSnRmIgAizTAQ From: To: X-OriginalArrivalTime: 05 Jan 2010 11:44:03.0186 (UTC) FILETIME=[60FBA520:01CA8DFC] Cc: re-ecn@ietf.org Subject: Re: [re-ECN] Complete draft Charter for proposed CONEX WG X-BeenThere: re-ecn@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: re-inserted explicit congestion notification List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 05 Jan 2010 11:44:11 -0000 >=20 > [BB]: A radically new approach is unlikely to be successful if people=20 > can't get an intuitive grasp of it. E.g. HIP would have been unlikely=20 > to get anywhere without RFC4423. We know ConEx hasn't been easy for=20 > newcomers to grasp, so we shouldn't fudge this issue. >=20 > I was thinking of a framework/architecture doc. Here's an idea... >=20 > Let's assume the use-cases item is >1 doc, rather than a single=20 > monolithic doc for all use-cases, ie. we encourage different people=20 > to document their own use-cases. >=20 > If so, then someone could attempt to write a more generic use-cases=20 > doc that describes building blocks that can be used to build the=20 > other use-cases. This could become a README-FIRST if written well, as=20 > it's difficult to introduce ConEx without describing how it=20 > might be used. An "intuitive guide" would be possible, although adding another doc is more work. I wonder if the applicability statement can be tweaked for this purpose. We could add another "purpose": [3] to provide an intuitive explanation of the new concepts in CONEX So that it reads as follows:-=20 1. An applicability statement that describes:=20 A. the functionality / capability that is expected to be provided by the CONEX mechanism itself, including its architectural features, limitations and assumptions it makes about networks and end systems B. a deployment analysis - how the CONEX mechanism can be deployed in networks (non vs ECN vs perhaps CONEX routers) and end systems C. a threat analysis - threats from falsifying or blanking CONEX info=20 The purpose is=20 [1] to detail the key functional and non-functional considerations that guide the work on the mechanism's design=20 [2] to allow exploration of use cases to begin before work on the mechanism is complete=20 [3] to provide an intuitive explanation of the new concepts in CONEX >=20 > Where do you imagine we should put best practice for the sending=20 > transport to set its expectation of congestion? > - The above EXP for e2e transport, > - or within the ConEx-IP doc (if so, which one? v4 or v6)? > It would seem to fit better in the e2e transport one, then the spec=20 > for TCP could provide an example of the complete best practice. Yes, same as you - I'd imagined it would be in the e2e transport doc. The IP doc defines packet the structure to carry CONEX information - ie what the codepoints are and what they mean. "what they mean" of course influences what the sending transport should do, but the advice for the sending transport would be in the transport doc [things like "send, as soon as possible, a Black codepoint for every loss or mark notified by the receiver". or whatever!]=20 Thanks phil > IOW, this proposal assumes the IP doc would not need to describe=20 > semantics of *when* the transport sets the codepoints. Instead it=20 > would focus on just the wire protocol - what the codepoints mean, how=20 > they are encoded, tunnel processing, router forwarding behaviour,=20 > errors & management etc. >=20 > Altho I'm not implying re-ECN is any more than a candidate, it would=20 > be a useful exercise to go through the contents of the re-ECN=20 > protocol spec and check where you=20 > assume the different sections will end up. I've just done that, which=20 > is why I keep bringing up awkward questions. >=20 From rbriscoe@jungle.bt.co.uk Tue Jan 5 05:49:01 2010 Return-Path: X-Original-To: re-ecn@core3.amsl.com Delivered-To: re-ecn@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 3EA793A6809 for ; Tue, 5 Jan 2010 05:49:01 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.887 X-Spam-Level: X-Spam-Status: No, score=-0.887 tagged_above=-999 required=5 tests=[AWL=1.230, BAYES_00=-2.599, DNS_FROM_RFC_BOGUSMX=1.482, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id aKDKjAcN8cxi for ; Tue, 5 Jan 2010 05:48:55 -0800 (PST) Received: from smtp1.smtp.bt.com (smtp1.smtp.bt.com [217.32.164.137]) by core3.amsl.com (Postfix) with ESMTP id E41B93A63C9 for ; Tue, 5 Jan 2010 05:48:54 -0800 (PST) Received: from i2kc06-ukbr.domain1.systemhost.net ([193.113.197.70]) by smtp1.smtp.bt.com with Microsoft SMTPSVC(6.0.3790.3959); Tue, 5 Jan 2010 13:48:52 +0000 Received: from cbibipnt05.iuser.iroot.adidom.com ([147.149.196.177]) by i2kc06-ukbr.domain1.systemhost.net with Microsoft SMTPSVC(6.0.3790.3959); Tue, 5 Jan 2010 13:48:52 +0000 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 1262699330601; Tue, 5 Jan 2010 13:48:50 +0000 Received: from MUT.jungle.bt.co.uk ([10.73.181.91]) by bagheera.jungle.bt.co.uk (8.13.5/8.12.8) with ESMTP id o05Dmcvv008008; Tue, 5 Jan 2010 13:48:39 GMT Message-Id: <201001051348.o05Dmcvv008008@bagheera.jungle.bt.co.uk> X-Mailer: QUALCOMM Windows Eudora Version 7.1.0.9 Date: Tue, 05 Jan 2010 13:48:38 +0000 To: From: Bob Briscoe In-Reply-To: <4A916DBC72536E419A0BD955EDECEDEC06363C14@E03MVB1-UKBR.doma in1.systemhost.net> References: <201001041842.o04Iglel023891@bagheera.jungle.bt.co.uk> <4A916DBC72536E419A0BD955EDECEDEC06363C14@E03MVB1-UKBR.domain1.systemhost.net> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-Scanned-By: MIMEDefang 2.56 on 132.146.168.158 X-OriginalArrivalTime: 05 Jan 2010 13:48:52.0047 (UTC) FILETIME=[D0B125F0:01CA8E0D] Cc: re-ecn@ietf.org Subject: Re: [re-ECN] Complete draft Charter for proposed CONEX WG X-BeenThere: re-ecn@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: re-inserted explicit congestion notification List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 05 Jan 2010 13:49:01 -0000 Phil, I'm happy with both responses. one outstanding issue inline... At 11:44 05/01/2010, philip.eardley@bt.com wrote: > > > > [BB]: A radically new approach is unlikely to be successful if people > > can't get an intuitive grasp of it. E.g. HIP would have been unlikely > > to get anywhere without RFC4423. We know ConEx hasn't been easy for > > newcomers to grasp, so we shouldn't fudge this issue. > > > > I was thinking of a framework/architecture doc. Here's an idea... > > > > Let's assume the use-cases item is >1 doc, rather than a single > > monolithic doc for all use-cases, ie. we encourage different people > > to document their own use-cases. > > > > If so, then someone could attempt to write a more generic use-cases > > doc that describes building blocks that can be used to build the > > other use-cases. This could become a README-FIRST if written well, as > > it's difficult to introduce ConEx without describing how it > > might be used. > >An "intuitive guide" would be possible, although adding another doc is >more work. I wonder if the applicability statement can be tweaked for >this purpose. We could add another "purpose": >[3] to provide an intuitive explanation of the new concepts in CONEX > >So that it reads as follows:- > >1. An applicability statement that describes: > >A. the functionality / capability that is expected to be provided by the >CONEX mechanism itself, including its architectural features, >limitations and assumptions it makes about networks and end systems > >B. a deployment analysis - how the CONEX mechanism can be deployed in >networks (non vs ECN vs perhaps CONEX routers) and end systems > >C. a threat analysis - threats from falsifying or blanking CONEX info The milestones have the applicability statement going to the IESG before the ConEx protocol is specified, so... B. I'm not convinced we will be able to write a deployment analysis of a protocol as yet to be defined - we can surely only write requirements at that stage. C. And it's certainly not possible to write a meaningful threat analysis of something that hasn't yet been specified. These problems would be solved by altering the chartering text as follows: s/deployment analysis/ /deployability goals/ s/threat analysis - threats from.../ /security goals - addressing threats from.../ Then after the protocol has been specified: - deployment analysis could be in "4. use-case(s)" - full threat analysis could be in "3B trust mechanisms" Bob >The purpose is >[1] to detail the key functional and non-functional considerations that >guide the work on the mechanism's design > >[2] to allow exploration of use cases to begin before work on the >mechanism is complete > >[3] to provide an intuitive explanation of the new concepts in CONEX > > > > > > Where do you imagine we should put best practice for the sending > > transport to set its expectation of congestion? > > - The above EXP for e2e transport, > > - or within the ConEx-IP doc (if so, which one? v4 or v6)? > > It would seem to fit better in the e2e transport one, then the spec > > for TCP could provide an example of the complete best practice. > >Yes, same as you - I'd imagined it would be in the e2e transport doc. >The IP doc defines packet the structure to carry CONEX information - ie >what the codepoints are and what they mean. "what they mean" of course >influences what the sending transport should do, but the advice for the >sending transport would be in the transport doc [things like "send, as >soon as possible, a Black codepoint for every loss or mark notified by >the receiver". or whatever!] > >Thanks >phil > > > IOW, this proposal assumes the IP doc would not need to describe > > semantics of *when* the transport sets the codepoints. Instead it > > would focus on just the wire protocol - what the codepoints mean, how > > they are encoded, tunnel processing, router forwarding behaviour, > > errors & management etc. > > > > Altho I'm not implying re-ECN is any more than a candidate, it would > > be a useful exercise to go through the contents of the re-ECN > > protocol spec and check where you > > assume the different sections will end up. I've just done that, which > > is why I keep bringing up awkward questions. > > ________________________________________________________________ Bob Briscoe, BT Innovate & Design From ingemar.s.johansson@ericsson.com Thu Jan 7 06:32:30 2010 Return-Path: X-Original-To: re-ecn@core3.amsl.com Delivered-To: re-ecn@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 16EC33A6810 for ; Thu, 7 Jan 2010 06:32:30 -0800 (PST) X-Quarantine-ID: X-Virus-Scanned: amavisd-new at amsl.com X-Amavis-Alert: BANNED, message contains part: multipart/mixed | application/ms-tnef,.tnef,winmail.dat X-Spam-Flag: NO X-Spam-Score: -3.552 X-Spam-Level: X-Spam-Status: No, score=-3.552 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FRT_POSSIBLE=2.697, HELO_EQ_SE=0.35, RCVD_IN_DNSWL_MED=-4] X-Amavis-Modified: Mail body modified (defanged) by core3.amsl.com Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id AS8gif1Rdi8R for ; Thu, 7 Jan 2010 06:32:28 -0800 (PST) Content-Type: multipart/mixed; boundary="----------=_1262874750-19539-1" Content-Transfer-Encoding: binary MIME-Version: 1.0 Received: from mailgw5.ericsson.se (mailgw5.ericsson.se [193.180.251.36]) by core3.amsl.com (Postfix) with ESMTP id 0CEA73A67B0 for ; Thu, 7 Jan 2010 06:32:24 -0800 (PST) Received: from esealmw126.eemea.ericsson.se (Unknown_Domain [153.88.253.124]) by mailgw5.ericsson.se (Symantec Mail Security) with SMTP id 88.8D.04178.670F54B4; Thu, 7 Jan 2010 15:32:22 +0100 (CET) Received: from esealmw109.eemea.ericsson.se ([153.88.200.2]) by esealmw126.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.3959); Thu, 7 Jan 2010 15:32:21 +0100 Date: Thu, 7 Jan 2010 15:32:21 +0100 Message-ID: <130EBB38279E9847BAAAE0B8F9905F8C6E40EC@esealmw109.eemea.ericsson.se> References: From: "Ingemar Johansson S" To: Subject: Re: [re-ECN] Complete draft Charter for proposed CONEX WG X-BeenThere: re-ecn@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: re-inserted explicit congestion notification List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 07 Jan 2010 14:32:30 -0000 This is a multi-part message in MIME format... ------------=_1262874750-19539-1 Content-Type: text/plain; charset="iso-8859-1" Content-Disposition: inline Content-Transfer-Encoding: 7bit WARNING: contains banned part ------------=_1262874750-19539-1 Content-Type: message/rfc822; x-spam-type=original; name="message" Content-Disposition: attachment; filename="message" Content-Transfer-Encoding: 7bit Content-Description: Original message Received: from mailgw5.ericsson.se (mailgw5.ericsson.se [193.180.251.36]) by core3.amsl.com (Postfix) with ESMTP id 0CEA73A67B0 for ; Thu, 7 Jan 2010 06:32:24 -0800 (PST) X-AuditID: c1b4fb24-b7bb6ae000001052-62-4b45f076ebc2 Received: from esealmw126.eemea.ericsson.se (Unknown_Domain [153.88.253.124]) by mailgw5.ericsson.se (Symantec Mail Security) with SMTP id 88.8D.04178.670F54B4; Thu, 7 Jan 2010 15:32:22 +0100 (CET) Received: from esealmw109.eemea.ericsson.se ([153.88.200.2]) by esealmw126.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.3959); Thu, 7 Jan 2010 15:32:21 +0100 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="----_=_NextPart_001_01CA8FA6.38DD7F26" Subject: Re: Complete draft Charter for proposed CONEX WG Date: Thu, 7 Jan 2010 15:32:21 +0100 Message-ID: <130EBB38279E9847BAAAE0B8F9905F8C6E40EC@esealmw109.eemea.ericsson.se> X-MS-Has-Attach: X-MS-TNEF-Correlator: <130EBB38279E9847BAAAE0B8F9905F8C6E40EC@esealmw109.eemea.ericsson.se> Thread-Topic: Complete draft Charter for proposed CONEX WG Thread-Index: AcqODdlIYjyUFZ0gR8++zvSxSLr4RgBlaOKa References: From: "Ingemar Johansson S" To: X-OriginalArrivalTime: 07 Jan 2010 14:32:21.0982 (UTC) FILETIME=[39291FE0:01CA8FA6] X-Brightmail-Tracker: AAAAAA== This is a multi-part message in MIME format. ------_=_NextPart_001_01CA8FA6.38DD7F26 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable =20 Hi If I get things correct idea is to create one IP doc and a number of = transport docs (TCP, RTP/UDP....), this sounds OK.=20 My feeling is that the IP doc needs to set some requirements on the = feedback/reinsertion done by the transport. The reason I see is that no = requirements at all on this level will make it difficult to design and = tune the incentive droppers and congestion rate policers.=20 The use of bit 48 in the IPv4 header is probably one thing that will = raise the noise level on the list. The IP doc will here need to specify = how this can be used safely (if posssible) =20 PS. Is it possible that you could post a refreshed version of the draft = charter on this list as it is a bit difficult to follow the discussion = (esp after being away after being out of office for a longer period). Regards Ingemar ---------------------------------------------------------------------- Message: 1 Date: Tue, 05 Jan 2010 13:48:38 +0000 From: Bob Briscoe Subject: Re: [re-ECN] Complete draft Charter for proposed CONEX WG To: Cc: re-ecn@ietf.org Message-ID: <201001051348.o05Dmcvv008008@bagheera.jungle.bt.co.uk> Content-Type: text/plain; charset=3D"us-ascii"; format=3Dflowed Phil, I'm happy with both responses. one outstanding issue inline... At 11:44 05/01/2010, philip.eardley@bt.com wrote: > > > > [BB]: A radically new approach is unlikely to be successful if = people > > can't get an intuitive grasp of it. E.g. HIP would have been = unlikely > > to get anywhere without RFC4423. We know ConEx hasn't been easy for > > newcomers to grasp, so we shouldn't fudge this issue. > > > > I was thinking of a framework/architecture doc. Here's an idea... > > > > Let's assume the use-cases item is >1 doc, rather than a single > > monolithic doc for all use-cases, ie. we encourage different people > > to document their own use-cases. > > > > If so, then someone could attempt to write a more generic use-cases > > doc that describes building blocks that can be used to build the > > other use-cases. This could become a README-FIRST if written well, = as > > it's difficult to introduce ConEx without describing how it > > might be used. > >An "intuitive guide" would be possible, although adding another doc is >more work. I wonder if the applicability statement can be tweaked for >this purpose. We could add another "purpose": >[3] to provide an intuitive explanation of the new concepts in CONEX > >So that it reads as follows:- > >1. An applicability statement that describes: > >A. the functionality / capability that is expected to be provided by = the >CONEX mechanism itself, including its architectural features, >limitations and assumptions it makes about networks and end systems > >B. a deployment analysis - how the CONEX mechanism can be deployed in >networks (non vs ECN vs perhaps CONEX routers) and end systems > >C. a threat analysis - threats from falsifying or blanking CONEX info The milestones have the applicability statement going to the IESG before the ConEx protocol is specified, so... B. I'm not convinced we will be able to write a deployment analysis of a protocol as yet to be defined - we can surely only write requirements at that stage. C. And it's certainly not possible to write a meaningful threat analysis of something that hasn't yet been specified. These problems would be solved by altering the chartering text as = follows: s/deployment analysis/ /deployability goals/ s/threat analysis - threats from.../ /security goals - addressing threats from.../ Then after the protocol has been specified: - deployment analysis could be in "4. use-case(s)" - full threat analysis could be in "3B trust mechanisms" Bob >The purpose is >[1] to detail the key functional and non-functional considerations that >guide the work on the mechanism's design > >[2] to allow exploration of use cases to begin before work on the >mechanism is complete > >[3] to provide an intuitive explanation of the new concepts in CONEX > > > > > > Where do you imagine we should put best practice for the sending > > transport to set its expectation of congestion? > > - The above EXP for e2e transport, > > - or within the ConEx-IP doc (if so, which one? v4 or v6)? > > It would seem to fit better in the e2e transport one, then the spec > > for TCP could provide an example of the complete best practice. > >Yes, same as you - I'd imagined it would be in the e2e transport doc. >The IP doc defines packet the structure to carry CONEX information - = ie >what the codepoints are and what they mean. "what they mean" of course >influences what the sending transport should do, but the advice for the >sending transport would be in the transport doc [things like "send, as >soon as possible, a Black codepoint for every loss or mark notified by >the receiver". or whatever!] > >Thanks >phil > > > IOW, this proposal assumes the IP doc would not need to describe > > semantics of *when* the transport sets the codepoints. Instead it > > would focus on just the wire protocol - what the codepoints mean, = how > > they are encoded, tunnel processing, router forwarding behaviour, > > errors & management etc. > > > > Altho I'm not implying re-ECN is any more than a candidate, it would > > be a useful exercise to go through the contents of the re-ECN > > protocol spec and check where = you > > assume the different sections will end up. I've just done that, = which > > is why I keep bringing up awkward questions. > > ________________________________________________________________ Bob Briscoe, BT Innovate & Design ------------------------------ _______________________________________________ re-ECN mailing list re-ECN@ietf.org https://www.ietf.org/mailman/listinfo/re-ecn End of re-ECN Digest, Vol 11, Issue 2 ************************************* ------_=_NextPart_001_01CA8FA6.38DD7F26 Content-Type: application/ms-tnef; name="winmail.dat" Content-Transfer-Encoding: base64 eJ8+IhYOAQaQCAAEAAAAAAABAAEAAQeQBgAIAAAA5AQAAAAAAADoAAEIgAcAGAAAAElQTS5NaWNy b3NvZnQgTWFpbC5Ob3RlADEIAQ2ABAACAAAAAgACAAEEgAEAMgAAAFJlOiAgQ29tcGxldGUgZHJh ZnQgQ2hhcnRlciBmb3IgcHJvcG9zZWQgQ09ORVggV0cA0hABBYADAA4AAADaBwEABwAPACAAFQAE ADEBASCAAwAOAAAA2gcBAAcADwAgABUABAAxAQEJgAEAIQAAAEY0MkJBNDNFNzhGN0MxNEY5NUUx NEU5QzE5MDVDRTYzAE4HAQOQBgD8IAAAOAAAAAMANgAAAAAAQAA5ACZ/3Timj8oBHgA9AAEAAAAG AAAAUmU6ICAAAAACAUcAAQAAADoAAABjPVNFO2E9NDAwbmV0O3A9RXJpY3Nzb247bD1FU0VBTE1X MTA5LTEwMDEwNzE0MzIyMVotMTUyNzMAAAAeAEkAAQAAAB8AAAByZS1FQ04gRGlnZXN0LCBWb2wg MTEsIElzc3VlIDIAAEAATgCARAfWDY7KAR4AWgABAAAAGAAAAHJlLWVjbi1ib3VuY2VzQGlldGYu b3JnAAIBWwABAAAATQAAAAAAAACBKx+kvqMQGZ1uAN0BD1QCAAAAAHJlLWVjbi1ib3VuY2VzQGll dGYub3JnAFNNVFAAcmUtZWNuLWJvdW5jZXNAaWV0Zi5vcmcAAAAAAgFcAAEAAAAdAAAAU01UUDpS RS1FQ04tQk9VTkNFU0BJRVRGLk9SRwAAAAAeAF0AAQAAABgAAAByZS1lY24tcmVxdWVzdEBpZXRm Lm9yZwACAV4AAQAAAE0AAAAAAAAAgSsfpL6jEBmdbgDdAQ9UAgAAAAByZS1lY24tcmVxdWVzdEBp ZXRmLm9yZwBTTVRQAHJlLWVjbi1yZXF1ZXN0QGlldGYub3JnAAAAAAIBXwABAAAAHQAAAFNNVFA6 UkUtRUNOLVJFUVVFU1RASUVURi5PUkcAAAAAHgBmAAEAAAAFAAAAU01UUAAAAAAeAGcAAQAAABgA AAByZS1lY24tYm91bmNlc0BpZXRmLm9yZwAeAGgAAQAAAAUAAABTTVRQAAAAAB4AaQABAAAAGAAA AHJlLWVjbi1yZXF1ZXN0QGlldGYub3JnAB4AcAABAAAALQAAAENvbXBsZXRlIGRyYWZ0IENoYXJ0 ZXIgZm9yIHByb3Bvc2VkIENPTkVYIFdHAAAAAAIBcQABAAAAGwAAAAHKjg3ZSGI8lBWdIEfPvs70 sUi6+EYAZWjimgAeAHQAAQAAABAAAAByZS1lY25AaWV0Zi5vcmcAHgAaDAEAAAAUAAAASW5nZW1h ciBKb2hhbnNzb24gUwAeAB0OAQAAAC0AAABDb21wbGV0ZSBkcmFmdCBDaGFydGVyIGZvciBwcm9w b3NlZCBDT05FWCBXRwAAAAACAQkQAQAAAL8ZAAC7GQAAS1oAAExaRnXt3J8kAwAKAHJjcGcxMjWC MgNDaHRtbDEDMD8BAwH3CoACpAPjAgBjaMEKwHNldDAgBxMCgP8QAwBQBFYIVQeyEdUOUQMB3RDX MgYABsMR1TMERhDZ+RLvZjQDxhGFEeMI7wn39jsaHw4wNRs/GxER4QxgzmMAUAsJAWQzNhFgC6Xk NCAQAipcDrIBkA4QADkgPEhUTUwgEGRpcj0gsHI+fc8gcwAhAzAhwWRvAOAhwfkKsVxxGgAhwRDw AzAiJRsRYCArMyAAISBFQUQTIfAgLDc3IRBUSVQ8TEUmHR/wDvAcoC1FQENOIERpZweQdIgsIFYG 8CAxMSmgJkkEEApQIDImLTg13SEQLydfIMIK4yAsXy1vBQ4QNg7wPE1FVEGOIAWgAjAJ8HQ9IgXg wSEzNi4wMC4fYDGRhS/QOS/QIiBuYQeAAD1HRU5FUkFU/E9SLE8urzQ/IJQooSvQLyXfKHE1vyDB NRFgPEI4T0RZJh0fcTivZzkCNiEQRElWIGlkgj09AE9XQVJlC1BAeVRleHQ4K6A4+yEAIY8gAAAj JSPDI4EkH386zzvfPOA+fz+PQJogSTZONER6QM8gpDQ4IRBG4E9OVCBmANAysAcTszBhGbE9IzHR MdEgAJC6ejKwMkRrGDADMGMT8K8DsgHQQK8ghjU8kS9KEhch+SIHJK04IAAmbmLMc3ACgCIYJ2EB QEZPfyDBAcAiBwqiUMgKgCAsMP0loS88wVAfUS9Xf1iPQX//Qo9Dn0SvRb9Gz0ffSO9J9edL/wHx TcxIaU6vT79bif9UX1VvVn9aT1tfXG8mLGJg/SEQUCH6CrEKgW7nYp9jr5dkv2XPdEdJIoBJIClg 6QVAdGgLgGcEIAWhHKBmYwVAPQBlYTzwBCB01m8wYBygYTCgIAIgKoCsSVBewCLwIABwZHug7TJw dQbQEzFvIoAh0ABxDnAZwXtiBCAoVENQASmgUlRQL1VEULoufnEpKaB48QQgcwhg43vABCBPSy5O n2iPbrr/az9sRXIPdF9qxCvBcdFvfz9wj3GedC91P3ZPd19NeftKUAngbHkReiMRAHjSeyb/UX9S j1OaexAJgHpDETF/IdMHgCjBcXVe4GUHgAIwTwQgAiCPk46hZGIA0GveLxygC4ARMAAgaZURIuDv exCQT5FfU5pijoCPony3/X/AVI+xeqF/MAOgeJARMPsqgI8mbnpwlEuPcQdAAyCjlRN6MWxldo7A IAPwu53hAMBrnAF9MQaQZg3g3nUgsHpSAQAAkGcDoHuyfnR/UJpBj7ELgEqAAjBp556wXsADYHBw BJCdgXvB/zBxKWKWknzAetF9AI7QSoD9ESAulx+YL1Oaf++A/4IP/4MfhC+nL4ZPh1+Ib4l/rT/v i5+Mr03qmxJ1ETCk36Xve1OafIFin5FJ0QuAj5V22yAAj7BhBIF6InADYJXA/QJgeba/t8+426Fj juKPU/+e83zABAChdJygwFKelJUV/47QKYCa9HtAvB+9L1Oae3K/nvOPsBygkxOTc6KwYwaQ2Y6A aG8H4H7jYwORfEDvws/D31OatoFkyH/Jj1Oa/HNhjqA9sH2QBpCkMQQQ8wCQAmBlKcufzK+m/9Af /9Ev0j/TT9Rf1W/Wf9ePp+//qP+qD6sfrC/a765Pr1+wb5+xf9sfs5+0r+W3UFN/wN8qQJ+CzyLP co9EeQhgMGH/oCB70M8hnbHYb9l/U5ocoP8DUAeQj7B70J6wESCWknyC/4+xonDOgAVAEPIwoHxh nib/whHsX+1vU5qbcJ+CejF6EP+5wp/LAhCd4MeTyG/zb8TcrwQAoBDPUZURKAeQcHugjwGAEzF8 QI7iYXdhjoD/+4oIYAVAfIF8gJ/xlWEFsT96EBmwo2EFwKKxlpBkKf+kzNwf3S/eP99P4F/hb+J/ f+OP5J8Ez+a/589Nrj2AZ/0eUXMgLC/QOeEzUSIZujD/95EJ7///AQ8RTwtfDG93yf+jYZ9AI3AT LwI/A08EXwVv/wZ/B49eH18vYD8cPw8jHYH/D6wbvyOfJK9y6WG/CX8WT70l1y0tHy4vLz8wTy0O j98PnxCvMa8yv3LpTe9wznBxo3A6IDE0fzWPM5xEI3rBN+BUdWV+wDA1PCBKyCFN0G2AN/AzOulJ 0DozSeArS4I4Hzkv1TOcRqKAbTfgQruwQLB7/yD6oG/CgPevCJD4+Tyl7pliQRRAan9QZ56QjC5i wjB5YC51a0GPemdCqj4z3z3fPu9HtVN4dWJqeaE34A4QN+BbAe8wLUVDTl0gQ92UAHCekHrR8MRD 8TX+Mhe7kc8hxqFDEsBFWCCcV0dIL0k/M5xUbzfgN0WfQp9HtXB5AI7QcC6negAOUJ6QeUBFE21S j59Gr0e/T+9Q/1iyQ2M34CNMAXmgbkBpeMBmLj15cGdY/1oPNp83oi1JvkRSb1N/WGc8MjxBNTyA BxUwXOA7wERtY3Z2fT0gOGTBVfAIsI+wosBh/i5Er1aPV59Yr13vXv9b0cd7AHrQohAtVHmisDfg MXrQeHQvTLDAQG470/ETk7E9IraALZtwxzC8aSJtwP4xn0BuQGb3Mb/LfWofay9pP3D/cg1QVSF+ LHL/dA9yH3Z/d48oqUn0J2264GGioI6AnvDHwP2Z4G99Ae9hpECWQaS9eh//ey95P38vgD2+8v1R wiChAd2O5HM7gLohgCIuheCBL9+CP4BPhk+HXyipQewgJzDXPKD4gDvALzxALzwyO6D/VR9WIp7g ooA7MYkfii+IP/9m72f/keKSH5Mvka+Pv5DPP5cPlY+T/5qfm6+csltC9EJdN+BBo+EgkMgQwADf x2C/APdQfJGigGHxILtSe2XQjZBrzqL20chQFbB1dmOkgOqQZvaQuiDPAWX/TlBVwJdfmG+Zf50v nj+cr/enr6i7yBEn7CD+wOwhyDDpujB0dfYAae/QrHDw0I/7UbmR9gDp8EUuZ+nw/ki6oL/Q66Px MK1hyFBsgP+hp6PvpP+mD6m/qs+pP7Q/57VL9tGshHl3xjN84v1SSFJGQ4xwMjPp8FedwoBrwND3 UGxBRXh8ce5zrEKvo1WAc87A/jGwf/+xj7Kftk+3X7XPwK/Bu6Cx31Yx7+G4o62iO6Bz9uBvwN8V sLnh68CsQqMQZP7A8cT/hSOGD73vvv/Cr8O/wi/ML/+Wj8i/yc/QD86Pz5/Tn9SvndW3SXzQ9UHx 0W5r/RM39ED+cO9QYcVwrvBya14vHwDxIPYAS2F1uYFkbG9jrpG5cSf1sazRZP9VgIXv0Y/Sn9ZP 11/Vz+CP/8+/3R/eL98/4u/j/+Jv6Q/96hlMbjDcIoUxxXDwc/rA/0wQrCB94fVhGBChcurP69/9 57Ux24I7oNow93H+ULnQ/6zB9dD64GXi5S/mP+dP78+v8N/qf/ef+Ktt/qBvjZD9x8Fj24L+JKBw 7mg7oFygf7qgxpFsgEFA21A3sSCBZv5muXFskKN/9H/1j/af+k//+L8DnwSvuITbke3x/7HuMfsg oIRQd6/R7obc7wFPAl//Bg8HHwWPDj/kXwrPC98SH/8QnxGvFa8Wv9hYFIDGYDug/+4xvEDGYMVw hCL+wa8hOyD97yFwCSHGcUEQTOHaAPwQ/9th/xCFwEEQ/KDudxK/E8//FN8YjxmfGA8i7yP7/MLz Ab+MINyQQTBBEKJw73BirSDLxwCE4mJvoGNr2SInwf+sIaJi7nFOoKJCKKLuIh8v/yA/IU8k/yYP JH8vLzA7fUH/TcEJ6FIwx9IcNKJwxVLZ8QBSRUFETUUtRvBJUlNUo0IdQmxxxoH/oHA7oNkQK28s fy2PMT8yT/8wvzu/PMuuINwh/0KgQMbw9xzzrPGO0GSisK+Au0S5tv8n9YTiueCg0K4gN/85Dzof 3z3PPt89T0ev+0xpZVC78v8qQwp/RO9F/0mvSr9Pv03P307fT+9Q/4uIvEAirPmtIP3ckCKu5aJx fbCFMChAjhDfN7FWILnhZVDZ8GSE06zA/zOk/MLvYFKfU69Uv1XPVt//X0Idw9pyrkDY4btQ3JD9 IP+jUe4yfJGNkKwgQzD8UbyQr4SR7yH/oinldG/AYaHw/xxwvL9db15/X49gn2j1x8P+cNtQWgH+ QbrBHDVbQFuX+iJsRSKPH2dvaH9pj2qfsXFzWzNdojKhEXbcgbmsvGV4ABCswPKgabtQ363i7jKg so6A/rBlHODu8cG8QENPTkVYbs9v3/9w73H/cw97X3lven97j3yffYCmU7jAJ6OuIKAA3KBkj+2i ZiGgcAmgczotfi//fz+AT4Ffgm+IT4Zfh2+If/+Jj/GnrkBYIWPPZNUnrG6//4wfjS+OP49Pli+U P5VPll//l29XmK5A7jLHYP6wdoJaoPVkYi+sEXCRZoPk73B2Ef/bISp1WeF01DVBoJIrX5oP/5sf nC+dP6XDeEP8ANsg8xFv72DvQXfgsEBm/hH+sGz/x3DZkqmh2fDa2FqgZiDcoP/bQv4Aox+kL6U/ pk+nX68y//xQTCBksXaR3DIcce3SHODbsnOEMW1l4dwxYrnyrpD/ZbDagbKkvDAccLyAZKDvMP9c f61/ro+vn7CvuO+2/7gP97kfui++N0LbwNoA3JAAEGxveQjzdlFstdDvYS3/Q3PuMqiuZUXBpCpx vdC7z7+8373vvv/AD8hitLco/DDF3GB273BFQ07MAv/g+nIpoHDvcKikdNBCoPLQ/HMptT/Fv8bP x9/I78n//7ufz//RD9If0y+oNsFi8wC/hGHCO9qEhNF00O9AZlqgeVowZnlbYv0RKSB2UGv/W2Ko pNaw/QDUr9W/1s/ev//fz+DZNLBs4EwgACBkoBvxn+9wKaB14WOPZJlnb1tiw0Eh7jJJRVNH4Y/i n//grFnQ/QHuFEH0dMFBIDWAu/1g72FzoVFjUP4wZDew/RsgLu4w6J/pr+Cv7p/vr/PwucFRSSep gFuxd3J08P93oRxw/nFCUP1RWdHmYAAg/x0Kwa9cb/Jf8G520R2g7Kf/hMHFQBzzxMNAsPCAHHDC 4L/1sWVCsyAd4MKACZBu/pHfHUP4n/mv8Iwd4HFYkB3g/wjysqGSZWShHhDuXwBv8H2/2jFYIMVh QEJBwNOwYfBw//6R9NJaBh0LhHDEMFtwnwD/q8DahAQfBS/wjMJXdtEbso9r8eeyKaIpoHNuJ0xg //yiWdAbgu12BA8MD/B/EX//Eo/jzTQQdLJaUc7wWWgbIP5sdeCik1qhHkEPM2zhKaD/07AZpXYQ wjGE2BRfFW8TfOxzL/dvwrAvG/8dDxN/GdfcbmLtYNjZXCdh/jBI2R8F5mbngNyBIE8hX/8eD9qP 25vuMSePKJ8ibyN//ySPJZo0EEDQNwEnFcLRbWH/rDFaMA8zK/8tDy4fLy81//c3D+QJkOFmzcHl s+ynD7H/EF0b7zmfN63C4B8fwrFtBLNZ0XgRIjRioEyxLaAA9WyQKM3wIj5PP19AbgphpwqGQg9D FDNCdIByTLD7s9GpFnNEX0VvN69LD0wf/00vTj9PT8DIF9BQ71H/UA//VE9VX1ZvV39Yj1mfWq9b v/9cz9hv0+rkgmxFoPFdH14v718/YE9hX3QTMXRzonAIAX8KgmzgtBDmwJ8IsrPL0S3/anl3gdyg onCroLJkkoJjj99kn2WvZr9nz3BCZwKQdRF/5cLLYv6x5bOpBwehktFp/mfFn26Pb59wr3G/eE92 X+93b3h/eY9oiDJpM/gwG6H/oSIboGzE+4JDoZ/xMtBtIf2h0mdDMeuVc7l7L3w/fU//fl9/b4eC qQlCgrNA9oD/T/+Fv4bPh9+I745PjF+Nb45/+4+PaHkzaTOiJfgBxXGrgP2rQGnlkYGCwlGB9uXC k1D/wyBsUQfQs1CzoRCQ3eORP/+ST5NflG+Vf53Pm9+c753//58PJbejn6Svoy+hP6JPqI//pw+o H6kvqj+t36xfpT+xb1uyfyXVV4Sg69Fk5/B5u82gY1BttKCwYfWic8MA30jyYuAQQkoB7KBhaqEH 0P8bYTwkMtDOMNzhrl+vb7B//7QvtT+zr75fv2tJ0M4g7WD/3SD8wzLQEECYIMugmIEy4L/m8YIF bFED4EoAasE/up//u6+8v8BvwX+/78mPypvbgF/kguZgl1D9IN4QULmTZfYy5aHC5izFz8bfx+/L n//Mr8sf0+/NPd0h9eAPAuv4jC1JzuC28GMgKO2gO+4B7fB3DxB0kHPxZT+MIHbWoN0hdjYpxb9/ 0S/SP9Xv1v/Vb9+/4MxJfxBAGEQy0Ocg59LtsBBCdP88Atj1z0vbAu3whJF0FO1i/9wP3R/eL+Hf 4u/hX+w/7Ut5uaJUQ9nQSNSXOZiAYf+LQpk2iya4vBFP6X/qj+4/f+9P91/1b/Z/94/4n/ynWfsX cOeAc/JgCbEzoLciK7D8SScHYbd0B2IYOOYPwzL/2fH0n/s//E/9X/5vYlfZxe8mUBEABjAzoHC5 MGoww1F/ufJJ0WqgMwBzUbcAQ+By/nIZUJqzSVGDwbdwarIHH/8w7yV7K7A+AAQfBS8GPwdPvwhf E7LasCrx8vQmUW+X4f8zoBpgl5IBEBaGalCKUGsg9UOAIhhMIsTUMwAy0BD/PxIPEx8ULxU/HaIN EWx1/z1wmiAzoBaHuiUDKbgVtvD954BiuJEW0jPgl2C5eBrv/xv/HQ8eHx8vJ6IhvwHvAzv7aQDY 0mczoCbgajBJgLoi/+eAAGAk7yX/Jw8oHykvKjPeb3QBAGFjEXVQYotgLpH/U9CYsArwFwjO9JhQ DIFBkP81ANuCt3CEMWtgarA98j1A/nku3y/vMP8yDzMfO4IW0ueD4JogmEFyIkOA2IJtUfk24iFd OM853zrvO/89D39C30DvQf9DD0QfYihrIGu/Ls9Gr0e/SM9J305DcNrA/mxLn0yvTb9Oz0/fVC9S Pz9TT1RfVW/tj1p/W49JT35X54KK8ZcxYxFq8jUAdf+KUG0iCcfkdDgRmaEBkWlT+HNjcjUgJN9X /1kPXL//Xc9cP2bvZ/zk0Ldwl/C5YNs3cWUAKtqwujAqLE3DofdgxBcYGSBJLMDlwCQAw9H/Yz9k T2VfaQ9qH2iPc090W9vkdIPAY4JwhFJqgnALJP/YsIPhlzGDEIsgYEAQsBaP78PxGOLngLggd2+P cJ9xr/91X3ZvdN9/38IMGKIXwiDB9zYRLoGYAG5+MGBAlzEg4X81ECIA54DxoLiQ5dENMXf/DGAh 47jAioCXYBqR0B99H/9+L4Hfgu+BX4wfjSy2sPGg2xqwjf8m8mGPOSbjmWuR/4kQ5PC6MLigw7AD /4lfim//jh+PL42fmF9WH5Tvlf+XD9+av5vPmj+g3+OoQaMQuCDfAOHlAGHyt2DygHkh8j6QsC1F Q05vUBehbhnRv88QDAFLQTVxDFC6QWQ/kf/ngAHGnO+d/58Por+jz6I//60vrjsCUTWAeMAKYAIQ xBHttrBjX6AMA2cMMCSwhqH+Z9rwFtQ2cJQxa/M+VKay/6lvqn+rj68/sE+uv7k/uku3eZfoMrsP JrugvEk8t9jCZPQgZnQtYmLwYtCGb6agw/B2d2ctppEF6FBuwfBjcC0wOP++n7wv48YYAtrg6FA1 4GxR/xfRAJG1f7aPt5/Db8R/us+fys/FDGBzFsOHcGZmxpH/NnHk0PRB51AhAVFAskEYEfR1cG7B Jz/AeKQjQMkg/aeydNqVxw/IH8kvzN/N7z/MX9df2GtfoXpANyBJIP8uEDYw87Bi8CIAIfLRsCPw 5Hdrh0IgcSCw8+DQ0v+Ur9Sf1a/ZX9pv2N/iT5wfv97f3+/mL+c/6E/pVV/szz/t3+7v77rpz+rf 6OxCb/5iNZDBlIhcDp8PrvSP9Z//9q/3v/jP+d/67/v//Q/+H///LwA/AU8CXwNvBH8Fjwaf/wev CL8JzwrfC+8M/w4PDx//EC8RPxJPE18UbxV/Fo8Xn/8Yrxm/Gs8b3xzvHf8fDyAf/yEvIj8jTyRf JW8mfyePKJ//Ka8qvyvPLN8t7y7/MA8xH/8yLzM/NE81XzZvN384jzmf/zqvO788zz3fPu8//0EP Qh//Qy9EP0VPRl9Hb0h/SY/FkuxCVG7RYfB2qJFKv5IfxcU4RN4QaWdu8M/x3//o71G/Us9T31Tv Vf9XD1gf+1kvWjMtXY9eWlqPW59Zr/9fn2Cv7B9lv2bP8F9jD2Qf/2IippWTwNEw3QJhYHjQaF8n aW9qf7VBQGmUcGYuPaeAZ2yPbZ9hj+RrPEEje9DQQGY9InHgdHCgczovL3d1gC5v9nYva8KTwS9s QnKAhxAv7cJkInG5cJBmb/CpQHCSDmapQHKAdvB7SFlQgEVSTElOSyB0//N2D3cafX14galAkODk wOBcY2YxXLIxcth6b397f3co5Yfld2JAgc9zTjnyMnFwL0FxsHB/cY9yn7+Fz4bfh++I/4oPixZF xeG7tKGmlURRUN4R0yBWvhHbjGDTIEnPUdIgMoufjK/9irwqk++U/5UgkO+R/4q8J4MPc0GWWTcy 5XdccC/dsIJYljCWPDB0US9EHElWl3mDn+SVMjQ4YYUxRk9OVIV9oGROwE9TQ1JJUKD+mRHvm+GC QKEti3A8onRsMKhAhGd1luBlPWphTiCb9DDBkHDScKhwPWR28DxiLacQoQ+LcNAAKHQWeb5QtKAo p0IpIT0dekB1xeCyEIqhZCIpDFx70oCnUSgpO1y/fTChL4VAon+jj+SGNaCCUEJPRFmnvjeFMUgo VE1Ml3B9saAAHgA1EAEAAABGAAAAPDEzMEVCQjM4Mjc5RTk4NDdCQUFBRTBCOEY5OTA1RjhDNkU0 MEVDQGVzZWFsbXcxMDkuZWVtZWEuZXJpY3Nzb24uc2U+AAAAHgA5EAEAAAAuAAAAPG1haWxtYW4u MTc4LjEyNjI2OTkzNDEuNDgzMi5yZS1lY25AaWV0Zi5vcmc+AAAAHgBHEAEAAAAPAAAAbWVzc2Fn ZS9yZmM4MjIAAAsA8hABAAAAHwDzEAEAAABwAAAAUgBlACUAMwBBACAAIABDAG8AbQBwAGwAZQB0 AGUAIABkAHIAYQBmAHQAIABDAGgAYQByAHQAZQByACAAZgBvAHIAIABwAHIAbwBwAG8AcwBlAGQA IABDAE8ATgBFAFgAIABXAEcALgBFAE0ATAAAAAsA9hAAAAAAQAAHMGR0zHyjj8oBQAAIMDBCATmm j8oBAwDeP69vAAADAPE/HQQAAB4A+D8BAAAAFAAAAEluZ2VtYXIgSm9oYW5zc29uIFMAAgH5PwEA AABIAAAAAAAAANynQMjAQhAatLkIACsv4YIBAAAAAAAAAC9PPUVSSUNTU09OL09VPVNFMi9DTj1S RUNJUElFTlRTL0NOPUVQTElKT0gAHgD6PwEAAAAVAAAAU3lzdGVtIEFkbWluaXN0cmF0b3IAAAAA AgH7PwEAAAAeAAAAAAAAANynQMjAQhAatLkIACsv4YIBAAAAAAAAAC4AAAADAP0/5AQAAAMAGUAA AAAAAwAaQAAAAAADAB1AAAAAAAMAHkAAAAAAHgAwQAEAAAAIAAAARVBMSUpPSAAeADFAAQAAAAgA AABFUExJSk9IAB4AMkABAAAAGAAAAHJlLWVjbi1ib3VuY2VzQGlldGYub3JnAB4AM0ABAAAAGAAA AHJlLWVjbi1yZXF1ZXN0QGlldGYub3JnAB4AOEABAAAACAAAAEVQTElKT0gAHgA5QAEAAAACAAAA LgAAAAMAdkD/////CwApAAAAAAALACMAAAAAAAMABhDVSJhmAwAHEKURAAADABAQAAAAAAMAERAA AAAAHgAIEAEAAABlAAAASElJRklHRVRUSElOR1NDT1JSRUNUSURFQUlTVE9DUkVBVEVPTkVJUERP Q0FOREFOVU1CRVJPRlRSQU5TUE9SVERPQ1MoVENQLFJUUC9VRFApLFRISVNTT1VORFNPS01ZRkVF TAAAAAACAX8AAQAAAEYAAAA8MTMwRUJCMzgyNzlFOTg0N0JBQUFFMEI4Rjk5MDVGOEM2RTQwRUNA ZXNlYWxtdzEwOS5lZW1lYS5lcmljc3Nvbi5zZT4AAAASEg== ------_=_NextPart_001_01CA8FA6.38DD7F26-- ------------=_1262874750-19539-1-- From leslie@thinkingcat.com Thu Jan 7 06:42:59 2010 Return-Path: X-Original-To: re-ecn@core3.amsl.com Delivered-To: re-ecn@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id D5C823A686D for ; Thu, 7 Jan 2010 06:42:59 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.098 X-Spam-Level: X-Spam-Status: No, score=0.098 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FRT_POSSIBLE=2.697] 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 4OBvDnI-tqkj for ; Thu, 7 Jan 2010 06:42:58 -0800 (PST) Received: from zeke.ecotroph.net (zeke.ecotroph.net [70.164.19.155]) by core3.amsl.com (Postfix) with ESMTP id 41AB33A6874 for ; Thu, 7 Jan 2010 06:42:58 -0800 (PST) Received: from beethoven.local ([::ffff:142.167.26.103]) (AUTH: PLAIN leslie, SSL: TLSv1/SSLv3,256bits,AES256-SHA) by zeke.ecotroph.net with esmtp; Thu, 07 Jan 2010 09:42:55 -0500 id 015B008A.4B45F2EF.00003D7A Message-ID: <4B45F2E6.8060909@thinkingcat.com> Date: Thu, 07 Jan 2010 10:42:46 -0400 From: Leslie Daigle User-Agent: Thunderbird 2.0.0.23 (Macintosh/20090812) MIME-Version: 1.0 To: Ingemar Johansson S References: <130EBB38279E9847BAAAE0B8F9905F8C6E40EC@esealmw109.eemea.ericsson.se> In-Reply-To: <130EBB38279E9847BAAAE0B8F9905F8C6E40EC@esealmw109.eemea.ericsson.se> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: re-ecn@ietf.org Subject: Re: [re-ECN] Complete draft Charter for proposed CONEX WG X-BeenThere: re-ecn@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: re-inserted explicit congestion notification List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 07 Jan 2010 14:42:59 -0000 Hi, For the (public) record, here's the most recent version of the charter. Phil sent it along to Lars for his consideration, yesterday. I think we'll wait to hear feedback from him before doing more serious mods on the charter -- I think (hope!) we're really close, and can be focusing on getting the work items moving. Congestion Exposure (CONEX) WG The purpose of the CONEX working group is to develop a mechanism to allow senders to inform the network of the level of congestion they expect their packets to encounter. This information is currently only visible at the transport layer in the end systems. With the output of CONEX, it will be possible to provide sufficient information in each IP datagram so that any node in the network can see the expected rest-of-path congestion. Once any node can see the impact it causes (and suffers) by sending or forwarding packets, it will be possible to hold senders and whole networks accountable for the congestion they cause downstream. Tools that exploit the CONEX output could be used for mitigating distributed denial of service (DDoS); simplifying differentiation of quality of service (QoS); policing compliance to congestion control; and so on. The WG will work on the following topics (see later for the list of documents): 1. An applicability statement that describes: A. the functionality / capability that is expected to be provided by the CONEX mechanism itself, including its architectural features, limitations and assumptions it makes about networks and end systems B. deployability goals - how the CONEX mechanism can be deployed in networks (non vs ECN vs perhaps CONEX routers) and end systems C. security goals - addressing threats from falsifying or blanking CONEX info The purpose is [1] to detail the key functional and non-functional considerations that guide the work on the mechanism's design [2] to allow exploration of use cases to begin before work on the mechanism is complete [3] to provide an intuitive explanation of the new concepts in CONEX 2. Specification of IP (v4 & v6) packet structure to carry CONEX information (header bits, interpretation) 3. Transport-related Best practices and specifications: A. for the timely transport of congestion information from the destination to the sender, B. for ensuring the trustworthiness of the CONEX information (to mitigate the threats identified in 1C) 4. Use cases -- possible uses of CONEX information, which include controlling or reducing congestion and increasing accountability for congestion. The main purpose is to encourage experiments that use CONEX information and to describe their results; it is not to delineate all potential uses cases, nor to provide a full architectural/deployment/security analysis of use cases. Future work may include specifications to implement one or more use cases. The output is Informational and Experimental, apart from #2 which is tentatively slated as Standards track. Depending on the bits that are proposed to be used in the IP header and their semantics (eg Bit 48 in IPv4, ECN nonce), there may need to be further STD or INFO documents to reassign the bits from their current definition(s) (which would be subject to appropriate IESG and IETF review as necessary). Milestones & List of documents to be produced: == Related to Output Item 1 == Feb 2010 Internet-Draft functionality statement (Output item 1A) Mar 2010 Internet-Draft applicability statement (Output item 1A, B, C) July 2010 Applicability statement to WGLC Sep 2010 Applicability statement sent to IESG (INFO) == Related to Output Item 2 == Mar 2010 Proposals (individual I-Ds) for CONEX IPv4 & IPv6 specifications Jun 2010 First WG draft CONEX IPv4 specification Jun 2010 First WG draft CONEX IPv6 specification Nov 2010 CONEX IPv4 specification to WGLC Nov 2010 CONEX IPv6 specification to WGLC Jan 2011 IPv4 specification sent to IESG (STD) Jan 2011 IPv6 specification sent to IESG (STD) == Related to Output Item 3 == Jun 2010 Draft transport-related best practices Jun 2010 Proposals (individual I-Ds) for TCP modification Jun 2010 Proposals (individual I-Ds) for mechanism to ensure trustworthiness of CONEX information Mar 2011 Transport-related Best practices for ensuring the trustworthiness of the CONEX information, including Spec of one mechanism to WGLC (EXP) Mar 2011 Transport-related Best practices for the transport of congestion information from the destination to the sender, including Spec of TCP modification to WGLC (EXP) May 2011 Both transport-related docs sent to IESG == Related to Output Item 4 == May 2010 Internet-Draft use cases Mar 2011 Use cases to WGLC May 2011 Use cases sent to IESG (INFO) == Jun 2011 Close or re-charter Leslie. Ingemar Johansson S wrote: > WARNING: contains banned part > > > ------------------------------------------------------------------------ > > > Subject: Re: Complete draft Charter for proposed CONEX WG From: > "Ingemar Johansson S" Date: Thu, 7 > Jan 2010 15:32:21 +0100 To: > > To: > > > > Hi > > If I get things correct idea is to create one IP doc and a number of > transport docs (TCP, RTP/UDP....), this sounds OK. > > My feeling is that the IP doc needs to set some requirements on the > feedback/reinsertion done by the transport. The reason I see is that > no requirements at all on this level will make it difficult to design > and tune the incentive droppers and congestion rate policers. > > The use of bit 48 in the IPv4 header is probably one thing that will > raise the noise level on the list. The IP doc will here need to > specify how this can be used safely (if posssible) > > PS. Is it possible that you could post a refreshed version of the > draft charter on this list as it is a bit difficult to follow the > discussion (esp after being away after being out of office for a > longer period). > > Regards Ingemar > > > > ---------------------------------------------------------------------- > > > Message: 1 Date: Tue, 05 Jan 2010 13:48:38 +0000 From: Bob Briscoe > Subject: Re: [re-ECN] Complete draft > Charter for proposed CONEX WG To: Cc: > re-ecn@ietf.org Message-ID: > <201001051348.o05Dmcvv008008@bagheera.jungle.bt.co.uk> Content-Type: > text/plain; charset="us-ascii"; format=flowed > > Phil, > > I'm happy with both responses. > > one outstanding issue inline... > > At 11:44 05/01/2010, philip.eardley@bt.com wrote: >>> [BB]: A radically new approach is unlikely to be successful if >>> people can't get an intuitive grasp of it. E.g. HIP would have >>> been unlikely to get anywhere without RFC4423. We know ConEx >>> hasn't been easy for newcomers to grasp, so we shouldn't fudge >>> this issue. >>> >>> I was thinking of a framework/architecture doc. Here's an idea... >>> >>> >>> Let's assume the use-cases item is >1 doc, rather than a single >>> monolithic doc for all use-cases, ie. we encourage different >>> people to document their own use-cases. >>> >>> If so, then someone could attempt to write a more generic >>> use-cases doc that describes building blocks that can be used to >>> build the other use-cases. This could become a README-FIRST if >>> written well, as it's difficult to introduce ConEx without >>> describing how it might be used. >> An "intuitive guide" would be possible, although adding another doc >> is more work. I wonder if the applicability statement can be >> tweaked for this purpose. We could add another "purpose": [3] to >> provide an intuitive explanation of the new concepts in CONEX >> >> So that it reads as follows:- >> >> 1. An applicability statement that describes: >> >> A. the functionality / capability that is expected to be provided >> by the CONEX mechanism itself, including its architectural >> features, limitations and assumptions it makes about networks and >> end systems >> >> B. a deployment analysis - how the CONEX mechanism can be deployed >> in networks (non vs ECN vs perhaps CONEX routers) and end systems >> >> C. a threat analysis - threats from falsifying or blanking CONEX >> info > > The milestones have the applicability statement going to the IESG > before the ConEx protocol is specified, so... > > B. I'm not convinced we will be able to write a deployment analysis > of a protocol as yet to be defined - we can surely only write > requirements at that stage. C. And it's certainly not possible to > write a meaningful threat analysis of something that hasn't yet been > specified. > > These problems would be solved by altering the chartering text as > follows: s/deployment analysis/ /deployability goals/ s/threat > analysis - threats from.../ /security goals - addressing threats > from.../ > > Then after the protocol has been specified: - deployment analysis > could be in "4. use-case(s)" - full threat analysis could be in "3B > trust mechanisms" > > > Bob > > > >> The purpose is [1] to detail the key functional and non-functional >> considerations that guide the work on the mechanism's design >> >> [2] to allow exploration of use cases to begin before work on the >> mechanism is complete >> >> [3] to provide an intuitive explanation of the new concepts in >> CONEX >> >>> Where do you imagine we should put best practice for the sending >>> transport to set its expectation of congestion? - The above EXP >>> for e2e transport, - or within the ConEx-IP doc (if so, which >>> one? v4 or v6)? It would seem to fit better in the e2e transport >>> one, then the spec for TCP could provide an example of the >>> complete best practice. >> Yes, same as you - I'd imagined it would be in the e2e transport >> doc. The IP doc defines packet the structure to carry CONEX >> information - ie what the codepoints are and what they mean. "what >> they mean" of course influences what the sending transport should >> do, but the advice for the sending transport would be in the >> transport doc [things like "send, as soon as possible, a Black >> codepoint for every loss or mark notified by the receiver". or >> whatever!] >> >> Thanks phil >> >>> IOW, this proposal assumes the IP doc would not need to describe >>> semantics of *when* the transport sets the codepoints. Instead it >>> would focus on just the wire protocol - what the codepoints >>> mean, how they are encoded, tunnel processing, router forwarding >>> behaviour, errors & management etc. >>> >>> Altho I'm not implying re-ECN is any more than a candidate, it >>> would be a useful exercise to go through the contents of the >>> re-ECN protocol spec and >>> check where you assume the different sections will end up. I've >>> just done that, which is why I keep bringing up awkward >>> questions. >>> > > ________________________________________________________________ Bob > Briscoe, BT Innovate & Design > > > > ------------------------------ > > _______________________________________________ re-ECN mailing list > re-ECN@ietf.org https://www.ietf.org/mailman/listinfo/re-ecn > > > End of re-ECN Digest, Vol 11, Issue 2 > ************************************* > > > > ------------------------------------------------------------------------ > > > _______________________________________________ re-ECN mailing list > re-ECN@ietf.org https://www.ietf.org/mailman/listinfo/re-ecn -- ------------------------------------------------------------------- "Reality: Yours to discover." -- ThinkingCat Leslie Daigle leslie@thinkingcat.com ------------------------------------------------------------------- From lars.eggert@nokia.com Thu Jan 7 07:13:54 2010 Return-Path: X-Original-To: re-ecn@core3.amsl.com Delivered-To: re-ecn@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id DA7EE3A685E for ; Thu, 7 Jan 2010 07:13:54 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.599 X-Spam-Level: X-Spam-Status: No, score=-3.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Uzhs7EreUiqC for ; Thu, 7 Jan 2010 07:13:54 -0800 (PST) Received: from smtp.tele.fi (smtp.tele.fi [192.89.123.25]) by core3.amsl.com (Postfix) with ESMTP id DB35E3A6838 for ; Thu, 7 Jan 2010 07:13:53 -0800 (PST) X-Originating-Ip: [212.213.221.241] Received: from host-241.nrln.net (host-241.nrln.net [212.213.221.241]) by smtp.tele.fi (Postfix) with ESMTP id 02E45443; Thu, 7 Jan 2010 17:13:46 +0200 (EET) Received: from mail.fit.nokia.com ([212.213.221.40]) by host-241.nrln.net (Lotus Domino Release 6.5) with ESMTP id 2010010717194981-6070 ; Thu, 7 Jan 2010 17:19:49 +0200 Received: from wlan-226.fit.nokia.com (wlan-226.fit.nokia.com [195.148.124.226]) (authenticated bits=0) by mail.fit.nokia.com (8.14.3/8.14.3) with ESMTP id o07FDdh4008102 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NOT); Thu, 7 Jan 2010 17:13:40 +0200 (EET) (envelope-from lars.eggert@nokia.com) Mime-Version: 1.0 (Apple Message framework v1077) From: Lars Eggert In-Reply-To: <4B45F2E6.8060909@thinkingcat.com> Date: Thu, 7 Jan 2010 17:13:39 +0200 Message-Id: References: <130EBB38279E9847BAAAE0B8F9905F8C6E40EC@esealmw109.eemea.ericsson.se> <4B45F2E6.8060909@thinkingcat.com> To: Leslie Daigle X-Mailer: Apple Mail (2.1077) X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.2.3 (mail.fit.nokia.com [195.148.124.194]); Thu, 07 Jan 2010 17:13:40 +0200 (EET) X-MIMETrack: Itemize by SMTP Server on host-241/srv/nrln(Release 6.5|September 26, 2003) at 01/07/2010 05:19:49 PM, Serialize by Router on host-241/srv/nrln(Release 6.5|September 26, 2003) at 01/07/2010 05:19:54 PM, Serialize complete at 01/07/2010 05:19:54 PM Content-Type: multipart/signed; boundary=Apple-Mail-99--1045305240; protocol="application/pkcs7-signature"; micalg=sha1 Cc: Ingemar Johansson S , "re-ecn@ietf.org" Subject: Re: [re-ECN] Complete draft Charter for proposed CONEX WG X-BeenThere: re-ecn@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: re-inserted explicit congestion notification List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 07 Jan 2010 15:13:55 -0000 --Apple-Mail-99--1045305240 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii Hi, On 2010-1-7, at 16:42, Leslie Daigle wrote: > For the (public) record, here's the most recent version of the = charter. > Phil sent it along to Lars for his consideration, yesterday. I think > we'll wait to hear feedback from him before doing more serious mods on > the charter -- I think (hope!) we're really close, and can be focusing > on getting the work items moving. yes, I got it yesterday. I think this captures the points made at the = BOF and during the follow-up discussion really well. I myself have no further comments; I'll being the charter to the = IESG/IAB for discussion. Thanks, Lars --Apple-Mail-99--1045305240 Content-Disposition: attachment; filename=smime.p7s Content-Type: application/pkcs7-signature; name=smime.p7s Content-Transfer-Encoding: base64 MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIGbDCCAyUw ggKOoAMCAQICEAdjk36sXKbnVn15S0/qUp0wDQYJKoZIhvcNAQEFBQAwYjELMAkGA1UEBhMCWkEx JTAjBgNVBAoTHFRoYXd0ZSBDb25zdWx0aW5nIChQdHkpIEx0ZC4xLDAqBgNVBAMTI1RoYXd0ZSBQ ZXJzb25hbCBGcmVlbWFpbCBJc3N1aW5nIENBMB4XDTA5MDYxNTExMjYxNFoXDTEwMDYxNTExMjYx NFowXDEPMA0GA1UEBBMGRWdnZXJ0MQ0wCwYDVQQqEwRMYXJzMRQwEgYDVQQDEwtMYXJzIEVnZ2Vy dDEkMCIGCSqGSIb3DQEJARYVbGFycy5lZ2dlcnRAbm9raWEuY29tMIIBIjANBgkqhkiG9w0BAQEF AAOCAQ8AMIIBCgKCAQEA7mR8A+Pn0/FsUkMX6Pyjw+FL3IFcJk8GaKV5VJ40TMI0Wh8oq20cqA9X uqnVDW9WztKwH+o+msJenLwWpprbpJm4TImYGbnUJxYyN8gb81aiX1Bw2xCpJ5z3H2+8DsReJLuY Rdl4bVvaIxLIL4odmfsRwzPyNkOK8LRtfl6OPcaDOlFWzbikULfIVGGu7BqK4lxQSpYwwpZkOMOB 6nnBSfUOtBEmqO+qZG/nL/JxWFV5vxQgg4XHbsMMTxFf6+ji18BD09BUIfDLTuJoCzFmQhrM9vLT VuRhHWSL20LoafGjXv6mPt3i9IGJHpVb2dMQUgOgRyWHTKiUJVU/rUTdWwIDAQABo14wXDAqBgUr ZQEEAQQhMB8CAQAwGjAYAgEEBBNMMnVNeWZmQk5VYk5KSmNkWjJzMCAGA1UdEQQZMBeBFWxhcnMu ZWdnZXJ0QG5va2lhLmNvbTAMBgNVHRMBAf8EAjAAMA0GCSqGSIb3DQEBBQUAA4GBADUx+67n98wt I1vydB90HeSZP4Y64VCxxb0NxGGFvfc2+JdVKeHJ/xT+l+ygYKsWNwJJprkPi4WZ5G0crkq4VK1H 5drEJIztpSPVfWI05vPidaaGuuuCR+6MvJMtOTEYEvc/6eovBnkrzRf9x5x5EyuJXAWTeuBADg80 QI3vQ1tZMIIDPzCCAqigAwIBAgIBDTANBgkqhkiG9w0BAQUFADCB0TELMAkGA1UEBhMCWkExFTAT BgNVBAgTDFdlc3Rlcm4gQ2FwZTESMBAGA1UEBxMJQ2FwZSBUb3duMRowGAYDVQQKExFUaGF3dGUg Q29uc3VsdGluZzEoMCYGA1UECxMfQ2VydGlmaWNhdGlvbiBTZXJ2aWNlcyBEaXZpc2lvbjEkMCIG A1UEAxMbVGhhd3RlIFBlcnNvbmFsIEZyZWVtYWlsIENBMSswKQYJKoZIhvcNAQkBFhxwZXJzb25h bC1mcmVlbWFpbEB0aGF3dGUuY29tMB4XDTAzMDcxNzAwMDAwMFoXDTEzMDcxNjIzNTk1OVowYjEL MAkGA1UEBhMCWkExJTAjBgNVBAoTHFRoYXd0ZSBDb25zdWx0aW5nIChQdHkpIEx0ZC4xLDAqBgNV BAMTI1RoYXd0ZSBQZXJzb25hbCBGcmVlbWFpbCBJc3N1aW5nIENBMIGfMA0GCSqGSIb3DQEBAQUA A4GNADCBiQKBgQDEpjxVc1X7TrnKmVoeaMB1BHCd3+n/ox7svc31W/Iadr1/DDph8r9RzgHU5VAK MNcCY1osiRVwjt3J8CuFWqo/cVbLrzwLB+fxH5E2JCoTzyvV84J3PQO+K/67GD4Hv0CAAmTXp6a7 n2XRxSpUhQ9IBH+nttE8YQRAHmQZcmC3+wIDAQABo4GUMIGRMBIGA1UdEwEB/wQIMAYBAf8CAQAw QwYDVR0fBDwwOjA4oDagNIYyaHR0cDovL2NybC50aGF3dGUuY29tL1RoYXd0ZVBlcnNvbmFsRnJl ZW1haWxDQS5jcmwwCwYDVR0PBAQDAgEGMCkGA1UdEQQiMCCkHjAcMRowGAYDVQQDExFQcml2YXRl TGFiZWwyLTEzODANBgkqhkiG9w0BAQUFAAOBgQBIjNFQg+oLLswNo2asZw9/r6y+whehQ5aUnX9M Ibj4Nh+qLZ82L8D0HFAgk3A8/a3hYWLD2ToZfoSxmRsAxRoLgnSeJVCUYsfbJ3FXJY3dqZw5jowg T2Vfldr394fWxghOrvbqNOUQGls1TXfjViF4gtwhGTXeJLHTHUb/XV9lTzGCAxAwggMMAgEBMHYw YjELMAkGA1UEBhMCWkExJTAjBgNVBAoTHFRoYXd0ZSBDb25zdWx0aW5nIChQdHkpIEx0ZC4xLDAq BgNVBAMTI1RoYXd0ZSBQZXJzb25hbCBGcmVlbWFpbCBJc3N1aW5nIENBAhAHY5N+rFym51Z9eUtP 6lKdMAkGBSsOAwIaBQCgggFvMBgGCSqGSIb3DQEJAzELBgkqhkiG9w0BBwEwHAYJKoZIhvcNAQkF MQ8XDTEwMDEwNzE1MTM0MFowIwYJKoZIhvcNAQkEMRYEFPxRTvUUbcI3swEkslHGZjkCq1IDMIGF BgkrBgEEAYI3EAQxeDB2MGIxCzAJBgNVBAYTAlpBMSUwIwYDVQQKExxUaGF3dGUgQ29uc3VsdGlu ZyAoUHR5KSBMdGQuMSwwKgYDVQQDEyNUaGF3dGUgUGVyc29uYWwgRnJlZW1haWwgSXNzdWluZyBD QQIQB2OTfqxcpudWfXlLT+pSnTCBhwYLKoZIhvcNAQkQAgsxeKB2MGIxCzAJBgNVBAYTAlpBMSUw IwYDVQQKExxUaGF3dGUgQ29uc3VsdGluZyAoUHR5KSBMdGQuMSwwKgYDVQQDEyNUaGF3dGUgUGVy c29uYWwgRnJlZW1haWwgSXNzdWluZyBDQQIQB2OTfqxcpudWfXlLT+pSnTANBgkqhkiG9w0BAQEF AASCAQAC0vkWFMx/vyihd7I9a1kaIbICBBg/jHnptTW5xOCbUOiUdnVdKpd/p1hd9MYCrV9pAxGD kkMgwDwasMV1dqbK2WEGzFluoTv2x6+dokN+gNiZRWUsklT80lkNky3ah5Vbk4gbOwve3hVmv7Gh D7IjCXFiPERNEKfhIFCKAq35k345nQir9fIO0DZTHYFYQF2cHpxqsOoP0KJxx0YKCn35mEJIyM7R zKd3vx/O7m0QhFS3TFG8VE7Nq7RwPB4PIvS0YbicagWUJFi6/NgvQF3z3ugC24/tBG0wrTj75Uzi fLLPREnIZFXe+g8QMyQq3buBNqGW3FY01kFT/trRQWmqAAAAAAAA --Apple-Mail-99--1045305240-- From rbriscoe@jungle.bt.co.uk Thu Jan 7 09:06:45 2010 Return-Path: X-Original-To: re-ecn@core3.amsl.com Delivered-To: re-ecn@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 9AD923A6896 for ; Thu, 7 Jan 2010 09:06:45 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.154 X-Spam-Level: X-Spam-Status: No, score=-0.154 tagged_above=-999 required=5 tests=[AWL=-0.734, BAYES_00=-2.599, DNS_FROM_RFC_BOGUSMX=1.482, FRT_POSSIBLE=2.697, 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 LBMSKQ7iLb62 for ; Thu, 7 Jan 2010 09:06:38 -0800 (PST) Received: from smtp3.smtp.bt.com (smtp3.smtp.bt.com [217.32.164.138]) by core3.amsl.com (Postfix) with ESMTP id B23433A687A for ; Thu, 7 Jan 2010 09:06:37 -0800 (PST) Received: from i2kc06-ukbr.domain1.systemhost.net ([193.113.197.70]) by smtp3.smtp.bt.com with Microsoft SMTPSVC(6.0.3790.3959); Thu, 7 Jan 2010 17:06:34 +0000 Received: from cbibipnt05.iuser.iroot.adidom.com ([147.149.196.177]) by i2kc06-ukbr.domain1.systemhost.net with Microsoft SMTPSVC(6.0.3790.3959); Thu, 7 Jan 2010 17:06:34 +0000 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 1262883993583; Thu, 7 Jan 2010 17:06:33 +0000 Received: from MUT.jungle.bt.co.uk ([10.73.182.253]) by bagheera.jungle.bt.co.uk (8.13.5/8.12.8) with ESMTP id o07H6TH3026583; Thu, 7 Jan 2010 17:06:29 GMT Message-Id: <201001071706.o07H6TH3026583@bagheera.jungle.bt.co.uk> X-Mailer: QUALCOMM Windows Eudora Version 7.1.0.9 Date: Thu, 07 Jan 2010 17:06:30 +0000 To: Leslie Daigle From: Bob Briscoe In-Reply-To: <4B45F2E6.8060909@thinkingcat.com> References: <130EBB38279E9847BAAAE0B8F9905F8C6E40EC@esealmw109.eemea.ericsson.se> <4B45F2E6.8060909@thinkingcat.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: 07 Jan 2010 17:06:34.0975 (UTC) FILETIME=[C45FCEF0:01CA8FBB] Cc: re-ecn@ietf.org Subject: Re: [re-ECN] Complete draft Charter for proposed CONEX WG X-BeenThere: re-ecn@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: re-inserted explicit congestion notification List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 07 Jan 2010 17:06:45 -0000 Leslie, Thanks for this. I'm v happy with the milestones now. Glad to see Lars is happy too. On reading thru, I've included one item inline to queue up: for if there's a future opportunity for mods... At 14:42 07/01/2010, Leslie Daigle wrote: >Hi, > >For the (public) record, here's the most recent version of the >charter. Phil sent it along to Lars for his consideration, >yesterday. I think we'll wait to hear feedback from him before >doing more serious mods on the charter -- I think (hope!) we're >really close, and can be focusing on getting the work items moving. > > >Congestion Exposure (CONEX) WG > >The purpose of the CONEX working group is to develop a mechanism to >allow senders to inform the network of the level of congestion they >expect their packets to encounter. This information is currently only >visible at the transport layer in the end systems. With the output >of CONEX, it will be >possible to provide sufficient information in each IP datagram so that >any node in the network can see the expected rest-of-path congestion. >Once any node can see the impact it causes (and suffers) by sending or >forwarding packets, it will be possible to hold senders and whole >networks accountable for the congestion they cause downstream. Tools >that exploit the CONEX output could be used for sharing capacity, [we seem to have omitted the primary, most generic use: accountability for contributing to congestion!] >mitigating distributed >denial of service (DDoS); simplifying differentiation of quality of >service (QoS); policing compliance to congestion control; and so on. > >The WG will work on the following topics (see later for the list of >documents): > >1. An applicability statement that describes: > >A. the functionality / capability that is expected to be provided by >the CONEX mechanism itself, including its architectural features, >limitations and assumptions it makes about networks and end systems > >B. deployability goals - how the CONEX mechanism can be deployed in >networks (non vs ECN vs perhaps CONEX routers) and end systems > >C. security goals - addressing threats from falsifying or blanking CONEX info > >The purpose is >[1] to detail the key functional and non-functional considerations >that guide the work on the mechanism's design > >[2] to allow exploration of use cases to begin before work on the >mechanism is complete > >[3] to provide an intuitive explanation of the new concepts in CONEX > >2. Specification of IP (v4 & v6) packet structure to carry CONEX >information (header bits, interpretation) > >3. Transport-related Best practices and specifications: > >A. for the timely transport of congestion information from the >destination to the sender, > >B. for ensuring the trustworthiness of the CONEX information (to >mitigate the threats identified in 1C) > >4. Use cases -- possible uses of CONEX information, which include >controlling or reducing congestion and increasing accountability for >congestion. The main purpose is to encourage experiments that use >CONEX information and to describe their results; it is not to >delineate all potential uses cases, nor to provide a full >architectural/deployment/security analysis of use cases. Future work >may include specifications to implement one or more use cases. > >The output is Informational and Experimental, apart from #2 which is >tentatively slated as Standards track. Depending on the bits that >are proposed to be used in the IP header and their semantics (eg Bit >48 in IPv4, ECN nonce), there may need to be further STD or INFO >documents to reassign the bits from their current definition(s) >(which would be subject to appropriate IESG and IETF review as necessary). > > >Milestones & List of documents to be produced: > >== Related to Output Item 1 == > >Feb 2010 Internet-Draft functionality statement (Output item 1A) > >Mar 2010 Internet-Draft applicability statement (Output item 1A, B, C) > >July 2010 Applicability statement to WGLC > >Sep 2010 Applicability statement sent to IESG (INFO) > >== Related to Output Item 2 == > >Mar 2010 Proposals (individual I-Ds) for CONEX IPv4 & IPv6 specifications > >Jun 2010 First WG draft CONEX IPv4 specification > >Jun 2010 First WG draft CONEX IPv6 specification > >Nov 2010 CONEX IPv4 specification to WGLC > >Nov 2010 CONEX IPv6 specification to WGLC > >Jan 2011 IPv4 specification sent to IESG (STD) > >Jan 2011 IPv6 specification sent to IESG (STD) > >== Related to Output Item 3 == > >Jun 2010 Draft transport-related best practices > >Jun 2010 Proposals (individual I-Ds) for TCP modification > >Jun 2010 Proposals (individual I-Ds) for mechanism to ensure >trustworthiness of CONEX information > >Mar 2011 Transport-related Best practices for ensuring the >trustworthiness of the CONEX information, including Spec of one >mechanism to WGLC (EXP) > >Mar 2011 Transport-related Best practices for the transport of >congestion information from the destination to the sender, including >Spec of TCP modification to WGLC (EXP) > >May 2011 Both transport-related docs sent to IESG > >== Related to Output Item 4 == > >May 2010 Internet-Draft use cases > >Mar 2011 Use cases to WGLC > >May 2011 Use cases sent to IESG (INFO) > >== >Jun 2011 Close or re-charter > > > > >Leslie. > >Ingemar Johansson S wrote: >>WARNING: contains banned part >> >>------------------------------------------------------------------------ >> >>Subject: Re: Complete draft Charter for proposed CONEX WG From: >>"Ingemar Johansson S" Date: Thu, 7 >>Jan 2010 15:32:21 +0100 To: >>To: >> >>Hi >>If I get things correct idea is to create one IP doc and a number of >>transport docs (TCP, RTP/UDP....), this sounds OK. >>My feeling is that the IP doc needs to set some requirements on the >>feedback/reinsertion done by the transport. The reason I see is that >>no requirements at all on this level will make it difficult to design >>and tune the incentive droppers and congestion rate policers. >>The use of bit 48 in the IPv4 header is probably one thing that will >>raise the noise level on the list. The IP doc will here need to >>specify how this can be used safely (if posssible) >>PS. Is it possible that you could post a refreshed version of the >>draft charter on this list as it is a bit difficult to follow the >>discussion (esp after being away after being out of office for a >>longer period). >>Regards Ingemar >> >>---------------------------------------------------------------------- >> >>Message: 1 Date: Tue, 05 Jan 2010 13:48:38 +0000 From: Bob Briscoe >> Subject: Re: [re-ECN] Complete draft >>Charter for proposed CONEX WG To: Cc: >>re-ecn@ietf.org Message-ID: >><201001051348.o05Dmcvv008008@bagheera.jungle.bt.co.uk> Content-Type: >>text/plain; charset="us-ascii"; format=flowed >>Phil, >>I'm happy with both responses. >>one outstanding issue inline... >>At 11:44 05/01/2010, philip.eardley@bt.com wrote: >>>>[BB]: A radically new approach is unlikely to be successful if >>>>people can't get an intuitive grasp of it. E.g. HIP would have >>>>been unlikely to get anywhere without RFC4423. We know ConEx >>>>hasn't been easy for newcomers to grasp, so we shouldn't fudge >>>>this issue. >>>>I was thinking of a framework/architecture doc. Here's an idea... >>>> >>>>Let's assume the use-cases item is >1 doc, rather than a single >>>>monolithic doc for all use-cases, ie. we encourage different >>>>people to document their own use-cases. >>>>If so, then someone could attempt to write a more generic >>>>use-cases doc that describes building blocks that can be used to >>>>build the other use-cases. This could become a README-FIRST if >>>>written well, as it's difficult to introduce ConEx without >>>>describing how it might be used. >>>An "intuitive guide" would be possible, although adding another doc >>>is more work. I wonder if the applicability statement can be >>>tweaked for this purpose. We could add another "purpose": [3] to >>>provide an intuitive explanation of the new concepts in CONEX >>>So that it reads as follows:- >>>1. An applicability statement that describes: >>>A. the functionality / capability that is expected to be provided >>>by the CONEX mechanism itself, including its architectural >>>features, limitations and assumptions it makes about networks and >>>end systems >>>B. a deployment analysis - how the CONEX mechanism can be deployed >>>in networks (non vs ECN vs perhaps CONEX routers) and end systems >>>C. a threat analysis - threats from falsifying or blanking CONEX >>>info >>The milestones have the applicability statement going to the IESG >>before the ConEx protocol is specified, so... >>B. I'm not convinced we will be able to write a deployment analysis >>of a protocol as yet to be defined - we can surely only write >>requirements at that stage. C. And it's certainly not possible to >>write a meaningful threat analysis of something that hasn't yet been >>specified. >>These problems would be solved by altering the chartering text as >>follows: s/deployment analysis/ /deployability goals/ s/threat >>analysis - threats from.../ /security goals - addressing threats >>from.../ >>Then after the protocol has been specified: - deployment analysis >>could be in "4. use-case(s)" - full threat analysis could be in "3B >>trust mechanisms" >> >>Bob >> >> >>>The purpose is [1] to detail the key functional and non-functional >>>considerations that guide the work on the mechanism's design >>>[2] to allow exploration of use cases to begin before work on the >>>mechanism is complete >>>[3] to provide an intuitive explanation of the new concepts in >>>CONEX >>> >>>>Where do you imagine we should put best practice for the sending >>>>transport to set its expectation of congestion? - The above EXP >>>>for e2e transport, - or within the ConEx-IP doc (if so, which >>>>one? v4 or v6)? It would seem to fit better in the e2e transport >>>>one, then the spec for TCP could provide an example of the >>>>complete best practice. >>>Yes, same as you - I'd imagined it would be in the e2e transport >>>doc. The IP doc defines packet the structure to carry CONEX >>>information - ie what the codepoints are and what they mean. "what >>>they mean" of course influences what the sending transport should >>>do, but the advice for the sending transport would be in the >>>transport doc [things like "send, as soon as possible, a Black >>>codepoint for every loss or mark notified by the receiver". or >>>whatever!] >>>Thanks phil >>> >>>>IOW, this proposal assumes the IP doc would not need to describe >>>>semantics of *when* the transport sets the codepoints. Instead it >>>> would focus on just the wire protocol - what the codepoints >>>>mean, how they are encoded, tunnel processing, router forwarding >>>>behaviour, errors & management etc. >>>>Altho I'm not implying re-ECN is any more than a candidate, it >>>>would be a useful exercise to go through the contents of the >>>>re-ECN protocol spec and >>>>check where you assume the different sections will end up. I've >>>>just done that, which is why I keep bringing up awkward >>>>questions. >>________________________________________________________________ Bob >>Briscoe, BT Innovate & Design >> >>------------------------------ >>_______________________________________________ re-ECN mailing list >>re-ECN@ietf.org https://www.ietf.org/mailman/listinfo/re-ecn >> >>End of re-ECN Digest, Vol 11, Issue 2 ************************************* >> >>------------------------------------------------------------------------ >> >>_______________________________________________ re-ECN mailing list >>re-ECN@ietf.org https://www.ietf.org/mailman/listinfo/re-ecn > >-- > >------------------------------------------------------------------- >"Reality: > Yours to discover." > -- ThinkingCat >Leslie Daigle >leslie@thinkingcat.com >------------------------------------------------------------------- >_______________________________________________ >re-ECN mailing list >re-ECN@ietf.org >https://www.ietf.org/mailman/listinfo/re-ecn ________________________________________________________________ Bob Briscoe, BT Innovate & Design From ingemar.s.johansson@ericsson.com Fri Jan 8 02:34:22 2010 Return-Path: X-Original-To: re-ecn@core3.amsl.com Delivered-To: re-ecn@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 62A303A6768 for ; Fri, 8 Jan 2010 02:34:22 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.552 X-Spam-Level: X-Spam-Status: No, score=-3.552 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FRT_POSSIBLE=2.697, HELO_EQ_SE=0.35, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id RZ1sPDj67dwT for ; Fri, 8 Jan 2010 02:34:20 -0800 (PST) Received: from mailgw5.ericsson.se (mailgw5.ericsson.se [193.180.251.36]) by core3.amsl.com (Postfix) with ESMTP id 38AB63A680F for ; Fri, 8 Jan 2010 02:34:19 -0800 (PST) X-AuditID: c1b4fb24-b7bb6ae000001052-72-4b470a284102 Received: from esealmw128.eemea.ericsson.se (Unknown_Domain [153.88.253.124]) by mailgw5.ericsson.se (Symantec Mail Security) with SMTP id 3A.C9.04178.82A074B4; Fri, 8 Jan 2010 11:34:17 +0100 (CET) Received: from esealmw109.eemea.ericsson.se ([153.88.200.2]) by esealmw128.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.3959); Fri, 8 Jan 2010 11:33:08 +0100 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Date: Fri, 8 Jan 2010 11:33:07 +0100 Message-ID: <130EBB38279E9847BAAAE0B8F9905F8C6E40ED@esealmw109.eemea.ericsson.se> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [re-ECN] Complete draft Charter for proposed CONEX WG Thread-Index: AcqPp7TcxFBfjO1ERJeEG5Izpg/3AwAo6qNN References: <130EBB38279E9847BAAAE0B8F9905F8C6E40EC@esealmw109.eemea.ericsson.se> <4B45F2E6.8060909@thinkingcat.com> From: "Ingemar Johansson S" To: "Leslie Daigle" , , , X-OriginalArrivalTime: 08 Jan 2010 10:33:08.0093 (UTC) FILETIME=[F7FD3AD0:01CA904D] X-Brightmail-Tracker: AAAAAA== Cc: re-ecn@ietf.org Subject: Re: [re-ECN] Complete draft Charter for proposed CONEX WG X-BeenThere: re-ecn@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: re-inserted explicit congestion notification List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 08 Jan 2010 10:34:22 -0000 Hi =20 Looks good as far as I can see.=20 =20 I have one question/comment however regarding the mechanism for IPv4.=20 The milestone says "IPv4 specification sent to IESG (STD)" This sounds reasonable but I recall that earlier it was considered as = EXP for IPv4 or ?. Asking because I can imagine that people may have = strong feelings esp. about the use for bit 48. =20 Also I can see that the text says "tentatively slated as standards = track". This may cause some confusion as the milestone says STD. =20 Regards Ingemar ________________________________ Fr=E5n: Leslie Daigle [mailto:leslie@thinkingcat.com] Skickat: to 2010-01-07 15:42 Till: Ingemar Johansson S Kopia: re-ecn@ietf.org =C4mne: Re: [re-ECN] Complete draft Charter for proposed CONEX WG Hi, For the (public) record, here's the most recent version of the charter. Phil sent it along to Lars for his consideration, yesterday. I think we'll wait to hear feedback from him before doing more serious mods on the charter -- I think (hope!) we're really close, and can be focusing on getting the work items moving. Congestion Exposure (CONEX) WG The purpose of the CONEX working group is to develop a mechanism to allow senders to inform the network of the level of congestion they expect their packets to encounter. This information is currently only visible at the transport layer in the end systems. With the output of CONEX, it will be possible to provide sufficient information in each IP datagram so that any node in the network can see the expected rest-of-path congestion. Once any node can see the impact it causes (and suffers) by sending or forwarding packets, it will be possible to hold senders and whole networks accountable for the congestion they cause downstream. Tools that exploit the CONEX output could be used for mitigating distributed denial of service (DDoS); simplifying differentiation of quality of service (QoS); policing compliance to congestion control; and so on. The WG will work on the following topics (see later for the list of documents): 1. An applicability statement that describes: A. the functionality / capability that is expected to be provided by the CONEX mechanism itself, including its architectural features, limitations and assumptions it makes about networks and end systems B. deployability goals - how the CONEX mechanism can be deployed in networks (non vs ECN vs perhaps CONEX routers) and end systems C. security goals - addressing threats from falsifying or blanking CONEX info The purpose is [1] to detail the key functional and non-functional considerations that guide the work on the mechanism's design [2] to allow exploration of use cases to begin before work on the mechanism is complete [3] to provide an intuitive explanation of the new concepts in CONEX 2. Specification of IP (v4 & v6) packet structure to carry CONEX information (header bits, interpretation) 3. Transport-related Best practices and specifications: A. for the timely transport of congestion information from the destination to the sender, B. for ensuring the trustworthiness of the CONEX information (to mitigate the threats identified in 1C) 4. Use cases -- possible uses of CONEX information, which include controlling or reducing congestion and increasing accountability for congestion. The main purpose is to encourage experiments that use CONEX information and to describe their results; it is not to delineate all potential uses cases, nor to provide a full architectural/deployment/security analysis of use cases. Future work may include specifications to implement one or more use cases. The output is Informational and Experimental, apart from #2 which is tentatively slated as Standards track. Depending on the bits that are proposed to be used in the IP header and their semantics (eg Bit 48 in IPv4, ECN nonce), there may need to be further STD or INFO documents to reassign the bits from their current definition(s) (which would be subject to appropriate IESG and IETF review as necessary). Milestones & List of documents to be produced: =3D=3D Related to Output Item 1 =3D=3D Feb 2010 Internet-Draft functionality statement (Output item 1A) Mar 2010 Internet-Draft applicability statement (Output item 1A, B, C) July 2010 Applicability statement to WGLC Sep 2010 Applicability statement sent to IESG (INFO) =3D=3D Related to Output Item 2 =3D=3D Mar 2010 Proposals (individual I-Ds) for CONEX IPv4 & IPv6 = specifications Jun 2010 First WG draft CONEX IPv4 specification Jun 2010 First WG draft CONEX IPv6 specification Nov 2010 CONEX IPv4 specification to WGLC Nov 2010 CONEX IPv6 specification to WGLC Jan 2011 IPv4 specification sent to IESG (STD) Jan 2011 IPv6 specification sent to IESG (STD) =3D=3D Related to Output Item 3 =3D=3D Jun 2010 Draft transport-related best practices Jun 2010 Proposals (individual I-Ds) for TCP modification Jun 2010 Proposals (individual I-Ds) for mechanism to ensure trustworthiness of CONEX information Mar 2011 Transport-related Best practices for ensuring the trustworthiness of the CONEX information, including Spec of one mechanism to WGLC (EXP) Mar 2011 Transport-related Best practices for the transport of congestion information from the destination to the sender, including Spec of TCP modification to WGLC (EXP) May 2011 Both transport-related docs sent to IESG =3D=3D Related to Output Item 4 =3D=3D May 2010 Internet-Draft use cases Mar 2011 Use cases to WGLC May 2011 Use cases sent to IESG (INFO) =3D=3D Jun 2011 Close or re-charter Leslie. Ingemar Johansson S wrote: > WARNING: contains banned part > > > = ------------------------------------------------------------------------ > > > Subject: Re: Complete draft Charter for proposed CONEX WG From: > "Ingemar Johansson S" Date: Thu, 7 > Jan 2010 15:32:21 +0100 To: > > To: > > > > Hi > > If I get things correct idea is to create one IP doc and a number of > transport docs (TCP, RTP/UDP....), this sounds OK. > > My feeling is that the IP doc needs to set some requirements on the > feedback/reinsertion done by the transport. The reason I see is that > no requirements at all on this level will make it difficult to design > and tune the incentive droppers and congestion rate policers. > > The use of bit 48 in the IPv4 header is probably one thing that will > raise the noise level on the list. The IP doc will here need to > specify how this can be used safely (if posssible) > > PS. Is it possible that you could post a refreshed version of the > draft charter on this list as it is a bit difficult to follow the > discussion (esp after being away after being out of office for a > longer period). > > Regards Ingemar > > > > ---------------------------------------------------------------------- > > > Message: 1 Date: Tue, 05 Jan 2010 13:48:38 +0000 From: Bob Briscoe > Subject: Re: [re-ECN] Complete draft > Charter for proposed CONEX WG To: Cc: > re-ecn@ietf.org Message-ID: > <201001051348.o05Dmcvv008008@bagheera.jungle.bt.co.uk> Content-Type: > text/plain; charset=3D"us-ascii"; format=3Dflowed > > Phil, > > I'm happy with both responses. > > one outstanding issue inline... > > At 11:44 05/01/2010, philip.eardley@bt.com wrote: >>> [BB]: A radically new approach is unlikely to be successful if >>> people can't get an intuitive grasp of it. E.g. HIP would have >>> been unlikely to get anywhere without RFC4423. We know ConEx >>> hasn't been easy for newcomers to grasp, so we shouldn't fudge >>> this issue. >>> >>> I was thinking of a framework/architecture doc. Here's an idea... >>> >>> >>> Let's assume the use-cases item is >1 doc, rather than a single >>> monolithic doc for all use-cases, ie. we encourage different >>> people to document their own use-cases. >>> >>> If so, then someone could attempt to write a more generic >>> use-cases doc that describes building blocks that can be used to >>> build the other use-cases. This could become a README-FIRST if >>> written well, as it's difficult to introduce ConEx without >>> describing how it might be used. >> An "intuitive guide" would be possible, although adding another doc >> is more work. I wonder if the applicability statement can be >> tweaked for this purpose. We could add another "purpose": [3] to >> provide an intuitive explanation of the new concepts in CONEX >> >> So that it reads as follows:- >> >> 1. An applicability statement that describes: >> >> A. the functionality / capability that is expected to be provided >> by the CONEX mechanism itself, including its architectural >> features, limitations and assumptions it makes about networks and >> end systems >> >> B. a deployment analysis - how the CONEX mechanism can be deployed >> in networks (non vs ECN vs perhaps CONEX routers) and end systems >> >> C. a threat analysis - threats from falsifying or blanking CONEX >> info > > The milestones have the applicability statement going to the IESG > before the ConEx protocol is specified, so... > > B. I'm not convinced we will be able to write a deployment analysis > of a protocol as yet to be defined - we can surely only write > requirements at that stage. C. And it's certainly not possible to > write a meaningful threat analysis of something that hasn't yet been > specified. > > These problems would be solved by altering the chartering text as > follows: s/deployment analysis/ /deployability goals/ s/threat > analysis - threats from.../ /security goals - addressing threats > from.../ > > Then after the protocol has been specified: - deployment analysis > could be in "4. use-case(s)" - full threat analysis could be in "3B > trust mechanisms" > > > Bob > > > >> The purpose is [1] to detail the key functional and non-functional >> considerations that guide the work on the mechanism's design >> >> [2] to allow exploration of use cases to begin before work on the >> mechanism is complete >> >> [3] to provide an intuitive explanation of the new concepts in >> CONEX >> >>> Where do you imagine we should put best practice for the sending >>> transport to set its expectation of congestion? - The above EXP >>> for e2e transport, - or within the ConEx-IP doc (if so, which >>> one? v4 or v6)? It would seem to fit better in the e2e transport >>> one, then the spec for TCP could provide an example of the >>> complete best practice. >> Yes, same as you - I'd imagined it would be in the e2e transport >> doc. The IP doc defines packet the structure to carry CONEX >> information - ie what the codepoints are and what they mean. "what >> they mean" of course influences what the sending transport should >> do, but the advice for the sending transport would be in the >> transport doc [things like "send, as soon as possible, a Black >> codepoint for every loss or mark notified by the receiver". or >> whatever!] >> >> Thanks phil >> >>> IOW, this proposal assumes the IP doc would not need to describe >>> semantics of *when* the transport sets the codepoints. Instead it >>> would focus on just the wire protocol - what the codepoints >>> mean, how they are encoded, tunnel processing, router forwarding >>> behaviour, errors & management etc. >>> >>> Altho I'm not implying re-ECN is any more than a candidate, it >>> would be a useful exercise to go through the contents of the >>> re-ECN protocol spec and >>> check where you assume the different sections will end up. I've >>> just done that, which is why I keep bringing up awkward >>> questions. >>> > > ________________________________________________________________ Bob > Briscoe, BT Innovate & Design > > > > ------------------------------ > > _______________________________________________ re-ECN mailing list > re-ECN@ietf.org https://www.ietf.org/mailman/listinfo/re-ecn > > > End of re-ECN Digest, Vol 11, Issue 2 > ************************************* > > > > = ------------------------------------------------------------------------ > > > _______________________________________________ re-ECN mailing list > re-ECN@ietf.org https://www.ietf.org/mailman/listinfo/re-ecn -- ------------------------------------------------------------------- "Reality: Yours to discover." -- ThinkingCat Leslie Daigle leslie@thinkingcat.com ------------------------------------------------------------------- From philip.eardley@bt.com Fri Jan 8 03:11:19 2010 Return-Path: X-Original-To: re-ecn@core3.amsl.com Delivered-To: re-ecn@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id F026C3A6954 for ; Fri, 8 Jan 2010 03:11:19 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.206 X-Spam-Level: X-Spam-Status: No, score=-1.206 tagged_above=-999 required=5 tests=[AWL=-0.904, BAYES_00=-2.599, FRT_POSSIBLE=2.697, J_CHICKENPOX_72=0.6, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id scVTnzj2HJhs for ; Fri, 8 Jan 2010 03:11:18 -0800 (PST) Received: from smtp2.smtp.bt.com (smtp2.smtp.bt.com [217.32.164.150]) by core3.amsl.com (Postfix) with ESMTP id BFE223A6958 for ; Fri, 8 Jan 2010 03:11:17 -0800 (PST) Received: from E03MVB1-UKBR.domain1.systemhost.net ([193.113.197.109]) by smtp2.smtp.bt.com with Microsoft SMTPSVC(6.0.3790.3959); Fri, 8 Jan 2010 11:11:14 +0000 x-mimeole: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Date: Fri, 8 Jan 2010 11:11:14 -0000 Message-ID: <4A916DBC72536E419A0BD955EDECEDEC06363C40@E03MVB1-UKBR.domain1.systemhost.net> In-Reply-To: <130EBB38279E9847BAAAE0B8F9905F8C6E40ED@esealmw109.eemea.ericsson.se> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [re-ECN] Complete draft Charter for proposed CONEX WG Thread-Index: AcqPp7TcxFBfjO1ERJeEG5Izpg/3AwAo6qNNAAHRp7A= From: To: , , , X-OriginalArrivalTime: 08 Jan 2010 11:11:14.0440 (UTC) FILETIME=[4AC21880:01CA9053] Cc: re-ecn@ietf.org Subject: Re: [re-ECN] Complete draft Charter for proposed CONEX WG X-BeenThere: re-ecn@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: re-inserted explicit congestion notification List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 08 Jan 2010 11:11:20 -0000 Idea is that we should try for STD - as the pkt structure is the key = thing that needs to be standardised. There arent a whole lot of choices = and not sure that you could do expts to distnguish between them. What track the various items are on is something that we expected the = iesg would have input on, hence "tentatively slated". Perhaps could have = been phrased better - anyway, it's in with the iesg now.=20 Thanks phil > -----Original Message----- > From: Ingemar Johansson S [mailto:ingemar.s.johansson@ericsson.com]=20 > Sent: 08 January 2010 10:33 > To: Leslie Daigle; lars.eggert@nokia.com; Briscoe,RJ,Bob,XVR9=20 > BRISCORJ R; Eardley,PL,Philip,DEE1 R > Cc: re-ecn@ietf.org > Subject: Re: [re-ECN] Complete draft Charter for proposed CONEX WG >=20 >=20 > Hi > =20 > Looks good as far as I can see.=20 > =20 > I have one question/comment however regarding the mechanism for IPv4.=20 > The milestone says "IPv4 specification sent to IESG (STD)" > This sounds reasonable but I recall that earlier it was=20 > considered as EXP for IPv4 or ?. Asking because I can imagine=20 > that people may have strong feelings esp. about the use for bit 48. =20 > Also I can see that the text says "tentatively slated as=20 > standards track". This may cause some confusion as the=20 > milestone says STD. > =20 > Regards > Ingemar >=20 > ________________________________ >=20 > Fr=E5n: Leslie Daigle [mailto:leslie@thinkingcat.com] > Skickat: to 2010-01-07 15:42 > Till: Ingemar Johansson S > Kopia: re-ecn@ietf.org > =C4mne: Re: [re-ECN] Complete draft Charter for proposed CONEX WG >=20 >=20 >=20 >=20 > Hi, >=20 > For the (public) record, here's the most recent version of=20 > the charter. > Phil sent it along to Lars for his consideration,=20 > yesterday. I think we'll wait to hear feedback from him=20 > before doing more serious mods on the charter -- I think=20 > (hope!) we're really close, and can be focusing on getting=20 > the work items moving. >=20 >=20 > Congestion Exposure (CONEX) WG >=20 > The purpose of the CONEX working group is to develop a=20 > mechanism to allow senders to inform the network of the level=20 > of congestion they expect their packets to encounter. This=20 > information is currently only visible at the transport layer=20 > in the end systems. With the output of CONEX, it will be=20 > possible to provide sufficient information in each IP=20 > datagram so that any node in the network can see the expected=20 > rest-of-path congestion. Once any node can see the impact it=20 > causes (and suffers) by sending or forwarding packets, it=20 > will be possible to hold senders and whole networks=20 > accountable for the congestion they cause downstream. Tools=20 > that exploit the CONEX output could be used for mitigating=20 > distributed denial of service (DDoS); simplifying=20 > differentiation of quality of service (QoS); policing=20 > compliance to congestion control; and so on. >=20 > The WG will work on the following topics (see later for the list of > documents): >=20 > 1. An applicability statement that describes: >=20 > A. the functionality / capability that is expected to be=20 > provided by the CONEX mechanism itself, including its=20 > architectural features, limitations and assumptions it makes=20 > about networks and end systems >=20 > B. deployability goals - how the CONEX mechanism can be=20 > deployed in networks (non vs ECN vs perhaps CONEX routers)=20 > and end systems >=20 > C. security goals - addressing threats from falsifying or=20 > blanking CONEX info >=20 > The purpose is > [1] to detail the key functional and non-functional=20 > considerations that guide the work on the mechanism's design >=20 > [2] to allow exploration of use cases to begin before work on=20 > the mechanism is complete >=20 > [3] to provide an intuitive explanation of the new concepts in CONEX >=20 > 2. Specification of IP (v4 & v6) packet structure to carry=20 > CONEX information (header bits, interpretation) >=20 > 3. Transport-related Best practices and specifications: >=20 > A. for the timely transport of congestion information from=20 > the destination to the sender, >=20 > B. for ensuring the trustworthiness of the CONEX information=20 > (to mitigate the threats identified in 1C) >=20 > 4. Use cases -- possible uses of CONEX information, which=20 > include controlling or reducing congestion and increasing=20 > accountability for congestion. The main purpose is to=20 > encourage experiments that use CONEX information and to=20 > describe their results; it is not to delineate all potential=20 > uses cases, nor to provide a full=20 > architectural/deployment/security analysis of use cases.=20 > Future work may include specifications to implement one or=20 > more use cases. >=20 > The output is Informational and Experimental, apart from #2=20 > which is tentatively slated as Standards track. Depending on=20 > the bits that are proposed to be used in the IP header and=20 > their semantics (eg Bit 48 in IPv4, ECN nonce), there may=20 > need to be further STD or INFO documents to reassign the bits=20 > from their current definition(s) (which would be subject to=20 > appropriate IESG and IETF review as necessary). >=20 >=20 > Milestones & List of documents to be produced: >=20 > =3D=3D Related to Output Item 1 =3D=3D >=20 > Feb 2010 Internet-Draft functionality statement (Output item 1A) >=20 > Mar 2010 Internet-Draft applicability statement (Output item 1A, B, C) >=20 > July 2010 Applicability statement to WGLC >=20 > Sep 2010 Applicability statement sent to IESG (INFO) >=20 > =3D=3D Related to Output Item 2 =3D=3D >=20 > Mar 2010 Proposals (individual I-Ds) for CONEX IPv4 & IPv6=20 > specifications >=20 > Jun 2010 First WG draft CONEX IPv4 specification >=20 > Jun 2010 First WG draft CONEX IPv6 specification >=20 > Nov 2010 CONEX IPv4 specification to WGLC >=20 > Nov 2010 CONEX IPv6 specification to WGLC >=20 > Jan 2011 IPv4 specification sent to IESG (STD) >=20 > Jan 2011 IPv6 specification sent to IESG (STD) >=20 > =3D=3D Related to Output Item 3 =3D=3D >=20 > Jun 2010 Draft transport-related best practices >=20 > Jun 2010 Proposals (individual I-Ds) for TCP modification >=20 > Jun 2010 Proposals (individual I-Ds) for mechanism to ensure=20 > trustworthiness of CONEX information >=20 > Mar 2011 Transport-related Best practices for ensuring the=20 > trustworthiness of the CONEX information, including Spec of=20 > one mechanism to WGLC (EXP) >=20 > Mar 2011 Transport-related Best practices for the transport=20 > of congestion information from the destination to the sender,=20 > including Spec of TCP modification to WGLC (EXP) >=20 > May 2011 Both transport-related docs sent to IESG >=20 > =3D=3D Related to Output Item 4 =3D=3D >=20 > May 2010 Internet-Draft use cases >=20 > Mar 2011 Use cases to WGLC >=20 > May 2011 Use cases sent to IESG (INFO) >=20 > =3D=3D > Jun 2011 Close or re-charter >=20 >=20 >=20 >=20 > Leslie. >=20 > Ingemar Johansson S wrote: > > WARNING: contains banned part > > > > > >=20 > ---------------------------------------------------------------------- > > -- > > > > > > Subject: Re: Complete draft Charter for proposed CONEX WG From:=20 > > "Ingemar Johansson S" =20 > Date: Thu, 7=20 > > Jan 2010 15:32:21 +0100 To: > > > > To: > > > > > > > > Hi > > > > If I get things correct idea is to create one IP doc and a=20 > number of=20 > > transport docs (TCP, RTP/UDP....), this sounds OK. > > > > My feeling is that the IP doc needs to set some requirements on the=20 > > feedback/reinsertion done by the transport. The reason I=20 > see is that=20 > > no requirements at all on this level will make it difficult=20 > to design=20 > > and tune the incentive droppers and congestion rate policers. > > > > The use of bit 48 in the IPv4 header is probably one thing=20 > that will=20 > > raise the noise level on the list. The IP doc will here need to=20 > > specify how this can be used safely (if posssible) > > > > PS. Is it possible that you could post a refreshed version of the=20 > > draft charter on this list as it is a bit difficult to follow the=20 > > discussion (esp after being away after being out of office for a=20 > > longer period). > > > > Regards Ingemar > > > > > > > >=20 > ---------------------------------------------------------------------- > > > > > > Message: 1 Date: Tue, 05 Jan 2010 13:48:38 +0000 From: Bob Briscoe=20 > > Subject: Re: [re-ECN] Complete draft=20 > > Charter for proposed CONEX WG To: Cc:=20 > > re-ecn@ietf.org Message-ID:=20 > > <201001051348.o05Dmcvv008008@bagheera.jungle.bt.co.uk>=20 > Content-Type:=20 > > text/plain; charset=3D"us-ascii"; format=3Dflowed > > > > Phil, > > > > I'm happy with both responses. > > > > one outstanding issue inline... > > > > At 11:44 05/01/2010, philip.eardley@bt.com wrote: > >>> [BB]: A radically new approach is unlikely to be successful if=20 > >>> people can't get an intuitive grasp of it. E.g. HIP would=20 > have been=20 > >>> unlikely to get anywhere without RFC4423. We know ConEx=20 > hasn't been=20 > >>> easy for newcomers to grasp, so we shouldn't fudge this issue. > >>> > >>> I was thinking of a framework/architecture doc. Here's an idea... > >>> > >>> > >>> Let's assume the use-cases item is >1 doc, rather than a single=20 > >>> monolithic doc for all use-cases, ie. we encourage=20 > different people=20 > >>> to document their own use-cases. > >>> > >>> If so, then someone could attempt to write a more generic=20 > use-cases=20 > >>> doc that describes building blocks that can be used to build the=20 > >>> other use-cases. This could become a README-FIRST if=20 > written well,=20 > >>> as it's difficult to introduce ConEx without describing=20 > how it might=20 > >>> be used. > >> An "intuitive guide" would be possible, although adding=20 > another doc=20 > >> is more work. I wonder if the applicability statement can=20 > be tweaked=20 > >> for this purpose. We could add another "purpose": [3] to=20 > provide an=20 > >> intuitive explanation of the new concepts in CONEX > >> > >> So that it reads as follows:- > >> > >> 1. An applicability statement that describes: > >> > >> A. the functionality / capability that is expected to be=20 > provided by=20 > >> the CONEX mechanism itself, including its architectural features,=20 > >> limitations and assumptions it makes about networks and end systems > >> > >> B. a deployment analysis - how the CONEX mechanism can be=20 > deployed in=20 > >> networks (non vs ECN vs perhaps CONEX routers) and end systems > >> > >> C. a threat analysis - threats from falsifying or blanking=20 > CONEX info > > > > The milestones have the applicability statement going to the IESG=20 > > before the ConEx protocol is specified, so... > > > > B. I'm not convinced we will be able to write a deployment=20 > analysis of=20 > > a protocol as yet to be defined - we can surely only write=20 > > requirements at that stage. C. And it's certainly not possible to=20 > > write a meaningful threat analysis of something that hasn't=20 > yet been=20 > > specified. > > > > These problems would be solved by altering the chartering text as > > follows: s/deployment analysis/ /deployability goals/ s/threat=20 > > analysis - threats from.../ /security goals - addressing threats=20 > > from.../ > > > > Then after the protocol has been specified: - deployment analysis=20 > > could be in "4. use-case(s)" - full threat analysis could be in "3B=20 > > trust mechanisms" > > > > > > Bob > > > > > > > >> The purpose is [1] to detail the key functional and non-functional=20 > >> considerations that guide the work on the mechanism's design > >> > >> [2] to allow exploration of use cases to begin before work on the=20 > >> mechanism is complete > >> > >> [3] to provide an intuitive explanation of the new=20 > concepts in CONEX > >> > >>> Where do you imagine we should put best practice for the sending=20 > >>> transport to set its expectation of congestion? - The=20 > above EXP for=20 > >>> e2e transport, - or within the ConEx-IP doc (if so, which=20 > one? v4 or=20 > >>> v6)? It would seem to fit better in the e2e transport=20 > one, then the=20 > >>> spec for TCP could provide an example of the complete=20 > best practice. > >> Yes, same as you - I'd imagined it would be in the e2e=20 > transport doc.=20 > >> The IP doc defines packet the structure to carry CONEX=20 > information -=20 > >> ie what the codepoints are and what they mean. "what they mean" of=20 > >> course influences what the sending transport should do, but the=20 > >> advice for the sending transport would be in the transport doc=20 > >> [things like "send, as soon as possible, a Black codepoint=20 > for every=20 > >> loss or mark notified by the receiver". or whatever!] > >> > >> Thanks phil > >> > >>> IOW, this proposal assumes the IP doc would not need to describe=20 > >>> semantics of *when* the transport sets the codepoints.=20 > Instead it =20 > >>> would focus on just the wire protocol - what the codepoints mean,=20 > >>> how they are encoded, tunnel processing, router forwarding=20 > >>> behaviour, errors & management etc. > >>> > >>> Altho I'm not implying re-ECN is any more than a=20 > candidate, it would=20 > >>> be a useful exercise to go through the contents of the re-ECN=20 > >>> protocol spec and check where=20 > >>> you assume the different sections will end up. I've just=20 > done that,=20 > >>> which is why I keep bringing up awkward questions. > >>> > > > > ________________________________________________________________ Bob > > Briscoe, BT Innovate & Design > > > > > > > > ------------------------------ > > > > _______________________________________________ re-ECN mailing list=20 > > re-ECN@ietf.org https://www.ietf.org/mailman/listinfo/re-ecn > > > > > > End of re-ECN Digest, Vol 11, Issue 2 > > ************************************* > > > > > > > >=20 > ---------------------------------------------------------------------- > > -- > > > > > > _______________________________________________ re-ECN mailing list=20 > > re-ECN@ietf.org https://www.ietf.org/mailman/listinfo/re-ecn >=20 > -- >=20 > ------------------------------------------------------------------- > "Reality: > Yours to discover." > -- ThinkingCat > Leslie Daigle > leslie@thinkingcat.com > ------------------------------------------------------------------- >=20 >=20 >=20 From rbriscoe@jungle.bt.co.uk Mon Jan 11 09:33:03 2010 Return-Path: X-Original-To: re-ecn@core3.amsl.com Delivered-To: re-ecn@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id CD30F3A6842 for ; Mon, 11 Jan 2010 09:33:03 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.258 X-Spam-Level: X-Spam-Status: No, score=-1.258 tagged_above=-999 required=5 tests=[AWL=0.859, BAYES_00=-2.599, DNS_FROM_RFC_BOGUSMX=1.482, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ehkAm9Xsa8nU for ; Mon, 11 Jan 2010 09:32:57 -0800 (PST) Received: from smtp2.smtp.bt.com (smtp2.smtp.bt.com [217.32.164.150]) by core3.amsl.com (Postfix) with ESMTP id EE4F13A6936 for ; Mon, 11 Jan 2010 09:32:31 -0800 (PST) Received: from i2kc06-ukbr.domain1.systemhost.net ([193.113.197.70]) by smtp2.smtp.bt.com with Microsoft SMTPSVC(6.0.3790.3959); Mon, 11 Jan 2010 17:32:28 +0000 Received: from cbibipnt05.iuser.iroot.adidom.com ([147.149.196.177]) by i2kc06-ukbr.domain1.systemhost.net with Microsoft SMTPSVC(6.0.3790.3959); Mon, 11 Jan 2010 17:32:28 +0000 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 1263231147184; Mon, 11 Jan 2010 17:32:27 +0000 Received: from MUT.jungle.bt.co.uk ([10.215.130.87]) by bagheera.jungle.bt.co.uk (8.13.5/8.12.8) with ESMTP id o0BHWPYe020038 for ; Mon, 11 Jan 2010 17:32:25 GMT Message-Id: <201001111732.o0BHWPYe020038@bagheera.jungle.bt.co.uk> X-Mailer: QUALCOMM Windows Eudora Version 7.1.0.9 Date: Mon, 11 Jan 2010 17:32:25 +0000 To: ConEx IETF list 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: 11 Jan 2010 17:32:28.0347 (UTC) FILETIME=[0BE890B0:01CA92E4] Subject: [re-ECN] IPv6 hop-by-hop extension headers, tunnels & ConEx X-BeenThere: re-ecn@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: re-inserted explicit congestion notification List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 11 Jan 2010 17:33:03 -0000 To anyone out there who knows what tunnels do in practice with v6 hop-by-hop extension headers? [OK, I admit this posting is about the details of encoding ConEx in IPv6, so we shouldn't get buried in this level of detail while having chartering discussions. But I'd like to have a warm feeling that there is some hope of doing ConEx properly in v6, and this issue has been bugging me...] Whole path ConEx info introduced by the sender doesn't need to be changed by routers, but it does need to be visible at trust boundaries (e.g. borders). If a packet gets tunnelled, that means the ConEx info ought to be in the outer header. If it were in the inner, a border router shouldn't be burying down the layers to find it (and anyway it might be encrypted if the tunnel is IPsec ESH). So I want to pick a way of encoding ConEx info that is likely to propagate into the outer header by default at most encapsulators. It's not a show-stopper if most tunnels don't (at least initially we can arrange for trials with tunnels modified to work), but it's a highly undesirable extra barrier to overcome. * IPv4 in v4: A major reason for proposing bit-48 for ConEx was that there's a decent chance existing tunnel encapsulators will copy the incoming header to create the outer, so ConEx info would 'naturally' propagate into the outer. * IPv6 in v6: We proposed adding an option to the v6 hop-by-hop extension header for ConEx info, in the expectation that a tunnel encap can copy it with the main header to create an outer header that consists of a new main header and the ConEx hop-by-hop extension header. RFC2473 (S.5.1) says that a v6 encapsulator can copy incoming extension headers to create new outer extension headers after the main v6 header. But which ones are copied depends on how the encapsulator is configured. I assume it will be configured so that certain headers are always copied, e.g.: * the jumbogram hop-by-hop option, otherwise a tunnelled jumbogram won't have a big enough total length field to say how big it is. * the tunnel encap limit, otherwise it wouldn't be in the outer for the next potential tunnel ingress to check. My question: Q1. what is a tunnel encap likely to do with a hop-by-hop option that it doesn't recognise? Will it copy it to the outer by default? Does it depend on the implementation, or should all implementations follow a rule? Whatever, I'm told it will probably go via the slow path at first. Bob PS. I'm aware that we have no hope of 'legacy' v4inv6 & v6inv4 tunnels propogating ConEx info by default, if we put ConEx info in completely different places in the v4 & v6 headers. PPS: A subsidiary question: Q2. what would probably happen at a tunnel encap if we defined a v6 extension headers for ConEx that was not in the hop-by-hop extension header? I assume the chances of existing tunnels copying this to the outer would be much lower. (But it does seem that RFC2473 allows a tunnel ingress to be configured to copy non-hop-by-hop headers to the outer as well.) ________________________________________________________________ Bob Briscoe, BT Innovate & Design From rbriscoe@jungle.bt.co.uk Tue Jan 19 02:31:15 2010 Return-Path: X-Original-To: re-ecn@core3.amsl.com Delivered-To: re-ecn@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 629F03A69F7 for ; Tue, 19 Jan 2010 02:31:14 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.266 X-Spam-Level: X-Spam-Status: No, score=-0.266 tagged_above=-999 required=5 tests=[AWL=-0.562, BAYES_40=-0.185, DNS_FROM_RFC_BOGUSMX=1.482, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ci+tFYJVF3gz for ; Tue, 19 Jan 2010 02:31:03 -0800 (PST) Received: from smtp4.smtp.bt.com (smtp4.smtp.bt.com [217.32.164.151]) by core3.amsl.com (Postfix) with ESMTP id 94BB23A680D for ; Tue, 19 Jan 2010 02:31:03 -0800 (PST) Received: from i2kc06-ukbr.domain1.systemhost.net ([193.113.197.70]) by smtp4.smtp.bt.com with Microsoft SMTPSVC(6.0.3790.3959); Tue, 19 Jan 2010 10:30:58 +0000 Received: from cbibipnt05.iuser.iroot.adidom.com ([147.149.196.177]) by i2kc06-ukbr.domain1.systemhost.net with Microsoft SMTPSVC(6.0.3790.3959); Tue, 19 Jan 2010 10:30:58 +0000 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 126389705783; Tue, 19 Jan 2010 10:30:57 +0000 Received: from MUT.jungle.bt.co.uk ([10.215.130.87]) by bagheera.jungle.bt.co.uk (8.13.5/8.12.8) with ESMTP id o0JAUtGT006942 for ; Tue, 19 Jan 2010 10:30:55 GMT Message-Id: <201001191030.o0JAUtGT006942@bagheera.jungle.bt.co.uk> X-Mailer: QUALCOMM Windows Eudora Version 7.1.0.9 Date: Tue, 19 Jan 2010 10:30:36 +0000 To: ConEx IETF list 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: 19 Jan 2010 10:30:58.0404 (UTC) FILETIME=[7D3B8240:01CA98F2] Subject: [re-ECN] Senior exec interest in ConEx X-BeenThere: re-ecn@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: re-inserted explicit congestion notification List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 19 Jan 2010 10:31:15 -0000 Folks, Senior ICT execs are showing an interest in ConEx as a potential solution to sharing Internet capacity in a neutral way: I was asked to present the proposal to the above workshop, which spent a day assessing it, from regulatory, commercial and technical viewpoints. You'll find links there to a report on the outcome of the workshop, as well as the original presentations given. Bob PS. GIIC is a club of CTOs & CEOs from the major ICT companies, who come together to consider acting on matters of concern to the whole industry. ________________________________________________________________ Bob Briscoe, BT Innovate & Design From philip.eardley@bt.com Fri Jan 29 09:20:09 2010 Return-Path: X-Original-To: re-ecn@core3.amsl.com Delivered-To: re-ecn@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id D7DA83A6A58 for ; Fri, 29 Jan 2010 09:20:09 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.598 X-Spam-Level: X-Spam-Status: No, score=-3.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id iLxdpjT0yRN7 for ; Fri, 29 Jan 2010 09:20:08 -0800 (PST) Received: from smtp2.smtp.bt.com (smtp2.smtp.bt.com [217.32.164.150]) by core3.amsl.com (Postfix) with ESMTP id 383913A6A4F for ; Fri, 29 Jan 2010 09:20:08 -0800 (PST) Received: from E03MVB1-UKBR.domain1.systemhost.net ([193.113.197.109]) by smtp2.smtp.bt.com with Microsoft SMTPSVC(6.0.3790.3959); Fri, 29 Jan 2010 17:20:29 +0000 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01CAA107.4A5D4388" Date: Fri, 29 Jan 2010 17:20:01 -0000 Message-ID: <4A916DBC72536E419A0BD955EDECEDEC06363D41@E03MVB1-UKBR.domain1.systemhost.net> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Advancing CONEX work Thread-Index: AcqhB0s7X18vWmXAScKw6TIbeK8BUQ== From: To: X-OriginalArrivalTime: 29 Jan 2010 17:20:29.0731 (UTC) FILETIME=[5B03F730:01CAA107] Subject: [re-ECN] Advancing CONEX work X-BeenThere: re-ecn@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: re-inserted explicit congestion notification List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 29 Jan 2010 17:20:10 -0000 This is a multi-part message in MIME format. ------_=_NextPart_001_01CAA107.4A5D4388 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable The draft Charter is on next week's IESG agenda, so hopefully we'll hear some good news soon. We've asked for a session in Anaheim, on the basis that we'll either have a WG by then or else we can have a "working" bof as the charter will be near final sign-off. So we should make progress on the first items of our presumed charter: >>Feb 2010 Internet-Draft functionality statement (Output item 1A) Mar=20 >>2010 Internet-Draft applicability statement (Output item 1A, B, C) The idea was for some short intensive discussion on "functionality", then some short intensive discussion on deployability & security goals. The best step might be for a volunteer(s) please to be "editor" on this initial item(s). The role would be to summarise the existing thinking, as a first step, and then to lead /capture discussion. Hopefully the output can be quite short - a number of bullets such as "a mechanism to allow senders to inform the network of the level of congestion they expect their packets to encounter"; "the information the sender adds is a RTT out of date"; etc.=20 In more detail:- 1. An applicability statement that describes: A. the functionality / capability that is expected to be provided by the CONEX mechanism itself, including its architectural features, limitations and assumptions it makes about networks and end systems B. deployability goals - how the CONEX mechanism can be deployed in networks (non vs ECN vs perhaps CONEX routers) and end systems C. security goals - addressing threats from falsifying or blanking CONEX info The purpose is [1] to detail the key functional and non-functional considerations that guide the work on the mechanism's design [2] to allow exploration of use cases to begin before work on the mechanism is complete [3] to provide an intuitive explanation of the new concepts in CONEX Please shout if you'd like to volunteer to be "editor" on this initial item(s).=20 Thanks Leslie & Phil.=20 ------_=_NextPart_001_01CAA107.4A5D4388 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Advancing CONEX work

The draft Charter is on next = week's IESG agenda, so hopefully we'll hear some good news soon. We've = asked for a session in Anaheim, on the basis that we'll either have a WG = by then or else we can have a "working" bof as the charter = will be near final sign-off.

So we should make progress on the = first items of our presumed charter:

>>Feb 2010 Internet-Draft = functionality statement (Output item 1A) Mar
>>2010 Internet-Draft = applicability statement (Output item 1A, B, C)

The idea was for some short = intensive discussion on "functionality", then some short = intensive discussion on deployability & security goals.

The best step might be for a = volunteer(s) please to be "editor" on this initial item(s). = The role would be to summarise the existing thinking, as a first step, = and then to lead /capture discussion.

Hopefully the output can be quite = short - a number of bullets such as "a mechanism to allow senders = to inform the network of the level of congestion they expect their = packets to encounter"; "the information the sender adds is a = RTT out of date"; etc.

In more detail:-

1. An applicability statement = that describes:


A. the functionality / capability = that is expected to be provided by the CONEX mechanism itself, including = its architectural features, limitations and assumptions it makes about = networks and end systems

B. deployability goals - how the = CONEX mechanism can be deployed in networks (non vs ECN vs perhaps CONEX = routers) and end systems

C. security goals - addressing = threats from falsifying or blanking CONEX info

The purpose is

[1] to detail the key functional = and non-functional considerations that guide the work on the mechanism's = design

[2] to allow exploration of use = cases to begin before work on the mechanism is complete

[3] to provide an intuitive = explanation of the new concepts in CONEX

Please shout if you'd like to = volunteer to be "editor" on this initial item(s).

Thanks
Leslie & Phil.=20

------_=_NextPart_001_01CAA107.4A5D4388--