From wwwrun@core3.amsl.com Thu Jun 3 13:48:41 2010 Return-Path: X-Original-To: conex@ietf.org Delivered-To: conex@core3.amsl.com Received: by core3.amsl.com (Postfix, from userid 30) id 011D53A68D6; Thu, 3 Jun 2010 13:48:40 -0700 (PDT) From: IESG Secretary To: IETF Announcement list Content-Type: text/plain; charset="utf-8" Mime-Version: 1.0 Message-Id: <20100603204841.011D53A68D6@core3.amsl.com> Date: Thu, 3 Jun 2010 13:48:40 -0700 (PDT) Cc: nanditad@google.com, conex@ietf.org Subject: [conex] WG Action: Congestion Exposure (conex) X-BeenThere: conex@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Congestion Exposure working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 03 Jun 2010 20:48:41 -0000 A new IETF working group has been formed in the Transport Area. For additional information, please contact the Area Directors or the WG Chairs. Congestion Exposure (conex) --------------------------------------------------- Current Status: Active Working Group Chairs: Nandita Dukkipati Marcelo Bagnulo Transport Area Director(s): Lars Eggert David Harrington Transport Area Advisor: Lars Eggert Mailing Lists: General Discussion: conex@ietf.org To Subscribe: https://www.ietf.org/mailman/listinfo/conex Archive: http://www.ietf.org/mail-archive/web/conex/ Description of Working Group: The purpose of the CONEX working group is to develop a mechanism by which senders inform the network about the congestion encountered by previous packets on the same flow. Today, the network may signal congestion by ECN markings or by dropping packets, and the receiver passes this information back to the sender in transport-layer acknowledgements. The mechanism to be developed by the CONEX WG will enable the sender to also relay the congestion information back into the network in-band at the IP layer, such that the total level of congestion is visible to all IP devices along the path, from where it could, for example, be provided as input to traffic management. The primary goal of the CONEX WG is to develop experimental specifications to achieve the above in IPv6 networks. The WG will also develop an abstract, higher-level description of the congestion exposure mechanism. Primary work items are: * An Informational document containing an abstract description of the congestion exposure mechanism that is independent of specific transport protocols and congestion information encoding techniques needed for different IP protocol versions. * An Experimental specification of an IPv6 packet structure that encapsulates CONEX information, defining a packet format and an interpretation. * An Experimental specification of a modification to TCP, for the timely transport of congestion information from the destination to the sender. It is believed that the CONEX mechanism will be useful as a generative technology that can be applied as a key element of congestion management solutions in a wide variety of use cases. However, the CONEX WG will initially focus on one use case, where the end hosts and the network that contains the destination end host are CONEX-enabled but other networks need not be. CONEX information can assist the network operator's traffic management and, for example, incentivize LEDBAT-like applications. Congestion-based billing is not within the scope of the WG. Experiments on use cases are encouraged and the WG will solicit feedback from such deployments. The WG may decide to document the experience from such use cases in Informational documents, covering: * Assumptions made * Deployment considerations * Advice on how to use the CONEX mechanism as an element of a congestion management solution * Security threats and advice on mitigation approaches (detailed specifications of threat mitigation techniques are out of scope) * Descriptions of results from experiments with the use case The CONEX WG is only chartered to work on a congestion exposure mechanism for IPv6 networks. When the output of the WG has seen adoption and has proven to be useful, the WG may propose to the IESG that it should be rechartered to extend this effort. The first result of the WG is the usage scenarios document. Other documents will not be considered for publication before this first document has seen IETF consensus (but may be worked on in the WG). Goals and Milestones: Mar 2011 Submit use case description to IESG as Informational Jul 2011 Submit abstract specification for the congestion exposure mechanism to IESG as Informational Nov 2011 Submit specification of IPv6 packet structure to IESG as Experimental Nov 2011 Submit specification for modification to TCP to IESG as Experimental From lars.eggert@nokia.com Fri Jun 4 00:31:11 2010 Return-Path: X-Original-To: conex@core3.amsl.com Delivered-To: conex@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 98F613A68D8; Fri, 4 Jun 2010 00:31:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.999 X-Spam-Level: X-Spam-Status: No, score=-5.999 tagged_above=-999 required=5 tests=[AWL=0.600, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 63TlXydy70D6; Fri, 4 Jun 2010 00:31:10 -0700 (PDT) Received: from mgw-mx03.nokia.com (smtp.nokia.com [192.100.122.230]) by core3.amsl.com (Postfix) with ESMTP id 92BF23A698C; Fri, 4 Jun 2010 00:31:09 -0700 (PDT) Received: from esebh105.NOE.Nokia.com (esebh105.ntc.nokia.com [172.21.138.211]) by mgw-mx03.nokia.com (Switch-3.3.3/Switch-3.3.3) with ESMTP id o547UeiS027791; Fri, 4 Jun 2010 10:30:53 +0300 Received: from vaebh104.NOE.Nokia.com ([10.160.244.30]) by esebh105.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.4675); Fri, 4 Jun 2010 10:30:51 +0300 Received: from mgw-sa01.ext.nokia.com ([147.243.1.47]) by vaebh104.NOE.Nokia.com over TLS secured channel with Microsoft SMTPSVC(6.0.3790.4675); Fri, 4 Jun 2010 10:30:22 +0300 Received: from mail.fit.nokia.com (esdhcp030222.research.nokia.com [172.21.30.222]) by mgw-sa01.ext.nokia.com (Switch-3.3.3/Switch-3.3.3) with ESMTP id o547UMqU029642 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 4 Jun 2010 10:30:22 +0300 X-Virus-Status: Clean X-Virus-Scanned: clamav-milter 0.96.1 at fit.nokia.com Mime-Version: 1.0 (Apple Message framework v1078) Content-Type: multipart/signed; boundary=Apple-Mail-59-976666882; protocol="application/pkcs7-signature"; micalg=sha1 From: Lars Eggert Date: Fri, 4 Jun 2010 10:30:10 +0300 Message-Id: <0CE22F0A-C26B-4F4E-B778-5062AF76ACB5@nokia.com> References: <20100603204841.011D53A68D6@core3.amsl.com> To: "re-ecn@ietf.org list" X-Mailer: Apple Mail (2.1078) X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.2.5 (mail.fit.nokia.com); Fri, 04 Jun 2010 10:30:15 +0300 (EEST) X-OriginalArrivalTime: 04 Jun 2010 07:30:22.0803 (UTC) FILETIME=[CAE40230:01CB03B7] X-Nokia-AV: Clean Cc: conex@ietf.org Subject: [conex] Fwd: WG Action: Congestion Exposure (conex) X-BeenThere: conex@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: conex@ietf.org List-Id: Congestion Exposure working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 04 Jun 2010 07:31:11 -0000 --Apple-Mail-59-976666882 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii Hi, you have probably seen that the CONEX WG has been chartered. The WG = mailing list is conex@ietf.org. I have requested that the secretariat = subscribe everyone who is currently on the re-ecn@ietf.org list to the = new CONEX WG list. I leave it up to Bob to decide if he wants to keep the re-ecn@ietf.org = list around; but any CONEX-related discussion should move to = conex@ietf.org. Lars Begin forwarded message: > From: IESG Secretary > Date: June 3, 2010 23:48:40 GMT+03:00 > To: IETF Announcement list > Cc: "marcelo@it.uc3m.es" , "nanditad@google.com" = , "conex@ietf.org" > Subject: WG Action: Congestion Exposure (conex)=20 >=20 > A new IETF working group has been formed in the Transport Area. For > additional information, please contact the Area Directors or the WG > Chairs. >=20 > Congestion Exposure (conex)=20 > --------------------------------------------------- > Current Status: Active Working Group >=20 > Chairs: > Nandita Dukkipati > Marcelo Bagnulo >=20 > Transport Area Director(s): > Lars Eggert > David Harrington >=20 > Transport Area Advisor: > Lars Eggert =20 >=20 > Mailing Lists: > General Discussion: conex@ietf.org > To Subscribe: https://www.ietf.org/mailman/listinfo/conex > Archive: http://www.ietf.org/mail-archive/web/conex/ >=20 > Description of Working Group: >=20 > The purpose of the CONEX working group is to develop a mechanism > by which senders inform the network about the congestion encountered > by previous packets on the same flow. Today, the network may signal > congestion by ECN markings or by dropping packets, and the receiver > passes this information back to the sender in transport-layer > acknowledgements. The mechanism to be developed by the CONEX WG > will enable the sender to also relay the congestion information > back into the network in-band at the IP layer, such that the total > level of congestion is visible to all IP devices along the path, > from where it could, for example, be provided as input to traffic > management. >=20 > The primary goal of the CONEX WG is to develop experimental > specifications to achieve the above in IPv6 networks. The WG will > also develop an abstract, higher-level description of the congestion > exposure mechanism. >=20 > Primary work items are: >=20 > * An Informational document containing an abstract description of > the congestion exposure mechanism that is independent of specific > transport protocols and congestion information encoding techniques > needed for different IP protocol versions. >=20 > * An Experimental specification of an IPv6 packet structure that > encapsulates CONEX information, defining a packet format and an > interpretation. >=20 > * An Experimental specification of a modification to TCP, for the > timely transport of congestion information from the destination to > the sender. >=20 > It is believed that the CONEX mechanism will be useful as a generative > technology that can be applied as a key element of congestion > management solutions in a wide variety of use cases. However, the > CONEX WG will initially focus on one use case, where the end hosts > and the network that contains the destination end host are = CONEX-enabled > but other networks need not be. CONEX information can assist the > network operator's traffic management and, for example, incentivize > LEDBAT-like applications. Congestion-based billing is not within the > scope of the WG. >=20 > Experiments on use cases are encouraged and the WG will solicit > feedback from such deployments. The WG may decide to document the > experience from such use cases in Informational documents, covering: >=20 > * Assumptions made >=20 > * Deployment considerations >=20 > * Advice on how to use the CONEX mechanism as an element of a > congestion management solution >=20 > * Security threats and advice on mitigation approaches (detailed > specifications of threat mitigation techniques are out of scope) >=20 > * Descriptions of results from experiments with the use case >=20 > The CONEX WG is only chartered to work on a congestion exposure = mechanism > for IPv6 networks. When the output of the WG has seen adoption and > has proven to be useful, the WG may propose to the IESG that it > should be rechartered to extend this effort. The first result of > the WG is the usage scenarios document. Other documents will not > be considered for publication before this first document has seen > IETF consensus (but may be worked on in the WG). >=20 > Goals and Milestones: >=20 > Mar 2011 Submit use case description to IESG as Informational >=20 > Jul 2011 Submit abstract specification for the congestion exposure > mechanism to IESG as Informational >=20 > Nov 2011 Submit specification of IPv6 packet structure to IESG as > Experimental >=20 > Nov 2011 Submit specification for modification to TCP to IESG as > Experimental >=20 > _______________________________________________ > IETF-Announce mailing list > IETF-Announce@ietf.org > https://www.ietf.org/mailman/listinfo/ietf-announce --Apple-Mail-59-976666882 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 MQ8XDTEwMDYwNDA3MzAxMFowIwYJKoZIhvcNAQkEMRYEFLbl+zwH0avJPU4lLDuTlUWNf5CYMIGF BgkrBgEEAYI3EAQxeDB2MGIxCzAJBgNVBAYTAlpBMSUwIwYDVQQKExxUaGF3dGUgQ29uc3VsdGlu ZyAoUHR5KSBMdGQuMSwwKgYDVQQDEyNUaGF3dGUgUGVyc29uYWwgRnJlZW1haWwgSXNzdWluZyBD QQIQB2OTfqxcpudWfXlLT+pSnTCBhwYLKoZIhvcNAQkQAgsxeKB2MGIxCzAJBgNVBAYTAlpBMSUw IwYDVQQKExxUaGF3dGUgQ29uc3VsdGluZyAoUHR5KSBMdGQuMSwwKgYDVQQDEyNUaGF3dGUgUGVy c29uYWwgRnJlZW1haWwgSXNzdWluZyBDQQIQB2OTfqxcpudWfXlLT+pSnTANBgkqhkiG9w0BAQEF AASCAQAnodagK/o0nzU7sjr5Uv044G1yKRH7NeO5PvpMhD/BNBVL3Wfb67PEqPcZEwa5k824Kz+z 4NUsZA+lpAD14828dJjddritaWgIHmPt0IixJ7yzYKPWpmAJA6KB+HySdSkTNEiMkCkuP9xdSb55 tELtA4lSgVEKmCP7ZuCsfJeMsSrWDqwTtwB/kskcqJHOVQ+Ywyt7+z2vedZhoY07/WD01OkKvQr6 VSfEw3O8WMGjnIF0WR+GB7C/cUt2KEqCFQv/mXosPxQe5mo/wDFg6Yz0dn/uSLyYx86w5iOd1vse N5dCFSwRIGkYsdmKqsgcyDm0P2FprmGAeZXORWpViflLAAAAAAAA --Apple-Mail-59-976666882-- From rbriscoe@jungle.bt.co.uk Fri Jun 4 04:49:34 2010 Return-Path: X-Original-To: conex@core3.amsl.com Delivered-To: conex@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 63A953A698D for ; Fri, 4 Jun 2010 04:49:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.358 X-Spam-Level: * X-Spam-Status: No, score=1.358 tagged_above=-999 required=5 tests=[AWL=0.875, BAYES_50=0.001, DNS_FROM_RFC_BOGUSMX=1.482, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id DWFKFPq1XFbp for ; Fri, 4 Jun 2010 04:49:28 -0700 (PDT) Received: from smtp4.smtp.bt.com (smtp4.smtp.bt.com [217.32.164.151]) by core3.amsl.com (Postfix) with ESMTP id 541603A6931 for ; Fri, 4 Jun 2010 04:49:24 -0700 (PDT) Received: from i2kc06-ukbr.domain1.systemhost.net ([193.113.197.70]) by smtp4.smtp.bt.com with Microsoft SMTPSVC(6.0.3790.3959); Fri, 4 Jun 2010 12:49:10 +0100 Received: from cbibipnt05.iuser.iroot.adidom.com ([147.149.196.177]) by i2kc06-ukbr.domain1.systemhost.net with Microsoft SMTPSVC(6.0.3790.4675); Fri, 4 Jun 2010 12:49:10 +0100 Received: From bagheera.jungle.bt.co.uk ([132.146.168.158]) by cbibipnt05.iuser.iroot.adidom.com (WebShield SMTP v4.5 MR1a P0803.399); id 1275652148465; Fri, 4 Jun 2010 12:49:08 +0100 Received: from MUT.jungle.bt.co.uk ([10.215.130.87]) by bagheera.jungle.bt.co.uk (8.13.5/8.12.8) with ESMTP id o54Bn70n026776; Fri, 4 Jun 2010 12:49:07 +0100 Message-Id: <201006041149.o54Bn70n026776@bagheera.jungle.bt.co.uk> X-Mailer: QUALCOMM Windows Eudora Version 7.1.0.9 Date: Fri, 04 Jun 2010 12:49:10 +0100 To: conex@ietf.org From: Bob Briscoe In-Reply-To: <0CE22F0A-C26B-4F4E-B778-5062AF76ACB5@nokia.com> References: <20100603204841.011D53A68D6@core3.amsl.com> <0CE22F0A-C26B-4F4E-B778-5062AF76ACB5@nokia.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: 04 Jun 2010 11:49:10.0360 (UTC) FILETIME=[F2092D80:01CB03DB] Cc: "re-ecn@ietf.org list" , conex@ietf.org Subject: Re: [conex] [re-ECN] Fwd: WG Action: Congestion Exposure (conex) X-BeenThere: conex@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Congestion Exposure working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 04 Jun 2010 11:49:34 -0000 Lars, At 08:30 04/06/2010, Lars Eggert wrote: >I leave it up to Bob to decide if he wants to keep the >re-ecn@ietf.org list around; but any CONEX-related discussion should >move to conex@ietf.org. Unless anyone objects, I intend to shut down the re-ECN list (in a few days once traffic in response to ongoing threads has died). If there starts to be too much discussion on re-ECN details that are beyond the ConEx charter, I'm sure the chairs will let those responsible know, then we can consider reopening a separate re-ECN list. But I don't think we'll get to that bridge and we can cross it if we do. Cheers Bob ________________________________________________________________ Bob Briscoe, BT Innovate & Design From ietfdbh@comcast.net Fri Jun 4 05:52:11 2010 Return-Path: X-Original-To: conex@core3.amsl.com Delivered-To: conex@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 286793A69D3 for ; Fri, 4 Jun 2010 05:52:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.106 X-Spam-Level: X-Spam-Status: No, score=-0.106 tagged_above=-999 required=5 tests=[AWL=-0.107, BAYES_50=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 4QMIa47MCNdY for ; Fri, 4 Jun 2010 05:52:10 -0700 (PDT) Received: from qmta04.westchester.pa.mail.comcast.net (qmta04.westchester.pa.mail.comcast.net [76.96.62.40]) by core3.amsl.com (Postfix) with ESMTP id 3F9643A69F6 for ; Fri, 4 Jun 2010 05:52:10 -0700 (PDT) Received: from omta02.westchester.pa.mail.comcast.net ([76.96.62.19]) by qmta04.westchester.pa.mail.comcast.net with comcast id Rn4G1e0010QuhwU54orxMk; Fri, 04 Jun 2010 12:51:57 +0000 Received: from Harrington73653 ([67.189.235.106]) by omta02.westchester.pa.mail.comcast.net with comcast id Rorx1e0032JQnJT3NorxVe; Fri, 04 Jun 2010 12:51:57 +0000 From: "David Harrington" To: "'Bob Briscoe'" , References: <20100603204841.011D53A68D6@core3.amsl.com><0CE22F0A-C26B-4F4E-B778-5062AF76ACB5@nokia.com> <201006041149.o54Bn70n026776@bagheera.jungle.bt.co.uk> Date: Fri, 4 Jun 2010 08:51:56 -0400 Message-ID: <06a701cb03e4$b6e30830$0600a8c0@china.huawei.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 11 In-Reply-To: <201006041149.o54Bn70n026776@bagheera.jungle.bt.co.uk> Thread-Index: AcsD2/tbxz3QcLrWQJia5xmWMVJYhgACEBhg X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3198 Cc: re-ecn@ietf.org, conex@ietf.org Subject: Re: [conex] [re-ECN] Fwd: WG Action: Congestion Exposure (conex) X-BeenThere: conex@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Congestion Exposure working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 04 Jun 2010 12:52:11 -0000 Hi, When we moved discussion from the BRIDGE MIB WG to an IEEE ML, we automated the WG ML to respond to posters with a message that discusion should be taken to , and here are the instructions for joining that list. I recommend a similar approach here. dbh > -----Original Message----- > From: conex-bounces@ietf.org [mailto:conex-bounces@ietf.org] > On Behalf Of Bob Briscoe > Sent: Friday, June 04, 2010 7:49 AM > To: conex@ietf.org > Cc: re-ecn@ietf.org list; conex@ietf.org > Subject: Re: [conex] [re-ECN] Fwd: WG Action: Congestion > Exposure (conex) > > Lars, > > At 08:30 04/06/2010, Lars Eggert wrote: > >I leave it up to Bob to decide if he wants to keep the > >re-ecn@ietf.org list around; but any CONEX-related discussion should > >move to conex@ietf.org. > > Unless anyone objects, I intend to shut down the re-ECN list (in a > few days once traffic in response to ongoing threads has died). > > If there starts to be too much discussion on re-ECN details that are > beyond the ConEx charter, I'm sure the chairs will let those > responsible know, then we can consider reopening a separate re-ECN > list. But I don't think we'll get to that bridge and we can > cross it if we do. > > Cheers > > > > Bob > > > ________________________________________________________________ > Bob Briscoe, BT Innovate & Design > > _______________________________________________ > conex mailing list > conex@ietf.org > https://www.ietf.org/mailman/listinfo/conex > From rbriscoe@jungle.bt.co.uk Fri Jun 4 08:15:48 2010 Return-Path: X-Original-To: conex@core3.amsl.com Delivered-To: conex@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id F18EB3A680E for ; Fri, 4 Jun 2010 08:15:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.92 X-Spam-Level: X-Spam-Status: No, score=0.92 tagged_above=-999 required=5 tests=[AWL=0.437, BAYES_50=0.001, DNS_FROM_RFC_BOGUSMX=1.482, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id hXh05r0o6KI0 for ; Fri, 4 Jun 2010 08:15:41 -0700 (PDT) Received: from smtp1.smtp.bt.com (smtp1.smtp.bt.com [217.32.164.137]) by core3.amsl.com (Postfix) with ESMTP id D335F3A67BD for ; Fri, 4 Jun 2010 08:15:40 -0700 (PDT) Received: from i2kc08-ukbr.domain1.systemhost.net ([193.113.197.71]) by smtp1.smtp.bt.com with Microsoft SMTPSVC(6.0.3790.4675); Fri, 4 Jun 2010 16:15:26 +0100 Received: from cbibipnt08.iuser.iroot.adidom.com ([147.149.100.81]) by i2kc08-ukbr.domain1.systemhost.net with Microsoft SMTPSVC(6.0.3790.4675); Fri, 4 Jun 2010 16:15:25 +0100 Received: From bagheera.jungle.bt.co.uk ([132.146.168.158]) by cbibipnt08.iuser.iroot.adidom.com (WebShield SMTP v4.5 MR1a P0803.399); id 1275664524858; Fri, 4 Jun 2010 16:15:24 +0100 Received: from MUT.jungle.bt.co.uk ([10.215.130.87]) by bagheera.jungle.bt.co.uk (8.13.5/8.12.8) with ESMTP id o54FFO5l029451; Fri, 4 Jun 2010 16:15:24 +0100 Message-Id: <201006041515.o54FFO5l029451@bagheera.jungle.bt.co.uk> X-Mailer: QUALCOMM Windows Eudora Version 7.1.0.9 Date: Fri, 04 Jun 2010 16:15:26 +0100 To: "David Harrington" From: Bob Briscoe In-Reply-To: <06a701cb03e4$b6e30830$0600a8c0@china.huawei.com> References: <20100603204841.011D53A68D6@core3.amsl.com> <0CE22F0A-C26B-4F4E-B778-5062AF76ACB5@nokia.com> <201006041149.o54Bn70n026776@bagheera.jungle.bt.co.uk> <06a701cb03e4$b6e30830$0600a8c0@china.huawei.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: 04 Jun 2010 15:15:25.0879 (UTC) FILETIME=[C26B8470:01CB03F8] Cc: re-ecn@ietf.org, conex@ietf.org Subject: Re: [conex] [re-ECN] Fwd: WG Action: Congestion Exposure (conex) X-BeenThere: conex@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Congestion Exposure working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 04 Jun 2010 15:15:48 -0000 David, OK, Will do. Even if we eventually shut down the re-ECN list, I will ask the IETF tools folks to make sure the archive remains accessible. On Web pages I can edit, I've also changed links advising how to post/subscribe to the re-ECN list to point to the new ConEx list. Cheers Bob At 13:51 04/06/2010, David Harrington wrote: >Hi, > >When we moved discussion from the BRIDGE MIB WG to an IEEE ML, we >automated the WG ML to respond to posters with a message that >discusion should be taken to , and here are the instructions >for joining that list. > >I recommend a similar approach here. > >dbh > > > -----Original Message----- > > From: conex-bounces@ietf.org [mailto:conex-bounces@ietf.org] > > On Behalf Of Bob Briscoe > > Sent: Friday, June 04, 2010 7:49 AM > > To: conex@ietf.org > > Cc: re-ecn@ietf.org list; conex@ietf.org > > Subject: Re: [conex] [re-ECN] Fwd: WG Action: Congestion > > Exposure (conex) > > > > Lars, > > > > At 08:30 04/06/2010, Lars Eggert wrote: > > >I leave it up to Bob to decide if he wants to keep the > > >re-ecn@ietf.org list around; but any CONEX-related discussion >should > > >move to conex@ietf.org. > > > > Unless anyone objects, I intend to shut down the re-ECN list (in a > > few days once traffic in response to ongoing threads has died). > > > > If there starts to be too much discussion on re-ECN details that are > > > beyond the ConEx charter, I'm sure the chairs will let those > > responsible know, then we can consider reopening a separate re-ECN > > list. But I don't think we'll get to that bridge and we can > > cross it if we do. > > > > Cheers > > > > > > > > Bob > > > > > > ________________________________________________________________ > > Bob Briscoe, BT Innovate & Design > > > > _______________________________________________ > > conex mailing list > > conex@ietf.org > > https://www.ietf.org/mailman/listinfo/conex > > ________________________________________________________________ Bob Briscoe, BT Innovate & Design From toby@moncaster.com Mon Jun 21 07:21:04 2010 Return-Path: X-Original-To: conex@core3.amsl.com Delivered-To: conex@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id C551C3A681C for ; Mon, 21 Jun 2010 07:21:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 3.51 X-Spam-Level: *** X-Spam-Status: No, score=3.51 tagged_above=-999 required=5 tests=[BAYES_50=0.001, HELO_EQ_DE=0.35, HTML_MESSAGE=0.001, MIME_QP_LONG_LINE=1.396, MISSING_SUBJECT=1.762] 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 8zBS5I2Lwr6P for ; Mon, 21 Jun 2010 07:20:33 -0700 (PDT) Received: from moutng.kundenserver.de (moutng.kundenserver.de [212.227.126.186]) by core3.amsl.com (Postfix) with ESMTP id 4F85828C0FE for ; Mon, 21 Jun 2010 07:20:14 -0700 (PDT) Received: from TobysHP (host86-170-50-165.range86-170.btcentralplus.com [86.170.50.165]) by mrelayeu.kundenserver.de (node=mreu2) with ESMTP (Nemesis) id 0MfV31-1Oao0Z34I7-00OdRB; Mon, 21 Jun 2010 16:17:23 +0200 From: "Toby Moncaster" To: Date: Mon, 21 Jun 2010 15:17:21 +0100 Message-ID: <000e01cb114c$77a83490$66f89db0$@com> MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="----=_NextPart_000_000F_01CB1154.D96C9C90" X-Mailer: Microsoft Office Outlook 12.0 Thread-Index: AcsRTHaTsQ9zIfxoRM+XuPJKgrj5VQ== Content-Language: en-gb X-Provags-ID: V01U2FsdGVkX1/7GIdq9bs7R0sz6fK40OAq/Bw+f7SIq1LqM3K OKDonisHM1PIfPa6TcINTd2+zoVSL526Eeia1MvV9/KpX9g8yf s339ghTu0SAHDG0r2NTxt2BeOKHTkNs Subject: [conex] (no subject) X-BeenThere: conex@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Congestion Exposure working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 21 Jun 2010 14:21:04 -0000 This is a multi-part message in MIME format. ------=_NextPart_000_000F_01CB1154.D96C9C90 Content-Type: multipart/alternative; boundary="----=_NextPart_001_0010_01CB1154.D96C9C90" ------=_NextPart_001_0010_01CB1154.D96C9C90 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Hi All, We have been working on the attached draft. This is intended to cover both the conex mechanism and the use cases documents listed in our charter. We have combined these into a single document since we believe they are mutually dependent (A mechanism makes little sense without knowing what it can be used for and a list of use cases are meaningless without knowing what mechanism will enable them). We believe that this draft is a good start towards the work of the conex working group and we would like the working group to consider adopting this as a formal working group item. If anyone has any comments please do post them on the list. We are keen to spark active discussions of conex and hope to encourage other authors to post their own documents too Toby PS This is listed on the IETF website as draft-conex-mechanism-00 rather than the real name of draft-moncaster-conex-mechanism. This is probably my fault for getting something wrong in the xml file! > -----Original Message----- > From: IETF I-D Submission Tool [mailto:idsubmission@ietf.org] > Sent: 21 June 2010 15:02 > To: toby@moncaster.com > Cc: bob.briscoe@bt.com; richard_woundy@cable.comcast.com; john@jlc.net > Subject: New Version Notification for draft-conex-mechanism-00 > > > A new version of I-D, draft-conex-mechanism-00.txt has been > successfully submitted by Toby Moncaster and posted to the IETF > repository. > > Filename: draft-conex-mechanism > Revision: 00 > Title: Congestion Exposure Mechanism Description > Creation_date: 2010-06-21 > WG ID: Independent Submission > Number_of_pages: 19 > > Abstract: > Internet Service Providers (ISPs) are facing problems where > congestion prevents full utilization of the path between sender and > receiver at today's "broadband" speeds. ISPs desire to control the > congestion, which often appears to be caused by a small number of > users consuming a large amount of bandwidth. Building out more > capacity along all of the path to handle this congestion can be > expensive; and network operators have sought other ways to manage > congestion. The current mechanisms all suffer from difficulty > measuring the congestion (as distinguished from the total traffic). > > The ConEx Working Group is designing a mechanism to make congestion > along any path visible at the Internet Layer. This document > discusses this mechanism. > > > > The IETF Secretariat. ------=_NextPart_001_0010_01CB1154.D96C9C90 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hi All,

 

We have been working on the attached draft. This is = intended to cover both the conex mechanism and the use cases documents listed in = our charter. We have combined these into a single document since we believe = they are mutually dependent (A mechanism makes little sense without knowing = what it can be used for and a list of use cases are meaningless without knowing = what mechanism will enable them).

 

We believe that this draft is a good start towards = the work of the conex working group and we would like the working group to = consider adopting this as a formal working group item.

 

If anyone has any comments please do post them on = the list. We are keen to spark active discussions of conex and hope to encourage = other authors to post their own documents too

 

Toby

 

PS This is listed on the IETF website as draft-conex-mechanism-00 rather than the real name of draft-moncaster-conex-mechanism. This is probably my fault for getting something wrong in the xml file!

 

 

> -----Original = Message-----

> From: IETF I-D = Submission Tool [mailto:idsubmission@ietf.org]

> Sent: 21 June 2010 = 15:02

> To: = toby@moncaster.com

> Cc: bob.briscoe@bt.com; richard_woundy@cable.comcast.com; john@jlc.net

> Subject: New Version = Notification for draft-conex-mechanism-00

>

>

> A new version of I-D, = draft-conex-mechanism-00.txt has been

> successfully submitted by Toby Moncaster = and posted to the IETF

> repository.

>

> Filename: = draft-conex-mechanism

> Revision: 00

> = Title:         =20 Congestion Exposure Mechanism Description

> Creation_date:  = 2010-06-21

> WG = ID:         =20 Independent Submission

> Number_of_pages: 19

>

> Abstract:

> Internet Service Providers (ISPs) are = facing problems where

> congestion prevents full utilization of the = path between sender and

> receiver at today's "broadband" speeds.  ISPs desire to control the

> congestion, which often appears to be = caused by a small number of

> users consuming a large amount of = bandwidth.  Building out more

> capacity along all of the path to handle = this congestion can be

> expensive; and network operators have = sought other ways to manage

> congestion.  The current mechanisms = all suffer from difficulty

> measuring the congestion (as distinguished = from the total traffic).

>

> The ConEx Working Group is designing a = mechanism to make congestion

> along any path visible at the Internet = Layer.  This document

> discusses this mechanism.

>

>

>

> The IETF Secretariat.

 

 

------=_NextPart_001_0010_01CB1154.D96C9C90-- ------=_NextPart_000_000F_01CB1154.D96C9C90 Content-Type: text/html; name="draft-moncaster-conex-mechanism-00.html" Content-Transfer-Encoding: quoted-printable Content-Disposition: attachment; filename="draft-moncaster-conex-mechanism-00.html" =0A= Congestion Exposure Mechanism = Description=0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A=
 TOC 
=0A=
=0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A=
CONEXB. = Briscoe
Internet-DraftBT
Intended status: InformationalR. Woundy
Expires: December 23, 2010Comcast
 T. Moncaster, = Ed.
 Moncaster.com
 J. Leslie, = Ed.
 JLC.net
 June 21, = 2010
=0A=


Congestion Exposure Mechanism Description
draft-conex-mechanism-00

=0A= =0A=

Abstract

=0A= =0A=

Internet Service Providers (ISPs) are facing problems where = congestion=0A= prevents full utilization of the path between sender and receiver at = today's=0A= "broadband" speeds. ISPs desire to control the congestion, which often = appears=0A= to be caused by a small number of users consuming a large amount of = bandwidth.=0A= Building out more capacity along all of the path to handle this = congestion can=0A= be expensive; and network operators have sought other ways to manage = congestion.=0A= The current mechanisms all suffer from difficulty measuring the = congestion (as=0A= distinguished from the total traffic). =0A=

=0A=

The ConEx Working Group is designing a mechanism to make congestion = along any=0A= path visible at the Internet Layer. This document discusses this = mechanism. =0A=

=0A=

Status of This Memo

=0A=

=0A= This Internet-Draft is submitted in full=0A= conformance with the provisions of BCP 78 and BCP 79.

=0A=

=0A= Internet-Drafts are working documents of the Internet Engineering=0A= Task Force (IETF). Note that other groups may also distribute=0A= working documents as Internet-Drafts. The list of current=0A= Internet-Drafts is at http://datatracker.ietf.org/drafts/current/.

=0A=

=0A= Internet-Drafts are draft documents valid for a maximum of six months=0A= and may be updated, replaced, or obsoleted by other documents at any = time.=0A= It is inappropriate to use Internet-Drafts as reference material or to = cite=0A= them other than as “work in progress.”

=0A=

=0A= This Internet-Draft will expire on December 23, 2010.

=0A= =0A=

Copyright Notice

=0A=

=0A= Copyright (c) 2010 IETF Trust and the persons identified as the=0A= document authors. All rights reserved.

=0A=

=0A= This document is subject to BCP 78 and the IETF Trust's Legal=0A= Provisions Relating to IETF Documents=0A= (http://trustee.ietf.org/license-info) in effect on the date of=0A= publication of this document. Please review these documents=0A= carefully, as they describe your rights and restrictions with respect=0A= to this document. Code Components extracted from this document must=0A= include Simplified BSD License text as described in Section 4.e of=0A= the Trust Legal Provisions and are provided without warranty as=0A= described in the Simplified BSD License.

=0A=
=0A=

Table of Contents

=0A=

=0A= 1. =0A= Introduction
=0A= 2. =0A= Definitions
=0A= 3. =0A= Existing Approaches to Congestion Management
=0A= 4. =0A= Exposing Congestion
=0A= 5. =0A= ECN - a Step in the Right Direction
=0A= 6. =0A= The Proposed Congestion Exposure Mechanism
=0A= 7. =0A= Conex Use Cases
=0A=     7.1. =0A= Ingress policing for traffic management
=0A=     7.2. =0A= Conex to incentivise scavenger transports
=0A=     7.3. =0A= Conex to mitigate DDoS
=0A=     7.4. =0A= Conex as a form of differential QoS
=0A=     7.5. =0A= Other issues
=0A= 8. =0A= Security Considerations
=0A= 9. =0A= IANA Considerations
=0A= 10. =0A= Acknowledgments
=0A= 11. =0A= References
=0A=     11.1. =0A= Normative References
=0A=     11.2. =0A= Informative References
=0A=

=0A=
=0A= =0A=
=0A=
 TOC 
=0A=

1. =0A= Introduction

=0A= =0A=

The growth of "always on" broadband connections, coupled with the = steady=0A= increase in access speeds [OfCom] (Ofcom: Office = of Communications, “UK Broadband Speeds 2008: Research = report,” January 2009.), has meant = network operators are increasingly=0A= facing problems with congestion. But congestion results from sharing = network=0A= capacity with others, not merely from using it. In general, today's = "DSL"=0A= and cable-internet users cannot "cause" congestion in the absence of=0A= competing traffic. (Wireless ISPs and cellular internet have different=0A= tradeoffs which we will not discuss here.) =0A=

=0A=

Actual congestion generally results from the interaction of traffic = from=0A= an ISPs own subscribers with traffic from other users. The tools = currently=0A= available don't allow an operator to identify the causes of the = congestion=0A= and so leave them powerless to properly control it. =0A=

=0A=

While building out more capacity to handle increased traffic is = always=0A= good, the expense and lead-time can be prohibitive, especially for = network=0A= operators that charge flat-rate feeds to subscribers and are thus unable=0A= to charge heavier users more for causing more congestion [BB‑incentive] = (MIT Communications Futures Program (CFP) = and Cambridge University Communications Research Network, “The = Broadband Incentive Problem,” = September 2005.). For an operator=0A= facing congestion caused by other operators' networks, building out its=0A= own capacity is unlikely to solve the congestion problem. Operators are=0A= thus facing increased pressure to find effective solutions to dealing=0A= with high-consuming users. =0A=

=0A=

The growth of "scavenger-class" services helps to reduce congestion,=0A= but actually make the ISPs problem less tractable. These are services=0A= where participating users are not at all interested in paying more, but=0A= wish to make good use of the capacity of the path. Thus, users of such=0A= services may show very heavy total traffic up until the moment = congestion=0A= is detected (at the Transport Layer), but immediately back off. ISP=0A= monitoring (at the Internet Layer) cannot detect this congestion = avoidance=0A= if the congestion in question is in a different domain further along the=0A= path; and must treat such users as congestion-causing users. =0A=

=0A=

We propose that Internet Protocol (IP) packets have two "congestion"=0A= fields. The exact protocol details of these fields are for another=0A= document, but we expect them to provide measures of "congestion so far"=0A= and "congestion still expected". =0A=

=0A=
=0A=
 TOC 
=0A=

2. =0A= Definitions

=0A= =0A=

Since conex expects to build on Explicit Congestion Notification = (ECN)=0A= [RFC3168] (Ramakrishnan, K., Floyd, S., and D. Black, “The = Addition of Explicit Congestion Notification (ECN) to IP,” = September 2001.), we use the term = "congestion" in a manner=0A= consistent with ECN, namely that congestion occurs before any packet is=0A= dropped. =0A=

=0A=

We define five specific terms carefully:=0A= =0A=

=0A=
=0A=
Congestion:
=0A=
Congestion is a measure of the probability that a=0A= given packet will be ECN-marked or dropped as it traverses the = network.=0A= At any given router it is a function of the queue state at that = router.=0A= Congestion is added in a combinatorial manner, that is, routers = ignore=0A= the congestion a packet has already seen when they decide whether to=0A= mark it or not. =0A=
=0A=
Upstream Congestion:
=0A=
The congestion that has already been=0A= experienced by a packet as it travels along its path. In other = words at =0A= =0A= any point on the path, it is the congestion between the source of = the=0A= packet and that point. =0A=
=0A=
Downstream Congestion:
=0A=
The congestion that a packet still=0A= has to experience on the remainder of its path. In other words at = any=0A= point it is the congestion still to be experienced as the packet=0A= travels between that point and its destination.=0A=
=0A=
Ingress Router:
=0A=
The Ingress Router is the first router a=0A= packet traverses that is outside its own network. In a domestic = network=0A= that will be the first router downstream from the home access = equipment.=0A= In a commercial network it may be the first router downstream of the=0A= firewall. =0A=
=0A=
Egress Router:
=0A=
The Egress Router is the last router a packet=0A= traverses before it enters the destination network. =0A=
=0A=

=0A= =0A=

=0A=
=0A=
 TOC 
=0A=

3. =0A= Existing Approaches to Congestion Management

=0A= =0A=

Initial attempts to capture congestion situations have usually = focused on=0A= the peak hours and aimed at rate limiting heavy users during that time. = For=0A= example, users who have consumed a certain amount of bandwidth during = the=0A= last 24 hours got elected as those who get their traffic shaped if the=0A= total amount of traffic reaches a congestion situation in certain nodes=0A= within the operator's network. =0A=

=0A=

All of the current approaches suffer from some general limitations. = First,=0A= they introduce performance uncertainty. Flat-rate pricing plans are = popular=0A= because users appreciate the certainty of having their monthly bill = amount=0A= remain the same for each billing period, allowing them to plan their = costs=0A= accordingly. But while flat-rate pricing avoids billing uncertainty, it=0A= creates performance uncertainty: users cannot know whether the = performance=0A= of their connection is being altered or degraded based on how the = network=0A= operator manages congestion. =0A=

=0A=

Second, none of the approaches is able to make use of what may be the = most=0A= important factor in managing congestion: the amount that a given = endpoint=0A= contributes to congestion on the network. This information simply is not=0A= available to network nodes, and neither volume nor rate nor application=0A= usage is an adequate proxy for congestion volume, because none of these=0A= metrics measures a user or network's actual contribution to congestion = on=0A= the network. =0A=

=0A=

Finally, none of these solutions accounts for inter-network = congestion.=0A= Mechanisms may exist that allow an operator to identify and mitigate=0A= congestion in their own network, but the design of the Internet means = that=0A= only the end-hosts have full visibility of congestion information along = the=0A= whole path. Conex allows this information to be visible to everyone on = the=0A= path and thus allows operators to make better-informed decisions about=0A= controlling traffic. =0A=

=0A=
=0A=
 TOC 
=0A=

4. =0A= Exposing Congestion

=0A= =0A=

We argue that current traffic-control mechanisms seek to control the=0A= wrong quantity. What matters in the network is neither the volume of=0A= traffic nor the rate of traffic: it is the contribution to congestion = over=0A= time — congestion means that your traffic impacts other = users,=0A= and conversely that their traffic impacts you. So if there is no = congestion=0A= there need not be any restriction on the amount a user can send;=0A= restrictions only need to apply when others are sending traffic such = that=0A= there is congestion. =0A=

=0A=

For example, an application intending to transfer large amounts of = data=0A= could use a congestion control mechanism like [LEDBAT] (Shalunov, = S., “Low Extra Delay Background Transport (LEDBAT),” = March 2010.)=0A= to reduce its transmission rate before any competing TCP flows do, by=0A= detecting an increase in end-to-end delay (as a measure of impending=0A= congestion). However such techniques rely on voluntary, altruistic = action=0A= by end users and their application providers. ISPs can neither enforce=0A= their use nor avoid penalizing them for congestion they avoid. =0A=

=0A=

The Internet was designed so that end-hosts detect and control = congestion.=0A= We argue that congestion needs to be visible to network nodes as well, = not=0A= just to the end hosts. More specifically, a network needs to be able to=0A= measure how much congestion any particular traffic expects to cause = between=0A= the monitoring point in the network and the destination ("rest-of-path=0A= congestion"). This would be a new capability. Today a network can use=0A= Explicit Congestion Notification (ECN) [RFC3168] (Ramakrishnan, K., Floyd, S., and D. Black, “The = Addition of Explicit Congestion Notification (ECN) to IP,” = September 2001.) to=0A= detect how much congestion the traffic has suffered between the source = and=0A= a monitoring point, but not beyond. This new capability would enable an=0A= ISP to give incentives for the use of LEDBAT-like applications whilst=0A= restricting inappropriate uses of traditional TCP and UDP ones. =0A=

=0A=

So we propose a new approach which we call Congestion Exposure. We=0A= =0A= propose that congestion information should be made visible at the IP=0A= =0A= layer, so that any network node can measure the contribution to = congestion=0A= of an aggregate of traffic as easily as straight volume can be measured=0A= today. Once the information is exposed in this way, it is then=0A= =0A= possible to use it to measure the true impact of any traffic on the=0A= =0A= network. =0A=

=0A=

In general, congestion exposure gives ISPs a principled way to hold = their=0A= customers accountable for the impact on others of their network usage = and=0A= reward them for choosing congestion-sensitive applications. =0A=

=0A=
=0A=
 TOC 
=0A=

5. =0A= ECN - a Step in the Right Direction

=0A= =0A=

Explicit Congestion Notification [RFC3168] (Ramakrishnan, K., Floyd, S., and D. Black, “The = Addition of Explicit Congestion Notification (ECN) to IP,” = September 2001.) allows=0A= routers to explicitly tell end-hosts that they are approaching the = point of=0A= congestion. ECN builds on Active Queue Mechanisms such as random early=0A= discard (RED) [RFC2309] = (Braden, B., Clark, D., Crowcroft, J., = Davie, B., Deering, S., Estrin, D., Floyd, S., Jacobson, V., Minshall, = G., Partridge, C., Peterson, L., Ramakrishnan, K., Shenker, S., = Wroclawski, J., and L. Zhang, “Recommendations on Queue Management = and Congestion Avoidance in the Internet,” = April 1998.) by allowing the router to mark=0A= a packet with a Congestion Experienced (CE) codepoint, rather than = dropping=0A= it. The probability of a packet being marked increases with the length = of=0A= the queue and thus the rate of CE marks is a guide to the level of = congestion=0A= at that queue. This CE codepoint travels forward through the network to = the=0A= receiver which then informs the sender that it has seen congestion. The=0A= sender is then required to respond as if it had experienced a packet = loss.=0A= Because the CE codepoint is visible in the IP layer, this approach = reveals=0A= the upstream congestion level for a packet. =0A=

=0A=

Alas, this is not enough - ECN only allows downstream nodes to = measure the=0A= congestion so far for any flow. This can help hold a receiver = accountable for=0A= the congestion caused by incoming traffic. But a receiver can only = indirectly=0A= influence incoming congestion, by politely asking the sender to control = it. A=0A= receiver cannot make a sender install an adaptive codec, or install = LEDBAT=0A= instead of TCP congestion-control. And a receiver cannot cause an = attacker to=0A= stop flooding it with traffic. =0A=

=0A=

What is needed is knowledge of the downstream congestion level, for = which=0A= you need additional information that is still concealed from the = network. =0A=

=0A=
=0A=
 TOC 
=0A=

6. =0A= The Proposed Congestion Exposure Mechanism

=0A= =0A=

The protocol we propose is based on a concept known as re-feedback=0A= [Re‑Feedback] = (Briscoe, B., Jacquet, A., Di = Cairano-Gilfedder, C., Salvatori, A., Soppera, A., and M. Koyabe, = “Policing Congestion Response in an Internetwork Using = Re-Feedback,” August 2005.), and = builds on existing active queue=0A= management techniques like RED [RFC2309] (Braden, = B., Clark, D., Crowcroft, J., Davie, B., Deering, S., Estrin, D., Floyd, = S., Jacobson, V., Minshall, G., Partridge, C., Peterson, L., = Ramakrishnan, K., Shenker, S., Wroclawski, J., and L. Zhang, = “Recommendations on Queue Management and Congestion Avoidance in = the Internet,” April 1998.) and ECN=0A= [RFC3168] (Ramakrishnan, K., Floyd, S., and D. Black, “The = Addition of Explicit Congestion Notification (ECN) to IP,” = September 2001.) that network elements can = already use to=0A= measure and expose congestion. =0A=

=0A=

We propose that packets have two "congestion" fields in their IP = header:=0A= =0A= =0A=

=0A=
    =0A=
  • A congestion experienced field to record the upstream congestion = level=0A= along the path. Routers indicate their current congestion level by=0A= updating this field in every packet. As the packet traverses the = network=0A= it builds up a record of the overall congestion along its path in this=0A= field. This data is sent back to the sender who uses it to determine = its=0A= transmission rate. =0A=
    • =0A=
  • A whole-path congestion field that uses re-feedback to record the = total=0A= congestion expected along the path. The sender does this by = re-inserting=0A= the current congestion level for the path into this field for every = packet=0A= it transmits. =0A=
    • =0A=

=0A= =0A= =0A= Thus at any node downstream of the sender you can see the upstream=0A= congestion for the packet (the congestion thus far) and the whole path=0A= congestion (with a time lag of one round-trip-time (RTT)) and can = calculate=0A= the downstream congestion by subtracting one from the other. =0A=

=0A=

So congestion exposure can be achieved by coupling congestion = notification=0A= from routers with the re-insertion of this information by the sender. = This=0A= establishes information symmetry between users and network providers. =0A=

=0A=
=0A=
 TOC 
=0A=

7. =0A= Conex Use Cases

=0A= =0A=

Conex is a simple concept that has revolutionary implications. It is = that rare=0A= thing — a truly disruptive technology, and as such it is = hard to=0A= imagine the variety of uses it may be put to. However there are several = obvious=0A= use cases that come to mind with a little thought. The authors aren't = claiming=0A= all of these have equal merit, nor are we claiming conex is the only = conceivable=0A= solution to achieve these. But these use cases represent a consensus = among=0A= people that have been working on this approach for some years. =0A=

=0A=

In the following use cases we are assuming the most abstract version = of the=0A= conex mechanism, namely that every packet carries two congestion = fields, one for=0A= upstream congestion and one for downstream. At every node that is = congested the=0A= upstream congestion value will be incremented in some manner and the = downstream=0A= congestion value will be decremented. Assuming there is accurate = feedback in the=0A= system then the aim should be for the downstream value to be zero or = slightly=0A= positive by the time the packet reaches its destination. =0A=

=0A=

If conex information is to be useful it has to be accurate (within = the=0A= limitations of the available feedback). This raises three issues that = need to be=0A= addressed:=0A= =0A=

=0A=
=0A=
Distinguishing conex traffic from non-conex traffic:
=0A=
=0A= On one level this seems pretty easy — conex traffic = needs to have=0A= the downstream congestion field in every packet. However in = practise it may not=0A= be as simple as this. Re-ECN is one proposed implementation of = conex. Here the=0A= two congestion fields are unary-encoded into a stream of packets by = effectively=0A= setting or clearing a single bit. Assuming you are able to identify = non-conex=0A= (or legacy) traffic, then you need to decide what to do about it. = An ISP may=0A= reasonably choose to do nothing different with this traffic. = Alternatively they=0A= might incentivise the conex traffic in order to give it marginally = better=0A= service. =0A=
=0A=
Over-declaring congestion:
=0A=
=0A= Conex relies on the sender accurately declaring the congestion they = expect to=0A= see. During TCP slow-start a sender is unable to predict the level = of congestion=0A= they will experience and it is advisable to declare that expect to = see some=0A= congestion on the first packet. However, if any host or router = marks more than=0A= a small fraction of total traffic, downstream routers are less = likely to trust=0A= its congestion markings. We do not initially propose any mechanism = to deal with=0A= this issue. =0A=
=0A=
Under-declaring congestion:
=0A=
=0A= Conex requires the sender to set the downstream congestion field in = each packet =0A= to their best estimate of what they expect the whole path = congestion to be. If=0A= this expected congestion level is to be used for traffic management = (see use=0A= cases) then it benefits the user to under-declare. Mechanisms are = needed to=0A= prevent this happening. =0A=
=0A=
=0A=
There are three approaches that may work (individually or in = combination):=0A= =0A=
    =0A=
  • An ingress router can monitor a user's feedback to see what their = reported=0A= congestion level actually is. =0A=
    • =0A=
  • A conex-aware router can drop any packet with a = downstream-congestion value=0A= of zero or less if that router is even slightly congested. =0A=
    • =0A=
  • An egress router can actively monitor some or all flows to check = that they=0A= are complying with the requirement that the downstream congestion = value should=0A= be zero or (slightly positive) when it reaches the egress. =0A=
    • =0A=
=0A= =0A=
=0A=

=0A= =0A=

=0A=

At any point of congestion, it is reasonable to treat conex-marked = traffic=0A= differently:=0A=

=0A=
    =0A=
  • non-conex traffic will mostly be dropped (as now); =0A=
    • =0A=
  • conex-marked traffic which has exhausted its congestion allowance = will (all)=0A= be dropped; =0A=
    • =0A=

=0A= =0A=

=0A=
=0A=
 TOC 
=0A=

7.1. =0A= Ingress policing for traffic management

=0A= =0A=

Currently many ISPs impose some form of traffic management at peak = hours. This=0A= is a simple economic necessity — the only reason the = Internet works=0A= as a commercial concern is that ISPs are able to rely on statistical = multiplexing=0A= to share their expensive core network between large numbers of = customers. In order=0A= to ensure all customers get some chance to access the network, the = "heaviest"=0A= customers will be subjected to some form of traffic management at = peak times=0A= (typically a rate cap for certain types of traffic) [Fair‑use] (Broadband Choices, “Truth about 'fair usage' = broadband,” 2009.). Often this traffic=0A= management is done with expensive flow aware devices such as DPI = boxes or flow-aware=0A= routers. =0A=

=0A=

Conex enables a new approach that requires simple per-user policing = at the ingress.=0A= As described above, every packet a user sends should declare the = total congestion=0A= that the sender expects that packet to encounter on its journey = through the network.=0A= Congestion volume has been defined [Fairer‑faster] (Briscoe, B., “A Fairer Faster Internet = Protocol,” December 2008.) as the = congestion a packet experiences,=0A= multiplied by the size of that packet. In effect this is a measure of = how much=0A= traffic was sent that was above the instantaneous transmission = capacity of the=0A= network. By extension the congestion rate would be the transmission = rate multiplied=0A= by the congestion level. A 1 Gbps router that is 0.1% congested = implies that there is=0A= 1 Mbps of excess traffic. =0A=

=0A=

At the Ingress Router an ISP can police the amount of congestion a = user is causing=0A= by limiting the congestion volume they send into the network. One = system that=0A= achieves this is described in [Policing‑freedom] (Briscoe, B., Jacquet, A., and T. Moncaster, = “Policing Freedom to Use the Internet Resource Pool,” = December 2008.).=0A= This uses a modified token bucket to limit the congestion rate being = sent rather=0A= than the overall rate. Such ingress policing is relatively simple as = it requires no=0A= flow state. Furthermore, unlike many mechanisms, it treats all a = user's packets=0A= equally. =0A=

=0A=
=0A=
 TOC 
=0A=

7.2. =0A= Conex to incentivise scavenger transports

=0A= =0A=

Recent work proposes a new approach for QoS where traffic is = provided with a less=0A= than best effort or "scavenger" quality of service. The idea is that = low priority=0A= but high volume traffic such as OS updates, P2P file transfers and = view-later TV=0A= programs should be allowed to use any spare network capacity, but = should rapidly=0A= get out of the way if a higher priority or interactive application = starts up.=0A= One solution being actively explored is LEDBAT which proposes a new = congestion=0A= control algorithm that is less aggressive in seeking out bandwidth = than TCP. =0A=

=0A=

At present most ISPs assume a strong correlation between the volume = of a flow=0A= and the impact that flow causes in the network. This assumption has = been eroded=0A= by the growth of interactive streaming which behaves in an inelastic = manner.=0A= Assuming the end-user is using conex marking on all traffic and that = LEDBAT=0A= leads to the expected low level of congestion and the ingress ISP has = deployed=0A= a conex-aware ingress policer, then the LEDBAT will not be penalised = since it=0A= will be causing less congestion. (If LEDBAT is not conex-marking = traffic then=0A= the ISP will be forced to guess the congestion, probably based on the = total=0A= volume). =0A=

=0A=

If the ISP has deployed a conex-aware ingress policer then they are = able to=0A= incentivise the use of LEDBAT because a user will be policed = according to the=0A= overall congestion volume their traffic generates. If all background = file=0A= transfers are only generating a low level of congestion then the = sender has=0A= more "congestion budget" to "spend" on their interactive = applications. It can=0A= be shown [Kelly] = (Kelly, F., Maulloo, A., and D. Tan, = “Rate control for communication networks: shadow prices, = proportional fairness and stability,” = 1998.) that this approach maximises social = welfare — in=0A= other words if you limit the congestion that all users can generate = then=0A= everyone benefits from a better service. =0A=

=0A=
=0A=
 TOC 
=0A=

7.3. =0A= Conex to mitigate DDoS

=0A= =0A=

DDoS relies on subverting innocent end users and getting them to = send flood=0A= traffic to a given destination. This is intended to cause a rapid = increase in=0A= congestion in the immediate vicinity of that destination. If it fails = to do this=0A= then it can't be called Denial of Service. If the ingress ISP has = deployed conex=0A= policers, that ISP will limit how much DDoS traffic enters the 'net. = If the=0A= compromised user tries to use the 'net during the DDoS attack, they = will quickly =0A= become aware that something is wrong, and their ISP can show the = evidence that=0A= their computer has become zombified. =0A=

=0A=
=0A=
 TOC 
=0A=

7.4. =0A= Conex as a form of differential QoS

=0A= =0A=

Most QoS approaches require the active participation of routers to = control the=0A= delay and loss characteristics for the traffic. For real-time = interactive traffic=0A= it is clear that low delay and low jitter are critical and thus these = probably=0A= always need different treatment at a router. However if low loss is = the issue=0A= then conex offers an alternative approach. Assuming the ingress ISP = has deployed=0A= conex-aware ingress policing then the only control on a user's = traffic is=0A= dependent on the congestion that user has caused. If they want to = prioritise some=0A= traffic over other traffic then they can allow that traffic to = generate more=0A= congestion. The price to pay will be to reduce the congestion that = their other=0A= traffic causes. =0A=

=0A=
=0A=
 TOC 
=0A=

7.5. =0A= Other issues

=0A= =0A=

make a source believe it has seen more congestion than it has =0A=

=0A=

hijack a user's identity and make it appear they are dishonest at an = egress =0A= policer =0A=

=0A=

clear or otherwise tamper with the conex markings =0A=

=0A=

... =0A=

=0A=
=0A=
 TOC 
=0A=

8. =0A= Security Considerations

=0A= =0A=

This document proposes a mechanism tagging onto Explicit Congestion = Notification=0A= [RFC3168] = (Ramakrishnan, K., Floyd, S., and D. Black, = “The Addition of Explicit Congestion Notification (ECN) to = IP,” September 2001.), and inherits = the security issues listed therein. The=0A= additional issues from Congestion Expected markings relate to = the degree of trust=0A= each forwarding point places in Congestion Expected markings it = receives, which is=0A= a business decision mostly orthogonal to the markings = themselves. =0A=

=0A=

One expected use of exposed congestion information is to hold the = end-to-end=0A= transport and the network accountable to each other. The network cannot = be relied=0A= on to report information to the receiver against its interest, and the = same applies=0A= for the information the receiver feeds back to the sender, and that the = sender=0A= reports back to the network. Looking at each in turn:=0A= =0A= =0A=

=0A=
    =0A=
  • The Network. In general it is not in any network's interest to = under-declare=0A= congestion since this will have potentially negative consequences for = all users=0A= of that network. It may be in its interest to over-declare congestion = if, for=0A= instance, it wishes to force traffic to move away to a different = network or=0A= simply to reduce the amount of traffic it is carrying. Congestion = Exposure=0A= itself won't significantly alter the incentives for and against honest=0A= declaration of congestion by a network, but we can imagine = applications of=0A= Congestion Exposure that will change these incentives. There is a = perception=0A= among network operators that their level of congestion is a business = secret.=0A= Today, congestion is one of the worst-kept secrets a network has, = because=0A= end-hosts can see congestion better than network operators can. = Congestion=0A= Exposure will enable network operators to pinpoint whether congestion = is on=0A= one side or the other of any border. It is conceivable that = forwarders with=0A= underprovisioned networks may try to obstruct deployment of Congestion=0A= Exposure. =0A=
    • =0A=
  • The Receiver. Receivers generally have an incentive to under-declare=0A= congestion since they generally wish to receive the data from the = sender as=0A= rapidly as possible. [Savage] (Savage, S., = Wetherall, D., and T. Anderson, “TCP Congestion Control with a = Misbehaving Receiver,” 1999.) explains how = a receiver can=0A= significantly improve their throughput my failing to declare = congestion. This=0A= is a problem with or without Congestion Exposure. [KGao] (Gao, K. and C. = Wang, “Incrementally Deployable Prevention to TCP Attack with = Misbehaving Receivers,” = December 2004.)=0A= explains one possible technique to encourage receiver's to be honest = in their=0A= declaration of congestion.=0A=
    • =0A=
  • The Sender. One proposed mechanism for Congestion Exposure = deployment adds=0A= a requirement for a sender to advise the network how much congestion = it has=0A= suffered or caused. Although most senders currently respond to = congestion=0A= they are informed of, one use of exposed congestion information might = be to=0A= encourage sources of excessive congestion to back off more = aggressively.=0A= Then clearly there may be an incentive for the sender to under-declare=0A= congestion. This will be a particular problem with sources of flooding=0A= attacks. "Policing" mechanisms have been proposed to deal with this. =0A=
    • =0A=

=0A= =0A= =0A= =0A= In addition there are potential problems from source spoofing. A = malicious=0A= sender can pretend to be another user by spoofing the source address.=0A= Congestion Exposure allows for "Policers" and "Traffic Shapers" so as = to be=0A= robust against injection of false congestion information into the = forward=0A= path. =0A=

=0A=
=0A=
 TOC 
=0A=

9. =0A= IANA Considerations

=0A= =0A=

This document does not require actions by IANA.=0A=

=0A=
=0A=
 TOC 
=0A=

10. =0A= Acknowledgments

=0A= =0A=

The authors would like to thank Contributing Authors Bernard Aboba,=0A= João Taveira Araújo, Louise Burness, Alissa Cooper, =0A= Philip Eardley, Michael Menth, and Hannes Tschofenig for their inputs to=0A= this document. =0A=

=0A=
=0A=
 TOC 
=0A=

11. =0A= References

=0A= =0A=
=0A=
 TOC 
=0A=

11.1. Normative References

=0A= =0A= =0A= =0A=
[RFC3168]Ramakrishnan, K., Floyd, S., and D. Black, = “The Addition of = Explicit Congestion Notification (ECN) to IP,” RFC 3168, = September 2001 (TXT).
=0A= =0A=
=0A=
 TOC 
=0A=

11.2. Informative References

=0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A=
[BB-incentive]MIT Communications Futures Program (CFP) and = Cambridge University Communications Research Network, “The Broadband = Incentive Problem,” September 2005.
[Fair-use]Broadband Choices, “Trut= h about 'fair usage' broadband,” 2009.
[Fairer-faster]Briscoe, B., “A Fairer Faster Internet Protocol,” IEEE = Spectrum Dec 2008 pp38-43, December 2008.
[KGao]Gao, K. and C. Wang, “Incremental= ly Deployable Prevention to TCP Attack with Misbehaving = Receivers,” December 2004.
[Kelly]Kelly, F., Maulloo, A., and D. Tan, “Rate control for = communication networks: shadow prices, proportional fairness and = stability,” Journal of the Operational Research = Society 49(3) 237--252, 1998 (PDF).
[LEDBAT]Shalunov, S., “Low Extra Delay Background Transport (LEDBAT),” = draft-ietf-ledbat-congestion-01 (work in progress), March 2010 (TXT).
[OfCom]Ofcom: Office of Communications, “UK Broadband Speeds 2008: Research report,” = January 2009.
[Policing-freedom]Briscoe, B., Jacquet, A., and T. Moncaster, = “Policing Freedom = to Use the Internet Resource Pool,” RE-Arch 2008 hosted at the = 2008 CoNEXT conference , December 2008.
[RFC2309]Braden, = B., Clark, D., Crowcroft, J., Davie, B., Deering, S., Estrin, D., Floyd, S., Jacobson, V., Minshall, G., Partridge, C., Peterson, L., Ramakrishnan, K., Shenker, S., Wroclawski, J., and L. Zhang, “Recommendations on Queue = Management and Congestion Avoidance in the Internet,” = RFC 2309, April 1998 (TXT, HTML, = XML).
[Re-Feedback]Briscoe, B., Jacquet, A., Di = Cairano-Gilfedder, C., Salvatori, A., Soppera, A., and M. Koyabe, = “Policing Congestion Response in an Internetwork Using = Re-Feedback,” ACM SIGCOMM CCR 35(4)277—288, = August 2005 (PDF).
[Savage]Savage, S., Wetherall, D., and T. Anderson, = “TCP = Congestion Control with a Misbehaving Receiver,” ACM SIGCOMM = Computer Communication Review , 1999.
=0A= =0A=
=0A=
 TOC 
=0A=

Authors' Addresses

=0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A=
 Bob Briscoe
 BT
 B54/77, Adastral Park
 Martlesham Heath
 Ipswich IP5 3RE
 UK
Phone: +44 1473 645196
EMail: bob.briscoe@bt.com
URI: http://bobbriscoe.net/
  
 Richard Woundy
 Comcast
 Comcast Cable Communications
 27 Industrial Avenue
 Chelmsford, MA 01824
 US
EMail: richard_woundy@cable.com= cast.com
URI: http://www.comcast.com
  
 Toby Moncaster (editor)
 Moncaster.com
 Layer Marney
 Colchester CO5 9UZ
 UK
EMail: toby@moncaster.com
  
 John Leslie (editor)
 JLC.net
 10 Souhegan Street
 Milford, NH 03055
 US
EMail: john@jlc.net
=0A= =0A= =0A= ------=_NextPart_000_000F_01CB1154.D96C9C90-- From ingemar.s.johansson@ericsson.com Tue Jun 22 04:14:21 2010 Return-Path: X-Original-To: conex@core3.amsl.com Delivered-To: conex@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 1E55E3A689E for ; Tue, 22 Jun 2010 04:14:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.037 X-Spam-Level: X-Spam-Status: No, score=-4.037 tagged_above=-999 required=5 tests=[AWL=-0.038, BAYES_50=0.001, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id DADVdXugE03d for ; Tue, 22 Jun 2010 04:14:19 -0700 (PDT) Received: from mailgw10.se.ericsson.net (mailgw10.se.ericsson.net [193.180.251.61]) by core3.amsl.com (Postfix) with ESMTP id D9C033A693A for ; Tue, 22 Jun 2010 04:14:18 -0700 (PDT) X-AuditID: c1b4fb3d-b7c50ae000005e30-79-4c209b10ebee Received: from esessmw0256.eemea.ericsson.se (Unknown_Domain [153.88.253.125]) by mailgw10.se.ericsson.net (Symantec Mail Security) with SMTP id 46.FF.24112.01B902C4; Tue, 22 Jun 2010 13:14:25 +0200 (CEST) Received: from ESESSCMS0356.eemea.ericsson.se ([169.254.2.128]) by esessmw0256.eemea.ericsson.se ([10.2.3.125]) with mapi; Tue, 22 Jun 2010 13:14:24 +0200 From: Ingemar Johansson S To: "conex@ietf.org" Date: Tue, 22 Jun 2010 13:14:24 +0200 Thread-Topic: What is a normal ECN rate ? Thread-Index: AcsR/BHuuNWpsi+OQriIxl0JB6/T+g== Message-ID: <548FC4B9D57A4043AAFFE888A39429031DA7831E7D@ESESSCMS0356.eemea.ericsson.se> Accept-Language: sv-SE, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: sv-SE, en-US Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Brightmail-Tracker: AAAAAA== Subject: [conex] What is a normal ECN rate ? X-BeenThere: conex@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Congestion Exposure working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 22 Jun 2010 11:14:21 -0000 Hi Seeking advice on a subject that I don't fully understand... The idea with conex is that the ECN-CE markings should be re-inserted into = the IP header in the forward flow for future use by e.g policers. This I be= lieve will require that there is some kind of uniform behavior in ECN marki= ng algorithms or? If not there is a chance that different nodes in the mesh may ECN-CE mark d= ifferently for the same load (in an abstract meaning) as there are AFAIK no= strict guidelines besides "mark instead of drop", and this may make polici= ng throublesome. =20 Trying to formulate a proper question here: Is the goal of ECN-CE marking t= hat the ECN rate should be zero at "normal congestion" or can one imagine t= he case that e.g a realtime streaming service can tune its bitrate such tha= t the ECN rate should stay below for instance 2% where 2% ECN rate is in fa= ct considered a healthy condition?. Regards Ingemar =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D INGEMAR JOHANSSON M.Sc.=20 Senior Research Engineer=20 Ericsson AB Multimedia Technologies Labratoriegr=E4nd 11 971 28, Lule=E5, Sweden Phone +46-1071 43042 SMS/MMS +46-73 078 3289 ingemar.s.johansson@ericsson.com www.ericsson.com=20 Visit http://labs.ericsson.com ! =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D From fred@cisco.com Tue Jun 22 05:32:57 2010 Return-Path: X-Original-To: conex@core3.amsl.com Delivered-To: conex@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 337013A69B5 for ; Tue, 22 Jun 2010 05:32:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -109.547 X-Spam-Level: X-Spam-Status: No, score=-109.547 tagged_above=-999 required=5 tests=[AWL=1.052, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 0xAzlQF8qxs9 for ; Tue, 22 Jun 2010 05:32:56 -0700 (PDT) Received: from rtp-iport-2.cisco.com (rtp-iport-2.cisco.com [64.102.122.149]) by core3.amsl.com (Postfix) with ESMTP id D2B943A6917 for ; Tue, 22 Jun 2010 05:32:55 -0700 (PDT) Authentication-Results: rtp-iport-2.cisco.com; dkim=neutral (message not signed) header.i=none X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AvsEAOJJIExAZnwN/2dsb2JhbACfFXGle5pRAoUZBA X-IronPort-AV: E=Sophos;i="4.53,460,1272844800"; d="scan'208";a="124263291" Received: from rtp-core-2.cisco.com ([64.102.124.13]) by rtp-iport-2.cisco.com with ESMTP; 22 Jun 2010 12:33:02 +0000 Received: from dhcp-144-254-34-100.cisco.com (dhcp-144-254-34-100.cisco.com [144.254.34.100]) by rtp-core-2.cisco.com (8.13.8/8.14.3) with ESMTP id o5MCWsLB016372; Tue, 22 Jun 2010 12:32:56 GMT Received: from [127.0.0.1] by dhcp-144-254-34-100.cisco.com (PGP Universal service); Tue, 22 Jun 2010 14:33:01 +0200 X-PGP-Universal: processed; by dhcp-144-254-34-100.cisco.com on Tue, 22 Jun 2010 14:33:01 +0200 Mime-Version: 1.0 (Apple Message framework v1081) From: Fred Baker In-Reply-To: <548FC4B9D57A4043AAFFE888A39429031DA7831E7D@ESESSCMS0356.eemea.ericsson.se> Date: Tue, 22 Jun 2010 14:32:45 +0200 Message-Id: <324F5D6D-D971-4571-A131-96AB5E0EA3DE@cisco.com> References: <548FC4B9D57A4043AAFFE888A39429031DA7831E7D@ESESSCMS0356.eemea.ericsson.se> To: Ingemar Johansson S X-Mailer: Apple Mail (2.1081) Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable Cc: "conex@ietf.org" Subject: Re: [conex] What is a normal ECN rate ? X-BeenThere: conex@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Congestion Exposure working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 22 Jun 2010 12:32:57 -0000 comparable to nominal loss rates in TCP On Jun 22, 2010, at 1:14 PM, Ingemar Johansson S wrote: > Hi >=20 > Seeking advice on a subject that I don't fully understand... >=20 > The idea with conex is that the ECN-CE markings should be re-inserted = into the IP header in the forward flow for future use by e.g policers. = This I believe will require that there is some kind of uniform behavior = in ECN marking algorithms or? > If not there is a chance that different nodes in the mesh may ECN-CE = mark differently for the same load (in an abstract meaning) as there are = AFAIK no strict guidelines besides "mark instead of drop", and this may = make policing throublesome. >=20 > Trying to formulate a proper question here: Is the goal of ECN-CE = marking that the ECN rate should be zero at "normal congestion" or can = one imagine the case that e.g a realtime streaming service can tune its = bitrate such that the ECN rate should stay below for instance 2% where = 2% ECN rate is in fact considered a healthy condition?. >=20 > Regards > Ingemar > =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D > INGEMAR JOHANSSON M.Sc.=20 > Senior Research Engineer=20 >=20 > Ericsson AB > Multimedia Technologies > Labratoriegr=E4nd 11 > 971 28, Lule=E5, Sweden > Phone +46-1071 43042 > SMS/MMS +46-73 078 3289 > ingemar.s.johansson@ericsson.com > www.ericsson.com=20 > Visit http://labs.ericsson.com ! > =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D > _______________________________________________ > conex mailing list > conex@ietf.org > https://www.ietf.org/mailman/listinfo/conex http://www.ipinc.net/IPv4.GIF From john@jlc.net Tue Jun 22 06:11:05 2010 Return-Path: X-Original-To: conex@core3.amsl.com Delivered-To: conex@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id D28D73A6985 for ; Tue, 22 Jun 2010 06:11:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.485 X-Spam-Level: X-Spam-Status: No, score=-3.485 tagged_above=-999 required=5 tests=[AWL=0.514, BAYES_50=0.001, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id y3wc4gGS1jeh for ; Tue, 22 Jun 2010 06:11:04 -0700 (PDT) Received: from mailhost.jlc.net (mailhost.jlc.net [199.201.159.9]) by core3.amsl.com (Postfix) with ESMTP id 1D5F63A685B for ; Tue, 22 Jun 2010 06:11:04 -0700 (PDT) Received: by mailhost.jlc.net (Postfix, from userid 104) id 548AA33C4A; Tue, 22 Jun 2010 09:11:11 -0400 (EDT) Date: Tue, 22 Jun 2010 09:11:11 -0400 From: John Leslie To: Ingemar Johansson S Message-ID: <20100622131111.GB5977@verdi> References: <548FC4B9D57A4043AAFFE888A39429031DA7831E7D@ESESSCMS0356.eemea.ericsson.se> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <548FC4B9D57A4043AAFFE888A39429031DA7831E7D@ESESSCMS0356.eemea.ericsson.se> User-Agent: Mutt/1.4.1i Cc: "conex@ietf.org" Subject: [conex] Transport 101 X-BeenThere: conex@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Congestion Exposure working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 22 Jun 2010 13:11:05 -0000 Ingemar Johansson raised a question, which brought to mind an issue documented in the NomCom report: http://tools.ietf.org/html/draft-barnes-nomcom-report-2009-00#section-7.3 ] ] Several individuals in the community emphasized the importance of ] having a researcher in the Transport AD position, given that the ] primary focus of current efforts is research based. However, none of ] the individuals with that specific background or focus were able to ] accept the nomination... (I am neither a researcher nor interested in that AD position; but I do perhaps have a Transport-101 level of understanding. I think it's important to develop folks that _can_ fill that position: so I'll start this thread and see what happens...) Ingemar Johansson S wrote: > > The idea with conex is that the ECN-CE markings should be re-inserted > into the IP header in the forward flow for future use by e.g policers. > This I believe will require that there is some kind of uniform behavior > in ECN marking algorithms or? Good question! Strangely enough, the answer is, "No." Let me start with the legacy "pure-dumb" forwarding router: - for every outgoing interface, have a buffer of "convenient" size; - when a packet to forward won't fit in it, drop that packet. "Convenient size" was left completely open. Transport protocols, especially TCP, were initially designed around this pure-dumb forwarding approach. They had to come up with algorithms to "accurately guess" when a packet had been dropped. (The student would do well to research some of these.) Since our "pure-dumb" forwarding network explicitly _does_not_ guarantee in-order delivery, the presence of an out-of-order packet cannot be taken as a definitive indication of a dropped packet. It turns out that different flavors of TCP congestion control use different indicators of dropped packets, but none of them can detect the loss in as little as one Round-Trip-Time (RTT). Explicit Congestion Notification attempts to close this loop faster. The basic change proposed by ECN is to detect the impending need to drop a packet; and instead "mark" a packet already in the queue as "we're congested here: please slow down." That signal (hopefully) will reach the sender in one RTT. While ECN states how the sender should react, it really has no way of enforcing that; and everybody involved knows that there are different flavors of TCP congestion control. Thus it's pretty loose what will actually happen. This is a problem for ECN deployment, of course. Folks are hesitant to program their routers to go to all this trouble if they can't trust senders to actually back off. Worse yet, there may be routers along the remainder of the path that strip off ECN marks. :^( (This turns out to be a deployment issue for ConEx, too.) Getting back to Ingemar's question: the important function of ECN is to get feedback sooner; and the router that ECN-marks a packet _is_ congested (in the sense that it's already pushing its limit of delay in forwarding, and "expects" to need to drop packets). Thus backing off the sending rate clearly is appropriate. Backing off sooner is an unmitigated good. Packet loss does nasty things. In particular, it prevents all ordinary TCP algorithms from ever filling a pipe if the Bandwidth-Delay product is too large. > If not there is a chance that different nodes in the mesh may ECN-CE > mark differently for the same load (in an abstract meaning) as there > are AFAIK no strict guidelines besides "mark instead of drop", and > this may make policing throublesome. Ingemar is correct that there are no strict guidelines. But in a well-functioning network we can hope for only one router along the path needing to ECN mark an individual packet, and we do know that router has good reason for the sender to slow down. "Policing" is a ConEx thing, not an ECN thing. Many details will need to be worked out (and aren't even in-charter for us yet), but the essence of proposals we've seen so far is that policing will verify that the sender isn't exceeding an allowance (or has sufficent credit if the business model involve charging). Thus, policing is not tied to any particular algorithm for ECN marking. > Trying to formulate a proper question here: Is the goal of ECN-CE > marking that the ECN rate should be zero at "normal congestion" Yes. (Of course, "normal congestion" here is taken to mean no packets being dropped, at a minimum.) > or can one imagine the case that e.g. a realtime streaming service > can tune its bitrate such that the ECN rate should stay below for > instance 2% where 2% ECN rate is in fact considered a healthy > condition?. IMHO, a 2% marking rate can _never_ be considered a healthy condition. I think the most wildly optimistic "healthy condition" any ISP today would consider is closer to 0.5% -- and that's bad enough to prevent filling pipes today. But, to answer the literal question, a streaming service that has sufficient credit _could_ tune to 2% marking in order to monopolize the congested link -- and the money changing hands could (in a perfect world) go towards expanding the capacity of that link. (In the real world, I'd guess that the money changing hands would have to be "sufficient" to cover that cost or there'd be _serious_ pressure on the upstream ISP to mark less packets.) -- John Leslie From ietfdbh@comcast.net Tue Jun 22 07:04:19 2010 Return-Path: X-Original-To: conex@core3.amsl.com Delivered-To: conex@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id DCC0F3A677D for ; Tue, 22 Jun 2010 07:04:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.28 X-Spam-Level: X-Spam-Status: No, score=-0.28 tagged_above=-999 required=5 tests=[AWL=-0.281, BAYES_50=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Pg3xBkX+vy38 for ; Tue, 22 Jun 2010 07:04:19 -0700 (PDT) Received: from qmta05.westchester.pa.mail.comcast.net (qmta05.westchester.pa.mail.comcast.net [76.96.62.48]) by core3.amsl.com (Postfix) with ESMTP id 0C1453A6359 for ; Tue, 22 Jun 2010 07:04:18 -0700 (PDT) Received: from omta18.westchester.pa.mail.comcast.net ([76.96.62.90]) by qmta05.westchester.pa.mail.comcast.net with comcast id Z0zE1e0041wpRvQ5524TtZ; Tue, 22 Jun 2010 14:04:27 +0000 Received: from 23FX1C1 ([67.189.235.106]) by omta18.westchester.pa.mail.comcast.net with comcast id Z24S1e00Z2JQnJT3e24SHJ; Tue, 22 Jun 2010 14:04:27 +0000 From: "David Harrington" To: "'John Leslie'" , "'Ingemar Johansson S'" References: <548FC4B9D57A4043AAFFE888A39429031DA7831E7D@ESESSCMS0356.eemea.ericsson.se> <20100622131111.GB5977@verdi> Date: Tue, 22 Jun 2010 10:03:07 -0400 Message-ID: <1A08A52AD45543F68B6D914A29CD74AF@23FX1C1> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 11 Thread-Index: AcsSDGX6zijm5CbdSmq0liWRq78j+AABmiTQ In-Reply-To: <20100622131111.GB5977@verdi> X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.5931 Cc: conex@ietf.org Subject: Re: [conex] Transport 101 X-BeenThere: conex@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Congestion Exposure working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 22 Jun 2010 14:04:20 -0000 Hi John, I found your answer very helpful in understanding the goals of conex. You got distracted by the sample numbers used in the last question, and I think you didn't answer the question. I think I know the answer, but let me restate the question with a different threshold to prompt your answer ... > > or can one imagine the case that e.g. a realtime streaming > service can > > tune its bitrate such that the ECN rate should stay below > for instance > > 0.4% where 0,4% ECN rate is in fact considered a healthy condition?. > dbh From john@jlc.net Tue Jun 22 07:26:53 2010 Return-Path: X-Original-To: conex@core3.amsl.com Delivered-To: conex@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 492103A69A6 for ; Tue, 22 Jun 2010 07:26:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.463 X-Spam-Level: X-Spam-Status: No, score=-2.463 tagged_above=-999 required=5 tests=[AWL=-0.764, BAYES_50=0.001, MANGLED_TOOL=2.3, 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 LXG1t2C4J6Ex for ; Tue, 22 Jun 2010 07:26:52 -0700 (PDT) Received: from mailhost.jlc.net (mailhost.jlc.net [199.201.159.9]) by core3.amsl.com (Postfix) with ESMTP id 244423A6825 for ; Tue, 22 Jun 2010 07:26:52 -0700 (PDT) Received: by mailhost.jlc.net (Postfix, from userid 104) id 25DEB33CA5; Tue, 22 Jun 2010 10:26:59 -0400 (EDT) Date: Tue, 22 Jun 2010 10:26:59 -0400 From: John Leslie To: David Harrington Message-ID: <20100622142659.GC5977@verdi> References: <548FC4B9D57A4043AAFFE888A39429031DA7831E7D@ESESSCMS0356.eemea.ericsson.se> <20100622131111.GB5977@verdi> <1A08A52AD45543F68B6D914A29CD74AF@23FX1C1> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <1A08A52AD45543F68B6D914A29CD74AF@23FX1C1> User-Agent: Mutt/1.4.1i Cc: conex@ietf.org Subject: Re: [conex] Transport 101 X-BeenThere: conex@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Congestion Exposure working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 22 Jun 2010 14:26:53 -0000 David Harrington wrote: > I found your answer very helpful in understanding the goals of conex. > > You got distracted by the sample numbers used in the last question, > and I think you didn't answer the question. I think I know the answer, > but let me restate the question with a different threshold to prompt > your answer ... > >>> or can one imagine the case that e.g. a realtime streaming service can >>> tune its bitrate such that the ECN rate should stay below for instance >>> 0.4% where 0,4% ECN rate is in fact considered a healthy condition?. That's still a little high for me, but if you'll permit me to revise it yet again, to 0.1%, I believe we consider it reasonable to tune the conex-CongestionExpected markings to 0.1% -- in today's Internet. Of course, that must somehow interact with whatever business model the ISP sets up... but I believe we envision allowance-based models where such a marking rate would be "reasonable." (When you quadruple that, the interaction becomes more critical, though I wouldn't _necessarily_ consider 0.4% unreasonable in all cases.) Getting back to didactic mode... The "transport" issue here is how to fill the pipe for a "normal" case. Neither ECN nor CONEX can get us all the way there, as currently envisioned. To the extent that a transport algorithm actually backs off 50% upon an ECN mark, you will need to work out the Bandwidth-Delay product to find an ECN-marking rate that permits filling the pipe. The conex-marking rate _can_ exceed that ECN-marking rate without preventing you from filling the pipe, but you probably don't want to exceed it by much, because conex-marking literally invites ECN-marking to catch up with it. -- John Leslie From rbriscoe@jungle.bt.co.uk Tue Jun 22 08:41:04 2010 Return-Path: X-Original-To: conex@core3.amsl.com Delivered-To: conex@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 268BC3A67F6 for ; Tue, 22 Jun 2010 08:41:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.633 X-Spam-Level: * X-Spam-Status: No, score=1.633 tagged_above=-999 required=5 tests=[AWL=-1.150, BAYES_50=0.001, DNS_FROM_RFC_BOGUSMX=1.482, MANGLED_TOOL=2.3, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Vwc3Swp2PE3S for ; Tue, 22 Jun 2010 08:40:57 -0700 (PDT) Received: from smtp1.smtp.bt.com (smtp1.smtp.bt.com [217.32.164.137]) by core3.amsl.com (Postfix) with ESMTP id CFEBE3A69AA for ; Tue, 22 Jun 2010 08:40:56 -0700 (PDT) Received: from i2kc06-ukbr.domain1.systemhost.net ([193.113.197.70]) by smtp1.smtp.bt.com with Microsoft SMTPSVC(6.0.3790.4675); Tue, 22 Jun 2010 16:41:03 +0100 Received: from cbibipnt05.iuser.iroot.adidom.com ([147.149.196.177]) by i2kc06-ukbr.domain1.systemhost.net with Microsoft SMTPSVC(6.0.3790.4675); Tue, 22 Jun 2010 16:41:02 +0100 Received: From bagheera.jungle.bt.co.uk ([132.146.168.158]) by cbibipnt05.iuser.iroot.adidom.com (WebShield SMTP v4.5 MR1a P0803.399); id 1277221261678; Tue, 22 Jun 2010 16:41:01 +0100 Received: from MUT.jungle.bt.co.uk ([10.215.130.87]) by bagheera.jungle.bt.co.uk (8.13.5/8.12.8) with ESMTP id o5MFewq4016653; Tue, 22 Jun 2010 16:40:58 +0100 Message-Id: <201006221540.o5MFewq4016653@bagheera.jungle.bt.co.uk> X-Mailer: QUALCOMM Windows Eudora Version 7.1.0.9 Date: Tue, 22 Jun 2010 16:40:02 +0100 To: David Harrington From: Bob Briscoe In-Reply-To: <20100622142659.GC5977@verdi> References: <548FC4B9D57A4043AAFFE888A39429031DA7831E7D@ESESSCMS0356.eemea.ericsson.se> <20100622131111.GB5977@verdi> <1A08A52AD45543F68B6D914A29CD74AF@23FX1C1> <20100622142659.GC5977@verdi> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-Scanned-By: MIMEDefang 2.56 on 132.146.168.158 X-OriginalArrivalTime: 22 Jun 2010 15:41:02.0582 (UTC) FILETIME=[51CD4960:01CB1221] Cc: conex@ietf.org Subject: Re: [conex] Transport 101 X-BeenThere: conex@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Congestion Exposure working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 22 Jun 2010 15:41:04 -0000 David, There's a simpler answer to Ingemar's question I think... Ingemar Johansson S wrote: > The idea with conex is that the ECN-CE markings should be re-inserted > into the IP header in the forward flow for future use by e.g policers. > This I believe will require that there is some kind of uniform behavior > in ECN marking algorithms or? Policing is only concerned with average/equilibrium congestion levels (whether 0.1% or 0.05% or 0.5%). An AQM algo has has little if any bearing on the equilibrium congestion level. So no uniform AQM behaviour is needed. Average/equilibrium congestion levels depend primarily on the algorithms in the end-systems that are driving load against the congestion. As long as at some point the AQM gives a large increase in drop/marking for a tiny increase in load (a hockeystick curve), the end-systems will find the equilibrium point where their combined pushing is no longer enough to push any higher up the hockeystick. If they want to push higher up the hockeystick, no amount of algorithm design in the queue can make the congestion level lower. As long as the queue gives you more drop or marking for a longer *queue*, congestion indications will be convex (ie hockeystick) with *load*. Any queue will do that, with or without active queue management (AQM). Nonetheless, an AQM does have to be designed carefully to maintain stability, responsiveness and randomness (ie no bias against certain packets). But its design can hardly affect the equilibrium at all. Bob At 15:26 22/06/2010, John Leslie wrote: >David Harrington wrote: > > I found your answer very helpful in understanding the goals of conex. > > > > You got distracted by the sample numbers used in the last question, > > and I think you didn't answer the question. I think I know the answer, > > but let me restate the question with a different threshold to prompt > > your answer ... > > > >>> or can one imagine the case that e.g. a realtime streaming service can > >>> tune its bitrate such that the ECN rate should stay below for instance > >>> 0.4% where 0,4% ECN rate is in fact considered a healthy condition?. > > That's still a little high for me, but if you'll permit me to revise >it yet again, to 0.1%, I believe we consider it reasonable to tune the >conex-CongestionExpected markings to 0.1% -- in today's Internet. > > Of course, that must somehow interact with whatever business model >the ISP sets up... but I believe we envision allowance-based models >where such a marking rate would be "reasonable." > > (When you quadruple that, the interaction becomes more critical, >though I wouldn't _necessarily_ consider 0.4% unreasonable in all cases.) > > Getting back to didactic mode... > > The "transport" issue here is how to fill the pipe for a "normal" >case. Neither ECN nor CONEX can get us all the way there, as currently >envisioned. To the extent that a transport algorithm actually backs off >50% upon an ECN mark, you will need to work out the Bandwidth-Delay >product to find an ECN-marking rate that permits filling the pipe. > > The conex-marking rate _can_ exceed that ECN-marking rate without >preventing you from filling the pipe, but you probably don't want to >exceed it by much, because conex-marking literally invites ECN-marking >to catch up with it. > >-- >John Leslie >_______________________________________________ >conex mailing list >conex@ietf.org >https://www.ietf.org/mailman/listinfo/conex ________________________________________________________________ Bob Briscoe, BT Innovate & Design From bauer@mit.edu Tue Jun 22 09:22:27 2010 Return-Path: X-Original-To: conex@core3.amsl.com Delivered-To: conex@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 921FF3A6836 for ; Tue, 22 Jun 2010 09:22:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.488 X-Spam-Level: X-Spam-Status: No, score=-4.488 tagged_above=-999 required=5 tests=[BAYES_05=-1.11, FM_FORGED_GMAIL=0.622, 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 S7j2mNH8pLr0 for ; Tue, 22 Jun 2010 09:22:26 -0700 (PDT) Received: from outgoing.csail.mit.edu (outgoing.csail.mit.edu [128.30.2.149]) by core3.amsl.com (Postfix) with ESMTP id B4B993A67AB for ; Tue, 22 Jun 2010 09:22:26 -0700 (PDT) Received: from mail-iw0-f172.google.com ([209.85.214.172]) by outgoing.csail.mit.edu with esmtpsa (TLSv1:RC4-MD5:128) (Exim 4.69) (envelope-from ) id 1OR6F7-0006PU-A9 for conex@ietf.org; Tue, 22 Jun 2010 12:22:33 -0400 Received: by iwn9 with SMTP id 9so1832541iwn.31 for ; Tue, 22 Jun 2010 09:22:30 -0700 (PDT) Received: by 10.42.5.134 with SMTP id 6mr2424967icw.2.1277223750308; Tue, 22 Jun 2010 09:22:30 -0700 (PDT) MIME-Version: 1.0 Received: by 10.231.207.13 with HTTP; Tue, 22 Jun 2010 09:22:00 -0700 (PDT) In-Reply-To: <20100622142659.GC5977@verdi> References: <548FC4B9D57A4043AAFFE888A39429031DA7831E7D@ESESSCMS0356.eemea.ericsson.se> <20100622131111.GB5977@verdi> <1A08A52AD45543F68B6D914A29CD74AF@23FX1C1> <20100622142659.GC5977@verdi> From: Steve Bauer Date: Tue, 22 Jun 2010 12:22:00 -0400 Message-ID: To: John Leslie Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: conex@ietf.org Subject: Re: [conex] Transport 101 X-BeenThere: conex@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Congestion Exposure working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 22 Jun 2010 16:22:27 -0000 On Tue, Jun 22, 2010 at 10:26 AM, John Leslie wrote: > =A0 The conex-marking rate _can_ exceed that ECN-marking rate without > preventing you from filling the pipe, but you probably don't want to > exceed it by much, because conex-marking literally invites ECN-marking > to catch up with it. Perhaps I am missing your point here... in what sense would conex-marking at a rate higher than the actual ECN-marking rate create this incentive? How could any one provider along the path (except the last hop provider) recognize such a scenario as the conex-marking rate will always naturally exceed the ECN-marking before the congestion point. Thanks, Steve From ingemar.s.johansson@ericsson.com Tue Jun 22 12:58:07 2010 Return-Path: X-Original-To: conex@core3.amsl.com Delivered-To: conex@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 506723A6898 for ; Tue, 22 Jun 2010 12:58:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.181 X-Spam-Level: X-Spam-Status: No, score=-2.181 tagged_above=-999 required=5 tests=[AWL=-1.882, BAYES_00=-2.599, MANGLED_TOOL=2.3] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id t2ehJFKETPQw for ; Tue, 22 Jun 2010 12:58:06 -0700 (PDT) Received: from mailgw9.se.ericsson.net (mailgw9.se.ericsson.net [193.180.251.57]) by core3.amsl.com (Postfix) with ESMTP id C31773A67B3 for ; Tue, 22 Jun 2010 12:58:05 -0700 (PDT) X-AuditID: c1b4fb39-b7b48ae0000006a6-09-4c2115d4a0e7 Received: from esessmw0247.eemea.ericsson.se (Unknown_Domain [153.88.253.125]) by mailgw9.se.ericsson.net (Symantec Mail Security) with SMTP id AF.12.01702.4D5112C4; Tue, 22 Jun 2010 21:58:12 +0200 (CEST) Received: from ESESSCMS0356.eemea.ericsson.se ([169.254.2.128]) by esessmw0247.eemea.ericsson.se ([10.2.3.116]) with mapi; Tue, 22 Jun 2010 21:58:12 +0200 From: Ingemar Johansson S To: Bob Briscoe , David Harrington , "john@jlc.net" Date: Tue, 22 Jun 2010 21:58:10 +0200 Thread-Topic: [conex] Transport 101 Thread-Index: AcsSJyPnFRngJtjoTVuWBJthEm9WDgAG879Q Message-ID: <548FC4B9D57A4043AAFFE888A39429031DA783216C@ESESSCMS0356.eemea.ericsson.se> References: <548FC4B9D57A4043AAFFE888A39429031DA7831E7D@ESESSCMS0356.eemea.ericsson.se> <20100622131111.GB5977@verdi> <1A08A52AD45543F68B6D914A29CD74AF@23FX1C1> <20100622142659.GC5977@verdi> <201006221540.o5MFewq4016653@bagheera.jungle.bt.co.uk> In-Reply-To: <201006221540.o5MFewq4016653@bagheera.jungle.bt.co.uk> Accept-Language: sv-SE, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: sv-SE, en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Brightmail-Tracker: AAAAAA== Cc: Ingemar Johansson S , "conex@ietf.org" Subject: Re: [conex] Transport 101 X-BeenThere: conex@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Congestion Exposure working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 22 Jun 2010 19:58:07 -0000 Hi Thanks all for taking the time to answer my question. My interpretation of = this is that for general internet 0.1 to 0.5% are reasonable figures.=20 On the other hand one can perhaps for some dedicated QoS traffic envision a= higher "equilibrium rate" ?. If one take that video streaming case again o= ne can think of a rate control that acts according to a function of the ECN= rate [ bitrate=3Df(ECN_rate) ] or something similar. My take is that it sh= ould be easier to get a smoothly varying bitrate depending on the congetsio= n situation if the concestion events occur at a higher frequency. With a 0.= 1% equilibrium point the video streaming service will likely have to resort= to TCP like behavior (rate halving) in its response to the ECN marks.=20 /Ingemar =20 > -----Original Message----- > From: Bob Briscoe [mailto:rbriscoe@jungle.bt.co.uk]=20 > Sent: den 22 juni 2010 17:40 > To: David Harrington > Cc: conex@ietf.org > Subject: Re: [conex] Transport 101 >=20 > David, >=20 > There's a simpler answer to Ingemar's question I think... >=20 > Ingemar Johansson S wrote: > > The idea with conex is that the ECN-CE markings should be=20 > re-inserted > into the IP header in the forward flow for=20 > future use by e.g policers. > > This I believe will require that there is some kind of=20 > uniform behavior > in ECN marking algorithms or? >=20 > Policing is only concerned with average/equilibrium=20 > congestion levels (whether 0.1% or 0.05% or 0.5%). An AQM=20 > algo has has little if any bearing on the equilibrium=20 > congestion level. So no uniform AQM behaviour is needed. >=20 > Average/equilibrium congestion levels depend primarily on the=20 > algorithms in the end-systems that are driving load against=20 > the congestion. As long as at some point the AQM gives a=20 > large increase in drop/marking for a tiny increase in load (a=20 > hockeystick curve), the end-systems will find the equilibrium=20 > point where their combined pushing is no longer enough to=20 > push any higher up the hockeystick. If they want to push=20 > higher up the hockeystick, no amount of algorithm design in=20 > the queue can make the congestion level lower. >=20 > As long as the queue gives you more drop or marking for a=20 > longer *queue*, congestion indications will be convex (ie=20 > hockeystick) with *load*. Any queue will do that, with or=20 > without active queue management (AQM). >=20 > Nonetheless, an AQM does have to be designed carefully to=20 > maintain stability, responsiveness and randomness (ie no bias=20 > against certain packets). But its design can hardly affect=20 > the equilibrium at all. >=20 >=20 > Bob >=20 > At 15:26 22/06/2010, John Leslie wrote: > >David Harrington wrote: > > > I found your answer very helpful in understanding the=20 > goals of conex. > > > > > > You got distracted by the sample numbers used in the last=20 > question,=20 > > > and I think you didn't answer the question. I think I know the=20 > > > answer, but let me restate the question with a different=20 > threshold=20 > > > to prompt your answer ... > > > > > >>> or can one imagine the case that e.g. a realtime=20 > streaming service=20 > > >>> can tune its bitrate such that the ECN rate should stay=20 > below for=20 > > >>> instance 0.4% where 0,4% ECN rate is in fact considered=20 > a healthy condition?. > > > > That's still a little high for me, but if you'll permit me to=20 > >revise it yet again, to 0.1%, I believe we consider it reasonable to=20 > >tune the conex-CongestionExpected markings to 0.1% -- in=20 > today's Internet. > > > > Of course, that must somehow interact with whatever=20 > business model=20 > >the ISP sets up... but I believe we envision allowance-based models=20 > >where such a marking rate would be "reasonable." > > > > (When you quadruple that, the interaction becomes more critical,=20 > >though I wouldn't _necessarily_ consider 0.4% unreasonable in all=20 > >cases.) > > > > Getting back to didactic mode... > > > > The "transport" issue here is how to fill the pipe for a "normal" > >case. Neither ECN nor CONEX can get us all the way there, as=20 > currently=20 > >envisioned. To the extent that a transport algorithm=20 > actually backs off=20 > >50% upon an ECN mark, you will need to work out the Bandwidth-Delay=20 > >product to find an ECN-marking rate that permits filling the pipe. > > > > The conex-marking rate _can_ exceed that ECN-marking=20 > rate without=20 > >preventing you from filling the pipe, but you probably don't want to=20 > >exceed it by much, because conex-marking literally invites=20 > ECN-marking=20 > >to catch up with it. > > > >-- > >John Leslie > >_______________________________________________ > >conex mailing list > >conex@ietf.org > >https://www.ietf.org/mailman/listinfo/conex >=20 > ________________________________________________________________ > Bob Briscoe, BT Innovate & Design=20 >=20 >=20 > = From rbriscoe@jungle.bt.co.uk Wed Jun 23 05:49:58 2010 Return-Path: X-Original-To: conex@core3.amsl.com Delivered-To: conex@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 21D563A659C for ; Wed, 23 Jun 2010 05:49:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.866 X-Spam-Level: X-Spam-Status: No, score=0.866 tagged_above=-999 required=5 tests=[AWL=0.383, BAYES_50=0.001, DNS_FROM_RFC_BOGUSMX=1.482, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id d6eKC1xGunvZ for ; Wed, 23 Jun 2010 05:49:50 -0700 (PDT) Received: from smtp3.smtp.bt.com (smtp3.smtp.bt.com [217.32.164.138]) by core3.amsl.com (Postfix) with ESMTP id 3F1843A681F for ; Wed, 23 Jun 2010 05:49:49 -0700 (PDT) Received: from i2kc06-ukbr.domain1.systemhost.net ([193.113.197.70]) by smtp3.smtp.bt.com with Microsoft SMTPSVC(6.0.3790.4675); Wed, 23 Jun 2010 13:49:56 +0100 Received: from cbibipnt05.iuser.iroot.adidom.com ([147.149.196.177]) by i2kc06-ukbr.domain1.systemhost.net with Microsoft SMTPSVC(6.0.3790.4675); Wed, 23 Jun 2010 13:49:56 +0100 Received: From bagheera.jungle.bt.co.uk ([132.146.168.158]) by cbibipnt05.iuser.iroot.adidom.com (WebShield SMTP v4.5 MR1a P0803.399); id 1277297395723; Wed, 23 Jun 2010 13:49:55 +0100 Received: from MUT.jungle.bt.co.uk ([10.215.130.87]) by bagheera.jungle.bt.co.uk (8.13.5/8.12.8) with ESMTP id o5NCnrmi027041; Wed, 23 Jun 2010 13:49:53 +0100 Message-Id: <201006231249.o5NCnrmi027041@bagheera.jungle.bt.co.uk> X-Mailer: QUALCOMM Windows Eudora Version 7.1.0.9 Date: Wed, 23 Jun 2010 13:49:57 +0100 To: Matt Mathis From: Bob Briscoe In-Reply-To: References: <201003290707.o2T777cP032534@bagheera.jungle.bt.co.uk> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-Scanned-By: MIMEDefang 2.56 on 132.146.168.158 X-OriginalArrivalTime: 23 Jun 2010 12:49:56.0703 (UTC) FILETIME=[954636F0:01CB12D2] Cc: conex@ietf.org Subject: Re: [conex] Abstract specification of ConEx X-BeenThere: conex@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Congestion Exposure working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 23 Jun 2010 12:49:58 -0000 Matt, I just found I never replied to this one (originally on the re-ECN list back in March!!!)... I agree - you're right, I was wrong. Bob At 04:55 31/03/2010, Matt Mathis wrote: >I don't think your encoding works for hybrid encoding for both loss >based and ECN based RE-Feedback. The problem is that if a flow is >getting both losses and ECN marks (different bottlenecks) you need to >used different techniques to enforce each. ECN cheating can be >detected by counting the red, black and green marks near to the >receiver, as mentioned before. Loss cheating requires reconstructing >the TCP state from the sequence numbers, which is hard a high rate and >most robust when you are close to the sender. > >Furthermore these are orthogonal signals in the transport ACKs: a >single TCP ACK might carry both SACK blocks indicating losses and ECT >marks. Choosing four code points rather than three independent bits >obscures a lot of information and the concurrency in other parts of >the system. > >In order to make sure that the abstract model isn't coloring our >thinking, we really want to preserve all of this information in the >model even though we think it is clear which credit marks we want to >conflate. That means the abstract model will not be the same as the >IPv6 encoding.... > >Thanks, >--MM-- > > >On Mon, Mar 29, 2010 at 3:06 AM, Bob Briscoe wrote: > > Matt, > > > > At 01:39 29/03/2010, Matt Mathis wrote: > >> > >> If it supports > >> ConEx, the sender needs to be able to send three different "credit" > >> markings: > >> BLACK_ECN - in exact agreement with the number of ECN marks seen at > >> the receiver (but implicitly delayed by one RTT). > >> BLACK_Loss - In exact agreement with the number of losses signaled. > >> For reliable protocols should be in exact agreement with > >> retransmissions. > >> GREEN - Pre-credits to used to assure that even though the BLACK marks > >> are delayed by one RTT count(RED) > > > For an unconstrained abstract encoding, I see this differently (as I tried > > to describe in my earlier posting on this subject): > > > > The ECN field already shows whether it supports drop (Not-ECT) or ECN (the > > other three codepoints). So, if an orthoginal re-feedback field > supports the > > following four codepoints: > > - re-feedback not supported > > - re-feedback unmarked > > - re-feedback marked > > - re-feedback pre-credit > > > > Then, combined with Not-ECT in the ECN field, these can re-echo losses. > > Or, combined with the other ECN codepoints, they can be used to > re-echo ECN. > > > > > >> Depending on the deployment scenario and other coding constraints the > >> sender marking might be three separate ternary values (unsupported, > >> not marked or marked) or one supported indication plus 3 binary > >> values. Note that as a practical matter it might be reasonable to > >> assume one 5 valued signal, but this representation can not model > >> situations where transport might carry both loss and ECN information > >> on the same ACK. > >> > >> The point of the abstract specification is to permit us to list some > >> of the algorithms that ConEx might support, such that when it comes > >> time to choose a particular encoding, it is easy to understand what > >> features we might forfeit when using it. > >> > >> For example, if a flow is observed to violate > >> count(RED) >> cheating. If I have to encode all of the sender marks into 2 bits (4 > >> code points) then would be better not to conflate BLACK_Loss with > >> either BLACK_ECN or GREEN, because doing so will either weaken or > >> break the cheating test. It looks as though it might be ok to use a > >> single code point for GREEN and BLACK_ECN marks. > >> > >> My notation is not particularly good. Perhaps somebody can suggest > >> something better.... > > > > I tried in my first posting of this thread. > > Did you see it and think it was not useful? Or did you miss it? > > > > > > > > Bob > > > > > >> Thanks, > >> --MM-- > >> ------------------------------------------- > >> Matt Mathis http://staff.psc.edu/mathis > >> Work:412.268.3319 Home/Cell:412.654.7529 > >> ------------------------------------------- > >> Evil is defined by mortals who think they know > >> "The Truth" and use force to apply it to others. > > > > ________________________________________________________________ > > Bob Briscoe, BT Innovate & Design > > ________________________________________________________________ Bob Briscoe, BT Innovate & Design From john@jlc.net Wed Jun 23 06:40:39 2010 Return-Path: X-Original-To: conex@core3.amsl.com Delivered-To: conex@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 5182B3A6A7D for ; Wed, 23 Jun 2010 06:40:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.461 X-Spam-Level: X-Spam-Status: No, score=-4.461 tagged_above=-999 required=5 tests=[AWL=1.538, BAYES_50=0.001, GB_I_INVITATION=-2, 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 gmnuctoVbs5X for ; Wed, 23 Jun 2010 06:40:27 -0700 (PDT) Received: from mailhost.jlc.net (mailhost.jlc.net [199.201.159.9]) by core3.amsl.com (Postfix) with ESMTP id F33D13A6957 for ; Wed, 23 Jun 2010 06:40:22 -0700 (PDT) Received: by mailhost.jlc.net (Postfix, from userid 104) id 40DD033C89; Wed, 23 Jun 2010 09:40:29 -0400 (EDT) Date: Wed, 23 Jun 2010 09:40:29 -0400 From: John Leslie To: Steve Bauer Message-ID: <20100623134029.GF5977@verdi> References: <548FC4B9D57A4043AAFFE888A39429031DA7831E7D@ESESSCMS0356.eemea.ericsson.se> <20100622131111.GB5977@verdi> <1A08A52AD45543F68B6D914A29CD74AF@23FX1C1> <20100622142659.GC5977@verdi> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.4.1i Cc: conex@ietf.org Subject: Re: [conex] Transport 101 X-BeenThere: conex@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Congestion Exposure working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 23 Jun 2010 13:40:40 -0000 Steve Bauer wrote: > On Tue, Jun 22, 2010 at 10:26 AM, John Leslie wrote: > >> The conex-marking rate _can_ exceed that ECN-marking rate without >> preventing you from filling the pipe, but you probably don't want to >> exceed it by much, because conex-marking literally invites ECN-marking >> to catch up with it. > > Perhaps I am missing your point here... in what sense would > conex-marking at a rate higher than the actual ECN-marking rate create > this incentive? I apologize if I gave the impression that a higher-than necessary CONEX marking rate (Congestion Expected) will cause the ECN marking rate (Congestion Experienced) to rise to meet it. That is not what I intended to say. :^( CONEX marking (Congestion Expected) _does_ invite ECN marking (Congestion Experienced) in that the CONEX mark does say, "Please mark Congestion-Experienced and forward if the alternative seems to be dropping a packet," but I wouldn't expect that invitation to be accepted as much as 1% of the time. > How could any one provider along the path (except the last hop > provider) recognize such a scenario as the conex-marking rate will > always naturally exceed the ECN-marking before the congestion point. Steve is right. My wording was poor. My bad. BTW, Bob Briscoe gave a much better explanation of why higher-than- needed CONEX-marking doesn't pay. -- John Leslie From john@jlc.net Wed Jun 23 07:09:21 2010 Return-Path: X-Original-To: conex@core3.amsl.com Delivered-To: conex@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 6CCA33A69DB for ; Wed, 23 Jun 2010 07:09:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.717 X-Spam-Level: X-Spam-Status: No, score=-3.717 tagged_above=-999 required=5 tests=[AWL=0.282, BAYES_50=0.001, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id HwWTc+sWYIfh for ; Wed, 23 Jun 2010 07:09:20 -0700 (PDT) Received: from mailhost.jlc.net (mailhost.jlc.net [199.201.159.9]) by core3.amsl.com (Postfix) with ESMTP id 4180B3A67FB for ; Wed, 23 Jun 2010 07:09:20 -0700 (PDT) Received: by mailhost.jlc.net (Postfix, from userid 104) id 53AAA33CC6; Wed, 23 Jun 2010 10:09:28 -0400 (EDT) Date: Wed, 23 Jun 2010 10:09:28 -0400 From: John Leslie To: Ingemar Johansson S Message-ID: <20100623140928.GG5977@verdi> References: <548FC4B9D57A4043AAFFE888A39429031DA7831E7D@ESESSCMS0356.eemea.ericsson.se> <20100622131111.GB5977@verdi> <1A08A52AD45543F68B6D914A29CD74AF@23FX1C1> <20100622142659.GC5977@verdi> <201006221540.o5MFewq4016653@bagheera.jungle.bt.co.uk> <548FC4B9D57A4043AAFFE888A39429031DA783216C@ESESSCMS0356.eemea.ericsson.se> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <548FC4B9D57A4043AAFFE888A39429031DA783216C@ESESSCMS0356.eemea.ericsson.se> User-Agent: Mutt/1.4.1i Cc: conex@ietf.org Subject: [conex] Off-Topic: Smoothing Variations in BitRate X-BeenThere: conex@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Congestion Exposure working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 23 Jun 2010 14:09:21 -0000 Ingemar Johansson S wrote: > > Thanks all for taking the time to answer my question. My interpretation > of this is that for general internet 0.1 to 0.5% are reasonable figures. I won't disagree (though I still think 0.5% is high). > On the other hand one can perhaps for some dedicated QoS traffic > envision a higher "equilibrium rate" ?. If one takes that video > streaming case again one can think of a rate control that acts > according to a function of the ECN rate [ bitrate=f(ECN_rate) ] or > something similar. This (IMHO) is clearly outside our charter; but traffic is low enough at the moment that I think we can elaborate a bit before deciding where this discussion belongs. > My take is that it should be easier to get a smoothly varying bitrate > depending on the congestion situation if the congestion events occur > at a higher frequency. Fundamentally, to get smoother variation, the reduction signaled by an individual ECN-CE mark would need to be less than 50%. This, IMHO, would indeed be reasonable if we agreed somehow to create more of them. (Unfortunately, setting more CONEX-CE marks isn't likely to cause this, despite my poorly-worded earlier posting.) > With a 0.1% equilibrium point the video streaming service will likely > have to resort to TCP like behavior (rate halving) in its response > to the ECN marks. Unfortunately, the basic ECN expectation in RFC 3168 is that an ECN-CE mark will cause rate halving. I'm sure Bob Briscoe can answer better than I as to how this rate- halving could be relaxed: I see several possibilities, but they seem to require changes in RFC 3168, and that goes way beyond our charter. Nonetheless, our charter calling for implementation in IPv6, it seems quite reasonable that IPv6 ECN-marking might not need to be limited to the two bits or might be extended somehow to better accomodate gentler variations in bit-rate. -- John Leslie From toby@moncaster.com Wed Jun 23 08:41:15 2010 Return-Path: X-Original-To: conex@core3.amsl.com Delivered-To: conex@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 648413A6982 for ; Wed, 23 Jun 2010 08:41:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.877 X-Spam-Level: X-Spam-Status: No, score=0.877 tagged_above=-999 required=5 tests=[AWL=0.526, BAYES_50=0.001, HELO_EQ_DE=0.35] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id RGEo81revhuX for ; Wed, 23 Jun 2010 08:41:14 -0700 (PDT) Received: from moutng.kundenserver.de (moutng.kundenserver.de [212.227.17.9]) by core3.amsl.com (Postfix) with ESMTP id 90B123A681D for ; Wed, 23 Jun 2010 08:41:13 -0700 (PDT) Received: from TobysHP (host86-170-50-165.range86-170.btcentralplus.com [86.170.50.165]) by mrelayeu.kundenserver.de (node=mreu1) with ESMTP (Nemesis) id 0MaoHu-1Okl6r0Jb8-00K46u; Wed, 23 Jun 2010 17:41:19 +0200 From: "Toby Moncaster" To: "'John Leslie'" , "'Ingemar Johansson S'" References: <548FC4B9D57A4043AAFFE888A39429031DA7831E7D@ESESSCMS0356.eemea.ericsson.se> <20100622131111.GB5977@verdi> <1A08A52AD45543F68B6D914A29CD74AF@23FX1C1> <20100622142659.GC5977@verdi> <201006221540.o5MFewq4016653@bagheera.jungle.bt.co.uk> <548FC4B9D57A4043AAFFE888A39429031DA783216C@ESESSCMS0356.eemea.ericsson.se> <20100623140928.GG5977@verdi> In-Reply-To: <20100623140928.GG5977@verdi> Date: Wed, 23 Jun 2010 16:41:19 +0100 Message-ID: <000f01cb12ea$868c25d0$93a47170$@com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 12.0 Thread-Index: AcsS3bOSieKGvqW4S5eSTycBEQLUBwACyJ4g Content-Language: en-gb X-Provags-ID: V01U2FsdGVkX1/PqDB9fgWQafcpH2Xi3BAXWCABGIJ346JYVe3 o0UH8q4mThplfMn8MkFH6eyjFEgQUg1gLbKCNMGRUc57l8h9Z7 va0HTLlVY/LNwKwCSeHoh9fHwUvBTHw Cc: conex@ietf.org Subject: Re: [conex] Off-Topic: Smoothing Variations in BitRate X-BeenThere: conex@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Congestion Exposure working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 23 Jun 2010 15:41:15 -0000 > -----Original Message----- > From: conex-bounces@ietf.org [mailto:conex-bounces@ietf.org] On Behalf > Of John Leslie > Sent: 23 June 2010 15:09 > To: Ingemar Johansson S > Cc: conex@ietf.org > Subject: [conex] Off-Topic: Smoothing Variations in BitRate > > Ingemar Johansson S wrote: > > > > Thanks all for taking the time to answer my question. My > interpretation > > of this is that for general internet 0.1 to 0.5% are reasonable > figures. > > I won't disagree (though I still think 0.5% is high). I think for this discussion we need to clarify exactly what our network model is. As I see it there are 3 main models: mobile broadband which I choose to believe is out of charter, DSL or cable In DSL the traffic is heavily aggregated at the DSLAM and then several DSLAMs will dump their traffic onto IP at a B-RAS. I can easily believe congestion at the B-RAS exceeds 0.5% at certain times, at least occasionally. In Cable things may be different, I am not really qualified to comment on it... > > > On the other hand one can perhaps for some dedicated QoS traffic > > envision a higher "equilibrium rate" ?. If one takes that video > > streaming case again one can think of a rate control that acts > > according to a function of the ECN rate [ bitrate=f(ECN_rate) ] or > > something similar. > > This (IMHO) is clearly outside our charter; but traffic is low > enough > at the moment that I think we can elaborate a bit before deciding where > this discussion belongs. I agree - out of charter, but no harm in discussing it here > > > My take is that it should be easier to get a smoothly varying bitrate > > depending on the congestion situation if the congestion events occur > > at a higher frequency. > > Fundamentally, to get smoother variation, the reduction signaled by > an individual ECN-CE mark would need to be less than 50%. This, IMHO, > would indeed be reasonable if we agreed somehow to create more of them. > (Unfortunately, setting more CONEX-CE marks isn't likely to cause this, > despite my poorly-worded earlier posting.) I think Ingemar would be well advised to talk to Matt Mathis and Bob Briscoe here... I think this is related to the question of whether the congestion controller responds to p or sqrt(p) (where p is the congestion on the path) > > > With a 0.1% equilibrium point the video streaming service will likely > > have to resort to TCP like behavior (rate halving) in its response > > to the ECN marks. > > Unfortunately, the basic ECN expectation in RFC 3168 is that an > ECN-CE mark will cause rate halving. Quoting it: " Upon the receipt by an ECN-Capable transport of a single CE packet, the congestion control algorithms followed at the end-systems MUST be essentially the same as the congestion control response to a *single* dropped packet." > > I'm sure Bob Briscoe can answer better than I as to how this rate- > halving could be relaxed: I see several possibilities, but they seem > to require changes in RFC 3168, and that goes way beyond our charter. > This is an issue of transport vs network layers. ECN is at the network layer (as is conex). The appropriate response at the transport layer depends on that transport. If you are a real-time inelastic transport, clearly the response is different than if you were a scavenging transport or an elastic bulk data transport... Conex is essentially transport-agnostic and I thought the idea is to try and get the whole network to move on from its inherent assumption that everything uses TCP. As long as the network can see how much congestion a flow is causing then that flow can respond as it wants. If it is causing too much congestion then it runs the risk of being policed in some manner... > Nonetheless, our charter calling for implementation in IPv6, it > seems quite reasonable that IPv6 ECN-marking might not need to be > limited to the two bits or might be extended somehow to better > accomodate gentler variations in bit-rate. Indeed it would be silly to limit it to 2 bits if there is space for more without increasing the overhead. This is potentially a very rich vein for discussions in its own right, independent of this current discussion Toby > > -- > John Leslie > _______________________________________________ > conex mailing list > conex@ietf.org > https://www.ietf.org/mailman/listinfo/conex From toby@moncaster.com Wed Jun 23 08:56:28 2010 Return-Path: X-Original-To: conex@core3.amsl.com Delivered-To: conex@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 344A43A6AA5 for ; Wed, 23 Jun 2010 08:56:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.254 X-Spam-Level: X-Spam-Status: No, score=-0.254 tagged_above=-999 required=5 tests=[AWL=1.395, BAYES_50=0.001, GB_I_INVITATION=-2, HELO_EQ_DE=0.35] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 4yBfbHcInVk8 for ; Wed, 23 Jun 2010 08:56:27 -0700 (PDT) Received: from moutng.kundenserver.de (moutng.kundenserver.de [212.227.17.8]) by core3.amsl.com (Postfix) with ESMTP id E9F853A6AA0 for ; Wed, 23 Jun 2010 08:56:26 -0700 (PDT) Received: from TobysHP (host86-170-50-165.range86-170.btcentralplus.com [86.170.50.165]) by mrelayeu.kundenserver.de (node=mreu2) with ESMTP (Nemesis) id 0Ls5Ln-1PCdRf45GR-013Eev; Wed, 23 Jun 2010 17:56:33 +0200 From: "Toby Moncaster" To: "'John Leslie'" , "'Steve Bauer'" References: <548FC4B9D57A4043AAFFE888A39429031DA7831E7D@ESESSCMS0356.eemea.ericsson.se> <20100622131111.GB5977@verdi> <1A08A52AD45543F68B6D914A29CD74AF@23FX1C1> <20100622142659.GC5977@verdi> <20100623134029.GF5977@verdi> In-Reply-To: <20100623134029.GF5977@verdi> Date: Wed, 23 Jun 2010 16:56:33 +0100 Message-ID: <001101cb12ec$a763aba0$f62b02e0$@com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 12.0 Thread-Index: AcsS2bQp8/YoAl5RTIettcHz8XEF3QAEU7fQ Content-Language: en-gb X-Provags-ID: V01U2FsdGVkX1/2eNjn43w4FBT/4JbxE23bC69iYJ8p2xyASyH P+PgSqLb0FHmrMEpGHak/91NNkHaee5qd6IhPXxjZYWMykanF6 00EdyBZlS6JYPgc3zjgH/jhf8aFWrCi Cc: conex@ietf.org Subject: Re: [conex] Transport 101 X-BeenThere: conex@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Congestion Exposure working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 23 Jun 2010 15:56:28 -0000 OK, not sure if this is going to help at all, but let's give it a try! Everyone in this discussion is assuming some variant of conex that looks more than a little like Bob's re-ECN. When you mark conex markings (let's call them congestion expected to mirror congestion experienced), you are telling the network how bad you think downstream congestion is currently. If you are starting a flow (or changing rate rapidly for some other purpose) then you are not sure how bad congestion is because your own flow is likely to have a measurable impact on it. Consequently a sensible sender will slightly inflate the congestion expected signal to allow for this possibility. I think John was suggesting that such behaviour may result in the ECN marking rate appearing fractionally lower than the congestion-expected rate. Implicitly conex marking implies ECN capability and that automatically encourages a router to mark if it is ECN capable. This is an orthogonal issue (as are all the related issues Bob and Matt were discussing in their email exchange relating to conex on drop as distinct from conex on ECN mark) If a sender consistently indicates too high a rate for congestion expected then this does have consequences for how congestion can be tracked in the network. In particular it can make a network in the middle look as though it is being asked to forward more congestion-causing traffic than it actually is. > -----Original Message----- > From: conex-bounces@ietf.org [mailto:conex-bounces@ietf.org] On Behalf > Of John Leslie > Sent: 23 June 2010 14:40 > To: Steve Bauer > Cc: conex@ietf.org > Subject: Re: [conex] Transport 101 > > Steve Bauer wrote: > > On Tue, Jun 22, 2010 at 10:26 AM, John Leslie wrote: > > > >> The conex-marking rate _can_ exceed that ECN-marking rate without > >> preventing you from filling the pipe, but you probably don't want to > >> exceed it by much, because conex-marking literally invites ECN- > marking > >> to catch up with it. > > > > Perhaps I am missing your point here... in what sense would > > conex-marking at a rate higher than the actual ECN-marking rate > create > > this incentive? > > I apologize if I gave the impression that a higher-than necessary > CONEX marking rate (Congestion Expected) will cause the ECN marking > rate (Congestion Experienced) to rise to meet it. That is not what I > intended to say. :^( > > CONEX marking (Congestion Expected) _does_ invite ECN marking > (Congestion Experienced) in that the CONEX mark does say, "Please mark > Congestion-Experienced and forward if the alternative seems to be > dropping a packet," but I wouldn't expect that invitation to be > accepted as much as 1% of the time. > > > How could any one provider along the path (except the last hop > > provider) recognize such a scenario as the conex-marking rate will > > always naturally exceed the ECN-marking before the congestion point. > > Steve is right. My wording was poor. My bad. > > BTW, Bob Briscoe gave a much better explanation of why higher-than- > needed CONEX-marking doesn't pay. > > -- > John Leslie > _______________________________________________ > conex mailing list > conex@ietf.org > https://www.ietf.org/mailman/listinfo/conex From rbriscoe@jungle.bt.co.uk Wed Jun 23 09:12:46 2010 Return-Path: X-Original-To: conex@core3.amsl.com Delivered-To: conex@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 36C7728C13E for ; Wed, 23 Jun 2010 09:12:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.827 X-Spam-Level: * X-Spam-Status: No, score=1.827 tagged_above=-999 required=5 tests=[AWL=-0.769, BAYES_40=-0.185, DNS_FROM_RFC_BOGUSMX=1.482, MANGLED_TOOL=2.3, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id gTH2adLOHdyi for ; Wed, 23 Jun 2010 09:12:38 -0700 (PDT) Received: from smtp3.smtp.bt.com (smtp3.smtp.bt.com [217.32.164.138]) by core3.amsl.com (Postfix) with ESMTP id B53D53A6831 for ; Wed, 23 Jun 2010 09:12:37 -0700 (PDT) Received: from i2kc06-ukbr.domain1.systemhost.net ([193.113.197.70]) by smtp3.smtp.bt.com with Microsoft SMTPSVC(6.0.3790.4675); Wed, 23 Jun 2010 17:12:44 +0100 Received: from cbibipnt05.iuser.iroot.adidom.com ([147.149.196.177]) by i2kc06-ukbr.domain1.systemhost.net with Microsoft SMTPSVC(6.0.3790.4675); Wed, 23 Jun 2010 17:12:44 +0100 Received: From bagheera.jungle.bt.co.uk ([132.146.168.158]) by cbibipnt05.iuser.iroot.adidom.com (WebShield SMTP v4.5 MR1a P0803.399); id 1277309562318; Wed, 23 Jun 2010 17:12:42 +0100 Received: from MUT.jungle.bt.co.uk ([10.215.130.87]) by bagheera.jungle.bt.co.uk (8.13.5/8.12.8) with ESMTP id o5NGCfjN031783; Wed, 23 Jun 2010 17:12:41 +0100 Message-Id: <201006231612.o5NGCfjN031783@bagheera.jungle.bt.co.uk> X-Mailer: QUALCOMM Windows Eudora Version 7.1.0.9 Date: Wed, 23 Jun 2010 17:12:24 +0100 To: Ingemar Johansson S From: Bob Briscoe In-Reply-To: <548FC4B9D57A4043AAFFE888A39429031DA783216C@ESESSCMS0356.ee mea.ericsson.se> References: <548FC4B9D57A4043AAFFE888A39429031DA7831E7D@ESESSCMS0356.eemea.ericsson.se> <20100622131111.GB5977@verdi> <1A08A52AD45543F68B6D914A29CD74AF@23FX1C1> <20100622142659.GC5977@verdi> <201006221540.o5MFewq4016653@bagheera.jungle.bt.co.uk> <548FC4B9D57A4043AAFFE888A39429031DA783216C@ESESSCMS0356.eemea.ericsson.se> 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: 23 Jun 2010 16:12:44.0702 (UTC) FILETIME=[E9F783E0:01CB12EE] Cc: Ingemar Johansson S , "conex@ietf.org" Subject: Re: [conex] Transport 101 X-BeenThere: conex@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Congestion Exposure working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 23 Jun 2010 16:12:46 -0000 Ingemar, The 'normal' congestion level depends on how the end-system congestion control algos scale with bit-rate. See Matt Mathis and my joint presentation to ICCRG co-located with last IETF in Anaheim: Slide 5: For example, if most endpoints are TCP Reno in Congestion Avoidance phase, and as the average window increases over the years (assuming capacity increases), the loss fraction will reduce over the years O(1/w^2), where w is the average window. BTW, the loss *rate* [loss per time] as opposed to loss fraction [% loss per packet] will decrease O(1/w). Example: 1Mb/s => 8.3pkt window => 2% loss fraction => 1.67 loss/sec 10Mb/s => 83pkt window => 0.02% loss fraction => 0.167 loss/sec 100Mb/s => 830pkt window => 0.0002% loss fraction => 0.0167 loss/sec BUT!!!... Slide 6: If the rate of flow arrivals stays constant, but bit-rates increase as in the example above, slow start (SS) will increasingly dominate over congestion avoidance (CA) as the source of congestion. Example: if on average you get 0.1 flow/sec arriving at the bottleneck (say), then slow start overshoot will cause 0.1 loss events per sec. Comparing this SS loss frequency with the CA loss frequency above, as average flow rate rises: 1Mb/s => CA: 1.67 loss/sec; SS: 0.1 loss event/sec 10Mb/s => CA: 0.167 loss/sec; SS: 0.1 loss event/sec 100Mb/s => CA: 0.0167 loss/sec; SS: 0.1 loss event/sec So as bit-rates increase 100x, CA losses evolve from being 17x more frequent that SS loss events to being nearly 6x less frequent than SS. In addition, the number of packets lost in an SS loss event goes up linearly with flow rate, whereas CA losses are generally single packets. This is all part of the argument that we need to move to scalable congestion control (slide 8). In the classic TCP Reno CA fomula, the window scales with 1/sqrt(p). With a scalable congestion control it scales with 1/p. Rearranging the formulae the other way up, with scalable congestion controls, the loss fraction [%] scales with O(1/w) not O(1/w^2) like TCP Reno does. Then loss rate [loss/sec] stays constant over time as bit rates increase. This keeps the frequency of the control signal constant, which is what you were looking for in your video streaming example. That's actually another dimension to the motivations for ConEx. I don't normally bother motivating ConEx this way, because it's too hard to explain to newbies (the other motivations are easy to explain??!!). There doesn't seem to be a way to manage the transition from unscalable TCP Reno to scalable congestion controls unless we have something that allows their relative impact on others to be compared. ConEx does this, whereas the TCP-friendly paradigm would just rule scalable congestion controls out of order. Here's some links to scalable (aka Proportionally Fair or PF) congestion controls: Note only some of the list are PF (DCTCP, Relentless, STCP, Weighted Window CC). HTH Bob At 20:58 22/06/2010, Ingemar Johansson S wrote: >Hi > >Thanks all for taking the time to answer my question. My >interpretation of this is that for general internet 0.1 to 0.5% are >reasonable figures. > >On the other hand one can perhaps for some dedicated QoS traffic >envision a higher "equilibrium rate" ?. If one take that video >streaming case again one can think of a rate control that acts >according to a function of the ECN rate [ bitrate=f(ECN_rate) ] or >something similar. My take is that it should be easier to get a >smoothly varying bitrate depending on the congetsion situation if >the concestion events occur at a higher frequency. With a 0.1% >equilibrium point the video streaming service will likely have to >resort to TCP like behavior (rate halving) in its response to the ECN marks. > >/Ingemar > > > > -----Original Message----- > > From: Bob Briscoe [mailto:rbriscoe@jungle.bt.co.uk] > > Sent: den 22 juni 2010 17:40 > > To: David Harrington > > Cc: conex@ietf.org > > Subject: Re: [conex] Transport 101 > > > > David, > > > > There's a simpler answer to Ingemar's question I think... > > > > Ingemar Johansson S wrote: > > > The idea with conex is that the ECN-CE markings should be > > re-inserted > into the IP header in the forward flow for > > future use by e.g policers. > > > This I believe will require that there is some kind of > > uniform behavior > in ECN marking algorithms or? > > > > Policing is only concerned with average/equilibrium > > congestion levels (whether 0.1% or 0.05% or 0.5%). An AQM > > algo has has little if any bearing on the equilibrium > > congestion level. So no uniform AQM behaviour is needed. > > > > Average/equilibrium congestion levels depend primarily on the > > algorithms in the end-systems that are driving load against > > the congestion. As long as at some point the AQM gives a > > large increase in drop/marking for a tiny increase in load (a > > hockeystick curve), the end-systems will find the equilibrium > > point where their combined pushing is no longer enough to > > push any higher up the hockeystick. If they want to push > > higher up the hockeystick, no amount of algorithm design in > > the queue can make the congestion level lower. > > > > As long as the queue gives you more drop or marking for a > > longer *queue*, congestion indications will be convex (ie > > hockeystick) with *load*. Any queue will do that, with or > > without active queue management (AQM). > > > > Nonetheless, an AQM does have to be designed carefully to > > maintain stability, responsiveness and randomness (ie no bias > > against certain packets). But its design can hardly affect > > the equilibrium at all. > > > > > > Bob > > > > At 15:26 22/06/2010, John Leslie wrote: > > >David Harrington wrote: > > > > I found your answer very helpful in understanding the > > goals of conex. > > > > > > > > You got distracted by the sample numbers used in the last > > question, > > > > and I think you didn't answer the question. I think I know the > > > > answer, but let me restate the question with a different > > threshold > > > > to prompt your answer ... > > > > > > > >>> or can one imagine the case that e.g. a realtime > > streaming service > > > >>> can tune its bitrate such that the ECN rate should stay > > below for > > > >>> instance 0.4% where 0,4% ECN rate is in fact considered > > a healthy condition?. > > > > > > That's still a little high for me, but if you'll permit me to > > >revise it yet again, to 0.1%, I believe we consider it reasonable to > > >tune the conex-CongestionExpected markings to 0.1% -- in > > today's Internet. > > > > > > Of course, that must somehow interact with whatever > > business model > > >the ISP sets up... but I believe we envision allowance-based models > > >where such a marking rate would be "reasonable." > > > > > > (When you quadruple that, the interaction becomes more critical, > > >though I wouldn't _necessarily_ consider 0.4% unreasonable in all > > >cases.) > > > > > > Getting back to didactic mode... > > > > > > The "transport" issue here is how to fill the pipe for a "normal" > > >case. Neither ECN nor CONEX can get us all the way there, as > > currently > > >envisioned. To the extent that a transport algorithm > > actually backs off > > >50% upon an ECN mark, you will need to work out the Bandwidth-Delay > > >product to find an ECN-marking rate that permits filling the pipe. > > > > > > The conex-marking rate _can_ exceed that ECN-marking > > rate without > > >preventing you from filling the pipe, but you probably don't want to > > >exceed it by much, because conex-marking literally invites > > ECN-marking > > >to catch up with it. > > > > > >-- > > >John Leslie > > >_______________________________________________ > > >conex mailing list > > >conex@ietf.org > > >https://www.ietf.org/mailman/listinfo/conex > > > > ________________________________________________________________ > > Bob Briscoe, BT Innovate & Design > > > > > > ________________________________________________________________ Bob Briscoe, BT Innovate & Design From rbriscoe@jungle.bt.co.uk Wed Jun 23 10:20:46 2010 Return-Path: X-Original-To: conex@core3.amsl.com Delivered-To: conex@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 590C93A6ADE for ; Wed, 23 Jun 2010 10:20:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.924 X-Spam-Level: X-Spam-Status: No, score=0.924 tagged_above=-999 required=5 tests=[AWL=0.441, BAYES_50=0.001, DNS_FROM_RFC_BOGUSMX=1.482, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id lLD3dFe0iZJT for ; Wed, 23 Jun 2010 10:20:39 -0700 (PDT) Received: from smtp2.smtp.bt.com (smtp2.smtp.bt.com [217.32.164.150]) by core3.amsl.com (Postfix) with ESMTP id 422FD3A6ADD for ; Wed, 23 Jun 2010 10:20:38 -0700 (PDT) Received: from i2kc06-ukbr.domain1.systemhost.net ([193.113.197.70]) by smtp2.smtp.bt.com with Microsoft SMTPSVC(6.0.3790.4675); Wed, 23 Jun 2010 18:20:46 +0100 Received: from cbibipnt05.iuser.iroot.adidom.com ([147.149.196.177]) by i2kc06-ukbr.domain1.systemhost.net with Microsoft SMTPSVC(6.0.3790.4675); Wed, 23 Jun 2010 18:20:46 +0100 Received: From bagheera.jungle.bt.co.uk ([132.146.168.158]) by cbibipnt05.iuser.iroot.adidom.com (WebShield SMTP v4.5 MR1a P0803.399); id 1277313644504; Wed, 23 Jun 2010 18:20:44 +0100 Received: from MUT.jungle.bt.co.uk ([10.215.130.87]) by bagheera.jungle.bt.co.uk (8.13.5/8.12.8) with ESMTP id o5NHKhWe032356; Wed, 23 Jun 2010 18:20:43 +0100 Message-Id: <201006231720.o5NHKhWe032356@bagheera.jungle.bt.co.uk> X-Mailer: QUALCOMM Windows Eudora Version 7.1.0.9 Date: Wed, 23 Jun 2010 18:20:33 +0100 To: John Leslie From: Bob Briscoe In-Reply-To: <20100623140928.GG5977@verdi> References: <548FC4B9D57A4043AAFFE888A39429031DA7831E7D@ESESSCMS0356.eemea.ericsson.se> <20100622131111.GB5977@verdi> <1A08A52AD45543F68B6D914A29CD74AF@23FX1C1> <20100622142659.GC5977@verdi> <201006221540.o5MFewq4016653@bagheera.jungle.bt.co.uk> <548FC4B9D57A4043AAFFE888A39429031DA783216C@ESESSCMS0356.eemea.ericsson.se> <20100623140928.GG5977@verdi> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-Scanned-By: MIMEDefang 2.56 on 132.146.168.158 X-OriginalArrivalTime: 23 Jun 2010 17:20:46.0239 (UTC) FILETIME=[6AC0A2F0:01CB12F8] Cc: Ingemar Johansson S , conex@ietf.org Subject: Re: [conex] Off-Topic: Smoothing Variations in BitRate X-BeenThere: conex@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Congestion Exposure working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 23 Jun 2010 17:20:46 -0000 John, MY previous mail on the Transport 101 thread ended up saying how one motivation for ConEx is to enable a shift to scalable congestion controls away from TCP Reno (see the mail for details)... Many of these more modern controls are not anything like as jumpy as Reno, at least in the downward direction. For instance, Relentless only reduces the window by one packet for each packet lost/marked. The hard part is the upward direction, particularly slow start and the increase during congestion avoidance phase of controls like Cubic. TCP RAPID (Infocom'09) is an interesting new approach in this respect, altho it looks like plenty more work is needed on practicality. Zooming out from the details of various proposed congestion controls, the relevant point for this list is that, if a network counts congestion-volume against you, you have an incentive to use a congestion control that doesn't spike into the traffic of others, at least not more than you need it to in order to achieve your performance objective. Bob At 15:09 23/06/2010, John Leslie wrote: >Ingemar Johansson S wrote: > > > > Thanks all for taking the time to answer my question. My interpretation > > of this is that for general internet 0.1 to 0.5% are reasonable figures. > > I won't disagree (though I still think 0.5% is high). > > > On the other hand one can perhaps for some dedicated QoS traffic > > envision a higher "equilibrium rate" ?. If one takes that video > > streaming case again one can think of a rate control that acts > > according to a function of the ECN rate [ bitrate=f(ECN_rate) ] or > > something similar. > > This (IMHO) is clearly outside our charter; but traffic is low enough >at the moment that I think we can elaborate a bit before deciding where >this discussion belongs. > > > My take is that it should be easier to get a smoothly varying bitrate > > depending on the congestion situation if the congestion events occur > > at a higher frequency. > > Fundamentally, to get smoother variation, the reduction signaled by >an individual ECN-CE mark would need to be less than 50%. This, IMHO, >would indeed be reasonable if we agreed somehow to create more of them. >(Unfortunately, setting more CONEX-CE marks isn't likely to cause this, >despite my poorly-worded earlier posting.) > > > With a 0.1% equilibrium point the video streaming service will likely > > have to resort to TCP like behavior (rate halving) in its response > > to the ECN marks. > > Unfortunately, the basic ECN expectation in RFC 3168 is that an >ECN-CE mark will cause rate halving. > > I'm sure Bob Briscoe can answer better than I as to how this rate- >halving could be relaxed: I see several possibilities, but they seem >to require changes in RFC 3168, and that goes way beyond our charter. > > Nonetheless, our charter calling for implementation in IPv6, it >seems quite reasonable that IPv6 ECN-marking might not need to be >limited to the two bits or might be extended somehow to better >accomodate gentler variations in bit-rate. > >-- >John Leslie ________________________________________________________________ Bob Briscoe, BT Innovate & Design From ingemar.s.johansson@ericsson.com Wed Jun 23 11:16:00 2010 Return-Path: X-Original-To: conex@core3.amsl.com Delivered-To: conex@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 203EC28C14A for ; Wed, 23 Jun 2010 11:16:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.855 X-Spam-Level: X-Spam-Status: No, score=-3.855 tagged_above=-999 required=5 tests=[AWL=0.330, BAYES_40=-0.185, 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 joFkePX-EhFn for ; Wed, 23 Jun 2010 11:15:58 -0700 (PDT) Received: from mailgw10.se.ericsson.net (mailgw10.se.ericsson.net [193.180.251.61]) by core3.amsl.com (Postfix) with ESMTP id 2B57928C14F for ; Wed, 23 Jun 2010 11:15:49 -0700 (PDT) X-AuditID: c1b4fb3d-b7c50ae000005e30-06-4c224f5bd7a8 Received: from esessmw0247.eemea.ericsson.se (Unknown_Domain [153.88.253.124]) by mailgw10.se.ericsson.net (Symantec Mail Security) with SMTP id 8E.07.24112.B5F422C4; Wed, 23 Jun 2010 20:15:55 +0200 (CEST) Received: from ESESSCMS0356.eemea.ericsson.se ([169.254.2.128]) by esessmw0247.eemea.ericsson.se ([10.2.3.116]) with mapi; Wed, 23 Jun 2010 20:15:56 +0200 From: Ingemar Johansson S To: John Leslie Date: Wed, 23 Jun 2010 20:15:55 +0200 Thread-Topic: Off-Topic: Smoothing Variations in BitRate Thread-Index: AcsS3bPdVR8QDjqPRleNtiYY/gB/2gAIWD63 Message-ID: <548FC4B9D57A4043AAFFE888A39429031DB65DB3FE@ESESSCMS0356.eemea.ericsson.se> References: <548FC4B9D57A4043AAFFE888A39429031DA7831E7D@ESESSCMS0356.eemea.ericsson.se> <20100622131111.GB5977@verdi> <1A08A52AD45543F68B6D914A29CD74AF@23FX1C1> <20100622142659.GC5977@verdi> <201006221540.o5MFewq4016653@bagheera.jungle.bt.co.uk> <548FC4B9D57A4043AAFFE888A39429031DA783216C@ESESSCMS0356.eemea.ericsson.se>, <20100623140928.GG5977@verdi> In-Reply-To: <20100623140928.GG5977@verdi> Accept-Language: sv-SE, en-US Content-Language: sv-SE X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: sv-SE, en-US Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Brightmail-Tracker: AAAAAA== Cc: "conex@ietf.org" Subject: Re: [conex] Off-Topic: Smoothing Variations in BitRate X-BeenThere: conex@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Congestion Exposure working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 23 Jun 2010 18:16:00 -0000 Hi Some comments [IJ] inline below Will be away on vacation until the week before IETF-78 will likely not resp= ond to emails until then. Regards and thanks again for the help. Ingemar ________________________________________ Fr=E5n: John Leslie [john@jlc.net] Skickat: den 23 juni 2010 16:09 Till: Ingemar Johansson S Kopia: Bob Briscoe; conex@ietf.org =C4mne: Off-Topic: Smoothing Variations in BitRate Ingemar Johansson S wrote: > > Thanks all for taking the time to answer my question. My interpretation > of this is that for general internet 0.1 to 0.5% are reasonable figures. I won't disagree (though I still think 0.5% is high). [IJ] Ok > On the other hand one can perhaps for some dedicated QoS traffic > envision a higher "equilibrium rate" ?. If one takes that video > streaming case again one can think of a rate control that acts > according to a function of the ECN rate [ bitrate=3Df(ECN_rate) ] or > something similar. This (IMHO) is clearly outside our charter; but traffic is low enough at the moment that I think we can elaborate a bit before deciding where this discussion belongs. [IJ] I would too believe that it is is getting outside the charter for this= WG. Looking in perspective I should perhaps have posted this to TSVWG inst= ead, not sure however that I would have received the same response. > My take is that it should be easier to get a smoothly varying bitrate > depending on the congestion situation if the congestion events occur > at a higher frequency. Fundamentally, to get smoother variation, the reduction signaled by an individual ECN-CE mark would need to be less than 50%. This, IMHO, would indeed be reasonable if we agreed somehow to create more of them. (Unfortunately, setting more CONEX-CE marks isn't likely to cause this, despite my poorly-worded earlier posting.) > With a 0.1% equilibrium point the video streaming service will likely > have to resort to TCP like behavior (rate halving) in its response > to the ECN marks. Unfortunately, the basic ECN expectation in RFC 3168 is that an ECN-CE mark will cause rate halving. [IJ], Yes I understand this. On the other hand protocols like DCTCP (http:/= /research.microsoft.com/apps/pubs/?id=3D121386) goes somewhat inbetween. I'm sure Bob Briscoe can answer better than I as to how this rate- halving could be relaxed: I see several possibilities, but they seem to require changes in RFC 3168, and that goes way beyond our charter. Nonetheless, our charter calling for implementation in IPv6, it seems quite reasonable that IPv6 ECN-marking might not need to be limited to the two bits or might be extended somehow to better accomodate gentler variations in bit-rate. -- John Leslie From ingemar.s.johansson@ericsson.com Wed Jun 23 11:28:50 2010 Return-Path: X-Original-To: conex@core3.amsl.com Delivered-To: conex@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id CCE9628C15F for ; Wed, 23 Jun 2010 11:28:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.103 X-Spam-Level: X-Spam-Status: No, score=-5.103 tagged_above=-999 required=5 tests=[AWL=1.496, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id gXhNTIsVtEej for ; Wed, 23 Jun 2010 11:28:49 -0700 (PDT) Received: from mailgw10.se.ericsson.net (mailgw10.se.ericsson.net [193.180.251.61]) by core3.amsl.com (Postfix) with ESMTP id CA7D628C157 for ; Wed, 23 Jun 2010 11:28:48 -0700 (PDT) X-AuditID: c1b4fb3d-b7c50ae000005e30-fb-4c2252675397 Received: from esessmw0256.eemea.ericsson.se (Unknown_Domain [153.88.253.124]) by mailgw10.se.ericsson.net (Symantec Mail Security) with SMTP id 4A.87.24112.762522C4; Wed, 23 Jun 2010 20:28:55 +0200 (CEST) Received: from ESESSCMS0356.eemea.ericsson.se ([169.254.2.128]) by esessmw0256.eemea.ericsson.se ([10.2.3.125]) with mapi; Wed, 23 Jun 2010 20:28:54 +0200 From: Ingemar Johansson S To: Toby Moncaster , 'John Leslie' Date: Wed, 23 Jun 2010 20:28:54 +0200 Thread-Topic: [conex] Off-Topic: Smoothing Variations in BitRate Thread-Index: AcsS3bOSieKGvqW4S5eSTycBEQLUBwACyJ4gAAXT3uQ= Message-ID: <548FC4B9D57A4043AAFFE888A39429031DB65DB3FF@ESESSCMS0356.eemea.ericsson.se> References: <548FC4B9D57A4043AAFFE888A39429031DA7831E7D@ESESSCMS0356.eemea.ericsson.se> <20100622131111.GB5977@verdi> <1A08A52AD45543F68B6D914A29CD74AF@23FX1C1> <20100622142659.GC5977@verdi> <201006221540.o5MFewq4016653@bagheera.jungle.bt.co.uk> <548FC4B9D57A4043AAFFE888A39429031DA783216C@ESESSCMS0356.eemea.ericsson.se> <20100623140928.GG5977@verdi>,<000f01cb12ea$868c25d0$93a47170$@com> In-Reply-To: <000f01cb12ea$868c25d0$93a47170$@com> Accept-Language: sv-SE, en-US Content-Language: sv-SE X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: sv-SE, en-US Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Brightmail-Tracker: AAAAAA== Cc: "conex@ietf.org" Subject: Re: [conex] Off-Topic: Smoothing Variations in BitRate X-BeenThere: conex@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Congestion Exposure working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 23 Jun 2010 18:28:50 -0000 Hi Comments inline below. Regards Ingemar ________________________________________ Fr=E5n: Toby Moncaster [toby@moncaster.com] Skickat: den 23 juni 2010 17:41 Till: 'John Leslie'; Ingemar Johansson S Kopia: conex@ietf.org =C4mne: RE: [conex] Off-Topic: Smoothing Variations in BitRate > -----Original Message----- > From: conex-bounces@ietf.org [mailto:conex-bounces@ietf.org] On Behalf > Of John Leslie > Sent: 23 June 2010 15:09 > To: Ingemar Johansson S > Cc: conex@ietf.org > Subject: [conex] Off-Topic: Smoothing Variations in BitRate > > Ingemar Johansson S wrote: > > > > Thanks all for taking the time to answer my question. My > interpretation > > of this is that for general internet 0.1 to 0.5% are reasonable > figures. > > I won't disagree (though I still think 0.5% is high). I think for this discussion we need to clarify exactly what our network model is. As I see it there are 3 main models: mobile broadband which I choose to believe is out of charter, DSL or cable [IJ] I believe that it would be unfortunate to exclude mobile broadband. I = would believe that wireless access e.g LTE can already provide with a decen= t fairness mechanisms as each users gets its own queue. The wireless acces= s is however part of the ECN loop and will therefore affect the performance= of ConEx.=20 In DSL the traffic is heavily aggregated at the DSLAM and then several DSLAMs will dump their traffic onto IP at a B-RAS. I can easily believe congestion at the B-RAS exceeds 0.5% at certain times, at least occasionally. In Cable things may be different, I am not really qualified to comment on it... > > > On the other hand one can perhaps for some dedicated QoS traffic > > envision a higher "equilibrium rate" ?. If one takes that video > > streaming case again one can think of a rate control that acts > > according to a function of the ECN rate [ bitrate=3Df(ECN_rate) ] or > > something similar. > > This (IMHO) is clearly outside our charter; but traffic is low > enough > at the moment that I think we can elaborate a bit before deciding where > this discussion belongs. I agree - out of charter, but no harm in discussing it here > > > My take is that it should be easier to get a smoothly varying bitrate > > depending on the congestion situation if the congestion events occur > > at a higher frequency. > > Fundamentally, to get smoother variation, the reduction signaled by > an individual ECN-CE mark would need to be less than 50%. This, IMHO, > would indeed be reasonable if we agreed somehow to create more of them. > (Unfortunately, setting more CONEX-CE marks isn't likely to cause this, > despite my poorly-worded earlier posting.) I think Ingemar would be well advised to talk to Matt Mathis and Bob Brisco= e here... I think this is related to the question of whether the congestion controller responds to p or sqrt(p) (where p is the congestion on the path) [IJ] Understood. Need to do some additional homework here after my vacation= . > > > With a 0.1% equilibrium point the video streaming service will likely > > have to resort to TCP like behavior (rate halving) in its response > > to the ECN marks. > > Unfortunately, the basic ECN expectation in RFC 3168 is that an > ECN-CE mark will cause rate halving. Quoting it: " Upon the receipt by an ECN-Capable transport of a single CE packet, the congestion control algorithms followed at the end-systems MUST be essentially the same as the congestion control response to a *single* dropped packet." > > I'm sure Bob Briscoe can answer better than I as to how this rate- > halving could be relaxed: I see several possibilities, but they seem > to require changes in RFC 3168, and that goes way beyond our charter. > This is an issue of transport vs network layers. ECN is at the network laye= r (as is conex). The appropriate response at the transport layer depends on that transport. If you are a real-time inelastic transport, clearly the response is different than if you were a scavenging transport or an elastic bulk data transport... Conex is essentially transport-agnostic and I thought the idea is to try an= d get the whole network to move on from its inherent assumption that everything uses TCP. As long as the network can see how much congestion a flow is causing then that flow can respond as it wants. If it is causing to= o much congestion then it runs the risk of being policed in some manner... > Nonetheless, our charter calling for implementation in IPv6, it > seems quite reasonable that IPv6 ECN-marking might not need to be > limited to the two bits or might be extended somehow to better > accomodate gentler variations in bit-rate. Indeed it would be silly to limit it to 2 bits if there is space for more without increasing the overhead. This is potentially a very rich vein for discussions in its own right, independent of this current discussion Toby > > -- > John Leslie > _______________________________________________ > conex mailing list > conex@ietf.org > https://www.ietf.org/mailman/listinfo/conex From rbriscoe@jungle.bt.co.uk Fri Jun 25 11:57:15 2010 Return-Path: X-Original-To: conex@core3.amsl.com Delivered-To: conex@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id F01563A6800 for ; Fri, 25 Jun 2010 11:57:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.584 X-Spam-Level: X-Spam-Status: No, score=0.584 tagged_above=-999 required=5 tests=[AWL=0.101, BAYES_50=0.001, DNS_FROM_RFC_BOGUSMX=1.482, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id YN1RZSQmlsAa for ; Fri, 25 Jun 2010 11:57:08 -0700 (PDT) Received: from smtp2.smtp.bt.com (smtp2.smtp.bt.com [217.32.164.150]) by core3.amsl.com (Postfix) with ESMTP id 67DCB3A6407 for ; Fri, 25 Jun 2010 11:57:08 -0700 (PDT) Received: from i2kc06-ukbr.domain1.systemhost.net ([193.113.197.70]) by smtp2.smtp.bt.com with Microsoft SMTPSVC(6.0.3790.4675); Fri, 25 Jun 2010 19:57:16 +0100 Received: from cbibipnt05.iuser.iroot.adidom.com ([147.149.196.177]) by i2kc06-ukbr.domain1.systemhost.net with Microsoft SMTPSVC(6.0.3790.4675); Fri, 25 Jun 2010 19:57:16 +0100 Received: From bagheera.jungle.bt.co.uk ([132.146.168.158]) by cbibipnt05.iuser.iroot.adidom.com (WebShield SMTP v4.5 MR1a P0803.399); id 1277492234710; Fri, 25 Jun 2010 19:57:14 +0100 Received: from MUT.jungle.bt.co.uk ([10.215.130.87]) by bagheera.jungle.bt.co.uk (8.13.5/8.12.8) with ESMTP id o5PIvCjk027931; Fri, 25 Jun 2010 19:57:12 +0100 Message-Id: <201006251857.o5PIvCjk027931@bagheera.jungle.bt.co.uk> X-Mailer: QUALCOMM Windows Eudora Version 7.1.0.9 Date: Fri, 25 Jun 2010 19:57:16 +0100 To: Ingemar Johansson S From: Bob Briscoe In-Reply-To: <548FC4B9D57A4043AAFFE888A39429031DB65DB3FF@ESESSCMS0356.ee mea.ericsson.se> References: <548FC4B9D57A4043AAFFE888A39429031DA7831E7D@ESESSCMS0356.eemea.ericsson.se> <20100622131111.GB5977@verdi> <1A08A52AD45543F68B6D914A29CD74AF@23FX1C1> <20100622142659.GC5977@verdi> <201006221540.o5MFewq4016653@bagheera.jungle.bt.co.uk> <548FC4B9D57A4043AAFFE888A39429031DA783216C@ESESSCMS0356.eemea.ericsson.se> <20100623140928.GG5977@verdi> <000f01cb12ea$868c25d0$93a47170$@com> <548FC4B9D57A4043AAFFE888A39429031DB65DB3FF@ESESSCMS0356.eemea.ericsson.se> Mime-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1"; format=flowed Content-Transfer-Encoding: quoted-printable X-Scanned-By: MIMEDefang 2.56 on 132.146.168.158 X-OriginalArrivalTime: 25 Jun 2010 18:57:16.0101 (UTC) FILETIME=[3A9AF750:01CB1498] Cc: "conex@ietf.org" Subject: Re: [conex] Off-Topic: Smoothing Variations in BitRate X-BeenThere: conex@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Congestion Exposure working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 25 Jun 2010 18:57:16 -0000 Ingemar, I would strongly agree with you that mobile bb is=20 not outside the charter. Nothing in the charter says ConEx is non-mobile. We are meant to believe in "IP over everything...." Similarly, I strongly agree with Toby that ConEx=20 should not be about TCP only (the rate halving is=20 just one of many possible responses). "...and everything over IP." Cheers Bob At 19:28 23/06/2010, Ingemar Johansson S wrote: >Hi > >Comments inline below. > >Regards >Ingemar >________________________________________ >Fr=E5n: Toby Moncaster [toby@moncaster.com] >Skickat: den 23 juni 2010 17:41 >Till: 'John Leslie'; Ingemar Johansson S >Kopia: conex@ietf.org >=C4mne: RE: [conex] Off-Topic: Smoothing Variations in BitRate > > > -----Original Message----- > > From: conex-bounces@ietf.org [mailto:conex-bounces@ietf.org] On Behalf > > Of John Leslie > > Sent: 23 June 2010 15:09 > > To: Ingemar Johansson S > > Cc: conex@ietf.org > > Subject: [conex] Off-Topic: Smoothing Variations in BitRate > > > > Ingemar Johansson S wrote: > > > > > > Thanks all for taking the time to answer my question. My > > interpretation > > > of this is that for general internet 0.1 to 0.5% are reasonable > > figures. > > > > I won't disagree (though I still think 0.5% is high). > >I think for this discussion we need to clarify exactly what our network >model is. As I see it there are 3 main models: mobile broadband which I >choose to believe is out of charter, DSL or cable >[IJ] I believe that it would be unfortunate to=20 >exclude mobile broadband. I would believe that=20 >wireless access e.g LTE can already provide with=20 >a decent fairness mechanisms as each users gets=20 >its own queue. The wireless access is however=20 >part of the ECN loop and will therefore affect the performance of ConEx. > >In DSL the traffic is heavily aggregated at the DSLAM and then several >DSLAMs will dump their traffic onto IP at a B-RAS. I can easily believe >congestion at the B-RAS exceeds 0.5% at certain times, at least >occasionally. > >In Cable things may be different, I am not really qualified to comment on >it... > > > > > > On the other hand one can perhaps for some dedicated QoS traffic > > > envision a higher "equilibrium rate" ?. If one takes that video > > > streaming case again one can think of a rate control that acts > > > according to a function of the ECN rate [ bitrate=3Df(ECN_rate) ] or > > > something similar. > > > > This (IMHO) is clearly outside our charter; but traffic is low > > enough > > at the moment that I think we can elaborate a bit before deciding where > > this discussion belongs. > >I agree - out of charter, but no harm in discussing it here > > > > > > My take is that it should be easier to get a smoothly varying bitrate > > > depending on the congestion situation if the congestion events occur > > > at a higher frequency. > > > > Fundamentally, to get smoother variation, the reduction signaled by > > an individual ECN-CE mark would need to be less than 50%. This, IMHO, > > would indeed be reasonable if we agreed somehow to create more of them. > > (Unfortunately, setting more CONEX-CE marks isn't likely to cause this, > > despite my poorly-worded earlier posting.) > >I think Ingemar would be well advised to talk to Matt Mathis and Bob= Briscoe >here... I think this is related to the question of whether the congestion >controller responds to p or sqrt(p) (where p is the congestion on the path) >[IJ] Understood. Need to do some additional homework here after my= vacation. > > > > > > With a 0.1% equilibrium point the video streaming service will likely > > > have to resort to TCP like behavior (rate halving) in its response > > > to the ECN marks. > > > > Unfortunately, the basic ECN expectation in RFC 3168 is that an > > ECN-CE mark will cause rate halving. > >Quoting it: >" Upon the receipt by an ECN-Capable transport of a single CE packet, > the congestion control algorithms followed at the end-systems MUST be > essentially the same as the congestion control response to a *single* > dropped packet." > > > > I'm sure Bob Briscoe can answer better than I as to how this rate- > > halving could be relaxed: I see several possibilities, but they seem > > to require changes in RFC 3168, and that goes way beyond our charter. > > > >This is an issue of transport vs network layers. ECN is at the network= layer >(as is conex). The appropriate response at the transport layer depends on >that transport. If you are a real-time inelastic transport, clearly the >response is different than if you were a scavenging transport or an elastic >bulk data transport... > >Conex is essentially transport-agnostic and I thought the idea is to try= and >get the whole network to move on from its inherent assumption that >everything uses TCP. As long as the network can see how much congestion a >flow is causing then that flow can respond as it wants. If it is causing= too >much congestion then it runs the risk of being policed in some manner... > > > > Nonetheless, our charter calling for implementation in IPv6, it > > seems quite reasonable that IPv6 ECN-marking might not need to be > > limited to the two bits or might be extended somehow to better > > accomodate gentler variations in bit-rate. > >Indeed it would be silly to limit it to 2 bits if there is space for more >without increasing the overhead. This is potentially a very rich vein for >discussions in its own right, independent of this current discussion > >Toby > > > > > -- > > John Leslie > > _______________________________________________ > > conex mailing list > > conex@ietf.org > > https://www.ietf.org/mailman/listinfo/conex > >_______________________________________________ >conex mailing list >conex@ietf.org >https://www.ietf.org/mailman/listinfo/conex ________________________________________________________________ Bob Briscoe, BT Innovate & Design=20 From toby@moncaster.com Sat Jun 26 06:28:13 2010 Return-Path: X-Original-To: conex@core3.amsl.com Delivered-To: conex@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 9D85E3A67E9 for ; Sat, 26 Jun 2010 06:28:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.434 X-Spam-Level: X-Spam-Status: No, score=0.434 tagged_above=-999 required=5 tests=[AWL=0.083, BAYES_50=0.001, HELO_EQ_DE=0.35] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 9scs1yjKixff for ; Sat, 26 Jun 2010 06:28:12 -0700 (PDT) Received: from moutng.kundenserver.de (moutng.kundenserver.de [212.227.17.8]) by core3.amsl.com (Postfix) with ESMTP id 3DD763A67B6 for ; Sat, 26 Jun 2010 06:28:12 -0700 (PDT) Received: from TobysHP (host86-170-50-165.range86-170.btcentralplus.com [86.170.50.165]) by mrelayeu.kundenserver.de (node=mrbap2) with ESMTP (Nemesis) id 0ME41n-1OOzyp3n6V-00HO18; Sat, 26 Jun 2010 15:28:17 +0200 From: "Toby Moncaster" To: "'Bob Briscoe'" , "'Ingemar Johansson S'" References: <548FC4B9D57A4043AAFFE888A39429031DA7831E7D@ESESSCMS0356.eemea.ericsson.se> <20100622131111.GB5977@verdi> <1A08A52AD45543F68B6D914A29CD74AF@23FX1C1> <20100622142659.GC5977@verdi> <201006221540.o5MFewq4016653@bagheera.jungle.bt.co.uk> <548FC4B9D57A4043AAFFE888A39429031DA783216C@ESESSCMS0356.eemea.ericsson.se> <20100623140928.GG5977@verdi> <000f01cb12ea$868c25d0$93a47170$@com> <548FC4B9D57A4043AAFFE888A39429031DB65DB3FF@ESESSCMS0356.eemea.ericsson.se> <201006251857.o5PIvCjk027931@bagheera.jungle.bt.co.uk> In-Reply-To: <201006251857.o5PIvCjk027931@bagheera.jungle.bt.co.uk> Date: Sat, 26 Jun 2010 14:28:16 +0100 Message-ID: <001201cb1533$6fb3f090$4f1bd1b0$@com> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable X-Mailer: Microsoft Office Outlook 12.0 thread-index: AcsUmDqLF1HHEug8Qn6Pbp6DeOFqFQAmwNAg Content-Language: en-gb X-Provags-ID: V01U2FsdGVkX1/VA596IaMIp4wR+L1haQmFyBPNY81Kbyp+wEt r1Kqe8h/rKxN1KeBcdRmODieAbng5YZ4cPSvluRXXMG9ZGhHRe H+NVtNUVzFqJCqxbQb1y608Oxd4fxTg Cc: conex@ietf.org Subject: Re: [conex] Off-Topic: Smoothing Variations in BitRate X-BeenThere: conex@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Congestion Exposure working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 26 Jun 2010 13:28:14 -0000 If we are going to include mobile BB then we need to encourage guys from = the mobility area to get involved... Toby=20 > -----Original Message----- > From: Bob Briscoe [mailto:rbriscoe@jungle.bt.co.uk] > Sent: 25 June 2010 19:57 > To: Ingemar Johansson S > Cc: Toby Moncaster; 'John Leslie'; conex@ietf.org > Subject: Re: [conex] Off-Topic: Smoothing Variations in BitRate >=20 > Ingemar, >=20 > I would strongly agree with you that mobile bb is > not outside the charter. Nothing in the charter says ConEx is non- > mobile. >=20 > We are meant to believe in "IP over everything...." >=20 > Similarly, I strongly agree with Toby that ConEx > should not be about TCP only (the rate halving is > just one of many possible responses). >=20 > "...and everything over IP." >=20 > Cheers >=20 >=20 > Bob >=20 > At 19:28 23/06/2010, Ingemar Johansson S wrote: > >Hi > > > >Comments inline below. > > > >Regards > >Ingemar > >________________________________________ > >Fr=E5n: Toby Moncaster [toby@moncaster.com] > >Skickat: den 23 juni 2010 17:41 > >Till: 'John Leslie'; Ingemar Johansson S > >Kopia: conex@ietf.org > >=C4mne: RE: [conex] Off-Topic: Smoothing Variations in BitRate > > > > > -----Original Message----- > > > From: conex-bounces@ietf.org [mailto:conex-bounces@ietf.org] On > Behalf > > > Of John Leslie > > > Sent: 23 June 2010 15:09 > > > To: Ingemar Johansson S > > > Cc: conex@ietf.org > > > Subject: [conex] Off-Topic: Smoothing Variations in BitRate > > > > > > Ingemar Johansson S wrote: > > > > > > > > Thanks all for taking the time to answer my question. My > > > interpretation > > > > of this is that for general internet 0.1 to 0.5% are reasonable > > > figures. > > > > > > I won't disagree (though I still think 0.5% is high). > > > >I think for this discussion we need to clarify exactly what our > network > >model is. As I see it there are 3 main models: mobile broadband which > I > >choose to believe is out of charter, DSL or cable > >[IJ] I believe that it would be unfortunate to > >exclude mobile broadband. I would believe that > >wireless access e.g LTE can already provide with > >a decent fairness mechanisms as each users gets > >its own queue. The wireless access is however > >part of the ECN loop and will therefore affect the performance of > ConEx. > > > >In DSL the traffic is heavily aggregated at the DSLAM and then = several > >DSLAMs will dump their traffic onto IP at a B-RAS. I can easily > believe > >congestion at the B-RAS exceeds 0.5% at certain times, at least > >occasionally. > > > >In Cable things may be different, I am not really qualified to = comment > on > >it... > > > > > > > > > On the other hand one can perhaps for some dedicated QoS traffic > > > > envision a higher "equilibrium rate" ?. If one takes that video > > > > streaming case again one can think of a rate control that acts > > > > according to a function of the ECN rate [ bitrate=3Df(ECN_rate) = ] > or > > > > something similar. > > > > > > This (IMHO) is clearly outside our charter; but traffic is low > > > enough > > > at the moment that I think we can elaborate a bit before deciding > where > > > this discussion belongs. > > > >I agree - out of charter, but no harm in discussing it here > > > > > > > > > My take is that it should be easier to get a smoothly varying > bitrate > > > > depending on the congestion situation if the congestion events > occur > > > > at a higher frequency. > > > > > > Fundamentally, to get smoother variation, the reduction = signaled > by > > > an individual ECN-CE mark would need to be less than 50%. This, > IMHO, > > > would indeed be reasonable if we agreed somehow to create more of > them. > > > (Unfortunately, setting more CONEX-CE marks isn't likely to cause > this, > > > despite my poorly-worded earlier posting.) > > > >I think Ingemar would be well advised to talk to Matt Mathis and Bob > Briscoe > >here... I think this is related to the question of whether the > congestion > >controller responds to p or sqrt(p) (where p is the congestion on the > path) > >[IJ] Understood. Need to do some additional homework here after my > vacation. > > > > > > > > > With a 0.1% equilibrium point the video streaming service will > likely > > > > have to resort to TCP like behavior (rate halving) in its > response > > > > to the ECN marks. > > > > > > Unfortunately, the basic ECN expectation in RFC 3168 is that an > > > ECN-CE mark will cause rate halving. > > > >Quoting it: > >" Upon the receipt by an ECN-Capable transport of a single CE = packet, > > the congestion control algorithms followed at the end-systems = MUST > be > > essentially the same as the congestion control response to a > *single* > > dropped packet." > > > > > > I'm sure Bob Briscoe can answer better than I as to how this > rate- > > > halving could be relaxed: I see several possibilities, but they > seem > > > to require changes in RFC 3168, and that goes way beyond our > charter. > > > > > > >This is an issue of transport vs network layers. ECN is at the = network > layer > >(as is conex). The appropriate response at the transport layer = depends > on > >that transport. If you are a real-time inelastic transport, clearly > the > >response is different than if you were a scavenging transport or an > elastic > >bulk data transport... > > > >Conex is essentially transport-agnostic and I thought the idea is to > try and > >get the whole network to move on from its inherent assumption that > >everything uses TCP. As long as the network can see how much > congestion a > >flow is causing then that flow can respond as it wants. If it is > causing too > >much congestion then it runs the risk of being policed in some > manner... > > > > > > > Nonetheless, our charter calling for implementation in IPv6, it > > > seems quite reasonable that IPv6 ECN-marking might not need to be > > > limited to the two bits or might be extended somehow to better > > > accomodate gentler variations in bit-rate. > > > >Indeed it would be silly to limit it to 2 bits if there is space for > more > >without increasing the overhead. This is potentially a very rich vein > for > >discussions in its own right, independent of this current discussion > > > >Toby > > > > > > > > -- > > > John Leslie > > > _______________________________________________ > > > conex mailing list > > > conex@ietf.org > > > https://www.ietf.org/mailman/listinfo/conex > > > >_______________________________________________ > >conex mailing list > >conex@ietf.org > >https://www.ietf.org/mailman/listinfo/conex >=20 > ________________________________________________________________ > Bob Briscoe, BT Innovate & Design From lei.zhu@huawei.com Sun Jun 27 18:42:33 2010 Return-Path: X-Original-To: conex@core3.amsl.com Delivered-To: conex@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id A6DBD3A688A for ; Sun, 27 Jun 2010 18:42:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.001 X-Spam-Level: X-Spam-Status: No, score=0.001 tagged_above=-999 required=5 tests=[BAYES_50=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ppdWUYJ1PvqA for ; Sun, 27 Jun 2010 18:42:31 -0700 (PDT) Received: from szxga02-in.huawei.com (szxga02-in.huawei.com [119.145.14.65]) by core3.amsl.com (Postfix) with ESMTP id 780E33A6867 for ; Sun, 27 Jun 2010 18:42:31 -0700 (PDT) Received: from huawei.com (szxga02-in [172.24.2.6]) by szxga02-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0L4P001PSBF3JJ@szxga02-in.huawei.com> for conex@ietf.org; Mon, 28 Jun 2010 09:42:39 +0800 (CST) Received: from huawei.com ([172.24.2.119]) by szxga02-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0L4P005P3BF3ZT@szxga02-in.huawei.com> for conex@ietf.org; Mon, 28 Jun 2010 09:42:39 +0800 (CST) Received: from z41317 ([10.111.16.163]) by szxml06-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTPA id <0L4P00LHWBF264@szxml06-in.huawei.com> for conex@ietf.org; Mon, 28 Jun 2010 09:42:39 +0800 (CST) Date: Mon, 28 Jun 2010 09:42:38 +0800 From: Zhu Lei In-reply-to: <001201cb1533$6fb3f090$4f1bd1b0$@com> To: 'Toby Moncaster' , 'Bob Briscoe' , 'Ingemar Johansson S' Message-id: <001401cb1663$3113b6a0$a3106f0a@china.huawei.com> MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2900.3350 X-Mailer: Microsoft Office Outlook 11 Content-type: text/plain; charset=utf-8 Content-transfer-encoding: quoted-printable Thread-index: AcsUmDqLF1HHEug8Qn6Pbp6DeOFqFQAmwNAgAEuvxfA= Cc: conex@ietf.org Subject: Re: [conex] Off-Topic: Smoothing Variations in BitRate X-BeenThere: conex@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Congestion Exposure working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 28 Jun 2010 01:42:33 -0000 =20 Hi all, I personally did not see the harms from collecting participants of IP = mobility into congestion control. But, congestion control did not impact the IP mobility issues by now. = And, I think this would be ok to mark ECN indication in IP header = without involving IP mobility. If your "mobility" means the particular topics at access part of = networks, I may close the mouth before really getting it. Zhu Lei HUAWEI TECHNOLOGIES CO.,LTD. huawei_logo Address: Huawei Bld, Xinxi Rd Shangdi Information Indursty BaseHaidian District Beijing 100085, P.R.China Tel: 86-10-82836301 Fax: 86-10-82836920 Mobile: 86-13910157020 E-mail: lei.zhu@huawei.com www.huawei.com -------------------------------------------------------------------------= ------------------------------------------------------------ This e-mail and its attachments contain confidential information from = HUAWEI, which=20 is intended only for the person or entity whose address is listed above. = Any use of the=20 information contained herein in any way (including, but not limited to, = total or partial=20 disclosure, reproduction, or dissemination) by persons other than the = intended=20 recipient(s) is prohibited. If you receive this e-mail in error, please = notify the sender by=20 phone or email immediately and delete it! -----=E9=82=AE=E4=BB=B6=E5=8E=9F=E4=BB=B6----- =E5=8F=91=E4=BB=B6=E4=BA=BA: conex-bounces@ietf.org = [mailto:conex-bounces@ietf.org] =E4=BB=A3=E8=A1=A8 Toby Moncaster =E5=8F=91=E9=80=81=E6=97=B6=E9=97=B4: 2010=E5=B9=B46=E6=9C=8826=E6=97=A5 = 21:28 =E6=94=B6=E4=BB=B6=E4=BA=BA: 'Bob Briscoe'; 'Ingemar Johansson S' =E6=8A=84=E9=80=81: conex@ietf.org =E4=B8=BB=E9=A2=98: Re: [conex] Off-Topic: Smoothing Variations in = BitRate If we are going to include mobile BB then we need to encourage guys from = the mobility area to get involved... Toby=20 > -----Original Message----- > From: Bob Briscoe [mailto:rbriscoe@jungle.bt.co.uk] > Sent: 25 June 2010 19:57 > To: Ingemar Johansson S > Cc: Toby Moncaster; 'John Leslie'; conex@ietf.org > Subject: Re: [conex] Off-Topic: Smoothing Variations in BitRate >=20 > Ingemar, >=20 > I would strongly agree with you that mobile bb is not outside the=20 > charter. Nothing in the charter says ConEx is non- mobile. >=20 > We are meant to believe in "IP over everything...." >=20 > Similarly, I strongly agree with Toby that ConEx should not be about=20 > TCP only (the rate halving is just one of many possible responses). >=20 > "...and everything over IP." >=20 > Cheers >=20 >=20 > Bob >=20 > At 19:28 23/06/2010, Ingemar Johansson S wrote: > >Hi > > > >Comments inline below. > > > >Regards > >Ingemar > >________________________________________ > >Fr=C3=A5n: Toby Moncaster [toby@moncaster.com] > >Skickat: den 23 juni 2010 17:41 > >Till: 'John Leslie'; Ingemar Johansson S > >Kopia: conex@ietf.org > >=C3=84mne: RE: [conex] Off-Topic: Smoothing Variations in BitRate > > > > > -----Original Message----- > > > From: conex-bounces@ietf.org [mailto:conex-bounces@ietf.org] On > Behalf > > > Of John Leslie > > > Sent: 23 June 2010 15:09 > > > To: Ingemar Johansson S > > > Cc: conex@ietf.org > > > Subject: [conex] Off-Topic: Smoothing Variations in BitRate > > > > > > Ingemar Johansson S wrote: > > > > > > > > Thanks all for taking the time to answer my question. My > > > interpretation > > > > of this is that for general internet 0.1 to 0.5% are reasonable > > > figures. > > > > > > I won't disagree (though I still think 0.5% is high). > > > >I think for this discussion we need to clarify exactly what our > network > >model is. As I see it there are 3 main models: mobile broadband which > I > >choose to believe is out of charter, DSL or cable [IJ] I believe that = > >it would be unfortunate to exclude mobile broadband. I would believe=20 > >that wireless access e.g LTE can already provide with a decent =20 > >fairness mechanisms as each users gets its own queue. The wireless=20 > >access is however part of the ECN loop and will therefore affect the=20 > >performance of > ConEx. > > > >In DSL the traffic is heavily aggregated at the DSLAM and then=20 > >several DSLAMs will dump their traffic onto IP at a B-RAS. I can=20 > >easily > believe > >congestion at the B-RAS exceeds 0.5% at certain times, at least=20 > >occasionally. > > > >In Cable things may be different, I am not really qualified to=20 > >comment > on > >it... > > > > > > > > > On the other hand one can perhaps for some dedicated QoS traffic = > > > > envision a higher "equilibrium rate" ?. If one takes that video=20 > > > > streaming case again one can think of a rate control that acts=20 > > > > according to a function of the ECN rate [ bitrate=3Df(ECN_rate) = ] > or > > > > something similar. > > > > > > This (IMHO) is clearly outside our charter; but traffic is low=20 > > > enough at the moment that I think we can elaborate a bit before=20 > > > deciding > where > > > this discussion belongs. > > > >I agree - out of charter, but no harm in discussing it here > > > > > > > > > My take is that it should be easier to get a smoothly varying > bitrate > > > > depending on the congestion situation if the congestion events > occur > > > > at a higher frequency. > > > > > > Fundamentally, to get smoother variation, the reduction=20 > > > signaled > by > > > an individual ECN-CE mark would need to be less than 50%. This, > IMHO, > > > would indeed be reasonable if we agreed somehow to create more of > them. > > > (Unfortunately, setting more CONEX-CE marks isn't likely to cause > this, > > > despite my poorly-worded earlier posting.) > > > >I think Ingemar would be well advised to talk to Matt Mathis and Bob > Briscoe > >here... I think this is related to the question of whether the > congestion > >controller responds to p or sqrt(p) (where p is the congestion on the > path) > >[IJ] Understood. Need to do some additional homework here after my > vacation. > > > > > > > > > With a 0.1% equilibrium point the video streaming service will > likely > > > > have to resort to TCP like behavior (rate halving) in its > response > > > > to the ECN marks. > > > > > > Unfortunately, the basic ECN expectation in RFC 3168 is that an = > > > ECN-CE mark will cause rate halving. > > > >Quoting it: > >" Upon the receipt by an ECN-Capable transport of a single CE = packet, > > the congestion control algorithms followed at the end-systems=20 > >MUST > be > > essentially the same as the congestion control response to a > *single* > > dropped packet." > > > > > > I'm sure Bob Briscoe can answer better than I as to how this > rate- > > > halving could be relaxed: I see several possibilities, but they > seem > > > to require changes in RFC 3168, and that goes way beyond our > charter. > > > > > > >This is an issue of transport vs network layers. ECN is at the=20 > >network > layer > >(as is conex). The appropriate response at the transport layer=20 > >depends > on > >that transport. If you are a real-time inelastic transport, clearly > the > >response is different than if you were a scavenging transport or an > elastic > >bulk data transport... > > > >Conex is essentially transport-agnostic and I thought the idea is to > try and > >get the whole network to move on from its inherent assumption that=20 > >everything uses TCP. As long as the network can see how much > congestion a > >flow is causing then that flow can respond as it wants. If it is > causing too > >much congestion then it runs the risk of being policed in some > manner... > > > > > > > Nonetheless, our charter calling for implementation in IPv6, it = > > > seems quite reasonable that IPv6 ECN-marking might not need to be=20 > > > limited to the two bits or might be extended somehow to better=20 > > > accomodate gentler variations in bit-rate. > > > >Indeed it would be silly to limit it to 2 bits if there is space for > more > >without increasing the overhead. This is potentially a very rich vein > for > >discussions in its own right, independent of this current discussion > > > >Toby > > > > > > > > -- > > > John Leslie > > > _______________________________________________ > > > conex mailing list > > > conex@ietf.org > > > https://www.ietf.org/mailman/listinfo/conex > > > >_______________________________________________ > >conex mailing list > >conex@ietf.org > >https://www.ietf.org/mailman/listinfo/conex >=20 > ________________________________________________________________ > Bob Briscoe, BT Innovate & Design _______________________________________________ conex mailing list conex@ietf.org https://www.ietf.org/mailman/listinfo/conex From prvs=379596A3BD=Kevin.Mason@telecom.co.nz Sun Jun 27 23:47:56 2010 Return-Path: X-Original-To: conex@core3.amsl.com Delivered-To: conex@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id CB41D3A6982 for ; Sun, 27 Jun 2010 23:47:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.599 X-Spam-Level: X-Spam-Status: No, score=-3.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id j4sHNHQzDJNF for ; Sun, 27 Jun 2010 23:47:55 -0700 (PDT) Received: from mgate2.telecom.co.nz (envoy-out.telecom.co.nz [146.171.15.100]) by core3.amsl.com (Postfix) with ESMTP id BF01C3A696F for ; Sun, 27 Jun 2010 23:47:54 -0700 (PDT) Received: from mgate3.telecom.co.nz (unknown [146.171.1.21]) by mgate2.telecom.co.nz (Tumbleweed MailGate 3.7.1) with ESMTP id 21AB01030F83; Mon, 28 Jun 2010 18:48:00 +1200 (NZST) X-WSS-ID: 0L4PPJX-03-08X-02 X-M-MSG: Received: from hp2846.telecom.tcnz.net (hp2846.telecom.tcnz.net [146.171.228.248]) (using TLSv1 with cipher RC4-MD5 (128/128 bits)) (No client certificate requested) by mgate3.telecom.co.nz (Postfix) with ESMTP id 14953334034; Mon, 28 Jun 2010 18:47:57 +1200 (NZST) Received: from hp3119.telecom.tcnz.net (146.171.212.204) by hp2846.telecom.tcnz.net (146.171.228.248) with Microsoft SMTP Server (TLS) id 8.2.234.1; Mon, 28 Jun 2010 18:47:59 +1200 Received: from WNEXMBX01.telecom.tcnz.net ([146.171.212.201]) by hp3119.telecom.tcnz.net ([146.171.212.204]) with mapi; Mon, 28 Jun 2010 18:47:59 +1200 From: Kevin Mason To: Toby Moncaster , 'Bob Briscoe' , 'Ingemar Johansson S' Date: Mon, 28 Jun 2010 18:47:58 +1200 Thread-Topic: [conex] Off-Topic: Smoothing Variations in BitRate Thread-Index: AcsUmDqLF1HHEug8Qn6Pbp6DeOFqFQAmwNAgAEzhHeA= Message-ID: <563C162F43D1B14E9FD2BC0A776C1E9127BE774EEC@WNEXMBX01.telecom.tcnz.net> References: <548FC4B9D57A4043AAFFE888A39429031DA7831E7D@ESESSCMS0356.eemea.ericsson.se> <20100622131111.GB5977@verdi> <1A08A52AD45543F68B6D914A29CD74AF@23FX1C1> <20100622142659.GC5977@verdi> <201006221540.o5MFewq4016653@bagheera.jungle.bt.co.uk> <548FC4B9D57A4043AAFFE888A39429031DA783216C@ESESSCMS0356.eemea.ericsson.se> <20100623140928.GG5977@verdi> <000f01cb12ea$868c25d0$93a47170$@com> <548FC4B9D57A4043AAFFE888A39429031DB65DB3FF@ESESSCMS0356.eemea.ericsson.se> <201006251857.o5PIvCjk027931@bagheera.jungle.bt.co.uk> <001201cb1533$6fb3f090$4f1bd1b0$@com> In-Reply-To: <001201cb1533$6fb3f090$4f1bd1b0$@com> Accept-Language: en-US, en-NZ Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US, en-NZ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "conex@ietf.org" Subject: Re: [conex] Off-Topic: Smoothing Variations in BitRate X-BeenThere: conex@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Congestion Exposure working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 28 Jun 2010 06:47:56 -0000 Whilst involvement for as wide an industry is potentially valuable, I do no= t think it is essential at this juncture. Exposing congestion information to the network is only of benefit if practi= cal policy decision and enforcement points can receive/extract it, and then= apply policy as required at the appropriate points in response. So this policy point needs to be "user" aware. In most cass the user for ne= twork service is only down to the account holder (UNI for BBF access and UA= for 3GPP mobility access) For access networks, the key policy management point is the BRAS/BNG (for B= BF fixed architectures) and the GGSN (for 3GPP mobile access) fro downstrea= m traffic (toward the user) and the Routing gateway (BBF) or nodeB under co= ntrol of the RAN (3GPP mobile) upstream. For broadband forum architecture both the BNG and the RG are primarily IP d= evices, so congestion information conveyed in the IP header could realistic= ally be extracted. For mobility the GGSN is an IP device but the RAN/NodeB does not inspect th= e IP header (as I understand) as the IP is encapsulated at this point. So the key thing is not toget to worries about how particular architecture = may use it, but ensure the relevant information can be inspected/extracted = at a network policy management point (like a BRAS or GGSN), and generically= how this might be acted on or conveyed to an appropriate and effective enf= orcement point. Cheers Kevin Mason -----Original Message----- From: conex-bounces@ietf.org [mailto:conex-bounces@ietf.org] On Behalf Of T= oby Moncaster Sent: Sunday, 27 June 2010 1:28 a.m. To: 'Bob Briscoe'; 'Ingemar Johansson S' Cc: conex@ietf.org Subject: Re: [conex] Off-Topic: Smoothing Variations in BitRate If we are going to include mobile BB then we need to encourage guys from th= e mobility area to get involved... Toby=20 > -----Original Message----- > From: Bob Briscoe [mailto:rbriscoe@jungle.bt.co.uk] > Sent: 25 June 2010 19:57 > To: Ingemar Johansson S > Cc: Toby Moncaster; 'John Leslie'; conex@ietf.org > Subject: Re: [conex] Off-Topic: Smoothing Variations in BitRate >=20 > Ingemar, >=20 > I would strongly agree with you that mobile bb is > not outside the charter. Nothing in the charter says ConEx is non- > mobile. >=20 > We are meant to believe in "IP over everything...." >=20 > Similarly, I strongly agree with Toby that ConEx > should not be about TCP only (the rate halving is > just one of many possible responses). >=20 > "...and everything over IP." >=20 > Cheers >=20 >=20 > Bob >=20 > At 19:28 23/06/2010, Ingemar Johansson S wrote: > >Hi > > > >Comments inline below. > > > >Regards > >Ingemar > >________________________________________ > >Fr=E5n: Toby Moncaster [toby@moncaster.com] > >Skickat: den 23 juni 2010 17:41 > >Till: 'John Leslie'; Ingemar Johansson S > >Kopia: conex@ietf.org > >=C4mne: RE: [conex] Off-Topic: Smoothing Variations in BitRate > > > > > -----Original Message----- > > > From: conex-bounces@ietf.org [mailto:conex-bounces@ietf.org] On > Behalf > > > Of John Leslie > > > Sent: 23 June 2010 15:09 > > > To: Ingemar Johansson S > > > Cc: conex@ietf.org > > > Subject: [conex] Off-Topic: Smoothing Variations in BitRate > > > > > > Ingemar Johansson S wrote: > > > > > > > > Thanks all for taking the time to answer my question. My > > > interpretation > > > > of this is that for general internet 0.1 to 0.5% are reasonable > > > figures. > > > > > > I won't disagree (though I still think 0.5% is high). > > > >I think for this discussion we need to clarify exactly what our > network > >model is. As I see it there are 3 main models: mobile broadband which > I > >choose to believe is out of charter, DSL or cable > >[IJ] I believe that it would be unfortunate to > >exclude mobile broadband. I would believe that > >wireless access e.g LTE can already provide with > >a decent fairness mechanisms as each users gets > >its own queue. The wireless access is however > >part of the ECN loop and will therefore affect the performance of > ConEx. > > > >In DSL the traffic is heavily aggregated at the DSLAM and then several > >DSLAMs will dump their traffic onto IP at a B-RAS. I can easily > believe > >congestion at the B-RAS exceeds 0.5% at certain times, at least > >occasionally. > > > >In Cable things may be different, I am not really qualified to comment > on > >it... > > > > > > > > > On the other hand one can perhaps for some dedicated QoS traffic > > > > envision a higher "equilibrium rate" ?. If one takes that video > > > > streaming case again one can think of a rate control that acts > > > > according to a function of the ECN rate [ bitrate=3Df(ECN_rate) ] > or > > > > something similar. > > > > > > This (IMHO) is clearly outside our charter; but traffic is low > > > enough > > > at the moment that I think we can elaborate a bit before deciding > where > > > this discussion belongs. > > > >I agree - out of charter, but no harm in discussing it here > > > > > > > > > My take is that it should be easier to get a smoothly varying > bitrate > > > > depending on the congestion situation if the congestion events > occur > > > > at a higher frequency. > > > > > > Fundamentally, to get smoother variation, the reduction signaled > by > > > an individual ECN-CE mark would need to be less than 50%. This, > IMHO, > > > would indeed be reasonable if we agreed somehow to create more of > them. > > > (Unfortunately, setting more CONEX-CE marks isn't likely to cause > this, > > > despite my poorly-worded earlier posting.) > > > >I think Ingemar would be well advised to talk to Matt Mathis and Bob > Briscoe > >here... I think this is related to the question of whether the > congestion > >controller responds to p or sqrt(p) (where p is the congestion on the > path) > >[IJ] Understood. Need to do some additional homework here after my > vacation. > > > > > > > > > With a 0.1% equilibrium point the video streaming service will > likely > > > > have to resort to TCP like behavior (rate halving) in its > response > > > > to the ECN marks. > > > > > > Unfortunately, the basic ECN expectation in RFC 3168 is that an > > > ECN-CE mark will cause rate halving. > > > >Quoting it: > >" Upon the receipt by an ECN-Capable transport of a single CE packet, > > the congestion control algorithms followed at the end-systems MUST > be > > essentially the same as the congestion control response to a > *single* > > dropped packet." > > > > > > I'm sure Bob Briscoe can answer better than I as to how this > rate- > > > halving could be relaxed: I see several possibilities, but they > seem > > > to require changes in RFC 3168, and that goes way beyond our > charter. > > > > > > >This is an issue of transport vs network layers. ECN is at the network > layer > >(as is conex). The appropriate response at the transport layer depends > on > >that transport. If you are a real-time inelastic transport, clearly > the > >response is different than if you were a scavenging transport or an > elastic > >bulk data transport... > > > >Conex is essentially transport-agnostic and I thought the idea is to > try and > >get the whole network to move on from its inherent assumption that > >everything uses TCP. As long as the network can see how much > congestion a > >flow is causing then that flow can respond as it wants. If it is > causing too > >much congestion then it runs the risk of being policed in some > manner... > > > > > > > Nonetheless, our charter calling for implementation in IPv6, it > > > seems quite reasonable that IPv6 ECN-marking might not need to be > > > limited to the two bits or might be extended somehow to better > > > accomodate gentler variations in bit-rate. > > > >Indeed it would be silly to limit it to 2 bits if there is space for > more > >without increasing the overhead. This is potentially a very rich vein > for > >discussions in its own right, independent of this current discussion > > > >Toby > > > > > > > > -- > > > John Leslie > > > _______________________________________________ > > > conex mailing list > > > conex@ietf.org > > > https://www.ietf.org/mailman/listinfo/conex > > > >_______________________________________________ > >conex mailing list > >conex@ietf.org > >https://www.ietf.org/mailman/listinfo/conex >=20 > ________________________________________________________________ > Bob Briscoe, BT Innovate & Design _______________________________________________ conex mailing list conex@ietf.org https://www.ietf.org/mailman/listinfo/conex From Dirk.Kutscher@nw.neclab.eu Mon Jun 28 02:48:36 2010 Return-Path: X-Original-To: conex@core3.amsl.com Delivered-To: conex@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 733193A69C3 for ; Mon, 28 Jun 2010 02:48:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id revs8Hzsw2fm for ; Mon, 28 Jun 2010 02:48:33 -0700 (PDT) Received: from smtp0.neclab.eu (smtp0.neclab.eu [195.37.70.41]) by core3.amsl.com (Postfix) with ESMTP id 590653A687E for ; Mon, 28 Jun 2010 02:48:32 -0700 (PDT) Received: from localhost (localhost.localdomain [127.0.0.1]) by smtp0.neclab.eu (Postfix) with ESMTP id 3827D2C000308; Mon, 28 Jun 2010 11:48:42 +0200 (CEST) X-Virus-Scanned: Amavisd on Debian GNU/Linux (atlas2.office) Received: from smtp0.neclab.eu ([127.0.0.1]) by localhost (atlas2.office [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id qUbv6O4fIyS8; Mon, 28 Jun 2010 11:48:42 +0200 (CEST) Received: from VENUS.office (mx1.office [192.168.24.3]) by smtp0.neclab.eu (Postfix) with ESMTP id 1979D2C000F05; Mon, 28 Jun 2010 11:48:22 +0200 (CEST) Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable X-MIMEOLE: Produced By Microsoft Exchange V6.5 Date: Mon, 28 Jun 2010 11:48:21 +0200 Message-ID: <547F018265F92642B577B986577D671C0152C55E@VENUS.office> In-Reply-To: <001201cb1533$6fb3f090$4f1bd1b0$@com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [conex] Off-Topic: Smoothing Variations in BitRate Thread-index: AcsUmDqLF1HHEug8Qn6Pbp6DeOFqFQAmwNAgAFxUFbA= References: <548FC4B9D57A4043AAFFE888A39429031DA7831E7D@ESESSCMS0356.eemea.ericsson.se><20100622131111.GB5977@verdi><1A08A52AD45543F68B6D914A29CD74AF@23FX1C1><20100622142659.GC5977@verdi><201006221540.o5MFewq4016653@bagheera.jungle.bt.co.uk><548FC4B9D57A4043AAFFE888A39429031DA783216C@ESESSCMS0356.eemea.ericsson.se><20100623140928.GG5977@verdi> <000f01cb12ea$868c25d0$93a47170$@com><548FC4B9D57A4043AAFFE888A39429031DB65DB3FF@ESESSCMS0356.eemea.ericsson.se><201006251857.o5PIvCjk027931@bagheera.jungle.bt.co.uk> <001201cb1533$6fb3f090$4f1bd1b0$@com> From: "Dirk Kutscher" To: "Toby Moncaster" , "Bob Briscoe" , "Ingemar Johansson S" Cc: conex@ietf.org Subject: Re: [conex] Off-Topic: Smoothing Variations in BitRate X-BeenThere: conex@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Congestion Exposure working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 28 Jun 2010 09:48:36 -0000 I also interpreted the charter to include mobile bb -- which is IMO = good. Best regards, Dirk > -----Original Message----- > From: conex-bounces@ietf.org [mailto:conex-bounces@ietf.org] On Behalf > Of Toby Moncaster > Sent: Saturday, June 26, 2010 3:28 PM > To: 'Bob Briscoe'; 'Ingemar Johansson S' > Cc: conex@ietf.org > Subject: Re: [conex] Off-Topic: Smoothing Variations in BitRate >=20 > If we are going to include mobile BB then we need to encourage guys > from the > mobility area to get involved... >=20 > Toby >=20 > > -----Original Message----- > > From: Bob Briscoe [mailto:rbriscoe@jungle.bt.co.uk] > > Sent: 25 June 2010 19:57 > > To: Ingemar Johansson S > > Cc: Toby Moncaster; 'John Leslie'; conex@ietf.org > > Subject: Re: [conex] Off-Topic: Smoothing Variations in BitRate > > > > Ingemar, > > > > I would strongly agree with you that mobile bb is > > not outside the charter. Nothing in the charter says ConEx is non- > > mobile. > > > > We are meant to believe in "IP over everything...." > > > > Similarly, I strongly agree with Toby that ConEx > > should not be about TCP only (the rate halving is > > just one of many possible responses). > > > > "...and everything over IP." > > > > Cheers > > > > > > Bob > > > > At 19:28 23/06/2010, Ingemar Johansson S wrote: > > >Hi > > > > > >Comments inline below. > > > > > >Regards > > >Ingemar > > >________________________________________ > > >Fr=E5n: Toby Moncaster [toby@moncaster.com] > > >Skickat: den 23 juni 2010 17:41 > > >Till: 'John Leslie'; Ingemar Johansson S > > >Kopia: conex@ietf.org > > >=C4mne: RE: [conex] Off-Topic: Smoothing Variations in BitRate > > > > > > > -----Original Message----- > > > > From: conex-bounces@ietf.org [mailto:conex-bounces@ietf.org] On > > Behalf > > > > Of John Leslie > > > > Sent: 23 June 2010 15:09 > > > > To: Ingemar Johansson S > > > > Cc: conex@ietf.org > > > > Subject: [conex] Off-Topic: Smoothing Variations in BitRate > > > > > > > > Ingemar Johansson S wrote: > > > > > > > > > > Thanks all for taking the time to answer my question. My > > > > interpretation > > > > > of this is that for general internet 0.1 to 0.5% are = reasonable > > > > figures. > > > > > > > > I won't disagree (though I still think 0.5% is high). > > > > > >I think for this discussion we need to clarify exactly what our > > network > > >model is. As I see it there are 3 main models: mobile broadband > which > > I > > >choose to believe is out of charter, DSL or cable > > >[IJ] I believe that it would be unfortunate to > > >exclude mobile broadband. I would believe that > > >wireless access e.g LTE can already provide with > > >a decent fairness mechanisms as each users gets > > >its own queue. The wireless access is however > > >part of the ECN loop and will therefore affect the performance of > > ConEx. > > > > > >In DSL the traffic is heavily aggregated at the DSLAM and then > several > > >DSLAMs will dump their traffic onto IP at a B-RAS. I can easily > > believe > > >congestion at the B-RAS exceeds 0.5% at certain times, at least > > >occasionally. > > > > > >In Cable things may be different, I am not really qualified to > comment > > on > > >it... > > > > > > > > > > > > On the other hand one can perhaps for some dedicated QoS > traffic > > > > > envision a higher "equilibrium rate" ?. If one takes that = video > > > > > streaming case again one can think of a rate control that acts > > > > > according to a function of the ECN rate [ = bitrate=3Df(ECN_rate) ] > > or > > > > > something similar. > > > > > > > > This (IMHO) is clearly outside our charter; but traffic is = low > > > > enough > > > > at the moment that I think we can elaborate a bit before = deciding > > where > > > > this discussion belongs. > > > > > >I agree - out of charter, but no harm in discussing it here > > > > > > > > > > > > My take is that it should be easier to get a smoothly varying > > bitrate > > > > > depending on the congestion situation if the congestion events > > occur > > > > > at a higher frequency. > > > > > > > > Fundamentally, to get smoother variation, the reduction > signaled > > by > > > > an individual ECN-CE mark would need to be less than 50%. This, > > IMHO, > > > > would indeed be reasonable if we agreed somehow to create more = of > > them. > > > > (Unfortunately, setting more CONEX-CE marks isn't likely to = cause > > this, > > > > despite my poorly-worded earlier posting.) > > > > > >I think Ingemar would be well advised to talk to Matt Mathis and = Bob > > Briscoe > > >here... I think this is related to the question of whether the > > congestion > > >controller responds to p or sqrt(p) (where p is the congestion on > the > > path) > > >[IJ] Understood. Need to do some additional homework here after my > > vacation. > > > > > > > > > > > > With a 0.1% equilibrium point the video streaming service will > > likely > > > > > have to resort to TCP like behavior (rate halving) in its > > response > > > > > to the ECN marks. > > > > > > > > Unfortunately, the basic ECN expectation in RFC 3168 is that > an > > > > ECN-CE mark will cause rate halving. > > > > > >Quoting it: > > >" Upon the receipt by an ECN-Capable transport of a single CE > packet, > > > the congestion control algorithms followed at the end-systems > MUST > > be > > > essentially the same as the congestion control response to a > > *single* > > > dropped packet." > > > > > > > > I'm sure Bob Briscoe can answer better than I as to how this > > rate- > > > > halving could be relaxed: I see several possibilities, but they > > seem > > > > to require changes in RFC 3168, and that goes way beyond our > > charter. > > > > > > > > > >This is an issue of transport vs network layers. ECN is at the > network > > layer > > >(as is conex). The appropriate response at the transport layer > depends > > on > > >that transport. If you are a real-time inelastic transport, clearly > > the > > >response is different than if you were a scavenging transport or an > > elastic > > >bulk data transport... > > > > > >Conex is essentially transport-agnostic and I thought the idea is = to > > try and > > >get the whole network to move on from its inherent assumption that > > >everything uses TCP. As long as the network can see how much > > congestion a > > >flow is causing then that flow can respond as it wants. If it is > > causing too > > >much congestion then it runs the risk of being policed in some > > manner... > > > > > > > > > > Nonetheless, our charter calling for implementation in IPv6, > it > > > > seems quite reasonable that IPv6 ECN-marking might not need to = be > > > > limited to the two bits or might be extended somehow to better > > > > accomodate gentler variations in bit-rate. > > > > > >Indeed it would be silly to limit it to 2 bits if there is space = for > > more > > >without increasing the overhead. This is potentially a very rich > vein > > for > > >discussions in its own right, independent of this current = discussion > > > > > >Toby > > > > > > > > > > > -- > > > > John Leslie > > > > _______________________________________________ > > > > conex mailing list > > > > conex@ietf.org > > > > https://www.ietf.org/mailman/listinfo/conex > > > > > >_______________________________________________ > > >conex mailing list > > >conex@ietf.org > > >https://www.ietf.org/mailman/listinfo/conex > > > > ________________________________________________________________ > > Bob Briscoe, BT Innovate & Design >=20 > _______________________________________________ > conex mailing list > conex@ietf.org > https://www.ietf.org/mailman/listinfo/conex From marcelo@it.uc3m.es Wed Jun 30 01:00:47 2010 Return-Path: X-Original-To: conex@core3.amsl.com Delivered-To: conex@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 429503A68A7 for ; Wed, 30 Jun 2010 01:00:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.007 X-Spam-Level: X-Spam-Status: No, score=-103.007 tagged_above=-999 required=5 tests=[BAYES_50=0.001, DATE_IN_PAST_12_24=0.992, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Cex9TSZ0+rFk for ; Wed, 30 Jun 2010 01:00:46 -0700 (PDT) Received: from smtp03.uc3m.es (smtp03.uc3m.es [163.117.176.133]) by core3.amsl.com (Postfix) with ESMTP id B8FE03A63EC for ; Wed, 30 Jun 2010 01:00:45 -0700 (PDT) X-uc3m-safe: yes Received: from marcelo-bagnulos-macbook-pro.local (clcama-adsl.demon.co.uk [62.49.66.1]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by smtp03.uc3m.es (Postfix) with ESMTP id A8E247FD582 for ; Wed, 30 Jun 2010 10:00:55 +0200 (CEST) Message-ID: <4C29C6D3.3070405@it.uc3m.es> Date: Tue, 29 Jun 2010 12:11:31 +0200 From: marcelo bagnulo braun User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.5; es-ES; rv:1.9.1.10) Gecko/20100512 Thunderbird/3.0.5 MIME-Version: 1.0 To: conex@ietf.org Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-TM-AS-Product-Ver: IMSS-7.0.0.3116-6.0.0.1038-17476.003 Subject: [conex] draft-conex-mechanism-00 comments X-BeenThere: conex@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Congestion Exposure working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 30 Jun 2010 08:00:47 -0000 -- I think the document is a good first step, but i am a bit hesitant with making a single document covering the mechanism and the use cases (since our charter explicitly ask us to first wrap up the use cases). I do understnad that some basic understnading of the conex concepts are needed in order to understand the use cases. Besides, i do believe that the current document falls a bit short doing a good job fully describing the mechnisms. I would expect that the mechanism document woul enter in more details about the plicer, the shaper and other pieces that would complete the whole picture. So, my suggestion would be to: keep the content as it is with a short description of the conex concepts (but not grow on the description of the mechinism in this document). Start another doucment where the mechanism can be fully descrived and refer to that document for further details. Rename the document as CONEX concepts and use cases. Change the style to avoid proposing the mechanism here, but rather talking about the conex mechanism in a descriptive manner. Focus on the use cases. -- The CONEX WG charter has focused the work on the use case "where the end hosts and the network that contains the destination end host are CONEX-enabled but other networks need not be." I think the document does cover this use case, but it has not explicitly mentioned that. I think it would be important to note that in the begining of the doucment. Morevoer, i think it is imporntat to explicitly distonguish the cases where it applies. In particular in section 7.1 it would be important to explain a bit more how is this case considered. Maybe some pcitures would help. The text that under the bullet 7. Conex Use Cases seems to be more descriptive of the overall framework rather than the use cases. I would suggest to move it to section 6 (maybe as a subsection) More specific comments Section 7 reads: Distinguishing conex traffic from non-conex traffic: On one level this seems pretty easy -- conex traffic needs to have the downstream congestion field in every packet. However in practise it may not be as simple as this. MB> I don't follow the logic here. Distinguishing the conex traffic from the non conex traffi is easy then. The problem is that it is not obvious what to do with the non-conex traffic correct? If so, please rephrase this to make it clearer. then it follows: implementation of conex. Here the two congestion fields are unary-encoded into a stream of packets by effectively setting or clearing a single bit. Assuming you are able to identify non- conex (or legacy) traffic, then you need to decide what to do about it. An ISP may reasonably choose to do nothing different with this traffic. Alternatively they might incentivise the conex traffic in order to give it marginally better service. MB> but later on in this section you state that non-conex traffic is to be dropped when the congestion allowance is depleted and the non-conex traffic is to be treated as today, so i would suggest to simply remove the above paragraph, since it is simply repeating in a mor obscure way what is being stated later on. MB> Later on in section 7.1 congestion volume is defined. I suggest the definition is moved to section 2 where definitions are. MB> Conex is capitalized conex and ConEx, please use a single capitalization MB> section 7.3 talks about "conex plicers" that have not been defined before. Plese define the term (maybe in section 2?) MB> please change the name to draft-moncaster-conex-use-cases