From lars.eggert@nokia.com Mon Mar 1 07:32:59 2010 Return-Path: X-Original-To: re-ecn@core3.amsl.com Delivered-To: re-ecn@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id A67E428C3AF; Mon, 1 Mar 2010 07:32:59 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.549 X-Spam-Level: X-Spam-Status: No, score=-6.549 tagged_above=-999 required=5 tests=[AWL=0.050, 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 tVE47unKqKge; Mon, 1 Mar 2010 07:32:58 -0800 (PST) Received: from mgw-mx03.nokia.com (smtp.nokia.com [192.100.122.230]) by core3.amsl.com (Postfix) with ESMTP id 246E128C159; Mon, 1 Mar 2010 07:32:57 -0800 (PST) Received: from esebh106.NOE.Nokia.com (esebh106.ntc.nokia.com [172.21.138.213]) by mgw-mx03.nokia.com (Switch-3.3.3/Switch-3.3.3) with ESMTP id o21FWav3024533; Mon, 1 Mar 2010 17:32:56 +0200 Received: from esebh102.NOE.Nokia.com ([172.21.138.183]) by esebh106.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.3959); Mon, 1 Mar 2010 17:32:55 +0200 Received: from mgw-sa02.ext.nokia.com ([147.243.1.48]) by esebh102.NOE.Nokia.com over TLS secured channel with Microsoft SMTPSVC(6.0.3790.3959); Mon, 1 Mar 2010 17:32:55 +0200 Received: from mail.fit.nokia.com (esdhcp030222.research.nokia.com [172.21.30.222]) by mgw-sa02.ext.nokia.com (Switch-3.3.3/Switch-3.3.3) with ESMTP id o21FWse7023399 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 1 Mar 2010 17:32:54 +0200 From: Lars Eggert X-Virus-Status: Clean X-Virus-Scanned: clamav-milter 0.95.3 at fit.nokia.com Mime-Version: 1.0 (Apple Message framework v1077) Content-Type: multipart/signed; boundary=Apple-Mail-13--759928087; protocol="application/pkcs7-signature"; micalg=sha1 Date: Mon, 1 Mar 2010 07:32:44 -0800 References: <88061F01C2B84E8FB392C3CB0F0B96DA@your029b8cecfe> To: "re-ecn@ietf.org list" Message-Id: X-Mailer: Apple Mail (2.1077) X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.2.3 (mail.fit.nokia.com [0.0.0.0]); Mon, 01 Mar 2010 17:32:47 +0200 (EET) X-OriginalArrivalTime: 01 Mar 2010 15:32:55.0861 (UTC) FILETIME=[7703CE50:01CAB954] X-Nokia-AV: Clean Cc: The IESG Subject: [re-ECN] CONEX IESG comments #1 X-BeenThere: re-ecn@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: re-inserted explicit congestion notification List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 01 Mar 2010 15:32:59 -0000 --Apple-Mail-13--759928087 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii Hi, CONEX group, I'm going to forward a few issues that were raised during the IESG = discussion of the charter to the list, and CC the IESG so that the = discussion can happen directly, without me being the bottleneck in the = middle. (I'd like to thank the ADs who wrote up their issues in this way - this = will make it much easier to progress the discussion!) Lars Begin forwarded message: > In no particular order... >=20 > 1. This looks like really interesting research work with a potential = outcome=20 > that could provide substantial benefit. But why is this not proposed = as work=20 > in the IRTF? >=20 > 2. The charter seems to be trying to say that the work will be = Experimental=20 > (which sounds like a grand goal), but fails dismally! I see... > The output of the CONEX WG are Informational and Experimental > documents, apart from work item #2 which is tentatively slated for > Standards Track. Depending on the bits that are proposed to be used > in the IP header and their semantics (e.g., Bit 48 in IPv4, "ECN > Nonce"), there may need to be further Standards Track or = Informational > documents to reassign those bits from their current definitions > (which would be subject to appropriate IESG and IETF review as > necessary). > But #2 is... > Specification of IPv4 and IPv6 packet structures to carry CONEX > information (header bits, interpretation) >=20 > And, in fact, no other documents listed would be appropriate as=20 > Experimental. > Why are the protocol specifications not also listed as Experimental? = If (and=20 > this is clearly not known yet because the protocol specs have not been=20= > written) it is necessary to use some bits, bytes, or codepoints that=20= > currently require standards action, then it would be appropriate to = write a=20 > standards action document to reassign those fields as experimental. = This=20 > document would be distinct from the protocol specification. >=20 > 3. Deployment and usage models > According to the charter, it appears that the deployment and usage = work is=20 > intended to follow on from the protocol specification and BCPs. I feel = that=20 > there is considerable lack of clarity about how/where the proposed=20 > mechanisms would be deployed. That is, it is unclear whether "...any = node=20 > along the network path..." is meant to mean what it says. > - Why is the deployment model not part of the problem spec? > - Is there an assumption that there is IP forwarding at every hop? > - Is there an implication that MPLS extensions will also be developed? > - Can you show some deployment examples? >=20 > 4. ISP support > Somewhat tied to the previous point is the issue I cannot find = supporters in=20 > the operational departments of ISPs. I have been trying, because I = feel it=20 > is important to understand their views. But the most I can get back is = "We=20 > will watch it in case it goes somewhere." Unfortunately, I also hear a = lot=20 > of "Our company does not support this work. We believe it will waste=20= > industry resources and cause confusion. We do not understand how we = could=20 > deploy it within our business model, and have no plans to deploy it." > - Where is the ISP support for this? >=20 > 5. Security > The charter does give a passing nod to the existence of security and = trust=20 > issues. These need to be addressed up front. An architecture that = relies on=20 > ISPs not gaming the system and not lying is critical in this area. The=20= > security and veracity of the information shared will also be critical. > - Where is the security and trust model described? --Apple-Mail-13--759928087 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 MQ8XDTEwMDMwMTE1MzI0NFowIwYJKoZIhvcNAQkEMRYEFNEKzbmFRWw0DSUtDsH/UGMOFtqFMIGF BgkrBgEEAYI3EAQxeDB2MGIxCzAJBgNVBAYTAlpBMSUwIwYDVQQKExxUaGF3dGUgQ29uc3VsdGlu ZyAoUHR5KSBMdGQuMSwwKgYDVQQDEyNUaGF3dGUgUGVyc29uYWwgRnJlZW1haWwgSXNzdWluZyBD QQIQB2OTfqxcpudWfXlLT+pSnTCBhwYLKoZIhvcNAQkQAgsxeKB2MGIxCzAJBgNVBAYTAlpBMSUw IwYDVQQKExxUaGF3dGUgQ29uc3VsdGluZyAoUHR5KSBMdGQuMSwwKgYDVQQDEyNUaGF3dGUgUGVy c29uYWwgRnJlZW1haWwgSXNzdWluZyBDQQIQB2OTfqxcpudWfXlLT+pSnTANBgkqhkiG9w0BAQEF AASCAQBKW0GeBFd3WBIIFNf13hHOe5jdUSzvPuDEBL40s7T525t/8J0OVEzAHA54ca/Ag/3Fe+44 qqCxwQQrDvhyohpHaJCQaW1vckuwwMg1n2rHNXFoqdsmh1USbUKFJvGJkPNXPe+5w1W6GfpTiJkL 1Noy7aHdbwBFpoNBVPsQaBtjprBX59MeUBSFLu3LRkTQYr0zp1u+c9027ZeERRUHEu3miM5zjSkD Ohtt0S//PQ4p8HNoNx6s/KP2m+Fu+3PcZpjte4B44qrdnB7nKr916bzSslO3mAdAMLEkWPO6fHhT FID8yPGvWlKxtClrMokAXiK3PcdoB3NlW82Sso5SLE8GAAAAAAAA --Apple-Mail-13--759928087-- From lars.eggert@nokia.com Mon Mar 1 07:34:07 2010 Return-Path: X-Original-To: re-ecn@core3.amsl.com Delivered-To: re-ecn@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 4503F28C3F4; Mon, 1 Mar 2010 07:34:07 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.556 X-Spam-Level: X-Spam-Status: No, score=-6.556 tagged_above=-999 required=5 tests=[AWL=0.043, 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 lfEvSAK7jP1h; Mon, 1 Mar 2010 07:34:05 -0800 (PST) Received: from mgw-mx06.nokia.com (smtp.nokia.com [192.100.122.233]) by core3.amsl.com (Postfix) with ESMTP id 2088F28C3D9; Mon, 1 Mar 2010 07:34:04 -0800 (PST) Received: from vaebh105.NOE.Nokia.com (vaebh105.europe.nokia.com [10.160.244.31]) by mgw-mx06.nokia.com (Switch-3.3.3/Switch-3.3.3) with ESMTP id o21FXtgJ020901; Mon, 1 Mar 2010 17:34:02 +0200 Received: from vaebh104.NOE.Nokia.com ([10.160.244.30]) by vaebh105.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.3959); Mon, 1 Mar 2010 17:34:01 +0200 Received: from mgw-sa02.ext.nokia.com ([147.243.1.48]) by vaebh104.NOE.Nokia.com over TLS secured channel with Microsoft SMTPSVC(6.0.3790.3959); Mon, 1 Mar 2010 17:33:51 +0200 Received: from mail.fit.nokia.com (esdhcp030222.research.nokia.com [172.21.30.222]) by mgw-sa02.ext.nokia.com (Switch-3.3.3/Switch-3.3.3) with ESMTP id o21FXn2I024737 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 1 Mar 2010 17:33:50 +0200 From: Lars Eggert X-Virus-Status: Clean X-Virus-Scanned: clamav-milter 0.95.3 at fit.nokia.com Mime-Version: 1.0 (Apple Message framework v1077) Content-Type: multipart/signed; boundary=Apple-Mail-14--759870386; protocol="application/pkcs7-signature"; micalg=sha1 Date: Mon, 1 Mar 2010 07:33:41 -0800 References: <4B88F60F.9070908@cisco.com> To: "re-ecn@ietf.org list" Message-Id: <504109EA-8E16-407A-91A0-89AC12FCC30B@nokia.com> X-Mailer: Apple Mail (2.1077) X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.2.3 (mail.fit.nokia.com [0.0.0.0]); Mon, 01 Mar 2010 17:33:43 +0200 (EET) X-OriginalArrivalTime: 01 Mar 2010 15:33:51.0047 (UTC) FILETIME=[97E88570:01CAB954] X-Nokia-AV: Clean Cc: The IESG Subject: [re-ECN] CONEX IESG comments #2 X-BeenThere: re-ecn@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: re-inserted explicit congestion notification List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 01 Mar 2010 15:34:07 -0000 --Apple-Mail-14--759870386 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii Hi, CONEX group, I'm going to forward a few issues that were raised during the IESG = discussion of the charter to the list, and CC the IESG so that the = discussion can happen directly, without me being the bottleneck in the = middle. (I'd like to thank the ADs who wrote up their issues in this way - this = will make it much easier to progress the discussion!) Lars Begin forwarded message: > The charter says: >=20 > "With the output of CONEX, it will be possible to provide sufficient=20= > information in each IP datagram so that any node in the network can = see=20 > the expected rest-of-path congestion." >=20 > With the scope that I heard on the call which was operation at the=20 > provider level, and the suggestion from Jari that this might be = applied=20 > to PWE3, the issue of how to make this work in MPLS has to addressed.=20= > Indeed If the goal is operation at the SP level and PWE3, failure to=20= > find an acceptable MPLS solution would be a showstopper. >=20 > However if the goal is only to provide a solution that operates at = parts=20 > of the network where the packet is visible as IP and this is clearly=20= > stated in the requirements then the work has some merit as an = experiment. >=20 > I agree with Adrian that this work looks experimental and really ought=20= > to be an IRTF project, and only when it has been shown to work = correctly=20 > in an experimental environment should we do the heavy weight = engineering=20 > needed to make this a robust protocol suitable for deployment in the=20= > operational Internet. --Apple-Mail-14--759870386 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 MQ8XDTEwMDMwMTE1MzM0MlowIwYJKoZIhvcNAQkEMRYEFFOOmBWNOfGn3G9SLaUbs+6rS8FPMIGF BgkrBgEEAYI3EAQxeDB2MGIxCzAJBgNVBAYTAlpBMSUwIwYDVQQKExxUaGF3dGUgQ29uc3VsdGlu ZyAoUHR5KSBMdGQuMSwwKgYDVQQDEyNUaGF3dGUgUGVyc29uYWwgRnJlZW1haWwgSXNzdWluZyBD QQIQB2OTfqxcpudWfXlLT+pSnTCBhwYLKoZIhvcNAQkQAgsxeKB2MGIxCzAJBgNVBAYTAlpBMSUw IwYDVQQKExxUaGF3dGUgQ29uc3VsdGluZyAoUHR5KSBMdGQuMSwwKgYDVQQDEyNUaGF3dGUgUGVy c29uYWwgRnJlZW1haWwgSXNzdWluZyBDQQIQB2OTfqxcpudWfXlLT+pSnTANBgkqhkiG9w0BAQEF AASCAQB9JYxaslQz8OkLle6+fWcETbSXRZnTCKf+T8t5GSlUjuyIrTYvqb8I3KcM24C95hPGesly 1jO7oieFgIsQtZBMVrNPWQUSNpSkPgEMKh7sPtrJVhLUjEF+ctl8SIPiEOgKF7Do5Of3R9AWKjUK NgHWoVSpGgaDBQkwMnGq04aZefziRjNxX/gkl+iOJgR53Dk2T+arc8WMp34gskVc0wmjt0IVVs81 t+XKAAvZFjDbMZR+RPBJaWSm3dWJkBDIduJpMm+oNml4btTkJc43YHTb+IEryD4opQ3W4do0+mpq Mr4z77fNzLFGxvgRJsoDvsMY7+aQNuoSzD7AasVWQcKGAAAAAAAA --Apple-Mail-14--759870386-- From matt.mathis@gmail.com Mon Mar 1 12:02:03 2010 Return-Path: X-Original-To: re-ecn@core3.amsl.com Delivered-To: re-ecn@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 44DB828C1B0 for ; Mon, 1 Mar 2010 12:02:03 -0800 (PST) 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 fkxJ66iYVkHa for ; Mon, 1 Mar 2010 12:02:02 -0800 (PST) Received: from mail-bw0-f212.google.com (mail-bw0-f212.google.com [209.85.218.212]) by core3.amsl.com (Postfix) with ESMTP id 5E06028C1A5 for ; Mon, 1 Mar 2010 12:01:20 -0800 (PST) Received: by bwz4 with SMTP id 4so2105850bwz.28 for ; Mon, 01 Mar 2010 12:01:17 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:in-reply-to:references :date:message-id:subject:from:to:cc:content-type :content-transfer-encoding; bh=Su/OEv9vvbQ757MLWwm2iiGjn6R1duET0pI9+xa1TJc=; b=Ux8dRjNuEfUcquQO4qK5rTw4OkcpEEXmksfj3LjKtHIYdlFsh6bJ+wIfOicoQ9MIjw l3fmAn6Yq+bBF7BtyNdWD0VnJsqE7j3Lz1BwxS2g8K6NxOAaDYSLAX2ge02a3YOL4ORq YbcTv07aXwuQDzU/ME98lXrsSXV/iGqznVxi0= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; b=LX8QGDGp43VqSlejzzxMNMJZy5c1T9ZcF3diS5tLdsRLIxlTqC2NrWCqce3mXqHOhR CfuTwr7W7gWdcyfw7KLhq+WZaH/uNuiyzrdRsT/diymvPlYQjabUfPWxlUzHrs1nXNf0 1SGR1xw34BkXoPjxJ9txn1mcEM3v8EYbqDd0c= MIME-Version: 1.0 Received: by 10.204.13.69 with SMTP id b5mr3373380bka.196.1267473677177; Mon, 01 Mar 2010 12:01:17 -0800 (PST) In-Reply-To: References: Date: Mon, 1 Mar 2010 15:01:17 -0500 Message-ID: From: Matt Mathis To: Jason Livingood Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: re-ecn@ietf.org Subject: Re: [re-ECN] Call for Comments: draft-livingood-woundy-congestion-mgmt-03 X-BeenThere: re-ecn@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: re-inserted explicit congestion notification List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 01 Mar 2010 20:02:03 -0000 Interesting draft. What are your plans for it? What do you gain by monitoring the CMTS total load? If you are not near congestion I would not expect BE vs PBE marking to make any difference to the traffic. I did not notice anything in the draft, other than the terminology, that seemed to be DOCSIS or cable specific. The algorithm seems as though it is completely general, and could recast for any technology. Am I correct, or did I overlook something? 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. On Fri, Feb 12, 2010 at 10:38 AM, Jason Livingood wrote: > This is a call for comments on an individual draft regarding a > protocol-agnostic congestion management system, which is related to some = of > the reason that Conex is starting up. =A0I and my co-authors would like > feedback on the latest revision of this draft at > http://tools.ietf.org/html/draft-livingood-woundy-congestion-mgmt-03. > > If you have any comments, please send them to me privately for > consideration. > > Thank you, > Jason > > _______________________________________________ > re-ECN mailing list > re-ECN@ietf.org > https://www.ietf.org/mailman/listinfo/re-ecn > > From richard_woundy@cable.comcast.com Mon Mar 1 17:10:37 2010 Return-Path: X-Original-To: re-ecn@core3.amsl.com Delivered-To: re-ecn@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id A89273A855B for ; Mon, 1 Mar 2010 17:10:37 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -8.463 X-Spam-Level: X-Spam-Status: No, score=-8.463 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_MODEMCABLE=0.768, HOST_EQ_MODEMCABLE=1.368, RCVD_IN_DNSWL_HI=-8] 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 5CBzfQOxdbdu for ; Mon, 1 Mar 2010 17:10:36 -0800 (PST) Received: from pacdcimo01.cable.comcast.com (PacdcIMO01.cable.comcast.com [24.40.8.145]) by core3.amsl.com (Postfix) with ESMTP id 422D13A7AEC for ; Mon, 1 Mar 2010 17:10:36 -0800 (PST) Received: from ([10.52.116.31]) by pacdcimo01.cable.comcast.com with ESMTP id 5503620.73198887; Mon, 01 Mar 2010 20:10:31 -0500 Received: from pacdcexcmb05.cable.comcast.com ([24.40.15.116]) by PAOAKEXCSMTP02.cable.comcast.com with Microsoft SMTPSVC(6.0.3790.3959); Mon, 1 Mar 2010 20:10:31 -0500 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: base64 Date: Mon, 1 Mar 2010 20:09:36 -0500 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: New Version Notification for draft-moncaster-conex-problem-00 Thread-Index: Acq5oULtE1sclHc9Qxm9ZCsjcGGTtwAAjuvQ From: "Woundy, Richard" To: "Leslie Daigle" , "Philip Eardley" X-OriginalArrivalTime: 02 Mar 2010 01:10:31.0724 (UTC) FILETIME=[2784D6C0:01CAB9A5] Cc: re-ecn@ietf.org Subject: [re-ECN] FW: New Version Notification for draft-moncaster-conex-problem-00 X-BeenThere: re-ecn@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: re-inserted explicit congestion notification List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 02 Mar 2010 01:10:38 -0000 TGVzbGllIGFuZCBQaGlsLA0KDQpJIHZvbHVudGVlcmVkIHRvIHRha2Ugb24gdGhlIGVkaXRpbmcg b2YgbW9uY2FzdGVyLWNvbmdlc3Rpb24tZXhwb3N1cmUtcHJvYmxlbS0wMyBmcm9tIFRvYnkgTW9u Y2FzdGVyLiBUbyBlbnN1cmUgdGhhdCB0aGlzIGRyYWZ0IGlzIGZpcm1seSBpZGVudGlmaWVkIHdp dGggdGhlIENvbmV4IHdvcmssIHRoZSBuZXcgZHJhZnQgaXMgY2FsbGVkIGRyYWZ0LW1vbmNhc3Rl ci1jb25leC1wcm9ibGVtLTAwLCA8aHR0cDovL3Rvb2xzLmlldGYub3JnL2h0bWwvZHJhZnQtbW9u Y2FzdGVyLWNvbmV4LXByb2JsZW0tMDA+Lg0KDQpUaGlzIHZlcnNpb24gaW5jbHVkZXMgc29tZSBl ZGl0cyBmcm9tIEJvYiBCcmlzY29lIGFuZCB1cGRhdGVzIHRvIHRoZSByZWZlcmVuY2VzLg0KDQpJ biB0aGUgd29ya3MgZm9yIC0wMSBhcmUgc2lnbmlmaWNhbnQgY2hhbmdlcyBzdWdnZXN0ZWQgYnkg TWljaGFlbCBNZW50aCwgYW5kIChob3BlZnVsbHkpIHNvbWUgaW1wcm92ZW1lbnRzIHRvIHRoZSBV c2UgQ2FzZXMgc2VjdGlvbi4NCg0KSWYgdGhlcmUgYXJlIGFueSBvdGhlciBzdWdnZXN0ZWQgY2hh bmdlcyB0byB0aGlzIGRyYWZ0LCBwbGVhc2Ugc2VuZCB0aGVtIG15IHdheSBhbmQgSSdsbCBkbyBt eSBiZXN0IHRvIGluY29ycG9yYXRlIHRoZW0uIFRoYW5rcy4NCg0KLS0gUmljaA0KDQotLS0tLU9y aWdpbmFsIE1lc3NhZ2UtLS0tLQ0KRnJvbTogSUVURiBJLUQgU3VibWlzc2lvbiBUb29sIFttYWls dG86aWRzdWJtaXNzaW9uQGlldGYub3JnXSANClNlbnQ6IE1vbmRheSwgTWFyY2ggMDEsIDIwMTAg Nzo0MyBQTQ0KVG86IFdvdW5keSwgUmljaGFyZA0KQ2M6IHRvYnkubW9uY2FzdGVyQGJ0LmNvbTsg bG91aXNlLmJ1cm5lc3NAYnQuY29tOyBtZW50aEBpbmZvcm1hdGlrLnVuaS13dWVyemJ1cmcuZGU7 IGouYXJhdWpvQGVlLnVjbC5hYy51azsgc2JsYWtlQGV4dHJlbWVuZXR3b3Jrcy5jb207IFdvdW5k eSwgUmljaGFyZA0KU3ViamVjdDogTmV3IFZlcnNpb24gTm90aWZpY2F0aW9uIGZvciBkcmFmdC1t b25jYXN0ZXItY29uZXgtcHJvYmxlbS0wMCANCg0KDQpBIG5ldyB2ZXJzaW9uIG9mIEktRCwgZHJh ZnQtbW9uY2FzdGVyLWNvbmV4LXByb2JsZW0tMDAudHh0IGhhcyBiZWVuIHN1Y2Nlc3NmdWx5IHN1 Ym1pdHRlZCBieSBSaWNoYXJkIFdvdW5keSBhbmQgcG9zdGVkIHRvIHRoZSBJRVRGIHJlcG9zaXRv cnkuDQoNCkZpbGVuYW1lOgkgZHJhZnQtbW9uY2FzdGVyLWNvbmV4LXByb2JsZW0NClJldmlzaW9u OgkgMDANClRpdGxlOgkJIFRoZSBOZWVkIGZvciBDb25nZXN0aW9uIEV4cG9zdXJlIGluIHRoZSBJ bnRlcm5ldA0KQ3JlYXRpb25fZGF0ZToJIDIwMTAtMDMtMDENCldHIElEOgkJIEluZGVwZW5kZW50 IFN1Ym1pc3Npb24NCk51bWJlcl9vZl9wYWdlczogMjINCg0KQWJzdHJhY3Q6DQpUb2RheSdzIElu dGVybmV0IGlzIGEgcHJvZHVjdCBvZiBpdHMgaGlzdG9yeS4gIFRDUCBpcyB0aGUgbWFpbg0KdHJh bnNwb3J0IHByb3RvY29sIHJlc3BvbnNpYmxlIGZvciBzaGFyaW5nIG91dCBiYW5kd2lkdGggYW5k DQpwcmV2ZW50aW5nIGEgcmVjdXJyZW5jZSBvZiBjb25nZXN0aW9uIGNvbGxhcHNlIHdoaWxlIHBh Y2tldCBkcm9wIGlzDQp0aGUgcHJpbWFyeSBzaWduYWwgb2YgY29uZ2VzdGlvbiBhdCBib3R0bGVu ZWNrcy4gIFNpbmNlIHBhY2tldCBkcm9wDQooYW5kIGluY3JlYXNlZCBkZWxheSkgaW1wYWN0cyBh bGwgdGhlaXIgY3VzdG9tZXJzIG5lZ2F0aXZlbHksIG5ldHdvcmsNCm9wZXJhdG9ycyB3b3VsZCBs aWtlIHRvIGJlIGFibGUgdG8gZGlzdGluZ3Vpc2ggYmV0d2VlbiBvdmVybHkNCmFnZ3Jlc3NpdmUg Y29uZ2VzdGlvbiBjb250cm9sIGFuZCBhIGNvbmZsdWVuY2Ugb2YgbWFueSBsb3ctYmFuZHdpZHRo LA0KbG93LWltcGFjdCBmbG93cy4gIEJ1dCB0aGV5IGFyZSB1bmFibGUgdG8gc2VlIHRoZSBhY3R1 YWwgY29uZ2VzdGlvbg0Kc2lnbmFsIGFuZCB0aHVzLCB0aGV5IGhhdmUgdG8gaW1wbGVtZW50IGJh bmR3aWR0aCBhbmQvb3IgdXNhZ2UgbGltaXRzDQpiYXNlZCBvbiB0aGUgb25seSBpbmZvcm1hdGlv biB0aGV5IGNhbiBzZWUgb3IgbWVhc3VyZSAodGhlIGNvbnRlbnRzDQpvZiB0aGUgcGFja2V0IGhl YWRlcnMgYW5kIHRoZSByYXRlIG9mIHRoZSB0cmFmZmljKS4gIFN1Y2ggbWVhc3VyZXMNCmRvbid0 IHNvbHZlIHRoZSBwYWNrZXQtZHJvcCBwcm9ibGVtcyBlZmZlY3RpdmVseSBhbmQgYXJlIGxlYWRp bmcgdG8NCmNhbGxzIGZvciBnb3Zlcm5tZW50IHJlZ3VsYXRpb24gKHdoaWNoIGFsc28gd29uJ3Qg c29sdmUgdGhlIHByb2JsZW0pLg0KDQpXZSBwcm9wb3NlIGNvbmdlc3Rpb24gZXhwb3N1cmUgYXMg YSBwb3NzaWJsZSBzb2x1dGlvbi4gIFRoaXMgYWxsb3dzDQpwYWNrZXRzIHRvIGNhcnJ5IGFuIGFj Y3VyYXRlIHByZWRpY3Rpb24gb2YgdGhlIGNvbmdlc3Rpb24gdGhleSBleHBlY3QNCnRvIGNhdXNl IGRvd25zdHJlYW0gdGh1cyBhbGxvd2luZyBpdCB0byBiZSB2aXNpYmxlIHRvIElTUHMgYW5kDQpu ZXR3b3JrIG9wZXJhdG9ycy4gIFRoaXMgbWVtbyBzZXRzIG91dCB0aGUgbW90aXZhdGlvbnMgZm9y IGNvbmdlc3Rpb24NCmV4cG9zdXJlIGFuZCBpbnRyb2R1Y2VzIGEgc3RyYXdtYW4gcHJvdG9jb2wg ZGVzaWduZWQgdG8gYWNoaWV2ZQ0KY29uZ2VzdGlvbiBleHBvc3VyZS4NCiAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICANCg0KDQpUaGUgSUVURiBTZWNyZXRhcmlhdC4NCg0KDQo= From leslie@thinkingcat.com Mon Mar 1 17:17:56 2010 Return-Path: X-Original-To: re-ecn@core3.amsl.com Delivered-To: re-ecn@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 4B2EE28C0EB for ; Mon, 1 Mar 2010 17:17:56 -0800 (PST) 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 HmMG5WGplCBE for ; Mon, 1 Mar 2010 17:17:55 -0800 (PST) Received: from zeke.ecotroph.net (zeke.ecotroph.net [70.164.19.155]) by core3.amsl.com (Postfix) with ESMTP id 565A83A85C5 for ; Mon, 1 Mar 2010 17:17:55 -0800 (PST) Received: from beethoven.local ([::ffff:173.71.206.39]) (AUTH: PLAIN leslie, SSL: TLSv1/SSLv3,256bits,AES256-SHA) by zeke.ecotroph.net with esmtp; Mon, 01 Mar 2010 20:17:51 -0500 id 015B0087.4B8C673F.00005335 Message-ID: <4B8C6735.30201@thinkingcat.com> Date: Mon, 01 Mar 2010 20:17:41 -0500 From: Leslie Daigle User-Agent: Thunderbird 2.0.0.23 (Macintosh/20090812) MIME-Version: 1.0 To: "Woundy, Richard" References: In-Reply-To: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Cc: re-ecn@ietf.org Subject: Re: [re-ECN] FW: New Version Notification for draft-moncaster-conex-problem-00 X-BeenThere: re-ecn@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: re-inserted explicit congestion notification List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 02 Mar 2010 01:17:56 -0000 Thanks, Rich. Will have a look. Leslie. Woundy, Richard wrote: > Leslie and Phil, > > I volunteered to take on the editing of moncaster-congestion-exposure-problem-03 from Toby Moncaster. To ensure that this draft is firmly identified with the Conex work, the new draft is called draft-moncaster-conex-problem-00, . > > This version includes some edits from Bob Briscoe and updates to the references. > > In the works for -01 are significant changes suggested by Michael Menth, and (hopefully) some improvements to the Use Cases section. > > If there are any other suggested changes to this draft, please send them my way and I'll do my best to incorporate them. Thanks. > > -- Rich > > -----Original Message----- > From: IETF I-D Submission Tool [mailto:idsubmission@ietf.org] > Sent: Monday, March 01, 2010 7:43 PM > To: Woundy, Richard > Cc: toby.moncaster@bt.com; louise.burness@bt.com; menth@informatik.uni-wuerzburg.de; j.araujo@ee.ucl.ac.uk; sblake@extremenetworks.com; Woundy, Richard > Subject: New Version Notification for draft-moncaster-conex-problem-00 > > > A new version of I-D, draft-moncaster-conex-problem-00.txt has been successfuly submitted by Richard Woundy and posted to the IETF repository. > > Filename: draft-moncaster-conex-problem > Revision: 00 > Title: The Need for Congestion Exposure in the Internet > Creation_date: 2010-03-01 > WG ID: Independent Submission > Number_of_pages: 22 > > Abstract: > Today's Internet is a product of its history. TCP is the main > transport protocol responsible for sharing out bandwidth and > preventing a recurrence of congestion collapse while packet drop is > the primary signal of congestion at bottlenecks. Since packet drop > (and increased delay) impacts all their customers negatively, network > operators would like to be able to distinguish between overly > aggressive congestion control and a confluence of many low-bandwidth, > low-impact flows. But they are unable to see the actual congestion > signal and thus, they have to implement bandwidth and/or usage limits > based on the only information they can see or measure (the contents > of the packet headers and the rate of the traffic). Such measures > don't solve the packet-drop problems effectively and are leading to > calls for government regulation (which also won't solve the problem). > > We propose congestion exposure as a possible solution. This allows > packets to carry an accurate prediction of the congestion they expect > to cause downstream thus allowing it to be visible to ISPs and > network operators. This memo sets out the motivations for congestion > exposure and introduces a strawman protocol designed to achieve > congestion exposure. > > > > The IETF Secretariat. > > -- ------------------------------------------------------------------- "Reality: Yours to discover." -- ThinkingCat Leslie Daigle leslie@thinkingcat.com ------------------------------------------------------------------- From rbriscoe@jungle.bt.co.uk Tue Mar 2 02:11:57 2010 Return-Path: X-Original-To: re-ecn@core3.amsl.com Delivered-To: re-ecn@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id F299928C0D0 for ; Tue, 2 Mar 2010 02:11:56 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.117 X-Spam-Level: X-Spam-Status: No, score=-2.117 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, DNS_FROM_RFC_BOGUSMX=1.482, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id KQjYg7sKY0rb for ; Tue, 2 Mar 2010 02:11:47 -0800 (PST) Received: from smtp3.smtp.bt.com (smtp3.smtp.bt.com [217.32.164.138]) by core3.amsl.com (Postfix) with ESMTP id 6DF0D3A8319 for ; Tue, 2 Mar 2010 02:11:47 -0800 (PST) Received: from i2kc06-ukbr.domain1.systemhost.net ([193.113.197.70]) by smtp3.smtp.bt.com with Microsoft SMTPSVC(6.0.3790.3959); Tue, 2 Mar 2010 10:11:46 +0000 Received: from cbibipnt05.iuser.iroot.adidom.com ([147.149.196.177]) by i2kc06-ukbr.domain1.systemhost.net with Microsoft SMTPSVC(6.0.3790.3959); Tue, 2 Mar 2010 10:11:47 +0000 Received: From bagheera.jungle.bt.co.uk ([132.146.168.158]) by cbibipnt05.iuser.iroot.adidom.com (WebShield SMTP v4.5 MR1a P0803.399); id 1267524706123; Tue, 2 Mar 2010 10:11:46 +0000 Received: from MUT.jungle.bt.co.uk ([10.73.97.204]) by bagheera.jungle.bt.co.uk (8.13.5/8.12.8) with ESMTP id o22ABgkG007266; Tue, 2 Mar 2010 10:11:43 GMT Message-Id: <201003021011.o22ABgkG007266@bagheera.jungle.bt.co.uk> X-Mailer: QUALCOMM Windows Eudora Version 7.1.0.9 Date: Tue, 02 Mar 2010 10:11:46 +0000 To: Leslie Daigle From: Bob Briscoe In-Reply-To: <4B8C6735.30201@thinkingcat.com> References: <4B8C6735.30201@thinkingcat.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-Scanned-By: MIMEDefang 2.56 on 132.146.168.158 X-OriginalArrivalTime: 02 Mar 2010 10:11:47.0098 (UTC) FILETIME=[C459A7A0:01CAB9F0] Cc: "Woundy, Richard" , re-ecn@ietf.org Subject: Re: [re-ECN] FW: New Version Notification for draft-moncaster-conex-problem-00 X-BeenThere: re-ecn@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: re-inserted explicit congestion notification List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 02 Mar 2010 10:11:58 -0000 Leslie, Currently both the old -03 and the new -00 are live, because of the name change, which is confusing. Am I correct that a chair can link a name change to the previous name? So that if people access the old draft, it points to the new. Or is this only for WG docs? In the mean time, I've updated the link to this doc on the Wiki: Bob At 01:17 02/03/2010, Leslie Daigle wrote: >Thanks, Rich. Will have a look. > >Leslie. > > >Woundy, Richard wrote: >>Leslie and Phil, >>I volunteered to take on the editing of >>moncaster-congestion-exposure-problem-03 from Toby Moncaster. To >>ensure that this draft is firmly identified with the Conex work, >>the new draft is called draft-moncaster-conex-problem-00, >>. >>This version includes some edits from Bob Briscoe and updates to >>the references. >>In the works for -01 are significant changes suggested by Michael >>Menth, and (hopefully) some improvements to the Use Cases section. >>If there are any other suggested changes to this draft, please send >>them my way and I'll do my best to incorporate them. Thanks. >>-- Rich >>-----Original Message----- >>From: IETF I-D Submission Tool [mailto:idsubmission@ietf.org] Sent: >>Monday, March 01, 2010 7:43 PM >>To: Woundy, Richard >>Cc: toby.moncaster@bt.com; louise.burness@bt.com; >>menth@informatik.uni-wuerzburg.de; j.araujo@ee.ucl.ac.uk; >>sblake@extremenetworks.com; Woundy, Richard >>Subject: New Version Notification for draft-moncaster-conex-problem-00 >>A new version of I-D, draft-moncaster-conex-problem-00.txt has been >>successfuly submitted by Richard Woundy and posted to the IETF repository. >>Filename: draft-moncaster-conex-problem >>Revision: 00 >>Title: The Need for Congestion Exposure in the Internet >>Creation_date: 2010-03-01 >>WG ID: Independent Submission >>Number_of_pages: 22 >>Abstract: >>Today's Internet is a product of its history. TCP is the main >>transport protocol responsible for sharing out bandwidth and >>preventing a recurrence of congestion collapse while packet drop is >>the primary signal of congestion at bottlenecks. Since packet drop >>(and increased delay) impacts all their customers negatively, network >>operators would like to be able to distinguish between overly >>aggressive congestion control and a confluence of many low-bandwidth, >>low-impact flows. But they are unable to see the actual congestion >>signal and thus, they have to implement bandwidth and/or usage limits >>based on the only information they can see or measure (the contents >>of the packet headers and the rate of the traffic). Such measures >>don't solve the packet-drop problems effectively and are leading to >>calls for government regulation (which also won't solve the problem). >>We propose congestion exposure as a possible solution. This allows >>packets to carry an accurate prediction of the congestion they expect >>to cause downstream thus allowing it to be visible to ISPs and >>network operators. This memo sets out the motivations for congestion >>exposure and introduces a strawman protocol designed to achieve >>congestion exposure. >> >> >> >>The IETF Secretariat. > >-- > >------------------------------------------------------------------- >"Reality: > Yours to discover." > -- ThinkingCat >Leslie Daigle >leslie@thinkingcat.com >------------------------------------------------------------------- >_______________________________________________ >re-ECN mailing list >re-ECN@ietf.org >https://www.ietf.org/mailman/listinfo/re-ecn ________________________________________________________________ Bob Briscoe, BT Innovate & Design From hannes.tschofenig@nsn.com Tue Mar 2 05:45:15 2010 Return-Path: X-Original-To: re-ecn@core3.amsl.com Delivered-To: re-ecn@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id ED4643A8926 for ; Tue, 2 Mar 2010 05:45:15 -0800 (PST) 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=[AWL=0.000, 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 Xz-JRzezL9c4 for ; Tue, 2 Mar 2010 05:45:15 -0800 (PST) Received: from demumfd002.nsn-inter.net (demumfd002.nsn-inter.net [93.183.12.31]) by core3.amsl.com (Postfix) with ESMTP id C76BF3A8692 for ; Tue, 2 Mar 2010 05:45:14 -0800 (PST) Received: from demuprx017.emea.nsn-intra.net ([10.150.129.56]) by demumfd002.nsn-inter.net (8.12.11.20060308/8.12.11) with ESMTP id o22DjBlj027428 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL) for ; Tue, 2 Mar 2010 14:45:14 +0100 Received: from demuexc022.nsn-intra.net (demuexc022.nsn-intra.net [10.150.128.35]) by demuprx017.emea.nsn-intra.net (8.12.11.20060308/8.12.11) with ESMTP id o22DjBuC030780 for ; Tue, 2 Mar 2010 14:45:11 +0100 Received: from FIESEXC015.nsn-intra.net ([10.159.0.23]) by demuexc022.nsn-intra.net with Microsoft SMTPSVC(6.0.3790.3959); Tue, 2 Mar 2010 14:45:11 +0100 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Tue, 2 Mar 2010 15:44:34 +0200 Message-ID: <3D3C75174CB95F42AD6BCC56E5555B4502424066@FIESEXC015.nsn-intra.net> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: draft-tschofenig-conex-ps and our recommendation for the group Thread-Index: Acq6Dn5VrHNVokBnRna+e5jhfBaX6g== From: "Tschofenig, Hannes (NSN - FI/Espoo)" To: X-OriginalArrivalTime: 02 Mar 2010 13:45:11.0510 (UTC) FILETIME=[945FDF60:01CABA0E] Subject: [re-ECN] draft-tschofenig-conex-ps and our recommendation for the group X-BeenThere: re-ecn@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: re-inserted explicit congestion notification List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 02 Mar 2010 13:45:16 -0000 Hi all,=20 we wanted to provide a bit of details of why Alissa and I worked on draft-tschofenig-conex-ps.=20 Our goal for the problem statement document was=20 1) to offer a writeup that does not talk about the solution 2) to focus on one aspect of the perceived problem only.=20 =20 While there may be the other problems problems out there that a specific solution can solve (e.g. denial of service attacks, trouble-shooting of network problems) we really think that one needs to focus on one thing at the time because otherwise you run into what I call the HIP-effect(*). The problem needs to be well understood and documented before one can go forward with the next step. The lack of a clear problem statement discussion was for me recognizable at the BOF. Once people agree on the problem then it is interesting to capture the state of the art as far as what tools operators are already using to solve the problem. Since a number of operator believe they have a problem there is a wide range of solutions they are deploying today. The excellent writeup by Jason and Ric (see draft-livingood-woundy-congestion-mgmt) is one example of a solution that offers very interesting properties already (such as being protocol agnostic). There are other solution approaches that other operators are deploying but they are less well documented. Every solution has pros and cons and, from what we can tell, there is no one-size fits all approach. Unfortunately, we have not seen a lot of discussions about what is being done and why the group considers them as insufficient. This leads to the next point, namely to document what is not good enough with the available techniques. If there is a specific problem identified, and the inadequacies of the existing solutions are compelling, that argues that there is space for new work in this area. So, in a summary we would suggest the following approach and this is also the approach we will try to take as we rev our problem statement (although there will certainly still be gaps), and there are some elements of it in the draft-moncaster problem statement, but we wanted to frame the thought process before posting a new version: A) Figure out whether most people agree to a description of the problem. (There may be multiple sub-problems.) B) Document the state-of-the-art (and why people have chosen a certain approaches). C) Document the gaps that are not covered by state-of-the-art solutions that would require additional work. For me a really important question is what are the incentives for someone to deploy anything in addition to draft-livingood-woundy-congestion-mgmt? There are other ways to approach the topic but we believe that this is the appropriate way in this case. Ciao Hannes & Alissa (*): A solution that solves all problems but none really well.=20 From rbriscoe@jungle.bt.co.uk Wed Mar 3 08:23:24 2010 Return-Path: X-Original-To: re-ecn@core3.amsl.com Delivered-To: re-ecn@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 5CF8328C136 for ; Wed, 3 Mar 2010 08:23:21 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.117 X-Spam-Level: X-Spam-Status: No, score=-2.117 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, DNS_FROM_RFC_BOGUSMX=1.482, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id OkuHEbpEBUhy for ; Wed, 3 Mar 2010 08:23:00 -0800 (PST) Received: from smtp3.smtp.bt.com (smtp3.smtp.bt.com [217.32.164.138]) by core3.amsl.com (Postfix) with ESMTP id B24A83A8B87 for ; Wed, 3 Mar 2010 08:22:59 -0800 (PST) Received: from i2kc08-ukbr.domain1.systemhost.net ([193.113.197.71]) by smtp3.smtp.bt.com with Microsoft SMTPSVC(6.0.3790.3959); Wed, 3 Mar 2010 16:22:59 +0000 Received: from cbibipnt08.iuser.iroot.adidom.com ([147.149.100.81]) by i2kc08-ukbr.domain1.systemhost.net with Microsoft SMTPSVC(6.0.3790.3959); Wed, 3 Mar 2010 16:22:59 +0000 Received: From bagheera.jungle.bt.co.uk ([132.146.168.158]) by cbibipnt08.iuser.iroot.adidom.com (WebShield SMTP v4.5 MR1a P0803.399); id 1267633378857; Wed, 3 Mar 2010 16:22:58 +0000 Received: from MUT.jungle.bt.co.uk ([10.215.130.87]) by bagheera.jungle.bt.co.uk (8.13.5/8.12.8) with ESMTP id o23GMuIE004096; Wed, 3 Mar 2010 16:22:56 GMT Message-Id: <201003031622.o23GMuIE004096@bagheera.jungle.bt.co.uk> X-Mailer: QUALCOMM Windows Eudora Version 7.1.0.9 Date: Wed, 03 Mar 2010 16:23:00 +0000 To: "Tschofenig, Hannes (NSN - FI/Espoo)" From: Bob Briscoe In-Reply-To: <3D3C75174CB95F42AD6BCC56E5555B4502424066@FIESEXC015.nsn-in tra.net> References: <3D3C75174CB95F42AD6BCC56E5555B4502424066@FIESEXC015.nsn-intra.net> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-Scanned-By: MIMEDefang 2.56 on 132.146.168.158 X-OriginalArrivalTime: 03 Mar 2010 16:22:59.0491 (UTC) FILETIME=[CA24DF30:01CABAED] Cc: re-ecn@ietf.org Subject: Re: [re-ECN] draft-tschofenig-conex-ps and our recommendation for the group X-BeenThere: re-ecn@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: re-inserted explicit congestion notification List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 03 Mar 2010 16:23:24 -0000 Hannes, Yes, I could see what you were trying to do with that draft. I'd like draft-tschofenig-conex-ps a lot more if it talked about traffic-management in general rather than p2p-traffic-management. I know you wanted to be very specific, but p2p was too specific. Talking only about p2p causes allergic reactions depending on what the reader's interests are. There's the same problem with video traffic - who decides which traffic isn't worth providing capacity for? Sally Floyd taught me well about solutions that solve all problems but none really well (what you call the HIP effect, but I don't like that association - it may be perjorative ;) I don't think re-ECN has a jack-of-all-trades-master-of-none problem. It has the problem that people find it difficult to imagine know how much better the Internet could be. This is better described as the "80-20 problem". But if you have a hack that solves 80% of the problem, what if it actually only solves 40% or 60% of the problem longer term - because we don't have a good handle on how broad the problem will really be in the future? The classic example is NATs. They seemed to solve 80% of the addressing problem when they were first deployed, but they have prevented a lot of other things happening - ie. how we define what is included in 100% of the problem determines whether we've solved 80% or only 10%. Similarly, some might say DPI solves 80% of the traffic management problem, but it has created other undesirable interactions. DPI doesn't encourage mutual co-operation between willing transports - so does it really solve 80% or 30% or 10%? I thought draft-moncaster-conex-problem hit about the right spot - it focuses on the problem of accountability for causing congestion. Admittedly, it mentions some other things ConEx could solve, but it keeps focus on the one problem fairly well. Incidentally, Rich Woundy has done a presentation on what additional benefits re-ECN would provide over ComCast's solution: It's under the link to all the speaker presentations in the article here: Specifically: HTH Bob At 13:44 02/03/2010, Tschofenig, Hannes (NSN - FI/Espoo) wrote: >Hi all, > >we wanted to provide a bit of details of why Alissa and I worked on >draft-tschofenig-conex-ps. > >Our goal for the problem statement document was >1) to offer a writeup that does not talk about the solution >2) to focus on one aspect of the perceived problem only. > >While there may be the other problems problems out there that a specific >solution can solve (e.g. denial of service attacks, trouble-shooting of >network problems) we really think that one needs to focus on one thing >at the time because otherwise you run into what I call the >HIP-effect(*). > >The problem needs to be well understood and documented before one can go >forward with the next step. The lack of a clear problem statement >discussion was for me recognizable at the BOF. > >Once people agree on the problem then it is interesting to capture the >state of the art as far as what tools operators are already using to >solve the problem. Since a number of operator believe they have a >problem there is a wide range of solutions they are deploying today. The >excellent writeup by Jason and Ric (see >draft-livingood-woundy-congestion-mgmt) is one example of a solution >that offers very interesting properties already (such as being protocol >agnostic). There are other solution approaches that other operators are >deploying but they are less well documented. Every solution has pros and >cons and, from what we can tell, there is no one-size fits all approach. > > >Unfortunately, we have not seen a lot of discussions about what is being >done and why the group considers them as insufficient. This leads to the >next point, namely to document what is not good enough with the >available techniques. If there is a specific problem identified, and the >inadequacies of the existing solutions are compelling, that argues that >there is space for new work in this area. > >So, in a summary we would suggest the following approach and this is >also the approach we will try to take as we rev our problem statement >(although there will certainly still be gaps), and there are some >elements of it in the draft-moncaster problem statement, but we wanted >to frame the thought process before posting a new version: > >A) Figure out whether most people agree to a description of the problem. > >(There may be multiple sub-problems.) > >B) Document the state-of-the-art (and why people have chosen a certain >approaches). > >C) Document the gaps that are not covered by state-of-the-art solutions >that would require additional work. For me a really important question >is what are the incentives for someone to deploy anything in addition to >draft-livingood-woundy-congestion-mgmt? > >There are other ways to approach the topic but we believe that this is >the appropriate way in this case. > >Ciao >Hannes & Alissa > >(*): A solution that solves all problems but none really well. > >_______________________________________________ >re-ECN mailing list >re-ECN@ietf.org >https://www.ietf.org/mailman/listinfo/re-ecn ________________________________________________________________ Bob Briscoe, BT Innovate & Design From philip.eardley@bt.com Wed Mar 3 10:41:24 2010 Return-Path: X-Original-To: re-ecn@core3.amsl.com Delivered-To: re-ecn@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 601E63A8BCC; Wed, 3 Mar 2010 10:41:24 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.449 X-Spam-Level: X-Spam-Status: No, score=-3.449 tagged_above=-999 required=5 tests=[AWL=0.150, 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 5jnznnxl-QfW; Wed, 3 Mar 2010 10:41:23 -0800 (PST) Received: from smtp3.smtp.bt.com (smtp3.smtp.bt.com [217.32.164.138]) by core3.amsl.com (Postfix) with ESMTP id 334383A8A91; Wed, 3 Mar 2010 10:41:22 -0800 (PST) Received: from E03MVB1-UKBR.domain1.systemhost.net ([193.113.197.110]) by smtp3.smtp.bt.com with Microsoft SMTPSVC(6.0.3790.3959); Wed, 3 Mar 2010 18:41:23 +0000 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Wed, 3 Mar 2010 18:41:23 -0000 Message-ID: <4A916DBC72536E419A0BD955EDECEDEC06363E71@E03MVB1-UKBR.domain1.systemhost.net> In-Reply-To: <504109EA-8E16-407A-91A0-89AC12FCC30B@nokia.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [re-ECN] CONEX IESG comments #2 thread-index: Acq5VUiM9p83PqJ9RE2SRRvyimF/rgBls6Nw From: To: , X-OriginalArrivalTime: 03 Mar 2010 18:41:23.0380 (UTC) FILETIME=[1FA5C740:01CABB01] Cc: iesg@ietf.org Subject: Re: [re-ECN] CONEX IESG comments #2 X-BeenThere: re-ecn@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: re-inserted explicit congestion notification List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 03 Mar 2010 18:41:24 -0000 Thanks for your commets and also in Comments #1. We think the best thing is if we work on the mailing list to put together a consolidated reply to the comments, which we will then send to the iesg. Hopefully a good timing for this would be over the next 2 weeks, ie reply before the ietf. Thanks Phil & Leslie > -----Original Message----- > From: re-ecn-bounces@ietf.org=20 > [mailto:re-ecn-bounces@ietf.org] On Behalf Of Lars Eggert > Sent: 01 March 2010 15:34 > To: re-ecn@ietf.org list > Cc: The IESG > Subject: [re-ECN] CONEX IESG comments #2 >=20 >=20 > Hi, CONEX group, >=20 > I'm going to forward a few issues that were raised during the=20 > IESG discussion of the charter to the list, and CC the IESG=20 > so that the discussion can happen directly, without me being=20 > the bottleneck in the middle. >=20 > (I'd like to thank the ADs who wrote up their issues in this=20 > way - this will make it much easier to progress the discussion!) >=20 > Lars >=20 > Begin forwarded message: > > The charter says: > >=20 > > "With the output of CONEX, it will be possible to provide sufficient > > information in each IP datagram so that any node in the=20 > network can see=20 > > the expected rest-of-path congestion." > >=20 > > With the scope that I heard on the call which was operation at the > > provider level, and the suggestion from Jari that this=20 > might be applied=20 > > to PWE3, the issue of how to make this work in MPLS has to=20 > addressed.=20 > > Indeed If the goal is operation at the SP level and PWE3,=20 > failure to=20 > > find an acceptable MPLS solution would be a showstopper. > >=20 > > However if the goal is only to provide a solution that operates at=20 > > parts > > of the network where the packet is visible as IP and this=20 > is clearly=20 > > stated in the requirements then the work has some merit as=20 > an experiment. > >=20 > > I agree with Adrian that this work looks experimental and=20 > really ought > > to be an IRTF project, and only when it has been shown to=20 > work correctly=20 > > in an experimental environment should we do the heavy=20 > weight engineering=20 > > needed to make this a robust protocol suitable for=20 > deployment in the=20 > > operational Internet. >=20 >=20 From jason_livingood@cable.comcast.com Wed Mar 3 16:24:05 2010 Return-Path: X-Original-To: re-ecn@core3.amsl.com Delivered-To: re-ecn@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id DFFE23A89D8 for ; Wed, 3 Mar 2010 16:24:05 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.604 X-Spam-Level: * X-Spam-Status: No, score=1.604 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_MODEMCABLE=0.768, HOST_EQ_MODEMCABLE=1.368, RCVD_NUMERIC_HELO=2.067] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id zMYr2l5Jq5Ip for ; Wed, 3 Mar 2010 16:24:04 -0800 (PST) Received: from paoakoavas09.cable.comcast.com (paoakoavas09.cable.comcast.com [208.17.35.58]) by core3.amsl.com (Postfix) with ESMTP id 681043A85B5 for ; Wed, 3 Mar 2010 16:24:01 -0800 (PST) Received: from ([24.40.15.92]) by paoakoavas09.cable.comcast.com with ESMTP id KP-NTF18.87945358; Wed, 03 Mar 2010 19:23:45 -0500 Received: from PACDCEXCMB04.cable.comcast.com ([24.40.15.86]) by PACDCEXCSMTP03.cable.comcast.com with Microsoft SMTPSVC(6.0.3790.3959); Wed, 3 Mar 2010 19:23:46 -0500 Received: from 207.228.237.150 ([207.228.237.150]) by PACDCEXCMB04.cable.comcast.com ([24.40.15.86]) via Exchange Front-End Server webmail.comcast.com ([24.40.8.152]) with Microsoft Exchange Server HTTP-DAV ; Thu, 4 Mar 2010 00:23:46 +0000 User-Agent: Microsoft-Entourage/12.23.0.091001 Date: Wed, 03 Mar 2010 19:23:29 -0500 From: Jason Livingood To: Matt Mathis Message-ID: Thread-Topic: [re-ECN] Call for Comments: draft-livingood-woundy-congestion-mgmt-03 Thread-Index: Acq7MOneRiXF2WI3q0+olh46AbdutA== In-Reply-To: Mime-version: 1.0 Content-type: text/plain; charset="ISO-8859-1" Content-transfer-encoding: quoted-printable X-OriginalArrivalTime: 04 Mar 2010 00:23:46.0914 (UTC) FILETIME=[F48C4C20:01CABB30] Cc: re-ecn@ietf.org Subject: Re: [re-ECN] Call for Comments: draft-livingood-woundy-congestion-mgmt-03 X-BeenThere: re-ecn@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: re-inserted explicit congestion notification List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 04 Mar 2010 00:24:06 -0000 Thanks for your response Matt (and for reading the draft of course). Some replies inline below. On 3/1/10 3:01 PM, "Matt Mathis" wrote: > Interesting draft. What are your plans for it? Heck if I know! ;-) Just kidding. We have the system in production for a little over a year and a quarter now, so soliciting comments on the overall design continues to be interesting to us and helps improve it. I'd also like to see it become an informational RFC at some point. First off, that provides a stable and easily consumable reference point for the document an= d it can be a reference in related work at the IETF. =20 > What do you gain by monitoring the CMTS total load? We actually monitor individual upstream and downstream ports on the CMTS (I'll have to re-read the relevant sections to ensure I'm communicating tha= t the best I can). That enables us to detect when a particular segment of th= e network is approaching a time of possible congestion. So we use it as an early warning system of sorts, at which point we proactively mark some traffic with a lower best effort QoS so that if congestion does actually occur we are prepared in advance (as compared to doing such analysis & action at that time precise of congestion, which is hard to get right). > If you are not > near congestion I would not expect BE vs PBE marking to make any > difference to the traffic. =20 Correct. It is only at times of actual congestion that BE vs PBE has any effect whatsoever. =20 > I did not notice anything in the draft, other than the terminology, > that seemed to be DOCSIS or cable specific. The algorithm seems as > though it is completely general, and could recast for any technology. > Am I correct, or did I overlook something? I think that is a fair conclusion to reach. We've gotten a few questions from parties involved in operating or supplying operators of different network types, and as we've explained the system it is apparent to us that it is a generalized system (it was not really apparent at first, but we wer= e thinking only of how to solve our problem initially). In the next version of the I-D I will probably add a section describing the applicability of th= e system to other access network technologies and indeed to other network segments other than just the last mile portion. >=20 > 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. >=20 >=20 >=20 > On Fri, Feb 12, 2010 at 10:38 AM, Jason Livingood > wrote: >> This is a call for comments on an individual draft regarding a >> protocol-agnostic congestion management system, which is related to some= of >> the reason that Conex is starting up. =A0I and my co-authors would like >> feedback on the latest revision of this draft at >> http://tools.ietf.org/html/draft-livingood-woundy-congestion-mgmt-03. >>=20 >> If you have any comments, please send them to me privately for >> consideration. >>=20 >> Thank you, >> Jason From Hannes.Tschofenig@gmx.net Thu Mar 4 00:56:35 2010 Return-Path: X-Original-To: re-ecn@core3.amsl.com Delivered-To: re-ecn@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 6DCD13A7AC6 for ; Thu, 4 Mar 2010 00:56:35 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.448 X-Spam-Level: X-Spam-Status: No, score=-2.448 tagged_above=-999 required=5 tests=[AWL=0.151, 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 bHKAJ2+QGdQU for ; Thu, 4 Mar 2010 00:56:34 -0800 (PST) Received: from mail.gmx.net (mail.gmx.net [213.165.64.20]) by core3.amsl.com (Postfix) with SMTP id 5F8AD3A77D0 for ; Thu, 4 Mar 2010 00:56:32 -0800 (PST) Received: (qmail invoked by alias); 04 Mar 2010 08:56:33 -0000 Received: from a88-115-222-204.elisa-laajakaista.fi (EHLO [192.168.255.4]) [88.115.222.204] by mail.gmx.net (mp042) with SMTP; 04 Mar 2010 09:56:33 +0100 X-Authenticated: #29516787 X-Provags-ID: V01U2FsdGVkX18prcJjVCUpbWqpigO74XESk6cN22dNvmYkYUDLPn 2VtA0ZMzSqCnf2 Message-ID: <4B8F759B.9080404@gmx.net> Date: Thu, 04 Mar 2010 10:55:55 +0200 From: Hannes Tschofenig User-Agent: Thunderbird 2.0.0.23 (Windows/20090812) MIME-Version: 1.0 To: Bob Briscoe References: <3D3C75174CB95F42AD6BCC56E5555B4502424066@FIESEXC015.nsn-intra.net> <201003031622.o23GMuIE004096@bagheera.jungle.bt.co.uk> In-Reply-To: <201003031622.o23GMuIE004096@bagheera.jungle.bt.co.uk> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Y-GMX-Trusted: 0 X-FuHaFi: 0.52000000000000002 Cc: "Tschofenig, Hannes \(NSN - FI/Espoo\)" , re-ecn@ietf.org Subject: Re: [re-ECN] draft-tschofenig-conex-ps and our recommendation for the group X-BeenThere: re-ecn@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: re-inserted explicit congestion notification List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 04 Mar 2010 08:56:35 -0000 Hi Bob, Bob Briscoe wrote: > Hannes, > > Yes, I could see what you were trying to do with that draft. I'd like > draft-tschofenig-conex-ps a lot more if it talked about > traffic-management in general rather than p2p-traffic-management. I > know you wanted to be very specific, but p2p was too specific. Talking > only about p2p causes allergic reactions depending on what the > reader's interests are. There's the same problem with video traffic - > who decides which traffic isn't worth providing capacity for? You are completely right that the description has to be independent of the type of traffic, at least to a certain extend. The reason why P2P is mentioned a lot is that today's problems are largely caused by P2P traffic rather than other traffic but I noticed recent surveys indicating that it is shifting again. A small note: The type of traffic is not totally irrelevant since various solutions being deployed today assume that you can shift the transfer of downloads to a later time. This might work well for file downloads where the user may be willing to wait but not for real-time traffic. > > Sally Floyd taught me well about solutions that solve all problems but > none really well (what you call the HIP effect, but I don't like that > association - it may be perjorative ;) You don't like me to call it HIP effect or you don't like me saying that at least one problem area has to be described well enough for folks to agree? > > I don't think re-ECN has a jack-of-all-trades-master-of-none problem. > It has the problem that people find it difficult to imagine know how > much better the Internet could be. This is better described as the > "80-20 problem". But if you have a hack that solves 80% of the > problem, what if it actually only solves 40% or 60% of the problem > longer term - because we don't have a good handle on how broad the > problem will really be in the future? > > The classic example is NATs. They seemed to solve 80% of the > addressing problem when they were first deployed, but they have > prevented a lot of other things happening - ie. how we define what is > included in 100% of the problem determines whether we've solved 80% or > only 10%. Sounds nice but the NAT case shows that the industry works different. > > Similarly, some might say DPI solves 80% of the traffic management > problem, but it has created other undesirable interactions. DPI > doesn't encourage mutual co-operation between willing transports - so > does it really solve 80% or 30% or 10%? I agree with you that a desirable solution is protocol agnostic. Even if we accomplish to design such a solution (which is not too complicated given the fact that Comcast already deploys such a solution today) I still believe that many operators would still buy a DPI solution because they are interested in the other properties (such as charging and analysis). Hence, you cannot see the DPI aspect in isolation and to believe that DPI will go away when you have a protocol agnostic solution for traffic management is misguided, I believe (otherwise you would not have seen some DPI vendors being supportive of the work in this group if their main cash cow could go away). > > I thought draft-moncaster-conex-problem hit about the right spot - it > focuses on the problem of accountability for causing congestion. > Admittedly, it mentions some other things ConEx could solve, but it > keeps focus on the one problem fairly well. > > Incidentally, Rich Woundy has done a presentation on what additional > benefits re-ECN would provide over ComCast's solution: > It's under the link to all the speaker presentations in the article > here: > Specifically: Thanks for the pointer. It would be nice if folks could agree (a) that there is a problem and (b) about the specific gaps of the currently deployed mechanisms. Ciao Hannes > > HTH > > > Bob > > At 13:44 02/03/2010, Tschofenig, Hannes (NSN - FI/Espoo) wrote: >> Hi all, >> >> we wanted to provide a bit of details of why Alissa and I worked on >> draft-tschofenig-conex-ps. >> >> Our goal for the problem statement document was >> 1) to offer a writeup that does not talk about the solution >> 2) to focus on one aspect of the perceived problem only. >> >> While there may be the other problems problems out there that a specific >> solution can solve (e.g. denial of service attacks, trouble-shooting of >> network problems) we really think that one needs to focus on one thing >> at the time because otherwise you run into what I call the >> HIP-effect(*). >> >> The problem needs to be well understood and documented before one can go >> forward with the next step. The lack of a clear problem statement >> discussion was for me recognizable at the BOF. >> >> Once people agree on the problem then it is interesting to capture the >> state of the art as far as what tools operators are already using to >> solve the problem. Since a number of operator believe they have a >> problem there is a wide range of solutions they are deploying today. The >> excellent writeup by Jason and Ric (see >> draft-livingood-woundy-congestion-mgmt) is one example of a solution >> that offers very interesting properties already (such as being protocol >> agnostic). There are other solution approaches that other operators are >> deploying but they are less well documented. Every solution has pros and >> cons and, from what we can tell, there is no one-size fits all approach. >> >> >> Unfortunately, we have not seen a lot of discussions about what is being >> done and why the group considers them as insufficient. This leads to the >> next point, namely to document what is not good enough with the >> available techniques. If there is a specific problem identified, and the >> inadequacies of the existing solutions are compelling, that argues that >> there is space for new work in this area. >> >> So, in a summary we would suggest the following approach and this is >> also the approach we will try to take as we rev our problem statement >> (although there will certainly still be gaps), and there are some >> elements of it in the draft-moncaster problem statement, but we wanted >> to frame the thought process before posting a new version: >> >> A) Figure out whether most people agree to a description of the problem. >> >> (There may be multiple sub-problems.) >> >> B) Document the state-of-the-art (and why people have chosen a certain >> approaches). >> >> C) Document the gaps that are not covered by state-of-the-art solutions >> that would require additional work. For me a really important question >> is what are the incentives for someone to deploy anything in addition to >> draft-livingood-woundy-congestion-mgmt? >> >> There are other ways to approach the topic but we believe that this is >> the appropriate way in this case. >> >> Ciao >> Hannes & Alissa >> >> (*): A solution that solves all problems but none really well. >> >> _______________________________________________ >> re-ECN mailing list >> re-ECN@ietf.org >> https://www.ietf.org/mailman/listinfo/re-ecn > > ________________________________________________________________ > Bob Briscoe, BT Innovate & Design > _______________________________________________ > re-ECN mailing list > re-ECN@ietf.org > https://www.ietf.org/mailman/listinfo/re-ecn From Hannes.Tschofenig@gmx.net Thu Mar 4 00:56:41 2010 Return-Path: X-Original-To: re-ecn@core3.amsl.com Delivered-To: re-ecn@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 7CA483A7D53 for ; Thu, 4 Mar 2010 00:56:41 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.465 X-Spam-Level: X-Spam-Status: No, score=-2.465 tagged_above=-999 required=5 tests=[AWL=0.134, 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 OWRBdS6QP-aW for ; Thu, 4 Mar 2010 00:56:40 -0800 (PST) Received: from mail.gmx.net (mail.gmx.net [213.165.64.20]) by core3.amsl.com (Postfix) with SMTP id DB7FD3A8155 for ; Thu, 4 Mar 2010 00:56:39 -0800 (PST) Received: (qmail invoked by alias); 04 Mar 2010 08:56:41 -0000 Received: from a88-115-222-204.elisa-laajakaista.fi (EHLO [192.168.255.4]) [88.115.222.204] by mail.gmx.net (mp001) with SMTP; 04 Mar 2010 09:56:41 +0100 X-Authenticated: #29516787 X-Provags-ID: V01U2FsdGVkX18XAedG/AoXcfEslCyg7IJKZIbXLBE9TBIFT3QAqj GCE8XnjtI63n7R Message-ID: <4B8F75A4.7090107@gmx.net> Date: Thu, 04 Mar 2010 10:56:04 +0200 From: Hannes Tschofenig User-Agent: Thunderbird 2.0.0.23 (Windows/20090812) MIME-Version: 1.0 To: Bob Briscoe References: <3D3C75174CB95F42AD6BCC56E5555B4502424066@FIESEXC015.nsn-intra.net> <201003031622.o23GMuIE004096@bagheera.jungle.bt.co.uk> In-Reply-To: <201003031622.o23GMuIE004096@bagheera.jungle.bt.co.uk> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Y-GMX-Trusted: 0 X-FuHaFi: 0.48999999999999999 Cc: "Tschofenig, Hannes \(NSN - FI/Espoo\)" , re-ecn@ietf.org Subject: [re-ECN] Another Approach ... .Re: draft-tschofenig-conex-ps and our recommendation for the group X-BeenThere: re-ecn@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: re-inserted explicit congestion notification List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 04 Mar 2010 08:56:41 -0000 From your mail I believe that you would like to approach the topic in a different way, namely similar to what I had suggested as a note in http://www.ietf.org/mail-archive/web/re-ecn/current/msg00328.html When I read the draft-moncaster-conex-problem I had gotten that this is essentially the introduction chapter of reECN rather than attempt to investigate the larger picture. The story is as follows: Instead of going through a lengthy analysis of what the requirements are, what people do in the industry, etc. you just standardize a solution and see what happens. In my opinion this is the way how the work in LEDBAT came to exist. The positive side about LEDBAT was that the algorithm was already deployed and hence standardizing it was seen as more natural instead of going through a more lenghty route of investigating the entire space. The ALTO work was not all that different. The group got scheduled with a very specific solution approach in mind. I was in fact stating several times that the requirements and the problem statement and requirements work was a waste of time. Do you think that this would be a better route for the congestion exposure work in the IETF? Ciao Hannes PS: You created the expectation that reECN would change the whole Internet. That obviously raised the bar a bit. Bob Briscoe wrote: > Hannes, > > Yes, I could see what you were trying to do with that draft. I'd like > draft-tschofenig-conex-ps a lot more if it talked about > traffic-management in general rather than p2p-traffic-management. I > know you wanted to be very specific, but p2p was too specific. Talking > only about p2p causes allergic reactions depending on what the > reader's interests are. There's the same problem with video traffic - > who decides which traffic isn't worth providing capacity for? > > Sally Floyd taught me well about solutions that solve all problems but > none really well (what you call the HIP effect, but I don't like that > association - it may be perjorative ;) > > I don't think re-ECN has a jack-of-all-trades-master-of-none problem. > It has the problem that people find it difficult to imagine know how > much better the Internet could be. This is better described as the > "80-20 problem". But if you have a hack that solves 80% of the > problem, what if it actually only solves 40% or 60% of the problem > longer term - because we don't have a good handle on how broad the > problem will really be in the future? > > The classic example is NATs. They seemed to solve 80% of the > addressing problem when they were first deployed, but they have > prevented a lot of other things happening - ie. how we define what is > included in 100% of the problem determines whether we've solved 80% or > only 10%. > > Similarly, some might say DPI solves 80% of the traffic management > problem, but it has created other undesirable interactions. DPI > doesn't encourage mutual co-operation between willing transports - so > does it really solve 80% or 30% or 10%? > > I thought draft-moncaster-conex-problem hit about the right spot - it > focuses on the problem of accountability for causing congestion. > Admittedly, it mentions some other things ConEx could solve, but it > keeps focus on the one problem fairly well. > > Incidentally, Rich Woundy has done a presentation on what additional > benefits re-ECN would provide over ComCast's solution: > It's under the link to all the speaker presentations in the article > here: > Specifically: > > HTH > > > Bob > > At 13:44 02/03/2010, Tschofenig, Hannes (NSN - FI/Espoo) wrote: >> Hi all, >> >> we wanted to provide a bit of details of why Alissa and I worked on >> draft-tschofenig-conex-ps. >> >> Our goal for the problem statement document was >> 1) to offer a writeup that does not talk about the solution >> 2) to focus on one aspect of the perceived problem only. >> >> While there may be the other problems problems out there that a specific >> solution can solve (e.g. denial of service attacks, trouble-shooting of >> network problems) we really think that one needs to focus on one thing >> at the time because otherwise you run into what I call the >> HIP-effect(*). >> >> The problem needs to be well understood and documented before one can go >> forward with the next step. The lack of a clear problem statement >> discussion was for me recognizable at the BOF. >> >> Once people agree on the problem then it is interesting to capture the >> state of the art as far as what tools operators are already using to >> solve the problem. Since a number of operator believe they have a >> problem there is a wide range of solutions they are deploying today. The >> excellent writeup by Jason and Ric (see >> draft-livingood-woundy-congestion-mgmt) is one example of a solution >> that offers very interesting properties already (such as being protocol >> agnostic). There are other solution approaches that other operators are >> deploying but they are less well documented. Every solution has pros and >> cons and, from what we can tell, there is no one-size fits all approach. >> >> >> Unfortunately, we have not seen a lot of discussions about what is being >> done and why the group considers them as insufficient. This leads to the >> next point, namely to document what is not good enough with the >> available techniques. If there is a specific problem identified, and the >> inadequacies of the existing solutions are compelling, that argues that >> there is space for new work in this area. >> >> So, in a summary we would suggest the following approach and this is >> also the approach we will try to take as we rev our problem statement >> (although there will certainly still be gaps), and there are some >> elements of it in the draft-moncaster problem statement, but we wanted >> to frame the thought process before posting a new version: >> >> A) Figure out whether most people agree to a description of the problem. >> >> (There may be multiple sub-problems.) >> >> B) Document the state-of-the-art (and why people have chosen a certain >> approaches). >> >> C) Document the gaps that are not covered by state-of-the-art solutions >> that would require additional work. For me a really important question >> is what are the incentives for someone to deploy anything in addition to >> draft-livingood-woundy-congestion-mgmt? >> >> There are other ways to approach the topic but we believe that this is >> the appropriate way in this case. >> >> Ciao >> Hannes & Alissa >> >> (*): A solution that solves all problems but none really well. >> >> _______________________________________________ >> re-ECN mailing list >> re-ECN@ietf.org >> https://www.ietf.org/mailman/listinfo/re-ecn > > ________________________________________________________________ > Bob Briscoe, BT Innovate & Design > _______________________________________________ > re-ECN mailing list > re-ECN@ietf.org > https://www.ietf.org/mailman/listinfo/re-ecn From Hannes.Tschofenig@gmx.net Thu Mar 4 01:09:35 2010 Return-Path: X-Original-To: re-ecn@core3.amsl.com Delivered-To: re-ecn@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id DA8803A77D0 for ; Thu, 4 Mar 2010 01:09:35 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.478 X-Spam-Level: X-Spam-Status: No, score=-2.478 tagged_above=-999 required=5 tests=[AWL=0.121, 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 ZDbx0yIToUjI for ; Thu, 4 Mar 2010 01:09:34 -0800 (PST) Received: from mail.gmx.net (mail.gmx.net [213.165.64.20]) by core3.amsl.com (Postfix) with SMTP id 21DEF3A8339 for ; Thu, 4 Mar 2010 01:09:33 -0800 (PST) Received: (qmail invoked by alias); 04 Mar 2010 09:09:34 -0000 Received: from a88-115-222-204.elisa-laajakaista.fi (EHLO [192.168.255.4]) [88.115.222.204] by mail.gmx.net (mp025) with SMTP; 04 Mar 2010 10:09:34 +0100 X-Authenticated: #29516787 X-Provags-ID: V01U2FsdGVkX1/B8JoDhdnBbNUGivYs7OqxEn0GsV9CvmEqACE7Yt J22zZ1cyg3c/T1 Message-ID: <4B8F78A9.1050805@gmx.net> Date: Thu, 04 Mar 2010 11:08:57 +0200 From: Hannes Tschofenig User-Agent: Thunderbird 2.0.0.23 (Windows/20090812) MIME-Version: 1.0 To: Jason Livingood References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Y-GMX-Trusted: 0 X-FuHaFi: 0.48999999999999999 Cc: Matt Mathis , re-ecn@ietf.org Subject: [re-ECN] Capturing Current Deployments ... was Re: Call for Comments: draft-livingood-woundy-congestion-mgmt-03 X-BeenThere: re-ecn@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: re-inserted explicit congestion notification List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 04 Mar 2010 09:09:35 -0000 I was a bit surprised to hear that the Comcast approach of dealing with congestion is not known to all folks in this group (given that it is highly relevant for the work in this group). This makes me wonder what is known about the currently deployed solutions in general. Unfortunately, many of the solutions being deployed are not published in such as nice writeup as the Comcast solution is (if they are public at all). Maybe some operators with interest in this problem space are willing to discuss their approach. Ciao Hannes PS: Jason, if you indeed extend your solution to other access technologies then I am wondering whether this shouldn't be a work item in a future group working. I believe that it has a lot of properties that many operators would be interested to look at. Given the current state of deployment in this area I believe that it could for many years be probably the most useful output a future group. Jason Livingood wrote: > Thanks for your response Matt (and for reading the draft of course). Some > replies inline below. > > > On 3/1/10 3:01 PM, "Matt Mathis" wrote: > > >> Interesting draft. What are your plans for it? >> > > Heck if I know! ;-) Just kidding. We have the system in production for a > little over a year and a quarter now, so soliciting comments on the overall > design continues to be interesting to us and helps improve it. I'd also > like to see it become an informational RFC at some point. First off, that > provides a stable and easily consumable reference point for the document and > it can be a reference in related work at the IETF. > > >> What do you gain by monitoring the CMTS total load? >> > > We actually monitor individual upstream and downstream ports on the CMTS > (I'll have to re-read the relevant sections to ensure I'm communicating that > the best I can). That enables us to detect when a particular segment of the > network is approaching a time of possible congestion. So we use it as an > early warning system of sorts, at which point we proactively mark some > traffic with a lower best effort QoS so that if congestion does actually > occur we are prepared in advance (as compared to doing such analysis & > action at that time precise of congestion, which is hard to get right). > > >> If you are not >> near congestion I would not expect BE vs PBE marking to make any >> difference to the traffic. >> > > Correct. It is only at times of actual congestion that BE vs PBE has any > effect whatsoever. > > >> I did not notice anything in the draft, other than the terminology, >> that seemed to be DOCSIS or cable specific. The algorithm seems as >> though it is completely general, and could recast for any technology. >> Am I correct, or did I overlook something? >> > > I think that is a fair conclusion to reach. We've gotten a few questions > from parties involved in operating or supplying operators of different > network types, and as we've explained the system it is apparent to us that > it is a generalized system (it was not really apparent at first, but we were > thinking only of how to solve our problem initially). In the next version > of the I-D I will probably add a section describing the applicability of the > system to other access network technologies and indeed to other network > segments other than just the last mile portion. > > >> 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. >> >> >> >> On Fri, Feb 12, 2010 at 10:38 AM, Jason Livingood >> wrote: >> >>> This is a call for comments on an individual draft regarding a >>> protocol-agnostic congestion management system, which is related to some of >>> the reason that Conex is starting up. I and my co-authors would like >>> feedback on the latest revision of this draft at >>> http://tools.ietf.org/html/draft-livingood-woundy-congestion-mgmt-03. >>> >>> If you have any comments, please send them to me privately for >>> consideration. >>> >>> Thank you, >>> Jason >>> > > _______________________________________________ > re-ECN mailing list > re-ECN@ietf.org > https://www.ietf.org/mailman/listinfo/re-ecn > From hannes.tschofenig@nsn.com Thu Mar 4 02:17:47 2010 Return-Path: X-Original-To: re-ecn@core3.amsl.com Delivered-To: re-ecn@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 3EA203A8747 for ; Thu, 4 Mar 2010 02:17:47 -0800 (PST) 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 rjKy1pe4IqbB for ; Thu, 4 Mar 2010 02:17:44 -0800 (PST) Received: from demumfd001.nsn-inter.net (demumfd001.nsn-inter.net [93.183.12.32]) by core3.amsl.com (Postfix) with ESMTP id C1F0E3A8522 for ; Thu, 4 Mar 2010 02:17:42 -0800 (PST) Received: from demuprx016.emea.nsn-intra.net ([10.150.129.55]) by demumfd001.nsn-inter.net (8.12.11.20060308/8.12.11) with ESMTP id o24AHggL024304 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL) for ; Thu, 4 Mar 2010 11:17:42 +0100 Received: from demuexc023.nsn-intra.net (demuexc023.nsn-intra.net [10.150.128.36]) by demuprx016.emea.nsn-intra.net (8.12.11.20060308/8.12.11) with ESMTP id o24AHghA005377 for ; Thu, 4 Mar 2010 11:17:42 +0100 Received: from FIESEXC015.nsn-intra.net ([10.159.0.23]) by demuexc023.nsn-intra.net with Microsoft SMTPSVC(6.0.3790.3959); Thu, 4 Mar 2010 11:17:42 +0100 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Thu, 4 Mar 2010 12:17:05 +0200 Message-ID: <3D3C75174CB95F42AD6BCC56E5555B450246E35A@FIESEXC015.nsn-intra.net> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: What Comcast's FairShare Solution does not provide... Thread-Index: Acq7g9bWAaZlOY4OSoeJd00SSOGFFg== From: "Tschofenig, Hannes (NSN - FI/Espoo)" To: X-OriginalArrivalTime: 04 Mar 2010 10:17:42.0296 (UTC) FILETIME=[ECE41180:01CABB83] Subject: [re-ECN] What Comcast's FairShare Solution does not provide... X-BeenThere: re-ecn@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: re-inserted explicit congestion notification List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 04 Mar 2010 10:17:47 -0000 Bob pointed to a slide set by Ric that talks about the Comcast congestion management solution. Here is the slide set:=20 http://giic.org/pdf/GIIC-CapShare-01-Woundy-Comcast.pdf I tried to re-word the arguments to avoid the solution specific touch.=20 Ric provided a few arguments what he believes is missing from their current solution that might require future work:=20 * Comcast's FairShare approach is not an end-to-end solution I would say: So what? As an argument for an ISP that has a problem to solve now that's probably not an interesting argument for further work.=20 * It does not signal congestion to user applications nor to devices along the path.=20 True.=20 Only devices within the Comcast network would see the DiffServ marking when the increased traffic leads to traffic marking (from PBE to BE).=20 * It does not enable application response.=20 I don't agree with that. Packet dropping will give applications an implicit indication.=20 * Re-ECN enables DDoS mitigation and other capabilities This is too unspecific to me to convince anyone.=20 Do we have a few more arguments?=20 Ciao Hannes From rbriscoe@jungle.bt.co.uk Thu Mar 4 04:27:34 2010 Return-Path: X-Original-To: re-ecn@core3.amsl.com Delivered-To: re-ecn@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id A14BB3A898D for ; Thu, 4 Mar 2010 04:27:34 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.884 X-Spam-Level: X-Spam-Status: No, score=-1.884 tagged_above=-999 required=5 tests=[AWL=0.233, BAYES_00=-2.599, DNS_FROM_RFC_BOGUSMX=1.482, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 821NL-ipdsOE for ; Thu, 4 Mar 2010 04:27:27 -0800 (PST) Received: from smtp4.smtp.bt.com (smtp4.smtp.bt.com [217.32.164.151]) by core3.amsl.com (Postfix) with ESMTP id CADB13A7D53 for ; Thu, 4 Mar 2010 04:27:26 -0800 (PST) Received: from i2kc06-ukbr.domain1.systemhost.net ([193.113.197.70]) by smtp4.smtp.bt.com with Microsoft SMTPSVC(6.0.3790.3959); Thu, 4 Mar 2010 12:27:27 +0000 Received: from cbibipnt05.iuser.iroot.adidom.com ([147.149.196.177]) by i2kc06-ukbr.domain1.systemhost.net with Microsoft SMTPSVC(6.0.3790.3959); Thu, 4 Mar 2010 12:27:27 +0000 Received: From bagheera.jungle.bt.co.uk ([132.146.168.158]) by cbibipnt05.iuser.iroot.adidom.com (WebShield SMTP v4.5 MR1a P0803.399); id 1267705645835; Thu, 4 Mar 2010 12:27:25 +0000 Received: from MUT.jungle.bt.co.uk ([10.73.129.186]) by bagheera.jungle.bt.co.uk (8.13.5/8.12.8) with ESMTP id o24CRLMV022433; Thu, 4 Mar 2010 12:27:22 GMT Message-Id: <201003041227.o24CRLMV022433@bagheera.jungle.bt.co.uk> X-Mailer: QUALCOMM Windows Eudora Version 7.1.0.9 Date: Thu, 04 Mar 2010 12:27:20 +0000 To: "EARDLEY, Phil" , Leslie Daigle From: Bob Briscoe In-Reply-To: References: <88061F01C2B84E8FB392C3CB0F0B96DA@your029b8cecfe> 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 Mar 2010 12:27:27.0011 (UTC) FILETIME=[0CF14F30:01CABB96] Cc: "re-ecn@ietf.org list" Subject: Re: [re-ECN] CONEX IESG comments #1 X-BeenThere: re-ecn@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: re-inserted explicit congestion notification List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 04 Mar 2010 12:27:34 -0000 Phil, Leslie, As suggested by Phil, I've chopped the IESG from the cc for now, while we collate responses. My suggestions for text in response to some of the items are below. I'm also keen to see other people's thoughts... At 15:32 01/03/2010, Lars Eggert wrote: >Hi, CONEX group, > >I'm going to forward a few issues that were raised during the IESG >discussion of the charter to the list, and CC the IESG so that the >discussion can happen directly, without me being the bottleneck in the middle. > >(I'd like to thank the ADs who wrote up their issues in this way - >this will make it much easier to progress the discussion!) Yes - thanks from me too - direct dialogue is much preferable to indirect. >Lars > >Begin forwarded message: > > In no particular order... > > > > 1. This looks like really interesting research work with a > potential outcome > > that could provide substantial benefit. But why is this not > proposed as work > > in the IRTF? [BB]: Research on the protocol is all done. It started in 2003 and it's baked enough for standards - at least experimental (see below). For instance, collected on the re-ECN project home page there's: - 18 papers on re-ECN, including - 4 assessments by other researchers or organisations (the protocol went through two evolutions in response to attacks proposed by researchers in these papers and more informally on mailing lists) - 2 implementations plus simulator implementations - 8 articles from the technical media Yes, there is research going on the IRTF (ICCRG) on the implications for congestion control of ConEx. But the protocol itself is not research any more. It is a pre-requisite for a branch of the ICCRG's research, hence bringing it the IETF. > > > > 2. The charter seems to be trying to say that the work will be > Experimental > > (which sounds like a grand goal), but fails dismally! I see... > > The output of the CONEX WG are Informational and Experimental > > documents, apart from work item #2 which is tentatively slated for > > Standards Track. Depending on the bits that are proposed to be used > > in the IP header and their semantics (e.g., Bit 48 in IPv4, "ECN > > Nonce"), there may need to be further Standards Track or Informational > > documents to reassign those bits from their current definitions > > (which would be subject to appropriate IESG and IETF review as > > necessary). > > But #2 is... > > Specification of IPv4 and IPv6 packet structures to carry CONEX > > information (header bits, interpretation) > > > > And, in fact, no other documents listed would be appropriate as > > Experimental. > > Why are the protocol specifications not also listed as > Experimental? If (and > > this is clearly not known yet because the protocol specs have not been > > written) it is necessary to use some bits, bytes, or codepoints that > > currently require standards action, then it would be appropriate > to write a > > standards action document to reassign those fields as experimental. This > > document would be distinct from the protocol specification. > > We should ask for the main protocol docs to be IETF experimental track which may require necessary stds track docs to change the status of relevant fields in existing RFCs (e.g. from reserved to experimental). Assessment of whether adoption will happen is one of the most common uses for the experimental track. IRTF isn't appropriate, as the protocol has been researched to death. > > 3. Deployment and usage models > > According to the charter, it appears that the deployment and usage work is > > intended to follow on from the protocol specification and BCPs. I > feel that > > there is considerable lack of clarity about how/where the proposed > > mechanisms would be deployed. That is, it is unclear whether "...any node > > along the network path..." is meant to mean what it says. > > - Why is the deployment model not part of the problem spec? > > - Is there an assumption that there is IP forwarding at every hop? > > - Is there an implication that MPLS extensions will also be developed? > > - Can you show some deployment examples? I know of at least two groups of folks are already working on deployment scenarios, and incentives. Both are part of industry-academic consortia: - one hosted by David Clark's group at MIT. - the other is part of the Trilogy project. These have both been helped a lot by Matt Mathis's suggestions on this list. If this milestone was brought forward, I'm sure material created by both/either of these groups would be ready in time for inclusion. Plus, of course, additional IETF work itself - and any other people working in this space that I'm not aware of. > > > > 4. ISP support > > Somewhat tied to the previous point is the issue I cannot find > supporters in > > the operational departments of ISPs. I have been trying, because I feel it > > is important to understand their views. But the most I can get back is "We > > will watch it in case it goes somewhere." Unfortunately, I also hear a lot > > of "Our company does not support this work. We believe it will waste > > industry resources and cause confusion. We do not understand how we could > > deploy it within our business model, and have no plans to deploy it." > > - Where is the ISP support for this? If I were an ISP, I wouldn't necessarily have developed a policy on using ConEx at this stage. For comparison (without implying any equivalence between Diffserv & ConEx) at the Diffserv BoF in April 1997 few of the operational people in ISPs had policies on deploying Diffserv. However, on this list it would be great to see messages of interest/support from operational/commercial people in ISPs. I have pointed this list at the interest expressed in the assessment of ConEx at > > > > 5. Security > > The charter does give a passing nod to the existence of security and trust > > issues. These need to be addressed up front. An architecture that > relies on > > ISPs not gaming the system and not lying is critical in this area. The > > security and veracity of the information shared will also be critical. > > - Where is the security and trust model described? There's been a huge amount of work on the integrity of the info provided by ConEx / re-ECN. The main doc on this is draft-briscoe-tsvwg-re-ecn-tcp-motivation In addition, I have prepared a comprehensive report giving pseudocode of policers/droppers etc, attack models, defences, simulations of the defence mechanisms etc. But I still cannot publish it because my company's IPR department (still) haven't given me permission to publish. Rest assured it will be available for when the w-g needs it tho. I am also aware of others who are working on their own designs for the security elements of a ConEx system. HTH Bob >_______________________________________________ >re-ECN mailing list >re-ECN@ietf.org >https://www.ietf.org/mailman/listinfo/re-ecn ________________________________________________________________ Bob Briscoe, BT Innovate & Design From ingemar.s.johansson@ericsson.com Thu Mar 4 05:58:27 2010 Return-Path: X-Original-To: re-ecn@core3.amsl.com Delivered-To: re-ecn@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 06F9D3A8C29 for ; Thu, 4 Mar 2010 05:58:27 -0800 (PST) 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 m9o4mdqGFkCy for ; Thu, 4 Mar 2010 05:58:26 -0800 (PST) Received: from mailgw9.se.ericsson.net (mailgw9.se.ericsson.net [193.180.251.57]) by core3.amsl.com (Postfix) with ESMTP id BC01528C103 for ; Thu, 4 Mar 2010 05:58:25 -0800 (PST) X-AuditID: c1b4fb39-b7c2dae000007b99-cb-4b8fbc81b9f7 Received: from esessmw0184.eemea.ericsson.se (Unknown_Domain [153.88.253.125]) by mailgw9.se.ericsson.net (Symantec Brightmail Gateway) with SMTP id C9.BD.31641.18CBF8B4; Thu, 4 Mar 2010 14:58:25 +0100 (CET) Received: from ESESSCMS0356.eemea.ericsson.se ([169.254.1.67]) by esessmw0184.eemea.ericsson.se ([153.88.115.81]) with mapi; Thu, 4 Mar 2010 14:58:25 +0100 From: Ingemar Johansson S To: "re-ecn@ietf.org" Date: Thu, 4 Mar 2010 14:58:22 +0100 Thread-Topic: Mobile traffic management Thread-Index: Acq7osDK1x7e/lgTSMyrv5PRijnQ7Q== Message-ID: <548FC4B9D57A4043AAFFE888A39429031CF1FD9CAE@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: [re-ECN] Mobile traffic management X-BeenThere: re-ecn@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: re-inserted explicit congestion notification List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 04 Mar 2010 13:58:27 -0000 Hi I beleive that this link may be an interesting read for people with interes= t in congestion related issues. http://disruptivewireless.blogspot.com/2010/03/mobile-traffic-management-vi= deo.html 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 acooper@cdt.org Thu Mar 4 07:14:13 2010 Return-Path: X-Original-To: re-ecn@core3.amsl.com Delivered-To: re-ecn@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 643EF28C184 for ; Thu, 4 Mar 2010 07:14:13 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.289 X-Spam-Level: X-Spam-Status: No, score=-2.289 tagged_above=-999 required=5 tests=[AWL=0.310, 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 1QsRKnjkBgpS for ; Thu, 4 Mar 2010 07:14:11 -0800 (PST) Received: from mail.maclaboratory.net (mail.maclaboratory.net [209.190.215.232]) by core3.amsl.com (Postfix) with ESMTP id 8B42828C186 for ; Thu, 4 Mar 2010 07:14:11 -0800 (PST) Received: from [10.0.205.31] ([129.67.117.242]) (authenticated user acooper@cdt.org) by mail.maclaboratory.net (using TLSv1/SSLv3 with cipher AES128-SHA (128 bits)); Thu, 4 Mar 2010 10:14:05 -0500 Message-Id: <2D8C263E-CAC5-4647-9113-B2CD4A02CE99@cdt.org> From: Alissa Cooper To: Bob Briscoe In-Reply-To: <201003031622.o23GMuIE004096@bagheera.jungle.bt.co.uk> Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v936) Date: Thu, 4 Mar 2010 15:14:04 +0000 References: <3D3C75174CB95F42AD6BCC56E5555B4502424066@FIESEXC015.nsn-intra.net> <201003031622.o23GMuIE004096@bagheera.jungle.bt.co.uk> X-Mailer: Apple Mail (2.936) Cc: re-ecn@ietf.org Subject: Re: [re-ECN] draft-tschofenig-conex-ps and our recommendation for the group X-BeenThere: re-ecn@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: re-inserted explicit congestion notification List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 04 Mar 2010 15:14:13 -0000 Bob, Couple of thoughts inline. On Mar 3, 2010, at 4:23 PM, Bob Briscoe wrote: > I thought draft-moncaster-conex-problem hit about the right spot - > it focuses on the problem of accountability for causing congestion. > Admittedly, it mentions some other things ConEx could solve, but it > keeps focus on the one problem fairly well. > > Incidentally, Rich Woundy has done a presentation on what additional > benefits re-ECN would provide over ComCast's solution: > It's under the link to all the speaker presentations in the article > here: > Specifically: Comcast.pdf> > I think there is a lot to like in draft-moncaster-problem, and it does focus to some extent on congestion accountability. But I think there could be a clearer statement of what problem congestion accountability would be solving. From reading the problem statement and looking at Rich's slides, there seem to be three congestion-related problems that congestion exposure could help to solve 1) LEDBAT-style congestion control is not currently incentivized because operators who use volume accounting treat apps that use it just like everything else. This is thoroughly discussed in draft- moncaster-problem. 2) Operators have no way to know, within the network, the volume of congestion being created by other networks, and therefore no way to hold those other networks accountable. This is not so thoroughly discussed in draft-moncaster-problem. 3) Users/apps need more information about congestion in order to be able to respond better. This is not really discussed in draft- moncaster-problem. I think it would be helpful for the group to have some sense of which subset of these problems we are trying to solve. Then, ticking through the mechanisms that already exist to solve the problems and showing how they are deficient could lead to the conclusion that the congestion exposure work is warranted (draft-moncaster-problem already does this to some extent, but in my reading at least the link between the stated problems, the inadequacies of the existing solutions, and the reasons why conex would improve the situation is somewhat weak). Alissa > HTH > > > Bob > > At 13:44 02/03/2010, Tschofenig, Hannes (NSN - FI/Espoo) wrote: >> Hi all, >> >> we wanted to provide a bit of details of why Alissa and I worked on >> draft-tschofenig-conex-ps. >> >> Our goal for the problem statement document was >> 1) to offer a writeup that does not talk about the solution >> 2) to focus on one aspect of the perceived problem only. >> >> While there may be the other problems problems out there that a >> specific >> solution can solve (e.g. denial of service attacks, trouble- >> shooting of >> network problems) we really think that one needs to focus on one >> thing >> at the time because otherwise you run into what I call the >> HIP-effect(*). >> >> The problem needs to be well understood and documented before one >> can go >> forward with the next step. The lack of a clear problem statement >> discussion was for me recognizable at the BOF. >> >> Once people agree on the problem then it is interesting to capture >> the >> state of the art as far as what tools operators are already using to >> solve the problem. Since a number of operator believe they have a >> problem there is a wide range of solutions they are deploying >> today. The >> excellent writeup by Jason and Ric (see >> draft-livingood-woundy-congestion-mgmt) is one example of a solution >> that offers very interesting properties already (such as being >> protocol >> agnostic). There are other solution approaches that other operators >> are >> deploying but they are less well documented. Every solution has >> pros and >> cons and, from what we can tell, there is no one-size fits all >> approach. >> >> >> Unfortunately, we have not seen a lot of discussions about what is >> being >> done and why the group considers them as insufficient. This leads >> to the >> next point, namely to document what is not good enough with the >> available techniques. If there is a specific problem identified, >> and the >> inadequacies of the existing solutions are compelling, that argues >> that >> there is space for new work in this area. >> >> So, in a summary we would suggest the following approach and this is >> also the approach we will try to take as we rev our problem >> statement >> (although there will certainly still be gaps), and there are some >> elements of it in the draft-moncaster problem statement, but we >> wanted >> to frame the thought process before posting a new version: >> >> A) Figure out whether most people agree to a description of the >> problem. >> >> (There may be multiple sub-problems.) >> >> B) Document the state-of-the-art (and why people have chosen a >> certain >> approaches). >> >> C) Document the gaps that are not covered by state-of-the-art >> solutions >> that would require additional work. For me a really important >> question >> is what are the incentives for someone to deploy anything in >> addition to >> draft-livingood-woundy-congestion-mgmt? >> >> There are other ways to approach the topic but we believe that this >> is >> the appropriate way in this case. >> >> Ciao >> Hannes & Alissa >> >> (*): A solution that solves all problems but none really well. >> >> _______________________________________________ >> re-ECN mailing list >> re-ECN@ietf.org >> https://www.ietf.org/mailman/listinfo/re-ecn > > ________________________________________________________________ > Bob Briscoe, BT Innovate & Design > _______________________________________________ > re-ECN mailing list > re-ECN@ietf.org > https://www.ietf.org/mailman/listinfo/re-ecn > From rbriscoe@jungle.bt.co.uk Thu Mar 4 15:52:13 2010 Return-Path: X-Original-To: re-ecn@core3.amsl.com Delivered-To: re-ecn@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 9A6EB28C0D7 for ; Thu, 4 Mar 2010 15:52:13 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.942 X-Spam-Level: X-Spam-Status: No, score=-1.942 tagged_above=-999 required=5 tests=[AWL=0.174, BAYES_00=-2.599, DNS_FROM_RFC_BOGUSMX=1.482, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id S4SkUJnlpHKJ for ; Thu, 4 Mar 2010 15:52:06 -0800 (PST) Received: from smtp2.smtp.bt.com (smtp2.smtp.bt.com [217.32.164.150]) by core3.amsl.com (Postfix) with ESMTP id 83B573A8BBE for ; Thu, 4 Mar 2010 15:52:05 -0800 (PST) Received: from i2kc08-ukbr.domain1.systemhost.net ([193.113.197.71]) by smtp2.smtp.bt.com with Microsoft SMTPSVC(6.0.3790.3959); Thu, 4 Mar 2010 23:52:06 +0000 Received: from cbibipnt08.iuser.iroot.adidom.com ([147.149.100.81]) by i2kc08-ukbr.domain1.systemhost.net with Microsoft SMTPSVC(6.0.3790.3959); Thu, 4 Mar 2010 23:52:06 +0000 Received: From bagheera.jungle.bt.co.uk ([132.146.168.158]) by cbibipnt08.iuser.iroot.adidom.com (WebShield SMTP v4.5 MR1a P0803.399); id 1267746725723; Thu, 4 Mar 2010 23:52:05 +0000 Received: from MUT.jungle.bt.co.uk ([10.73.128.162]) by bagheera.jungle.bt.co.uk (8.13.5/8.12.8) with ESMTP id o24Nq1CM032382; Thu, 4 Mar 2010 23:52:02 GMT Message-Id: <201003042352.o24Nq1CM032382@bagheera.jungle.bt.co.uk> X-Mailer: QUALCOMM Windows Eudora Version 7.1.0.9 Date: Thu, 04 Mar 2010 23:52:00 +0000 To: Jason Livingood From: Bob Briscoe In-Reply-To: References: 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 Mar 2010 23:52:06.0408 (UTC) FILETIME=[B22BD880:01CABBF5] Cc: Matt Mathis , re-ecn@ietf.org Subject: Re: [re-ECN] Call for Comments: draft-livingood-woundy-congestion-mgmt-03 X-BeenThere: re-ecn@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: re-inserted explicit congestion notification List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 04 Mar 2010 23:52:13 -0000 Jason, I had read the draft before, and it will be a useful ref. I would advise that you publish soon before things move on, rather than trying to add stuff on applicability to non-cable networks (even tho that would be interesting - perhaps best as a separate short draft). I have some hopefully constructive comments below from my reading of the latest -03 rev. 1/ Average utilisation It would be useful for context to state what proportion of their provisioned access capacity your customers utilise on average (The summary in S.4 would be a good place). If you gave the typical figures your customers demand it would allow readers to better understand why it doesn't make sense to provision as if everyone uses their max bit-rate all the time. It will also explain why a slight change in the behaviour of many customers all at once might easily congest provisioned capacity. And it would also give context to the stats in S.5.2, where customers using 70% of their provisioned capacity are considered excessive when aggregate utilisation is about 70%. 2/ Why not increase capacity instead? Many readers will ask this question. I believe the answer is straightforward. It would be nice to be able to point to your document for that answer. We tried to give the answer in a draft we have allowed to expire (but we could rejuvenate it if there's demand): See S.3.1 of available at: 3/ Port utilisation thresholds & durations It should be pointed out that inferring congestion from utilisation is only a heuristic, so the recommended figures are only applicable given current traffic patterns. For instance, port utilisation thresholds can increase as aggregate bit-rates increase over the years (more aggregation leads to more smoothing). Conversely, if the traffic mix became more bursty due to different popular applications, there would be more congestion at lower utilisation. Also the 15-minute duration was presumably found to be useful because shorter episodes of high utilisation tend not to always become persistent. It would be worth saying what criteria you used to make these judgements, as I suspect figures like this will get quoted as gospel by people who don't consider what objective was trying to be achieved. 4/ What is "actually congested"? At the end of S.5.1 it says, "the instances where the network actually becomes congested during the Port Utilization Duration are few," How is "actually congested" defined? Is just one loss considered "actual congestion"? Presumably not. This is important, as many consider mild levels of loss as perfectly healthy, so it's not easy to know the situation that Comcast is trying to avoid with this congestion mangement scheme. This is the objective of the whole congestion management scheme, so it's important to be precise here. In S.5.3 there's the sentence "in those rare cases where packets may be dropped..." But a single TCP flow with RTT 80ms can attain 50Mb/s with a loss fraction of 0.0013% (1 in ~74000 packets) so there's no need to try to achieve loss figures much lower than this. And indeed, if flows aren't bottlenecked elsewhere, TCP will drive the system until it gets such loss levels. If, instead, a customer is downloading 5x 10Mb/s TCP flows still with 80ms RTT, TCP will drive losses up to 1 in ~3000 or 0.03% and any lower loss rates won't be able to improve performance. 5/ Straying into "justificatory advertising"? Generally the doc keeps to technical facts, which is good. In some places I detected a little bit of business justification, which was OK, because it was mild. However, the para justifying User Consumption Thresholds based on usage of VoIP, web surfing, Hulu etc etc struck me as too much like justifying Comcast's choices - it felt like the doc was speaking to the FCC at this point. This may well be how Comcast judges where to pitch these thresholds. But it doesn't sit well in a doc that says that this technique is app-neutral. The same info could be given but in a different way. For instance, you could say business success for companies like Comcast depends on judging what the maximum demand will be from the large majority of households for different applications like VoIP, web surfing, Hulu. So Comcast pitch capacity at a level that allows x, y & z simultaneously. But of course it is up to each household what mix of apps they actually use. Yada yada. 6/ Why hysteresis? Can it fail? In the para starting "A user's traffic is released from a BE state..." in S.5.2, firstly, there's a nit in that 'hysteresis' is given as an alternative word for 'QoS oscillation', when hysteresis is actually the hi-lo watermark technique you use to prevent QoS oscillation. Moving to my point: it's not clear why hysteresis is considered better than QoS oscillation. You say the approach worked well, which presumably means it prevented QoS oscillation. But where's the evidence that QoS oscillation is not actually preferred by the affected customers? To regain the right to priority BE, a customer has to drop consumption to <50% for ~15mins. Without the low watermark, they could regain PBE without having to reduce consumption so much. Wouldn't they prefer this? Or are you saying the watermark approach is beneficial to all the other customers, rather than to the heavy customers? It's also not clear to me how the customer's software knows how to get out of jail. Does forcing them into BE always force their consumption to drop below ~50% for 15mins? So they will automatically get out of jail? Do they have to be using a TCP-like transport that responds to the drops from BE by taking them below ~50%? If their software doesn't automatically take them below 50%, can't they get trapped in jail for a long time without knowing the passkey to get out (ie. reduce consumption <50%)? 7/ What if no users stand out? Wrt Fig 2: "What if everyone persistently arrives at Result #2 'No action taken'"? This could happen if the distribution of customers doesn't include any seriously heavy customers, just a lot of equally heavy customers. I guess you consider upgrading capacity at this juncture? 8/ Bytes transferred during congestion not necessarily the problem. It should be stated somewhere that different transports can respond more or less aggressively to others sharing the same capacity, while still transferring as many bytes (e.g. LEDBAT-like transports). This is one limitation of the approach described: it doesn't reward yielding behaviour. Elsewhere Rich Woundy has compiled a wider list of limitations of Comcast's approach. It might be worth stating these, either in this doc, or in a companion doc along with the generalisations to other technologies that you were discussing with Matt. 9/ All in all... A very useful contribution to the IETF's knowledge. Thank you very much for all the work involved in having produced this. Nits: ----- 491 Even without channel bonding, 492 multiple channels are usually configured to come out each physical 493 port. s/out each/out of each/ Fig 1: Double vision nightmare! 631 this is usually done through a command sent from the network and 632 without any effect on the subscriber. s/without any effect on the subscriber./without the subscriber noticing./ [If there's no effect at all, why do it!?] 742 (Note: Although each cable modem is typically 743 assigned to a particular household, the software does not and cannot 744 actually identify individual users, the number of users sharing a 745 cable modem, or analyze particular users' traffic.) For purposes of 746 this document, we use "cable modem", "user", and "subscriber" 747 interchangeably to mean a subscriber account or user account and not 748 an individual person. This note would be better in the terminology section (S.2). Question #3 under Fig 2: Add: "over a period of 15 minutes." S.5.3 heading: s/Users&apos/Users'/ 942 (It is important to note that 943 congestion can occur in any IP network, and, when it does, packets 944 can be delayed or dropped. As a result, applications and protocols 945 have been designed to deal with this reality. Our congestion 946 management system attempts to ensure that, in those rare cases where 947 packets may be dropped, BE packets are dropped before PBE packets are 956 dropped.) This parenthesis should be upfront somewhere at the start of the doc, and not in parentheses. 1019 find a specific complaint that can be traced back to the effected of 1020 this congestion management system. s/effected/effect/ Cheers Bob ________________________________________________________________ Bob Briscoe, BT Innovate & Design From rbriscoe@jungle.bt.co.uk Fri Mar 5 09:18:29 2010 Return-Path: X-Original-To: re-ecn@core3.amsl.com Delivered-To: re-ecn@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id E1A1628C2E7 for ; Fri, 5 Mar 2010 09:18:28 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.977 X-Spam-Level: X-Spam-Status: No, score=-1.977 tagged_above=-999 required=5 tests=[AWL=0.140, BAYES_00=-2.599, DNS_FROM_RFC_BOGUSMX=1.482, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id s15dO8G91b6J for ; Fri, 5 Mar 2010 09:18:22 -0800 (PST) Received: from smtp2.smtp.bt.com (smtp2.smtp.bt.com [217.32.164.150]) by core3.amsl.com (Postfix) with ESMTP id C038828C2E3 for ; Fri, 5 Mar 2010 09:18:21 -0800 (PST) Received: from i2kc06-ukbr.domain1.systemhost.net ([193.113.197.70]) by smtp2.smtp.bt.com with Microsoft SMTPSVC(6.0.3790.3959); Fri, 5 Mar 2010 17:18:23 +0000 Received: from cbibipnt05.iuser.iroot.adidom.com ([147.149.196.177]) by i2kc06-ukbr.domain1.systemhost.net with Microsoft SMTPSVC(6.0.3790.3959); Fri, 5 Mar 2010 17:18:20 +0000 Received: From bagheera.jungle.bt.co.uk ([132.146.168.158]) by cbibipnt05.iuser.iroot.adidom.com (WebShield SMTP v4.5 MR1a P0803.399); id 1267809497681; Fri, 5 Mar 2010 17:18:17 +0000 Received: from MUT.jungle.bt.co.uk ([10.73.179.5]) by bagheera.jungle.bt.co.uk (8.13.5/8.12.8) with ESMTP id o25HIDdw017757; Fri, 5 Mar 2010 17:18:13 GMT Message-Id: <201003051718.o25HIDdw017757@bagheera.jungle.bt.co.uk> X-Mailer: QUALCOMM Windows Eudora Version 7.1.0.9 Date: Fri, 05 Mar 2010 17:18:12 +0000 To: Hannes Tschofenig From: Bob Briscoe In-Reply-To: <4B8F759B.9080404@gmx.net> References: <3D3C75174CB95F42AD6BCC56E5555B4502424066@FIESEXC015.nsn-intra.net> <201003031622.o23GMuIE004096@bagheera.jungle.bt.co.uk> <4B8F759B.9080404@gmx.net> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-Scanned-By: MIMEDefang 2.56 on 132.146.168.158 X-OriginalArrivalTime: 05 Mar 2010 17:18:20.0850 (UTC) FILETIME=[DAA78920:01CABC87] Cc: "Tschofenig, Hannes \(NSN - FI/Espoo\)" , re-ecn@ietf.org Subject: Re: [re-ECN] draft-tschofenig-conex-ps and our recommendation for the group X-BeenThere: re-ecn@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: re-inserted explicit congestion notification List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 05 Mar 2010 17:18:29 -0000 Hannes, At 08:55 04/03/2010, Hannes Tschofenig wrote: >Hi Bob, > >Bob Briscoe wrote: >>Hannes, >> >>Yes, I could see what you were trying to do with that draft. I'd >>like draft-tschofenig-conex-ps a lot more if it talked about >>traffic-management in general rather than p2p-traffic-management. I >>know you wanted to be very specific, but p2p was too specific. >>Talking only about p2p causes allergic reactions depending on what >>the reader's interests are. There's the same problem with video >>traffic - who decides which traffic isn't worth providing capacity for? > >You are completely right that the description has to be independent >of the type of traffic, at least to a certain extend. >The reason why P2P is mentioned a lot is that today's problems are >largely caused by P2P traffic rather than other traffic but I >noticed recent surveys indicating that it is shifting again. [BB]: Yes, all the studies I've seen in the last year or so (scholarly and from equipment vendors) have shown p2p is staying about constant in absolute terms, but therefore reducing in relative terms as video grows. Many ISPs are investing in capacity to deliver their own value-added services, often given priority using Diffserv. But when customers get their services over-the-top (OTT) as best-efforts (BE), they can use the same capacity, because BE borrows from the unused capacity the ISPs are provisioning for their premium value added services. But, now that the growth is in video, I think many ISPs believe their customers will be willing to pay more for basic bit-transport even if they don't subscribe to the ISP's own services. I.e. they assume there is real cash behind the growth in demand for video streaming bytes, whereas they didn't see much real cash behind demand for p2p file-sharing bytes. However, if cash flows don't match up to increasing costs, there won't be an easy way for the ISP to decide which traffic users value least any more. That's why I believe ConEx is important - it's intended to encourage machinery in operating systems & apps to give different weights to different apps, rather than the ISP making choices. P2p was an easy target. Altho people don't like their ISP making their choices, if the customer had had to choose, they would have often reduced p2p themselves, rather than slowing down their streaming, Web, VoIP, email etc. >A small note: The type of traffic is not totally irrelevant since >various solutions being deployed today assume that you can shift the >transfer of downloads to a later time. This might work well for file >downloads where the user may be willing to wait but not for real-time traffic. [BB]: You gain considerably from timeshifting even by seconds (or even less). The study linked below got 100% more video through the same capacity by multiplexing variable bit-rate encoded videos which all timeshifted away from congested times (when all the hard scenes in each video happened to coincide). The timeshifting was solely within the buffering time of the videos. >>Sally Floyd taught me well about solutions that solve all problems >>but none really well (what you call the HIP effect, but I don't >>like that association - it may be perjorative ;) >You don't like me to call it HIP effect or you don't like me saying >that at least one problem area has to be described well enough for >folks to agree? I don't like calling it the HIP effect. >>I don't think re-ECN has a jack-of-all-trades-master-of-none >>problem. It has the problem that people find it difficult to >>imagine know how much better the Internet could be. This is better >>described as the "80-20 problem". But if you have a hack that >>solves 80% of the problem, what if it actually only solves 40% or >>60% of the problem longer term - because we don't have a good >>handle on how broad the problem will really be in the future? >> >>The classic example is NATs. They seemed to solve 80% of the >>addressing problem when they were first deployed, but they have >>prevented a lot of other things happening - ie. how we define what >>is included in 100% of the problem determines whether we've solved >>80% or only 10%. > >Sounds nice but the NAT case shows that the industry works different. With ConEx, we're trying to learn from the mistakes with NATs by recognising the ISPs' economic concerns and standardising something that gives ISPs information they cannot get right now: the incremental cost of traffic. This provides an architecture for traffic management that will give ISPs sufficient control over their costs, but without having to violate the architecture. >>Similarly, some might say DPI solves 80% of the traffic management >>problem, but it has created other undesirable interactions. DPI >>doesn't encourage mutual co-operation between willing transports - >>so does it really solve 80% or 30% or 10%? > >I agree with you that a desirable solution is protocol agnostic. > >Even if we accomplish to design such a solution (which is not too >complicated given the fact that Comcast already deploys such a >solution today) I still believe that many operators would still buy >a DPI solution because they are interested in the other properties >(such as charging and analysis). Hence, you cannot see the DPI >aspect in isolation and to believe that DPI will go away when you >have a protocol agnostic solution for traffic management is >misguided, I believe (otherwise you would not have seen some DPI >vendors being supportive of the work in this group if their main >cash cow could go away). Indeed. There are other reasons for using DPI than controlling costs... For instance, if cellular operators use ConEx, I suspect it will be to complement their DPI. DPI will tell them the value of sessions and ConEx will tell them the cost of traffic, then they will maximise (value minus cost). But the fixed ISP market is commoditising much more rapidly. If an ISP tried to extract more cash from a session that it inferred was more valuable (using DPI), the customer would just switch to another ISP. It's the classic outcome of competition: driving prices down towards the cost of provision. Even if a customer values a session a lot higher than it costs to deliver, no ISP can capture that extra value because others can undercut them and still cover their costs. That's why I figured it was correct for the IETF to focus only on the incremental cost of traffic (ConEx). If a provider can extract more value using DPI, good luck to them. But that's icing on the cake, whereas cost is the cake itself - cost is the essential and neutral economic factor that any industry needs to understand in order to function. When we first evaluated the early DPI offerings, we advised that most of the proposed uses for DPI were reasonable (market analysis, rapid development of new protocol handlers, anomaly detection etc). But we advised that DPI would not be a long term solution for traffic management and control. Traffic management needed to be able to work for all traffic, whether encrypted or not. Whereas the other uses of DPI were valid because they were either optional or consensual. >>I thought draft-moncaster-conex-problem hit about the right spot - >>it focuses on the problem of accountability for causing congestion. >>Admittedly, it mentions some other things ConEx could solve, but it >>keeps focus on the one problem fairly well. >> >>Incidentally, Rich Woundy has done a presentation on what >>additional benefits re-ECN would provide over ComCast's solution: >>It's under the link to all the speaker presentations in the article >>here: >>Specifically: > >Thanks for the pointer. It would be nice if folks could agree (a) >that there is a problem and (b) about the specific gaps of the >currently deployed mechanisms. Yes. Rich's presentation in the Hiroshima BoF largely used the same material as his GIIC slides linked above, in order to hilite the gaps that Comcast couldn't do with Capshare but would be able to do with ConEx. I agree that we all need to focus more on those gaps. Cheers Bob >Ciao >Hannes > >> >>HTH >> >> >>Bob >> >>At 13:44 02/03/2010, Tschofenig, Hannes (NSN - FI/Espoo) wrote: >>>Hi all, >>> >>>we wanted to provide a bit of details of why Alissa and I worked on >>>draft-tschofenig-conex-ps. >>> >>>Our goal for the problem statement document was >>>1) to offer a writeup that does not talk about the solution >>>2) to focus on one aspect of the perceived problem only. >>> >>>While there may be the other problems problems out there that a specific >>>solution can solve (e.g. denial of service attacks, trouble-shooting of >>>network problems) we really think that one needs to focus on one thing >>>at the time because otherwise you run into what I call the >>>HIP-effect(*). >>> >>>The problem needs to be well understood and documented before one can go >>>forward with the next step. The lack of a clear problem statement >>>discussion was for me recognizable at the BOF. >>> >>>Once people agree on the problem then it is interesting to capture the >>>state of the art as far as what tools operators are already using to >>>solve the problem. Since a number of operator believe they have a >>>problem there is a wide range of solutions they are deploying today. The >>>excellent writeup by Jason and Ric (see >>>draft-livingood-woundy-congestion-mgmt) is one example of a solution >>>that offers very interesting properties already (such as being protocol >>>agnostic). There are other solution approaches that other operators are >>>deploying but they are less well documented. Every solution has pros and >>>cons and, from what we can tell, there is no one-size fits all approach. >>> >>> >>>Unfortunately, we have not seen a lot of discussions about what is being >>>done and why the group considers them as insufficient. This leads to the >>>next point, namely to document what is not good enough with the >>>available techniques. If there is a specific problem identified, and the >>>inadequacies of the existing solutions are compelling, that argues that >>>there is space for new work in this area. >>> >>>So, in a summary we would suggest the following approach and this is >>>also the approach we will try to take as we rev our problem statement >>>(although there will certainly still be gaps), and there are some >>>elements of it in the draft-moncaster problem statement, but we wanted >>>to frame the thought process before posting a new version: >>> >>>A) Figure out whether most people agree to a description of the problem. >>> >>>(There may be multiple sub-problems.) >>> >>>B) Document the state-of-the-art (and why people have chosen a certain >>>approaches). >>> >>>C) Document the gaps that are not covered by state-of-the-art solutions >>>that would require additional work. For me a really important question >>>is what are the incentives for someone to deploy anything in addition to >>>draft-livingood-woundy-congestion-mgmt? >>> >>>There are other ways to approach the topic but we believe that this is >>>the appropriate way in this case. >>> >>>Ciao >>>Hannes & Alissa >>> >>>(*): A solution that solves all problems but none really well. >>> >>>_______________________________________________ >>>re-ECN mailing list >>>re-ECN@ietf.org >>>https://www.ietf.org/mailman/listinfo/re-ecn >> >>________________________________________________________________ >>Bob Briscoe, BT Innovate & Design >>_______________________________________________ >>re-ECN mailing list >>re-ECN@ietf.org >>https://www.ietf.org/mailman/listinfo/re-ecn > >________________________________________________________________ >Bob Briscoe, BT Innovate & Design From rbriscoe@jungle.bt.co.uk Fri Mar 5 10:09:33 2010 Return-Path: X-Original-To: re-ecn@core3.amsl.com Delivered-To: re-ecn@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 4395D3A897A for ; Fri, 5 Mar 2010 10:09:33 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.001 X-Spam-Level: X-Spam-Status: No, score=-2.001 tagged_above=-999 required=5 tests=[AWL=0.116, BAYES_00=-2.599, DNS_FROM_RFC_BOGUSMX=1.482, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id VTmUNG9i7fBL for ; Fri, 5 Mar 2010 10:09:25 -0800 (PST) Received: from smtp1.smtp.bt.com (smtp1.smtp.bt.com [217.32.164.137]) by core3.amsl.com (Postfix) with ESMTP id 7B0B93A8AB9 for ; Fri, 5 Mar 2010 10:09:25 -0800 (PST) Received: from i2kc08-ukbr.domain1.systemhost.net ([193.113.197.71]) by smtp1.smtp.bt.com with Microsoft SMTPSVC(6.0.3790.3959); Fri, 5 Mar 2010 18:09:26 +0000 Received: from cbibipnt08.iuser.iroot.adidom.com ([147.149.100.81]) by i2kc08-ukbr.domain1.systemhost.net with Microsoft SMTPSVC(6.0.3790.3959); Fri, 5 Mar 2010 18:09:26 +0000 Received: From bagheera.jungle.bt.co.uk ([132.146.168.158]) by cbibipnt08.iuser.iroot.adidom.com (WebShield SMTP v4.5 MR1a P0803.399); id 1267812566113; Fri, 5 Mar 2010 18:09:26 +0000 Received: from MUT.jungle.bt.co.uk ([10.73.179.5]) by bagheera.jungle.bt.co.uk (8.13.5/8.12.8) with ESMTP id o25I9LAi018387; Fri, 5 Mar 2010 18:09:22 GMT Message-Id: <201003051809.o25I9LAi018387@bagheera.jungle.bt.co.uk> X-Mailer: QUALCOMM Windows Eudora Version 7.1.0.9 Date: Fri, 05 Mar 2010 18:08:51 +0000 To: Alissa Cooper From: Bob Briscoe In-Reply-To: <2D8C263E-CAC5-4647-9113-B2CD4A02CE99@cdt.org> References: <3D3C75174CB95F42AD6BCC56E5555B4502424066@FIESEXC015.nsn-intra.net> <201003031622.o23GMuIE004096@bagheera.jungle.bt.co.uk> <2D8C263E-CAC5-4647-9113-B2CD4A02CE99@cdt.org> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-Scanned-By: MIMEDefang 2.56 on 132.146.168.158 X-OriginalArrivalTime: 05 Mar 2010 18:09:26.0778 (UTC) FILETIME=[FE1705A0:01CABC8E] Cc: re-ecn@ietf.org Subject: Re: [re-ECN] draft-tschofenig-conex-ps and our recommendation for the group X-BeenThere: re-ecn@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: re-inserted explicit congestion notification List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 05 Mar 2010 18:09:33 -0000 Alissa, At 15:14 04/03/2010, Alissa Cooper wrote: >Bob, > >Couple of thoughts inline. > >On Mar 3, 2010, at 4:23 PM, Bob Briscoe wrote: >>I thought draft-moncaster-conex-problem hit about the right spot - >>it focuses on the problem of accountability for causing congestion. >>Admittedly, it mentions some other things ConEx could solve, but it >>keeps focus on the one problem fairly well. >> >>Incidentally, Rich Woundy has done a presentation on what additional >>benefits re-ECN would provide over ComCast's solution: >>It's under the link to all the speaker presentations in the article >>here: >>Specifically: > >I think there is a lot to like in draft-moncaster-problem, and it does >focus to some extent on congestion accountability. But I think there >could be a clearer statement of what problem congestion accountability >would be solving. From reading the problem statement and looking at >Rich's slides, there seem to be three congestion-related problems that >congestion exposure could help to solve > >1) LEDBAT-style congestion control is not currently incentivized >because operators who use volume accounting treat apps that use it >just like everything else. This is thoroughly discussed in draft- >moncaster-problem. yes >2) Operators have no way to know, within the network, the volume of >congestion being created by other networks, and therefore no way to >hold those other networks accountable. This is not so thoroughly >discussed in draft-moncaster-problem. Yes. And you're right that draft-moncaster-problem doesn't do this aspect as much justice. >3) Users/apps need more information about congestion in order to be >able to respond better. This is not really discussed in draft- >moncaster-problem. Don't agree with this one. It's not actually true to say users/apps don't have congestion info - they have full visibility of their congestion. But this congestion information has no *significance* to users/apps, while they know that networks cannot see it. >I think it would be helpful for the group to have some sense of which >subset of these problems we are trying to solve. Then, ticking through >the mechanisms that already exist to solve the problems and showing >how they are deficient could lead to the conclusion that the >congestion exposure work is warranted (draft-moncaster-problem already >does this to some extent, but in my reading at least the link between >the stated problems, the inadequacies of the existing solutions, and >the reasons why conex would improve the situation is somewhat weak). OK. Agreed. We also need to make sure this same approach comes across in the BoF presentations. From Rich's presentation, we have the following that match your list, and add to it: ==Requirements for a long term solution:== a) Incentivize customer-directed prioritization of application bandwidth usage b) Avoid 'cat and mouse game' with the detection and mitigation of specific protocols c) Enable transparency of network operation for current and future applications d) Support growth in per-customer average and peak bandwidth e) Avoid uneconomic capacity upgrades that benefit only 5% of heavy usage customers ==Advantages of re-ECN over FairShare:== f) Re-ECN enables end-to-end congestion management g) Re-ECN signals the presence of congestion to user applications and to all devices on the network path h) Re-ECN enables additional user and/or application responses to congestion i) Re-ECN enables DDoS mitigation and other capabilities a) = your #1) b) ConEx is not unique in this respect c) = perhaps an additional particularly strong point of ConEx? d) & e) supply side strengths of ConEx f) = your #2) g) = your #3) but I say the Internet already does this well h) = your #1 again i) another strength of ConEx, but only to be mentioned in passing; We're left with the following unique selling points: a) Incentivize customer-controlled prioritization of app bandwidth usage c) Enable unambiguous transparent network operations for current & future apps d) Drive capacity investment where financially warranted f) Enable e2e congestion mgmt between networks as well as by single networks i) Enable DDoS mitigation [only to mention in passing] HTH Bob >Alissa > >>HTH >> >> >>Bob >> >>At 13:44 02/03/2010, Tschofenig, Hannes (NSN - FI/Espoo) wrote: >>>Hi all, >>> >>>we wanted to provide a bit of details of why Alissa and I worked on >>>draft-tschofenig-conex-ps. >>> >>>Our goal for the problem statement document was >>>1) to offer a writeup that does not talk about the solution >>>2) to focus on one aspect of the perceived problem only. >>> >>>While there may be the other problems problems out there that a >>>specific >>>solution can solve (e.g. denial of service attacks, trouble- shooting of >>>network problems) we really think that one needs to focus on one >>>thing >>>at the time because otherwise you run into what I call the >>>HIP-effect(*). >>> >>>The problem needs to be well understood and documented before one >>>can go >>>forward with the next step. The lack of a clear problem statement >>>discussion was for me recognizable at the BOF. >>> >>>Once people agree on the problem then it is interesting to capture >>>the >>>state of the art as far as what tools operators are already using to >>>solve the problem. Since a number of operator believe they have a >>>problem there is a wide range of solutions they are deploying >>>today. The >>>excellent writeup by Jason and Ric (see >>>draft-livingood-woundy-congestion-mgmt) is one example of a solution >>>that offers very interesting properties already (such as being >>>protocol >>>agnostic). There are other solution approaches that other operators >>>are >>>deploying but they are less well documented. Every solution has >>>pros and >>>cons and, from what we can tell, there is no one-size fits all >>>approach. >>> >>> >>>Unfortunately, we have not seen a lot of discussions about what is >>>being >>>done and why the group considers them as insufficient. This leads >>>to the >>>next point, namely to document what is not good enough with the >>>available techniques. If there is a specific problem identified, >>>and the >>>inadequacies of the existing solutions are compelling, that argues >>>that >>>there is space for new work in this area. >>> >>>So, in a summary we would suggest the following approach and this is >>>also the approach we will try to take as we rev our problem >>>statement >>>(although there will certainly still be gaps), and there are some >>>elements of it in the draft-moncaster problem statement, but we >>>wanted >>>to frame the thought process before posting a new version: >>> >>>A) Figure out whether most people agree to a description of the >>>problem. >>> >>>(There may be multiple sub-problems.) >>> >>>B) Document the state-of-the-art (and why people have chosen a >>>certain >>>approaches). >>> >>>C) Document the gaps that are not covered by state-of-the-art >>>solutions >>>that would require additional work. For me a really important >>>question >>>is what are the incentives for someone to deploy anything in >>>addition to >>>draft-livingood-woundy-congestion-mgmt? >>> >>>There are other ways to approach the topic but we believe that this >>>is >>>the appropriate way in this case. >>> >>>Ciao >>>Hannes & Alissa >>> >>>(*): A solution that solves all problems but none really well. >>> >>>_______________________________________________ >>>re-ECN mailing list >>>re-ECN@ietf.org >>>https://www.ietf.org/mailman/listinfo/re-ecn >> >>________________________________________________________________ >>Bob Briscoe, BT Innovate & Design >>_______________________________________________ >>re-ECN mailing list >>re-ECN@ietf.org >>https://www.ietf.org/mailman/listinfo/re-ecn ________________________________________________________________ Bob Briscoe, BT Innovate & Design From philip.eardley@bt.com Fri Mar 5 11:28:21 2010 Return-Path: X-Original-To: re-ecn@core3.amsl.com Delivered-To: re-ecn@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 6E0D83A83F1 for ; Fri, 5 Mar 2010 11:28:21 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.47 X-Spam-Level: X-Spam-Status: No, score=-3.47 tagged_above=-999 required=5 tests=[AWL=0.129, 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 2ceKQYAt6Q6m for ; Fri, 5 Mar 2010 11:28:19 -0800 (PST) Received: from smtp1.smtp.bt.com (smtp1.smtp.bt.com [217.32.164.137]) by core3.amsl.com (Postfix) with ESMTP id B50C028C129 for ; Fri, 5 Mar 2010 11:28:18 -0800 (PST) Received: from E03MVB1-UKBR.domain1.systemhost.net ([193.113.197.110]) by smtp1.smtp.bt.com with Microsoft SMTPSVC(6.0.3790.3959); Fri, 5 Mar 2010 19:28:20 +0000 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Fri, 5 Mar 2010 19:27:37 -0000 Message-ID: <4A916DBC72536E419A0BD955EDECEDEC06363E9B@E03MVB1-UKBR.domain1.systemhost.net> In-Reply-To: <201003051809.o25I9LAi018387@bagheera.jungle.bt.co.uk> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [re-ECN] draft-tschofenig-conex-ps and our recommendation for the group thread-index: Acq8jwa38caoi5CgRROeYP5rtTBv8AAB9C7Q From: To: , X-OriginalArrivalTime: 05 Mar 2010 19:28:20.0275 (UTC) FILETIME=[03795830:01CABC9A] Cc: re-ecn@ietf.org Subject: Re: [re-ECN] draft-tschofenig-conex-ps and our recommendation for the group X-BeenThere: re-ecn@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: re-inserted explicit congestion notification List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 05 Mar 2010 19:28:21 -0000 I think reason (2) is the key one - the inter-network aspect. This is the new thing.=20 If the only problem of interest is an intra-network one (eg if congestion is always in just one network), then there will be several possible solutions. The livingwood draft documents an interesting one for instance. DPI-based solutions would be another method of different interest. can imagine conex-based solutions as well (see moncaster & other drafts). ---- Looking at the list of "requirements for a solution" prompts the thought that we should distinguish two things: - the conex "building block" - the ability for any node to see the rest-of-path congestion (& the whole path congestion) - the solutions to various aspects of 'congestion mgt' that can be built using the conex "building block" The conex draft charter proposes work on the first of these (ie to standardise the IP header bits so that whole-path congestion info is exposed (visible) to all nodes on the path, and to define a TCP-based mechanism that allows a TCP destination to tell the source the whole-path info, & hence the IP header can be set by the source) The conex draft charter only proposes a little work on the second of these. This work item is to encourage experiments on some "use cases" and document about them. I guess the "use cases" would be tests towards a solution (to some aspect of congestion mgt) that might get deployed by an operator.=20 We should be clear: the charter doesn't propose to standardise a full solution that would get deployed. Rather it standardises a capability which would be used to build a solution.=20 Not sure if everyone will agree with this! phil > -----Original Message----- > From: re-ecn-bounces@ietf.org=20 > [mailto:re-ecn-bounces@ietf.org] On Behalf Of Bob Briscoe > Sent: 05 March 2010 18:09 > To: Alissa Cooper > Cc: re-ecn@ietf.org > Subject: Re: [re-ECN] draft-tschofenig-conex-ps and our=20 > recommendation for the group >=20 >=20 > Alissa, >=20 > At 15:14 04/03/2010, Alissa Cooper wrote: > >Bob, > > > >Couple of thoughts inline. > > > >On Mar 3, 2010, at 4:23 PM, Bob Briscoe wrote: > >>I thought draft-moncaster-conex-problem hit about the right=20 > spot - it=20 > >>focuses on the problem of accountability for causing congestion.=20 > >>Admittedly, it mentions some other things ConEx could solve, but it=20 > >>keeps focus on the one problem fairly well. > >> > >>Incidentally, Rich Woundy has done a presentation on what=20 > additional=20 > >>benefits re-ECN would provide over ComCast's solution: It's=20 > under the=20 > >>link to all the speaker presentations in the article > >>here: > >>Specifically:=20 > >> > > > >I think there is a lot to like in draft-moncaster-problem,=20 > and it does=20 > >focus to some extent on congestion accountability. But I think there=20 > >could be a clearer statement of what problem congestion=20 > accountability=20 > >would be solving. From reading the problem statement and looking at=20 > >Rich's slides, there seem to be three congestion-related=20 > problems that=20 > >congestion exposure could help to solve > > > >1) LEDBAT-style congestion control is not currently incentivized=20 > >because operators who use volume accounting treat apps that=20 > use it just=20 > >like everything else. This is thoroughly discussed in draft-=20 > >moncaster-problem. >=20 > yes >=20 >=20 > >2) Operators have no way to know, within the network, the volume of=20 > >congestion being created by other networks, and therefore no way to=20 > >hold those other networks accountable. This is not so thoroughly=20 > >discussed in draft-moncaster-problem. >=20 > Yes. > And you're right that draft-moncaster-problem doesn't do this aspect=20 > as much justice. >=20 >=20 > >3) Users/apps need more information about congestion in order to be=20 > >able to respond better. This is not really discussed in draft-=20 > >moncaster-problem. >=20 > Don't agree with this one. It's not actually true to say users/apps=20 > don't have congestion info - they have full visibility of=20 > their congestion. >=20 > But this congestion information has no *significance* to users/apps,=20 > while they know that networks cannot see it. >=20 >=20 > >I think it would be helpful for the group to have some sense=20 > of which=20 > >subset of these problems we are trying to solve. Then,=20 > ticking through=20 > >the mechanisms that already exist to solve the problems and=20 > showing how=20 > >they are deficient could lead to the conclusion that the congestion=20 > >exposure work is warranted (draft-moncaster-problem already=20 > does this=20 > >to some extent, but in my reading at least the link between=20 > the stated=20 > >problems, the inadequacies of the existing solutions, and=20 > the reasons=20 > >why conex would improve the situation is somewhat weak). >=20 > OK. Agreed. > We also need to make sure this same approach comes across in the BoF=20 > presentations. >=20 > From Rich's presentation, we have the following that match your=20 > list, and add to it: > =3D=3DRequirements for a long term solution:=3D=3D > a) Incentivize customer-directed prioritization of=20 > application bandwidth usage > b) Avoid 'cat and mouse game' with the detection and mitigation of=20 > specific protocols > c) Enable transparency of network operation for current and=20 > future applications > d) Support growth in per-customer average and peak bandwidth > e) Avoid uneconomic capacity upgrades that benefit only 5% of heavy=20 > usage customers > =3D=3DAdvantages of re-ECN over FairShare:=3D=3D > f) Re-ECN enables end-to-end congestion management > g) Re-ECN signals the presence of congestion to user applications and=20 > to all devices on the network path > h) Re-ECN enables additional user and/or application=20 > responses to congestion > i) Re-ECN enables DDoS mitigation and other capabilities >=20 > a) =3D your #1) > b) ConEx is not unique in this respect > c) =3D perhaps an additional particularly strong point of ConEx? > d) & e) supply side strengths of ConEx > f) =3D your #2) > g) =3D your #3) but I say the Internet already does this well > h) =3D your #1 again > i) another strength of ConEx, but only to be mentioned in passing; >=20 > We're left with the following unique selling points: > a) Incentivize customer-controlled prioritization of app=20 > bandwidth usage > c) Enable unambiguous transparent network operations for=20 > current & future apps > d) Drive capacity investment where financially warranted > f) Enable e2e congestion mgmt between networks as well as by=20 > single networks > i) Enable DDoS mitigation [only to mention in passing] >=20 > HTH >=20 >=20 > Bob >=20 > >Alissa > > > >>HTH > >> > >> > >>Bob > >> > >>At 13:44 02/03/2010, Tschofenig, Hannes (NSN - FI/Espoo) wrote: > >>>Hi all, > >>> > >>>we wanted to provide a bit of details of why Alissa and I=20 > worked on=20 > >>>draft-tschofenig-conex-ps. > >>> > >>>Our goal for the problem statement document was > >>>1) to offer a writeup that does not talk about the solution > >>>2) to focus on one aspect of the perceived problem only. > >>> > >>>While there may be the other problems problems out there that a=20 > >>>specific solution can solve (e.g. denial of service=20 > attacks, trouble-=20 > >>>shooting of network problems) we really think that one=20 > needs to focus=20 > >>>on one thing > >>>at the time because otherwise you run into what I call the > >>>HIP-effect(*). > >>> > >>>The problem needs to be well understood and documented=20 > before one can=20 > >>>go forward with the next step. The lack of a clear problem=20 > statement > >>>discussion was for me recognizable at the BOF. > >>> > >>>Once people agree on the problem then it is interesting to capture=20 > >>>the state of the art as far as what tools operators are=20 > already using=20 > >>>to solve the problem. Since a number of operator believe=20 > they have a > >>>problem there is a wide range of solutions they are deploying > >>>today. The > >>>excellent writeup by Jason and Ric (see > >>>draft-livingood-woundy-congestion-mgmt) is one example of=20 > a solution > >>>that offers very interesting properties already (such as being > >>>protocol > >>>agnostic). There are other solution approaches that other operators > >>>are > >>>deploying but they are less well documented. Every solution has > >>>pros and > >>>cons and, from what we can tell, there is no one-size fits all > >>>approach. > >>> > >>> > >>>Unfortunately, we have not seen a lot of discussions about what is=20 > >>>being done and why the group considers them as insufficient. This=20 > >>>leads to the > >>>next point, namely to document what is not good enough with the > >>>available techniques. If there is a specific problem identified, > >>>and the > >>>inadequacies of the existing solutions are compelling, that argues > >>>that > >>>there is space for new work in this area. > >>> > >>>So, in a summary we would suggest the following approach=20 > and this is=20 > >>>also the approach we will try to take as we rev our problem=20 > >>>statement (although there will certainly still be gaps), and there=20 > >>>are some elements of it in the draft-moncaster problem=20 > statement, but=20 > >>>we wanted > >>>to frame the thought process before posting a new version: > >>> > >>>A) Figure out whether most people agree to a description of the=20 > >>>problem. > >>> > >>>(There may be multiple sub-problems.) > >>> > >>>B) Document the state-of-the-art (and why people have chosen a=20 > >>>certain approaches). > >>> > >>>C) Document the gaps that are not covered by state-of-the-art=20 > >>>solutions that would require additional work. For me a really=20 > >>>important question > >>>is what are the incentives for someone to deploy anything in > >>>addition to > >>>draft-livingood-woundy-congestion-mgmt? > >>> > >>>There are other ways to approach the topic but we believe=20 > that this=20 > >>>is the appropriate way in this case. > >>> > >>>Ciao > >>>Hannes & Alissa > >>> > >>>(*): A solution that solves all problems but none really well. > >>> > >>>_______________________________________________ > >>>re-ECN mailing list > >>>re-ECN@ietf.org > >>>https://www.ietf.org/mailman/listinfo/re-ecn > >> > >>________________________________________________________________ > >>Bob Briscoe, BT Innovate & Design > >>_______________________________________________ > >>re-ECN mailing list > >>re-ECN@ietf.org > >>https://www.ietf.org/mailman/listinfo/re-ecn >=20 > ________________________________________________________________ > Bob Briscoe, BT Innovate & Design=20 >=20 > _______________________________________________ > re-ECN mailing list > re-ECN@ietf.org > https://www.ietf.org/mailman/listinfo/re-ecn >=20 From acooper@cdt.org Sun Mar 7 12:47:44 2010 Return-Path: X-Original-To: re-ecn@core3.amsl.com Delivered-To: re-ecn@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id BF9F928C103 for ; Sun, 7 Mar 2010 12:47:44 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.413 X-Spam-Level: X-Spam-Status: No, score=-2.413 tagged_above=-999 required=5 tests=[AWL=0.186, 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 y+bZ-4kRyttS for ; Sun, 7 Mar 2010 12:47:43 -0800 (PST) Received: from mail.maclaboratory.net (mail.maclaboratory.net [209.190.215.232]) by core3.amsl.com (Postfix) with ESMTP id A24A43A91A1 for ; Sun, 7 Mar 2010 12:47:42 -0800 (PST) Received: from [10.0.205.31] ([129.67.117.70]) (authenticated user acooper@cdt.org) by mail.maclaboratory.net (using TLSv1/SSLv3 with cipher AES128-SHA (128 bits)); Sun, 7 Mar 2010 15:47:34 -0500 Message-Id: From: Alissa Cooper To: In-Reply-To: <4A916DBC72536E419A0BD955EDECEDEC06363E9B@E03MVB1-UKBR.domain1.systemhost.net> Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v936) Date: Sun, 7 Mar 2010 20:47:29 +0000 References: <4A916DBC72536E419A0BD955EDECEDEC06363E9B@E03MVB1-UKBR.domain1.systemhost.net> X-Mailer: Apple Mail (2.936) Cc: re-ecn@ietf.org Subject: Re: [re-ECN] draft-tschofenig-conex-ps and our recommendation for the group X-BeenThere: re-ecn@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: re-inserted explicit congestion notification List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 07 Mar 2010 20:47:44 -0000 Phil and Bob, On Mar 5, 2010, at 7:27 PM, wrote: > I think reason (2) is the key one - the inter-network aspect. This is > the new thing. > If the only problem of interest is an intra-network one (eg if > congestion is always in just one network), then there will be several > possible solutions. The livingwood draft documents an interesting one > for instance. DPI-based solutions would be another method of different > interest. can imagine conex-based solutions as well (see moncaster & > other drafts). > This is, I think, what Hannes and I have been trying to elucidate. Here's Bob's list of selling points: >> We're left with the following unique selling points: >> a) Incentivize customer-controlled prioritization of app >> bandwidth usage >> c) Enable unambiguous transparent network operations for >> current & future apps >> d) Drive capacity investment where financially warranted >> f) Enable e2e congestion mgmt between networks as well as by >> single networks >> i) Enable DDoS mitigation [only to mention in passing] I think the list is more or less on target -- but identifying all of the great things about conex (the selling points) is not the same as identifying the problem that the work is supposed to solve. I'm not saying that there isn't a need to emphasize the selling points, but I am saying that if the selling points are in the problem statement, there needs to be some demonstration of the problem that they solve. Thus far, the links between the problems of lack of transparency and inter-network congestion management have not been so strongly linked to (c) and (f), respectively, and (i) might better be saved for later so as not to distract. But, if the central problem is that there's no way to manage inter- network congestion as Phil says, that's what the problem statement should focus on, and not all of these other things. Neither of the drafts do that right now. I'm not trying to be critical, I'm just hoping to get us to a place where the IESG sees the value of the work. > ---- > > Looking at the list of "requirements for a solution" prompts the > thought > that we should distinguish two things: > > - the conex "building block" - the ability for any node to see the > rest-of-path congestion (& the whole path congestion) > - the solutions to various aspects of 'congestion mgt' that can be > built > using the conex "building block" > > The conex draft charter proposes work on the first of these (ie to > standardise the IP header bits so that whole-path congestion info is > exposed (visible) to all nodes on the path, and to define a TCP-based > mechanism that allows a TCP destination to tell the source the > whole-path info, & hence the IP header can be set by the source) > > The conex draft charter only proposes a little work on the second of > these. This work item is to encourage experiments on some "use cases" > and document about them. I guess the "use cases" would be tests > towards > a solution (to some aspect of congestion mgt) that might get > deployed by > an operator. I don't see anything wrong with this approach. The use cases are bound to come up all the time though, since it can sometimes be difficult to conceptualize the building block without an example of what you would do with the building block. That's probably also why we end up with solutions discussions in problem statement documents. :) Alissa > > We should be clear: the charter doesn't propose to standardise a full > solution that would get deployed. Rather it standardises a capability > which would be used to build a solution. > > Not sure if everyone will agree with this! > > phil > >> -----Original Message----- >> From: re-ecn-bounces@ietf.org >> [mailto:re-ecn-bounces@ietf.org] On Behalf Of Bob Briscoe >> Sent: 05 March 2010 18:09 >> To: Alissa Cooper >> Cc: re-ecn@ietf.org >> Subject: Re: [re-ECN] draft-tschofenig-conex-ps and our >> recommendation for the group >> >> >> Alissa, >> >> At 15:14 04/03/2010, Alissa Cooper wrote: >>> Bob, >>> >>> Couple of thoughts inline. >>> >>> On Mar 3, 2010, at 4:23 PM, Bob Briscoe wrote: >>>> I thought draft-moncaster-conex-problem hit about the right >> spot - it >>>> focuses on the problem of accountability for causing congestion. >>>> Admittedly, it mentions some other things ConEx could solve, but it >>>> keeps focus on the one problem fairly well. >>>> >>>> Incidentally, Rich Woundy has done a presentation on what >> additional >>>> benefits re-ECN would provide over ComCast's solution: It's >> under the >>>> link to all the speaker presentations in the article >>>> here: >>>> Specifically: >>>> >>> >>> I think there is a lot to like in draft-moncaster-problem, >> and it does >>> focus to some extent on congestion accountability. But I think there >>> could be a clearer statement of what problem congestion >> accountability >>> would be solving. From reading the problem statement and looking at >>> Rich's slides, there seem to be three congestion-related >> problems that >>> congestion exposure could help to solve >>> >>> 1) LEDBAT-style congestion control is not currently incentivized >>> because operators who use volume accounting treat apps that >> use it just >>> like everything else. This is thoroughly discussed in draft- >>> moncaster-problem. >> >> yes >> >> >>> 2) Operators have no way to know, within the network, the volume of >>> congestion being created by other networks, and therefore no way to >>> hold those other networks accountable. This is not so thoroughly >>> discussed in draft-moncaster-problem. >> >> Yes. >> And you're right that draft-moncaster-problem doesn't do this aspect >> as much justice. >> >> >>> 3) Users/apps need more information about congestion in order to be >>> able to respond better. This is not really discussed in draft- >>> moncaster-problem. >> >> Don't agree with this one. It's not actually true to say users/apps >> don't have congestion info - they have full visibility of >> their congestion. >> >> But this congestion information has no *significance* to users/apps, >> while they know that networks cannot see it. >> >> >>> I think it would be helpful for the group to have some sense >> of which >>> subset of these problems we are trying to solve. Then, >> ticking through >>> the mechanisms that already exist to solve the problems and >> showing how >>> they are deficient could lead to the conclusion that the congestion >>> exposure work is warranted (draft-moncaster-problem already >> does this >>> to some extent, but in my reading at least the link between >> the stated >>> problems, the inadequacies of the existing solutions, and >> the reasons >>> why conex would improve the situation is somewhat weak). >> >> OK. Agreed. >> We also need to make sure this same approach comes across in the BoF >> presentations. >> >> From Rich's presentation, we have the following that match your >> list, and add to it: >> ==Requirements for a long term solution:== >> a) Incentivize customer-directed prioritization of >> application bandwidth usage >> b) Avoid 'cat and mouse game' with the detection and mitigation of >> specific protocols >> c) Enable transparency of network operation for current and >> future applications >> d) Support growth in per-customer average and peak bandwidth >> e) Avoid uneconomic capacity upgrades that benefit only 5% of heavy >> usage customers >> ==Advantages of re-ECN over FairShare:== >> f) Re-ECN enables end-to-end congestion management >> g) Re-ECN signals the presence of congestion to user applications and >> to all devices on the network path >> h) Re-ECN enables additional user and/or application >> responses to congestion >> i) Re-ECN enables DDoS mitigation and other capabilities >> >> a) = your #1) >> b) ConEx is not unique in this respect >> c) = perhaps an additional particularly strong point of ConEx? >> d) & e) supply side strengths of ConEx >> f) = your #2) >> g) = your #3) but I say the Internet already does this well >> h) = your #1 again >> i) another strength of ConEx, but only to be mentioned in passing; >> >> We're left with the following unique selling points: >> a) Incentivize customer-controlled prioritization of app >> bandwidth usage >> c) Enable unambiguous transparent network operations for >> current & future apps >> d) Drive capacity investment where financially warranted >> f) Enable e2e congestion mgmt between networks as well as by >> single networks >> i) Enable DDoS mitigation [only to mention in passing] >> >> HTH >> >> >> Bob >> >>> Alissa >>> >>>> HTH >>>> >>>> >>>> Bob >>>> >>>> At 13:44 02/03/2010, Tschofenig, Hannes (NSN - FI/Espoo) wrote: >>>>> Hi all, >>>>> >>>>> we wanted to provide a bit of details of why Alissa and I >> worked on >>>>> draft-tschofenig-conex-ps. >>>>> >>>>> Our goal for the problem statement document was >>>>> 1) to offer a writeup that does not talk about the solution >>>>> 2) to focus on one aspect of the perceived problem only. >>>>> >>>>> While there may be the other problems problems out there that a >>>>> specific solution can solve (e.g. denial of service >> attacks, trouble- >>>>> shooting of network problems) we really think that one >> needs to focus >>>>> on one thing >>>>> at the time because otherwise you run into what I call the >>>>> HIP-effect(*). >>>>> >>>>> The problem needs to be well understood and documented >> before one can >>>>> go forward with the next step. The lack of a clear problem >> statement >>>>> discussion was for me recognizable at the BOF. >>>>> >>>>> Once people agree on the problem then it is interesting to capture >>>>> the state of the art as far as what tools operators are >> already using >>>>> to solve the problem. Since a number of operator believe >> they have a >>>>> problem there is a wide range of solutions they are deploying >>>>> today. The >>>>> excellent writeup by Jason and Ric (see >>>>> draft-livingood-woundy-congestion-mgmt) is one example of >> a solution >>>>> that offers very interesting properties already (such as being >>>>> protocol >>>>> agnostic). There are other solution approaches that other >>>>> operators >>>>> are >>>>> deploying but they are less well documented. Every solution has >>>>> pros and >>>>> cons and, from what we can tell, there is no one-size fits all >>>>> approach. >>>>> >>>>> >>>>> Unfortunately, we have not seen a lot of discussions about what is >>>>> being done and why the group considers them as insufficient. This >>>>> leads to the >>>>> next point, namely to document what is not good enough with the >>>>> available techniques. If there is a specific problem identified, >>>>> and the >>>>> inadequacies of the existing solutions are compelling, that argues >>>>> that >>>>> there is space for new work in this area. >>>>> >>>>> So, in a summary we would suggest the following approach >> and this is >>>>> also the approach we will try to take as we rev our problem >>>>> statement (although there will certainly still be gaps), and there >>>>> are some elements of it in the draft-moncaster problem >> statement, but >>>>> we wanted >>>>> to frame the thought process before posting a new version: >>>>> >>>>> A) Figure out whether most people agree to a description of the >>>>> problem. >>>>> >>>>> (There may be multiple sub-problems.) >>>>> >>>>> B) Document the state-of-the-art (and why people have chosen a >>>>> certain approaches). >>>>> >>>>> C) Document the gaps that are not covered by state-of-the-art >>>>> solutions that would require additional work. For me a really >>>>> important question >>>>> is what are the incentives for someone to deploy anything in >>>>> addition to >>>>> draft-livingood-woundy-congestion-mgmt? >>>>> >>>>> There are other ways to approach the topic but we believe >> that this >>>>> is the appropriate way in this case. >>>>> >>>>> Ciao >>>>> Hannes & Alissa >>>>> >>>>> (*): A solution that solves all problems but none really well. >>>>> >>>>> _______________________________________________ >>>>> re-ECN mailing list >>>>> re-ECN@ietf.org >>>>> https://www.ietf.org/mailman/listinfo/re-ecn >>>> >>>> ________________________________________________________________ >>>> Bob Briscoe, BT Innovate & Design >>>> _______________________________________________ >>>> re-ECN mailing list >>>> re-ECN@ietf.org >>>> https://www.ietf.org/mailman/listinfo/re-ecn >> >> ________________________________________________________________ >> Bob Briscoe, BT Innovate & Design >> >> _______________________________________________ >> re-ECN mailing list >> re-ECN@ietf.org >> https://www.ietf.org/mailman/listinfo/re-ecn >> > From leslie@thinkingcat.com Sun Mar 7 15:34:00 2010 Return-Path: X-Original-To: re-ecn@core3.amsl.com Delivered-To: re-ecn@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id CF3813A659A for ; Sun, 7 Mar 2010 15:34:00 -0800 (PST) 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 uCXbpUHLY+1L for ; Sun, 7 Mar 2010 15:33:58 -0800 (PST) Received: from zeke.ecotroph.net (zeke.ecotroph.net [70.164.19.155]) by core3.amsl.com (Postfix) with ESMTP id 02A9E3A67A3 for ; Sun, 7 Mar 2010 15:33:57 -0800 (PST) Received: from beethoven.local ([::ffff:173.71.206.39]) (AUTH: PLAIN leslie, SSL: TLSv1/SSLv3,256bits,AES256-SHA) by zeke.ecotroph.net with esmtp; Sun, 07 Mar 2010 18:33:59 -0500 id 015B005B.4B9437E8.000008DD Message-ID: <4B9437DF.30804@thinkingcat.com> Date: Sun, 07 Mar 2010 18:33:51 -0500 From: Leslie Daigle User-Agent: Thunderbird 2.0.0.23 (Macintosh/20090812) MIME-Version: 1.0 To: Alissa Cooper References: <4A916DBC72536E419A0BD955EDECEDEC06363E9B@E03MVB1-UKBR.domain1.systemhost.net> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: re-ecn@ietf.org Subject: [re-ECN] Congestion exposure problem statement Re: draft-tschofenig-conex-ps and our recommendation for the group X-BeenThere: re-ecn@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: re-inserted explicit congestion notification List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 07 Mar 2010 23:34:00 -0000 Hi, I think this [Alissa wrote:] > I think the list is more or less on target -- but identifying all of the > great things about conex (the selling points) is not the same as > identifying the problem that the work is supposed to solve. I'm not > saying that there isn't a need to emphasize the selling points, but I am > saying that if the selling points are in the problem statement, there > needs to be some demonstration of the problem that they solve. is a very fair critique of where the documents & discussion stand today. The 3 things on the table, that we keep mixing together and seem not to be crisp about, are: 1. Congestion exposure -- a proposed, generative technology. A building block, as Phil said. This is where the problem statement should focus. 2. Potential applications and solutions that can be built with a congestion exposure technology in place. These are important to see in order to understand usefulness of the technology, but they are not the "it" for which the problem statement should be written. 3. re-ECN -- which is an excellent proof point that congestion exposure technologies are possible, that desirable effects can be achieved using them, and applications and solutions can be built on them. Whether it's how we say it, or how it gets heard -- when we talk about things that have been built on re-ECN, we get miles away from "1." -- congestion exposure and its problem statement. Where we want to get to with CONEX is a solid problem statement for 1., and a plan to develop or shake out an actual implementation -- whether it starts from re-ECN or not. [Elsewhere, I wrote:] > > My personal cut on the CONEX work statement, separating out the > technology specification from its potential uses: > > Flow-rate fairness is acknowledged to provide a "rough, simple fairness > model" and is also acknowledged to have its limitations [RFC5290]. It is > not possible to ensure a fair share of aggregate capacity through > end-to-end congestion control alone. However, addressing this > shortcoming in application-, service- or network-specific ways leads to > considerable complexity in network management and undermines the general > applicability of the Internet. > > The purpose of the CONEX working group is to develop a mechanism by > which IP datagrams can signal the total rest-of-path congestion that > they are expecting along the entire path they are traversing. This > information is currently only visible at the transport layer in the end > systems. > > Once any node can see the impact it causes (and suffers) by sending or > forwarding packets, it will be possible for nodes to make choices based > on expected conditions, enabling a more sophisticated overall congestion > management spanning multiple networks and without getting into > application- or service-specific rules. > > The text above describes congestion exposure, the intended work of > CONEX. Separately, potential outcomes of this more sophisticated > congestion management include tools that exploit the CONEX output to > mitigate distributed denial of service (DDoS) attacks; simplify > differentiation of quality of service (QoS); police compliance to > congestion control; and don't require compute-intensive (and > questionably-appropriate) DPI practices. > > > > > The intended purpose of CONEX is to develop a generative technology: > building blocks to allow more sophisticated and network-sensitive > congestion management than is possible with the data available to nodes > today. This is a good way to architect for future-proof networking, if > you believe in open, best-effort packet transmission networking as > opposed to virtual circuits. It does make a challenge for determining > "deployability". ISPs will deploy solutions, not technology: solutions > enabled by the CONEX building blocks. > > > > > So, what do we have? > > We have proof of concept that congestion exposure works: the research > work that Bob Briscoe, BT and others have done on re-ECN demonstrates > that it is possible to implement congestion exposure, and build the > types of tools outlined above. > > We have technical experts from ISPs acknowledging that it would be nice > to have tools that recognize conditions beyond the edges of their own > networks. > > > > What is missing? > > While re-ECN demonstrates the validity of the concept, it is not clear > if it is the "right" choice for the overall Internet, and what would be > the correct engineering choices in its specification in order to ensure > that it aligns well with other TCP specifications underway (e.g., > multipath TCP). > > > Personally, I don't have answers to those questions -- I believe they > are open. I also believe that the only environment that can find the > answers is the IETF. This is not research any longer. re-ECN is not > something that should be specified and deployed by a private interest. > Whether or not it plays well with other protocols requires broader input > from engineers from many different angles, which is what a WG > environment is supposed to provide. Leslie. Alissa Cooper wrote: > Phil and Bob, > > On Mar 5, 2010, at 7:27 PM, > wrote: > >> I think reason (2) is the key one - the inter-network aspect. This is >> the new thing. >> If the only problem of interest is an intra-network one (eg if >> congestion is always in just one network), then there will be several >> possible solutions. The livingwood draft documents an interesting one >> for instance. DPI-based solutions would be another method of different >> interest. can imagine conex-based solutions as well (see moncaster & >> other drafts). >> > > This is, I think, what Hannes and I have been trying to elucidate. > Here's Bob's list of selling points: > >>> We're left with the following unique selling points: >>> a) Incentivize customer-controlled prioritization of app >>> bandwidth usage >>> c) Enable unambiguous transparent network operations for >>> current & future apps >>> d) Drive capacity investment where financially warranted >>> f) Enable e2e congestion mgmt between networks as well as by >>> single networks >>> i) Enable DDoS mitigation [only to mention in passing] > > > I think the list is more or less on target -- but identifying all of the > great things about conex (the selling points) is not the same as > identifying the problem that the work is supposed to solve. I'm not > saying that there isn't a need to emphasize the selling points, but I am > saying that if the selling points are in the problem statement, there > needs to be some demonstration of the problem that they solve. Thus far, > the links between the problems of lack of transparency and inter-network > congestion management have not been so strongly linked to (c) and (f), > respectively, and (i) might better be saved for later so as not to > distract. > > But, if the central problem is that there's no way to manage > inter-network congestion as Phil says, that's what the problem statement > should focus on, and not all of these other things. Neither of the > drafts do that right now. > > I'm not trying to be critical, I'm just hoping to get us to a place > where the IESG sees the value of the work. > > >> ---- >> >> Looking at the list of "requirements for a solution" prompts the thought >> that we should distinguish two things: >> >> - the conex "building block" - the ability for any node to see the >> rest-of-path congestion (& the whole path congestion) >> - the solutions to various aspects of 'congestion mgt' that can be built >> using the conex "building block" >> >> The conex draft charter proposes work on the first of these (ie to >> standardise the IP header bits so that whole-path congestion info is >> exposed (visible) to all nodes on the path, and to define a TCP-based >> mechanism that allows a TCP destination to tell the source the >> whole-path info, & hence the IP header can be set by the source) >> >> The conex draft charter only proposes a little work on the second of >> these. This work item is to encourage experiments on some "use cases" >> and document about them. I guess the "use cases" would be tests towards >> a solution (to some aspect of congestion mgt) that might get deployed by >> an operator. > > I don't see anything wrong with this approach. The use cases are bound > to come up all the time though, since it can sometimes be difficult to > conceptualize the building block without an example of what you would do > with the building block. That's probably also why we end up with > solutions discussions in problem statement documents. :) > > Alissa > >> >> We should be clear: the charter doesn't propose to standardise a full >> solution that would get deployed. Rather it standardises a capability >> which would be used to build a solution. >> >> Not sure if everyone will agree with this! >> >> phil >> >>> -----Original Message----- >>> From: re-ecn-bounces@ietf.org >>> [mailto:re-ecn-bounces@ietf.org] On Behalf Of Bob Briscoe >>> Sent: 05 March 2010 18:09 >>> To: Alissa Cooper >>> Cc: re-ecn@ietf.org >>> Subject: Re: [re-ECN] draft-tschofenig-conex-ps and our >>> recommendation for the group >>> >>> >>> Alissa, >>> >>> At 15:14 04/03/2010, Alissa Cooper wrote: >>>> Bob, >>>> >>>> Couple of thoughts inline. >>>> >>>> On Mar 3, 2010, at 4:23 PM, Bob Briscoe wrote: >>>>> I thought draft-moncaster-conex-problem hit about the right >>> spot - it >>>>> focuses on the problem of accountability for causing congestion. >>>>> Admittedly, it mentions some other things ConEx could solve, but it >>>>> keeps focus on the one problem fairly well. >>>>> >>>>> Incidentally, Rich Woundy has done a presentation on what >>> additional >>>>> benefits re-ECN would provide over ComCast's solution: It's >>> under the >>>>> link to all the speaker presentations in the article >>>>> here: >>>>> Specifically: >>>>> >>>> >>>> I think there is a lot to like in draft-moncaster-problem, >>> and it does >>>> focus to some extent on congestion accountability. But I think there >>>> could be a clearer statement of what problem congestion >>> accountability >>>> would be solving. From reading the problem statement and looking at >>>> Rich's slides, there seem to be three congestion-related >>> problems that >>>> congestion exposure could help to solve >>>> >>>> 1) LEDBAT-style congestion control is not currently incentivized >>>> because operators who use volume accounting treat apps that >>> use it just >>>> like everything else. This is thoroughly discussed in draft- >>>> moncaster-problem. >>> >>> yes >>> >>> >>>> 2) Operators have no way to know, within the network, the volume of >>>> congestion being created by other networks, and therefore no way to >>>> hold those other networks accountable. This is not so thoroughly >>>> discussed in draft-moncaster-problem. >>> >>> Yes. >>> And you're right that draft-moncaster-problem doesn't do this aspect >>> as much justice. >>> >>> >>>> 3) Users/apps need more information about congestion in order to be >>>> able to respond better. This is not really discussed in draft- >>>> moncaster-problem. >>> >>> Don't agree with this one. It's not actually true to say users/apps >>> don't have congestion info - they have full visibility of >>> their congestion. >>> >>> But this congestion information has no *significance* to users/apps, >>> while they know that networks cannot see it. >>> >>> >>>> I think it would be helpful for the group to have some sense >>> of which >>>> subset of these problems we are trying to solve. Then, >>> ticking through >>>> the mechanisms that already exist to solve the problems and >>> showing how >>>> they are deficient could lead to the conclusion that the congestion >>>> exposure work is warranted (draft-moncaster-problem already >>> does this >>>> to some extent, but in my reading at least the link between >>> the stated >>>> problems, the inadequacies of the existing solutions, and >>> the reasons >>>> why conex would improve the situation is somewhat weak). >>> >>> OK. Agreed. >>> We also need to make sure this same approach comes across in the BoF >>> presentations. >>> >>> From Rich's presentation, we have the following that match your >>> list, and add to it: >>> ==Requirements for a long term solution:== >>> a) Incentivize customer-directed prioritization of >>> application bandwidth usage >>> b) Avoid 'cat and mouse game' with the detection and mitigation of >>> specific protocols >>> c) Enable transparency of network operation for current and >>> future applications >>> d) Support growth in per-customer average and peak bandwidth >>> e) Avoid uneconomic capacity upgrades that benefit only 5% of heavy >>> usage customers >>> ==Advantages of re-ECN over FairShare:== >>> f) Re-ECN enables end-to-end congestion management >>> g) Re-ECN signals the presence of congestion to user applications and >>> to all devices on the network path >>> h) Re-ECN enables additional user and/or application >>> responses to congestion >>> i) Re-ECN enables DDoS mitigation and other capabilities >>> >>> a) = your #1) >>> b) ConEx is not unique in this respect >>> c) = perhaps an additional particularly strong point of ConEx? >>> d) & e) supply side strengths of ConEx >>> f) = your #2) >>> g) = your #3) but I say the Internet already does this well >>> h) = your #1 again >>> i) another strength of ConEx, but only to be mentioned in passing; >>> >>> We're left with the following unique selling points: >>> a) Incentivize customer-controlled prioritization of app >>> bandwidth usage >>> c) Enable unambiguous transparent network operations for >>> current & future apps >>> d) Drive capacity investment where financially warranted >>> f) Enable e2e congestion mgmt between networks as well as by >>> single networks >>> i) Enable DDoS mitigation [only to mention in passing] >>> >>> HTH >>> >>> >>> Bob >>> >>>> Alissa >>>> >>>>> HTH >>>>> >>>>> >>>>> Bob >>>>> >>>>> At 13:44 02/03/2010, Tschofenig, Hannes (NSN - FI/Espoo) wrote: >>>>>> Hi all, >>>>>> >>>>>> we wanted to provide a bit of details of why Alissa and I >>> worked on >>>>>> draft-tschofenig-conex-ps. >>>>>> >>>>>> Our goal for the problem statement document was >>>>>> 1) to offer a writeup that does not talk about the solution >>>>>> 2) to focus on one aspect of the perceived problem only. >>>>>> >>>>>> While there may be the other problems problems out there that a >>>>>> specific solution can solve (e.g. denial of service >>> attacks, trouble- >>>>>> shooting of network problems) we really think that one >>> needs to focus >>>>>> on one thing >>>>>> at the time because otherwise you run into what I call the >>>>>> HIP-effect(*). >>>>>> >>>>>> The problem needs to be well understood and documented >>> before one can >>>>>> go forward with the next step. The lack of a clear problem >>> statement >>>>>> discussion was for me recognizable at the BOF. >>>>>> >>>>>> Once people agree on the problem then it is interesting to capture >>>>>> the state of the art as far as what tools operators are >>> already using >>>>>> to solve the problem. Since a number of operator believe >>> they have a >>>>>> problem there is a wide range of solutions they are deploying >>>>>> today. The >>>>>> excellent writeup by Jason and Ric (see >>>>>> draft-livingood-woundy-congestion-mgmt) is one example of >>> a solution >>>>>> that offers very interesting properties already (such as being >>>>>> protocol >>>>>> agnostic). There are other solution approaches that other operators >>>>>> are >>>>>> deploying but they are less well documented. Every solution has >>>>>> pros and >>>>>> cons and, from what we can tell, there is no one-size fits all >>>>>> approach. >>>>>> >>>>>> >>>>>> Unfortunately, we have not seen a lot of discussions about what is >>>>>> being done and why the group considers them as insufficient. This >>>>>> leads to the >>>>>> next point, namely to document what is not good enough with the >>>>>> available techniques. If there is a specific problem identified, >>>>>> and the >>>>>> inadequacies of the existing solutions are compelling, that argues >>>>>> that >>>>>> there is space for new work in this area. >>>>>> >>>>>> So, in a summary we would suggest the following approach >>> and this is >>>>>> also the approach we will try to take as we rev our problem >>>>>> statement (although there will certainly still be gaps), and there >>>>>> are some elements of it in the draft-moncaster problem >>> statement, but >>>>>> we wanted >>>>>> to frame the thought process before posting a new version: >>>>>> >>>>>> A) Figure out whether most people agree to a description of the >>>>>> problem. >>>>>> >>>>>> (There may be multiple sub-problems.) >>>>>> >>>>>> B) Document the state-of-the-art (and why people have chosen a >>>>>> certain approaches). >>>>>> >>>>>> C) Document the gaps that are not covered by state-of-the-art >>>>>> solutions that would require additional work. For me a really >>>>>> important question >>>>>> is what are the incentives for someone to deploy anything in >>>>>> addition to >>>>>> draft-livingood-woundy-congestion-mgmt? >>>>>> >>>>>> There are other ways to approach the topic but we believe >>> that this >>>>>> is the appropriate way in this case. >>>>>> >>>>>> Ciao >>>>>> Hannes & Alissa >>>>>> >>>>>> (*): A solution that solves all problems but none really well. >>>>>> >>>>>> _______________________________________________ >>>>>> re-ECN mailing list >>>>>> re-ECN@ietf.org >>>>>> https://www.ietf.org/mailman/listinfo/re-ecn >>>>> >>>>> ________________________________________________________________ >>>>> Bob Briscoe, BT Innovate & Design >>>>> _______________________________________________ >>>>> re-ECN mailing list >>>>> re-ECN@ietf.org >>>>> https://www.ietf.org/mailman/listinfo/re-ecn >>> >>> ________________________________________________________________ >>> Bob Briscoe, BT Innovate & Design >>> >>> _______________________________________________ >>> re-ECN mailing list >>> re-ECN@ietf.org >>> https://www.ietf.org/mailman/listinfo/re-ecn >>> >> > > > _______________________________________________ > re-ECN mailing list > re-ECN@ietf.org > https://www.ietf.org/mailman/listinfo/re-ecn -- ------------------------------------------------------------------- "Reality: Yours to discover." -- ThinkingCat Leslie Daigle leslie@thinkingcat.com ------------------------------------------------------------------- From leslie@thinkingcat.com Sun Mar 7 15:34:11 2010 Return-Path: X-Original-To: re-ecn@core3.amsl.com Delivered-To: re-ecn@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id AB8973A67A6 for ; Sun, 7 Mar 2010 15:34:11 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.299 X-Spam-Level: X-Spam-Status: No, score=-1.299 tagged_above=-999 required=5 tests=[AWL=-1.300, 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 Ij-cXPWOhmjZ for ; Sun, 7 Mar 2010 15:34:08 -0800 (PST) Received: from zeke.ecotroph.net (zeke.ecotroph.net [70.164.19.155]) by core3.amsl.com (Postfix) with ESMTP id BFDCE3A67A3 for ; Sun, 7 Mar 2010 15:34:07 -0800 (PST) Received: from beethoven.local ([::ffff:173.71.206.39]) (AUTH: PLAIN leslie, SSL: TLSv1/SSLv3,256bits,AES256-SHA) by zeke.ecotroph.net with esmtp; Sun, 07 Mar 2010 18:34:10 -0500 id 015B0062.4B9437F2.000008FC Message-ID: <4B9437E9.3030905@thinkingcat.com> Date: Sun, 07 Mar 2010 18:34:01 -0500 From: Leslie Daigle User-Agent: Thunderbird 2.0.0.23 (Macintosh/20090812) MIME-Version: 1.0 To: "Woundy, Richard" References: In-Reply-To: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Cc: re-ecn@ietf.org Subject: Re: [re-ECN] FW: New Version Notification for draft-moncaster-conex-problem-00 X-BeenThere: re-ecn@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: re-inserted explicit congestion notification List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 07 Mar 2010 23:34:11 -0000 Hi, Some comments & suggestions from me as an individual, not bof co-chair, and following up some of the points recently raised on the list as we try to get clarity. I think it's important to focus the problem statement on the generative technology that is congestion exposure -- which makes it independent of any potential applications or services (use cases) built with it, or of any implementation. So, here are some suggestions for turning the crank to do that. > > 1. Introduction > > The Internet has grown from humble origins to become a global > phenomenon with billions of end-users able to share the network and > exchange data and more. One of the key elements in this success has > been the use of distributed algorithms such as TCP that share > capacity while avoiding congestion collapse. These algorithms rely > on the end-systems altruistically reducing their transmission rate in > response to any congestion they see. > > In recent years ISPs have seen a minority of users taking a larger Reading through the document again, I was struck by the focus on "ISPs". Perhaps one of the ways to emphasize the "inter-network" aspect of this proposal is to back out of that: remove all instances of "ISP" in this document, and focus the text on networks, whatever their type. (That said, the access network example here is a fair illustration of one possible cases, and the text is probably helpful. As long as it doesn't distract the reader from pausing to imagine other, completely different, network and network-to-network situations that could be addressed with congestion exposure). > share of the network by using applications that transfer data > continuously for hours or even days at a time and even opening > multiple simultaneous TCP connections. This issue became prevalent > with the advent of "always on" broadband connections. Frequently > peer to peer protocols have been held responsible [RFC5594] but > streaming video traffic is becoming increasingly significant. In > order to improve the network experience for the majority of their > customers, many ISPs have chosen to impose controls on how their > network's capacity is shared rather than continually buying more > capacity. They calculate that most customers will be unwilling to > contribute to the cost of extra shared capacity if that will only > really benefit a minority of users. Approaches include volume > counting or charging, and application rate limiting. Typically these > traffic controls, whilst not impacting most customers, set a > restriction on a customer's level of network usage, as defined in a > "fair usage policy". The latter part of this paragraph seems to become a bit of a distraction from a problem statement about a specific technology? It's fairly far into business practices of the moment. I appreciate that it is illustrating some *bad* traffic control practices, but it would perhaps be better to spell out how these practices break networking than simply citing them as actions. That may go to Alissa & Hannes' point about describing the shortcomings of current technologies. > > We believe that such traffic controls seek to control the wrong > quantity. What matters in the network is neither the volume of > traffic nor the rate of traffic, it is the contribution to congestion > over time - congestion means that your traffic impacts other users, > and conversely that their traffic impacts you. > So if there is no > congestion there need not be any restriction on the amount a user can > send; restrictions only need to apply when others are sending traffic > such that there is congestion. Could this paragraph spell out the network-technology reasons why traffic should not be restricted in the absence of congestion? Or is that getting into a choice, question? I.e., this seems to state a business choice (don't restrict your customers in the absence of congestion) rather than a network technology reality, and I think this document needs to stay focused on the former. >In fact some of the current work at > the IETF [LEDBAT] and IRTF [CC-open-research] already reflects this > thinking. For example, an application intending to transfer large > amounts of data could use LEDBAT to try to reduce its transmission > rate before any competing TCP flows do, by detecting an increase in > end-to-end delay (as a measure of incipient congestion). However > these techniques rely on voluntary, altruistic action by end users > and their application providers. ISPs cannot enforce their use. > This leads to our second point. The above is a fine place to excise "ISP". The point is well taken that LEDBAT and CONEX can play well together. Everything else speaks to motivations of individuals, which seems beyond the scope of a problem statement for a generative technology, IMO. (It's not that I'm disagreeing with it as a statement of reality; just trying to suggest where to level the document up a bit). > > The Internet was designed so that end-hosts detect and control > congestion. We believe that congestion needs to be visible to > network nodes as well, not just to the end hosts. More specifically, And this is very true, and well motivated, even if "ISP" is excised, above. > > > > Moncaster, et al. Expires September 2, 2010 [Page 4] > > > Internet-Draft Congestion Exposure Problem March 2010 > > > a network needs to be able to measure how much congestion traffic > causes between the monitoring point in the network and the > destination ("rest-of-path congestion"). This would be a new > capability; today a network can use explicit congestion notification > (ECN) [RFC3168] to detect how much congestion traffic has suffered > between the source and a monitoring point in the network, but not This para, to here, should probably find its way earlier in the document, because it goes to the heart of the matter. > beyond. Such a capability would enable an ISP to give incentives for > the use, without restrictions, of LEDBAT-like applications whilst > perhaps restricting excessive use of TCP and UDP ones. Excise ISP. Perhaps, "Such a capability would enable networks to support LEDBAT-enabled applications in adjusting their use of network capacity over time. This would provide motivation for deploying LEDBAT-enabled applications, as other applications will be unable to make full use of network availability." > > So we propose a new approach which we call congestion exposure. We > propose that congestion information should be made visible at the IP > layer, so that any network node can measure the contribution to > congestion of an aggregate of traffic as easily as straight volume > can be measured today. Once the information is exposed in this way, > it is then possible to use it to measure the true impact of any > traffic on the network. Lacking the ability to see congestion, some > ISPs count the volume each user transfers. On this basis LEDBAT s/ISPs/networks/ > applications would get blamed for hogging the network given the large > amount of volume they transfer. However, because they yield rather > than hog, they actually contribute very little to congestion. One > use of exposed congestion information would be to measure the > congestion attributable to a given user, and thereby incentivise the > use of protocols such as [LEDBAT] which aim to reduce the congestion > caused by bulk data transfers. I think this is getting beyond the problem statement of the basic technology? It posits a possible future, but is heavily tied up in possible motives of network operators (ISPs or otherwise). > > Creating the incentive to deploy low-congestion protocols such as > LEDBAT is just one of many motivations for congestion exposure. In > general, congestion exposure gives ISPs a principled way to hold > their customers accountable for the impact on others of their network > usage and reward them for choosing congestion-sensitive applications. > It can measure the impact of an individual consumer, a large > enterprise network or the traffic crossing a border from another ISP > - anywhere where volume is used today as a (poor) measure of usage. > In Section 7, a range of potential use cases for congestion exposure > are given, showing it is possible to imagine a wide range of other > ways to use the exposed congestion information. I think the para above is driving at an important point -- the granularity of choices that will be available at nodes within the network. However, as written, it is too steeped in a specific part of the network (the edge), and business motivations at that part of the network, to really carry home the architectural point. > > 1.1. Definitions > > Throughout this document we refer to congestion repeatedly. > Congestion has a wide range of definitions. For the purposes of this > document it is defined using the simplest way that it can be measured > - the instantaneous fraction of loss. More precisely, congestion is > bits lost divided by bits sent, taken over any brief period. By > extension, if explicit congestion notification (ECN) is being used, > the fraction of bits marked (rather than lost) gives a useful metric > that can be thought of as analagous to congestion. Strictly > > > > Moncaster, et al. Expires September 2, 2010 [Page 5] > > > Internet-Draft Congestion Exposure Problem March 2010 > > > congestion should measure impairment, whereas ECN aims to avoid any > loss or delay impairments due to congestion. But for the purposes of > this document, the two will both be called congestion. > > We also need to define two specific terms carefully: > > Upstream Congestion: The congestion that has already been > experienced by a packet as it travels along its path. In other > words at any point on the path it is the congestion between that > point and the source of the packet. > > Downstream Congestion: The congestion that a packet still has to > experience on the remainder of its path. In other words at any > point it is the congestion still to be experienced as the packet > travels between that point and its destination. > > 1.2. Changes from previous versions > > From -03 to -04 (current version): > > Many edits throughout per comments from Bob Briscoe about the > intentions of ConEx. > > References section updated; reference to Comcast congestion > management system added as ISP example. > > NOTE: there are still sections needing more work, especially > the Use Cases. The whole document also needs trimming in > places and checking for repetition or omission. > > From -02 to -03: > > Abstract re-written again following comments from John Leslie. > > Use Cases Section re-written. > > Security Considerations section improved. > > This ChangeLog added. > > From -01 to -02: > > Extensive changes throughout the document: > > + Abstract and Introduction re-written. > > + The Problem section re-written and extended significantly. > > > > > Moncaster, et al. Expires September 2, 2010 [Page 6] > > > Internet-Draft Congestion Exposure Problem March 2010 > > > + Why Now? Section re-written and extended. > > + Requirements extended. > > + Security Considerations expanded. > > Other less major changes throughout. > > From -00 -01: > > Significant changes throughout including re-organising the main > structure. > > New Abstract and changes to Introduction. > > 2. The Problem > > 2.1. Congestion is not the problem > > The problem is not congestion itself. The problem is how best to > share available capacity. When too much traffic meets too little > capacity, congestion occurs. Then we have to share out what capacity > there is. But we should not (and cannot) solve the capacity sharing > problem by trying to make it go away - by saying there should somehow > be no congestion, slower traffic or more capacity. That misses the > whole point of the Internet: to multiplex or share available capacity > at maximum bit-rate. Without making claims about missing the point of the Internet, I think it's fair and neutral to say there will always be cases where demand exceeds reasonably available capacity. > > So as we say, the problem is not congestion in itself. Every elastic > data transfer should (and usually will) congest a healthy data > network. If it doesn't, its transport protocol is broken. That's a pretty broad statement. There > should always be periods approaching 100% utilisation at some link > along every data path through the Internet, implying that frequent > periods of congestion are a healthy sign. If transport protocols are > too weak to congest capacity, they are under-utilising it and hanging > around longer than they need to, reducing the capacity available for > the next data transfers that might be about to start. This may be the text I was looking for to speak to the network technology impact (not business reasoning) for not restricting traffic when congestion is not a problem -- might be good to put the two pieces of text closer together? > > 2.2. Increase capacity or manage traffic? > > Some say the problem is that ISPs should invest in more capacity. Excise ISP. And it would be grand to come up with some illustrations that go beyond access networks... > Certainly increasing capacity should make the congested periods > during data transfers shorter and the non-congested gaps between them > longer. The argument goes that if capacity were large enough it > would make the periods when there is a capacity sharing problem > insignificant and not worth solving. > > Yet, ISPs are facing a quandary - traffic is growing rapidly and > > > > Moncaster, et al. Expires September 2, 2010 [Page 7] > > > Internet-Draft Congestion Exposure Problem March 2010 > > > traffic patterns are changing significantly (see Section 4 and > [Cisco-VNI]) They know that any increases in capacity will have to be > paid for by all their customers but capacity growth will be of most > benefit to the heaviest users. Faced with these problems, some ISPs > are seeking to reduce what they regard as "heavy usage" in order to > improve the service experienced by the majority of their customers. > > If done properly, managing traffic should be a valid alternative to > increasing capacity. Because of the point above. It may not solve the problem, but at least makes more efficient use of available bandwidth before considering increasing capacity. (It might be good to spell that out -- so that it doesn't sound like "I don't want to have to upgrade my networks", which it isn't trying to say). > An ISP's customers can vote with their feet if > the ISP chooses the wrong balance between managing heavy traffic and > charging for too much shared capacity. Current traffic management > techniques (Section 3) fight against the capacity shares that TCP is > aiming for. Ironically, they try to impose something approaching > LEDBAT-like behaviour on heavier flows. But as we have seen, they > cannot give LEDBAT the credit for doing this itself - the network > just sees a LEDBAT flow as a large amount of volume. IMO -- this part of the para gets way too into business models for a problem statement about an architectural building block. > > Thus the problem for the IETF is to ensure that ISPs and their > equipment suppliers have appropriate protocol support - not just to > impose good capacity sharing themselves, but to encourage end-to-end > protocols to share out capacity in everyone's best interests. Excise ISP. And equipment suppliers while you're at it -- the IETF is here to engineer Internet technology specifications, for whoever happens to be in the Internet development business. > > 2.2.1. Making Congestion Visible > > Unfortunately ISPs are only able to see limited information about the Excise... (The point stands, well, with "networks"). > traffic they forward. As we will see in section 3 they are forced to > use the only information they do have available which leads to myopic > control that has scant regard for the actual impact of the traffic or > the underlying network conditions. All their approaches are unsound > because they cannot measure the most useful metric. The volume or > rate of a given flow or aggregate doesn't directly affect other > users, but the congestion it causes does. This can be seen with a > simple illustration. A 5Mbps flow in an otherwise empty 10Mbps > bottleneck causes no congestion and so affects no other users. By > contrast a 1Mbps flow entering a 10Mbps bottleneck that is already > fully occupied causes significant congestion and impacts every other > user sharing that bottleneck as well as suffering impairment itself. > So the real problem that needs to be addressed is how to close this > information gap. How can we expose congestion at the IP layer so > that it can be used as the basis for measuring the impact of any > traffic on the network as a whole? > > 2.2.2. ECN - a Step in the Right Directions Perhaps this should move down to "existing approaches"? > > Explicit Congestion Notification [RFC3168] allows routers to > explicitly tell end-hosts that they are approaching the point of > congestion. ECN builds on Active Queue Mechanisms such as random > early discard (RED) [RFC2309] by allowing the router to mark a packet > > > > Moncaster, et al. Expires September 2, 2010 [Page 8] > > > Internet-Draft Congestion Exposure Problem March 2010 > > > with a Congestion Experienced (CE) codepoint, rather than dropping > it. The probability of a packet being marked increases with the > length of the queue and thus the rate of CE marks is a guide to the > level of congestion at that queue. This CE codepoint travels forward > through the network to the receiver which then informs the sender > that it has seen congestion. The sender is then required to respond > as if it had experienced a packet loss. Because the CE codepoint is > visible in the IP layer, this approach reveals the upstream > congestion level for a packet. > > So Is ECN the Solution? Alas not - ECN does allow downstream nodes > to measure the upstream congestion for any flow, but this is not > enough. This can make a receiver accountable for the congestion > caused by incoming traffic. But a receiver can only control incoming > congestion indirectly, by politely asking the sender to control it. > A receiver cannot make a sender install an adaptive codec, or install > LEDBAT instead of TCP. And a receiver cannot ask an attacker to stop > flooding it with traffic. What is needed is knowledge of the > downstream congestion level for which you need additional information > that is still concealed from the network - by design. > > 3. Existing Approaches to Traffic Control > > Existing approaches intended to address the problems outlined above > can be broadly divided into two groups - those that passively monitor > traffic and can thus measure the apparent impact of a given flow of > packets and those that can actively discriminate against certain > packets, flows, applications or users based on various > characteristics or metrics. > > 3.1. Layer 3 Measurement > > L3 measurement of traffic relies on using the information that can be > measured directly or is revealed in the IP header of the packet (or > lower layers). Architecturally, L3 measurement is best since it fits > with the idea of the hourglass design of the Internet [RFC3439]. > This asserts that "the complexity of the Internet belongs at the > edges, and the IP layer of the Internet should remain as simple as > possible." > > 3.1.1. Volume Accounting > > Volume accounting is a technique that is often used to discriminate > between heavy and light users. Is this specific to access providers (ISPs)? Are there other instances (e.g., enterprise networks) where it might also be true? The volume of traffic sent by a given > user or network is one of the easiest pieces of information to > monitor in a network. Measuring the size of every packet from the > header and adding them up is a simple operation. Consequently this > has long been a favoured measure used by operators to control their > > > > Moncaster, et al. Expires September 2, 2010 [Page 9] > > > Internet-Draft Congestion Exposure Problem March 2010 > > > customers. > > The precise manner in which this volume information is used may vary. > Typically ISPs may impose an overall volume cap on their customers > (perhaps 10Gbytes a month). Alternatively they may decide that the > heaviest users each month are subjected to some sanction. > > Volume is naively thought to indicate the impact that one party's > traffic has on others. But the same volume can cause very different > impacts on others if it is transferred at slightly different times, > or between slightly different endpoints. Also the impact on others > greatly depends on how responsive the transport is to congestion, > whether responsive (TCP), very responsive (LEDBAT), aggressive > (multiple TCPs) or totally unresponsive. > > 3.1.2. Rate Measurement > > Rate measurements might be thought indicative of the impact of one > aggregate of traffic on others, and rate is often limited to avoid > impact on others. However such limits generally constrain everyone > much more than they need to, just in case most parties send fast at > the same time. And such limits constrain everyone too little at > other times, when everyone actually does send fast at the same time. > > The problem with measuring rate is that it doesn't say how much the > rate is occupying shared capacity over time, and whether the high > rate of one user comes at times when others want a high rate. > > 3.2. Higher Layer Discrimination > > Over recent years a number of traffic management techniques have > emerged that explicitly differentiate between different traffic > types, applications and even users. This is done because ISPs and > operators feel they have a need to use such techniques to better > control a new raft of applications that break some of the implicit > design assumptions behind TCP (short-lived flows, limited flows per > connection, generally between server and client). > > 3.2.1. Bottleneck Rate Policing > > Bottleneck flow rate policers such as [XCHOKe] and [pBox] have been > proposed as approaches for rate policing traffic. But they must be > deployed at bottlenecks in order to work. Unfortunately, capacity > sharing is not only about congestion-responsive behaviour of each > flow, but also about how long the flows occupy the capacity and the > combined total of multiple flows. Such rate policers also make an > assumption about what constitutes acceptable per-flow behaviour. If > these bottleneck policers were widely deployed, the Internet could > > > > Moncaster, et al. Expires September 2, 2010 [Page 10] > > > Internet-Draft Congestion Exposure Problem March 2010 > > > find itself with one universal rate adaptation policy embedded > throughout the network. With TCP's congestion control algorithm > approaching its scalability limits as the network bandwidth continues > to increase, new algorithms are being developed for high-speed > congestion control. Embedding assumptions about acceptable rate > adaptation would make evolution to such new algorithms extremely > painful. > > 3.2.2. DPI and Application Rate Policing > > Some operators use deep packet inspection (DPI) and traffic analysis > to identify certain applications they believe to have an excessive > impact on the network. ISPs generally pick on applications that that > they judge as low value to the customer in question and high impact > on other customers. A common example is peer-to-peer file-sharing. > Having identified a flow as belonging to such an application, the > operator uses differential scheduling to limit the impact of that > flow on others, which usually limits its throughput as well. This > has fuelled the on-going battle between application developers and > DPI vendors. > > When operators first started to limit the throughput of P2P, it soon > became common knowledge that turning on encryption could boost your > throughput. The DPI vendors then improved their equipment so that it > could identify P2P traffic by the pattern of packets it sends. This > risks becoming an endless vicious cycle - an arms race that neither > side can win. Furthermore such techniques may put the operator in > direct conflict with the customers, regulators and content providers. I think it would be good (after excising ISP ;-) ) to add a bit here to spell out the problem: any approach that attempts to ascertain application type and act on an application-specific approach is a poor long-term architectural approach: this is where we can observe that such a tactic will stifle evolution and growth of applications (and managed networks). > > 4. Why Now? > > The accountability and capacity sharing problems highlighted so far > have always characterised the Internet to some extent. In 1988 Van > Jacobson coded capacity sharing into TCP's e2e congestion control > algorithms [TCPcc]. But fair queuing algorithms were already being > written for network operators to ensure each active user received an > equal share of a link and couldn't game the system [RFC0970]. The > two approaches have divergent objectives, but they have co-existed > ever since. > > The main new factor has been the introduction of residential > broadband, making 'always-on' available to all, not just campuses and > enterprises. Both TCP and approaches like fair queuing don't take > account of how much of each user's data is occupying a link over > time, which can significantly reduce the capacity available to > lighter usage. Therefore residential ISPs have been introducing new > traffic management equipment that can prioritise based on each > customer's usage volume, e.g. [Comcast]. Otherwise capacity > > > > Moncaster, et al. Expires September 2, 2010 [Page 11] > > > Internet-Draft Congestion Exposure Problem March 2010 > > > upgrades get eaten up by transfers of large amounts of data, with > little gain for interactive usage [BB-Incentive]. Okay, I can buy the use of ISP above ;-) > > In campus networks, capacity upgrades are the easiest way to mitigate > the inability of TCP or FQ to take account of activity over time. > But capacity upgrades are much more expensive in residential > broadband networks that are spread over large geographic areas and > customers will only be happy to pay more for their service if the > majority can see a significant benefit. Nice example of an access network that is not an ISP. > > However, these traffic management techniques fight the capacity > shares e2e protocols are aiming at, rather than working together in > unison. And, the more optimal ISPs try to make their controls, the > more they need application knowledge within the network - which isn't > how the Internet was designed to work. Congestion exposure hasn't > been considered before, because the depth of the problem has only > recently been understood. We now understand that both networks and > end-systems to focus on contribution to congestion, not volume or > rate. Then application knowledge is only needed on the end-system, > where it should be. But the reason this isn't happening is because > the network cannot see the information it needs (congestion). I think another para after this one would be suitable -- to emphasize that *today* the problem is seen in ISPs (access networks), but an architectural solution really has to address the overall inter-network issue, whether it's from the access networks or somewhere else in the middle. And that solution has to scale up. > > As long as ISPs continue to use rate and volume as the key metrics > for determining when to control traffic there is no incentive to use > LEDBAT or other low-congestion protocols to improve the performance > of competing interactive traffic. We believe that congestion > exposure gives ISPs the information they need to be able to > discriminate in favour of such low-congestion transports. In turn > this will give users a direct benefit from using such transports and > so encourage their wider use. I'm not sure this para is necessary, and may get too much into current realities. At a minimum, it should be generalized beyond "ISPs". > > 5. Requirements for a Solution > > This section proposes some requirements for any solution to this > problem. We believe that a solution that meets most of these > requirements is likely to be better than one that doesn't, but we > recognise that if a working group is established in this area, it may > have to make tradeoffs. I think this whole section seems pretty solid -- good and general and not ISP-centric. > > 6. A Strawman Congestion Exposure Protocol > > In this section we explore a simple strawman protocol that would > solve the congestion exposure problem. I appreciate that this has been stripped down to the bare essentials of the description. But, I wonder if it is still too detailed for a problem statement. Perhaps this, and subsequent sections, now need to migrate into a separate document? This protocol neatly > illustrates how a solution might work. A practical implementation of > this protocol has been produced and both simulations and real-life > testing show that it works. The protocol is based on a concept known > as re-feedback [Re-fb] and builds on existing active queue management > techniques like RED [RFC2309] and ECN [RFC3168] that network elements > can already use to measure and expose congestion. > > Re-feedback, standing for re-inserted feedback, is a system designed > to allow end-hosts to reveal to the network information about their > network path that they have received via conventional feedback (for > instance congestion). > > In our strawman protocol we imagine that packets have two > "congestion" fields in their IP header: > > o The first is a congestion experienced field to record the upstream > congestion level along the path. Routers indicate their current > congestion level by updating this field in every packet. As the > packet traverses the network it builds up a record of the overall > congestion along its path in this field. This data is sent back > to the sender who uses it to determine its transmission rate. > > o The other is a whole-path congestion field that uses re-feedback > to record the total congestion along the path. The sender does > this by re-inserting the current congestion level for the path > into this field for every packet it transmits. > > Thus at any node downstream of the sender you can see the upstream > congestion for the packet (the congestion thus far), the whole path > congestion (with a time lag of 1RTT) and can calculate the downstream > congestion by subtracting one from the other. > > So congestion exposure can be achieved by coupling congestion > notification from routers with the re-insertion of this information > by the sender. This establishes information symmetry between users > and network providers. > > 7. Use Cases > > Once downstream congestion information is revealed in the IP header > it can be used for a number of purposes. Precise details of how the All of these use cases seem pretty ISP, and ISP-business, centric. While I appreciate that they are powerful and useful in that context, I think they may be distractions from the overall point of a problem statement for an architectural building block that the CONEX group is meant to tackle. We run the risk of getting people arguing about business practices rather than focusing on the specific, inter-networking issue that CONEX needs to address. So -- I believe these need to migrate out of the problem statement document. If use cases (applicability cases) are needed, they need to be more general. Having said that -- I think that they are something of a distraction. People need to get the architectural intent. I think we've struggled with the balance between "illustrations so you can see how it would be useful" and mistaking the illustrations for the thing. Woundy, Richard wrote: > Leslie and Phil, > > I volunteered to take on the editing of moncaster-congestion-exposure-problem-03 from Toby Moncaster. To ensure that this draft is firmly identified with the Conex work, the new draft is called draft-moncaster-conex-problem-00, . > > This version includes some edits from Bob Briscoe and updates to the references. > > In the works for -01 are significant changes suggested by Michael Menth, and (hopefully) some improvements to the Use Cases section. > > If there are any other suggested changes to this draft, please send them my way and I'll do my best to incorporate them. Thanks. > > -- Rich > > -----Original Message----- > From: IETF I-D Submission Tool [mailto:idsubmission@ietf.org] > Sent: Monday, March 01, 2010 7:43 PM > To: Woundy, Richard > Cc: toby.moncaster@bt.com; louise.burness@bt.com; menth@informatik.uni-wuerzburg.de; j.araujo@ee.ucl.ac.uk; sblake@extremenetworks.com; Woundy, Richard > Subject: New Version Notification for draft-moncaster-conex-problem-00 > > > A new version of I-D, draft-moncaster-conex-problem-00.txt has been successfuly submitted by Richard Woundy and posted to the IETF repository. > > Filename: draft-moncaster-conex-problem > Revision: 00 > Title: The Need for Congestion Exposure in the Internet > Creation_date: 2010-03-01 > WG ID: Independent Submission > Number_of_pages: 22 > > Abstract: > Today's Internet is a product of its history. TCP is the main > transport protocol responsible for sharing out bandwidth and > preventing a recurrence of congestion collapse while packet drop is > the primary signal of congestion at bottlenecks. Since packet drop > (and increased delay) impacts all their customers negatively, network > operators would like to be able to distinguish between overly > aggressive congestion control and a confluence of many low-bandwidth, > low-impact flows. But they are unable to see the actual congestion > signal and thus, they have to implement bandwidth and/or usage limits > based on the only information they can see or measure (the contents > of the packet headers and the rate of the traffic). Such measures > don't solve the packet-drop problems effectively and are leading to > calls for government regulation (which also won't solve the problem). > > We propose congestion exposure as a possible solution. This allows > packets to carry an accurate prediction of the congestion they expect > to cause downstream thus allowing it to be visible to ISPs and > network operators. This memo sets out the motivations for congestion > exposure and introduces a strawman protocol designed to achieve > congestion exposure. > > > > The IETF Secretariat. > > -- ------------------------------------------------------------------- "Reality: Yours to discover." -- ThinkingCat Leslie Daigle leslie@thinkingcat.com ------------------------------------------------------------------- From leslie@thinkingcat.com Sun Mar 7 15:51:12 2010 Return-Path: X-Original-To: re-ecn@core3.amsl.com Delivered-To: re-ecn@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id C0B173A67AF for ; Sun, 7 Mar 2010 15:51:12 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.866 X-Spam-Level: X-Spam-Status: No, score=-1.866 tagged_above=-999 required=5 tests=[AWL=0.133, BAYES_00=-2.599, J_CHICKENPOX_43=0.6] 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 9C+OnSS8sOUz for ; Sun, 7 Mar 2010 15:51:12 -0800 (PST) Received: from zeke.ecotroph.net (zeke.ecotroph.net [70.164.19.155]) by core3.amsl.com (Postfix) with ESMTP id 0C6213A67AC for ; Sun, 7 Mar 2010 15:51:11 -0800 (PST) Received: from beethoven.local ([::ffff:173.71.206.39]) (AUTH: PLAIN leslie, SSL: TLSv1/SSLv3,256bits,AES256-SHA) by zeke.ecotroph.net with esmtp; Sun, 07 Mar 2010 18:51:13 -0500 id 015B0060.4B943BF2.00000BB5 Message-ID: <4B943BE9.40304@thinkingcat.com> Date: Sun, 07 Mar 2010 18:51:05 -0500 From: Leslie Daigle User-Agent: Thunderbird 2.0.0.23 (Macintosh/20090812) MIME-Version: 1.0 To: "re-ecn@ietf.org" , Philip Eardley Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: [re-ECN] Draft agenda, prep'ing for Anaheim (IETF77) X-BeenThere: re-ecn@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: re-inserted explicit congestion notification List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 07 Mar 2010 23:51:12 -0000 Hi, I wanted to give a bit of an update on planning for the Anaheim meeting. Also, we're probably getting to be delinquent on filing an agenda. That's partly because Phil & I have been working with Lars on the scheduling problem: we're currently scheduled into 2 approx 1 hour slots that are NOT back to back on Wednesday. That's suboptimal at the best of times, but made worse by the fact that the one we're advised will be the best shot at getting RTG players into the room is the 2nd one. We're trying to find a way to take the (currently) first slot and reschedule it for later in the week. Options are few. We may just cancel that session. With all that -- we've been thinking about how to use a 1-hour slot to articulate the motivation for CONEX and lay out a sensible workplan for an eventual working group. So, proposed: 1 hour slot Wed 3.10-4.10pm We will finish promptly due to the plenary in the same room * overview of conex - Leslie or Phil - only the high-level, architectural issue * architectural overview of the problem - Mark H (tbc) - the problem of congestion * traffic mgt problems - whole internet perspective - Mat Ford (tbc), overall perspective - briefing panel at last ietf * Network perspective - Rich Woundy (tbc) - yes, ISPs think there's aproblem - current solutions have drawbacks, hence want conex * Lay out the CONEX proposed approach (charter) - Phil or Leslie * 20-30 mins discussion - how to structure? - hum on charter again? I'll note that, if we don't think we can achieve what we need to in the one hour slot, we (collectively) may seriously need to consider scramming the BoF for Anaheim, and review whether we can take it up again later in Maastricht, if we can be scheduled better. Leslie. -- ------------------------------------------------------------------- "Reality: Yours to discover." -- ThinkingCat Leslie Daigle leslie@thinkingcat.com ------------------------------------------------------------------- From hannes.tschofenig@nsn.com Mon Mar 8 01:03:37 2010 Return-Path: X-Original-To: re-ecn@core3.amsl.com Delivered-To: re-ecn@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 889CE3A67A1 for ; Mon, 8 Mar 2010 01:03:37 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.299 X-Spam-Level: X-Spam-Status: No, score=-2.299 tagged_above=-999 required=5 tests=[AWL=-0.300, BAYES_00=-2.599, J_CHICKENPOX_43=0.6] 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 AipdeGZHnzLu for ; Mon, 8 Mar 2010 01:03:36 -0800 (PST) Received: from demumfd001.nsn-inter.net (demumfd001.nsn-inter.net [93.183.12.32]) by core3.amsl.com (Postfix) with ESMTP id E12A33A67A5 for ; Mon, 8 Mar 2010 01:03:35 -0800 (PST) Received: from demuprx017.emea.nsn-intra.net ([10.150.129.56]) by demumfd001.nsn-inter.net (8.12.11.20060308/8.12.11) with ESMTP id o2893awU029974 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Mon, 8 Mar 2010 10:03:36 +0100 Received: from demuexc023.nsn-intra.net (demuexc023.nsn-intra.net [10.150.128.36]) by demuprx017.emea.nsn-intra.net (8.12.11.20060308/8.12.11) with ESMTP id o2893XYC027984; Mon, 8 Mar 2010 10:03:36 +0100 Received: from FIESEXC015.nsn-intra.net ([10.159.0.23]) by demuexc023.nsn-intra.net with Microsoft SMTPSVC(6.0.3790.3959); Mon, 8 Mar 2010 10:03:29 +0100 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Mon, 8 Mar 2010 11:02:54 +0200 Message-ID: <3D3C75174CB95F42AD6BCC56E5555B45024AD4E6@FIESEXC015.nsn-intra.net> In-Reply-To: <4B943BE9.40304@thinkingcat.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [re-ECN] Draft agenda, prep'ing for Anaheim (IETF77) Thread-Index: Acq+URhou4xnxPG2Tj+OqF+IV3NKWwASlWQQ References: <4B943BE9.40304@thinkingcat.com> From: "Tschofenig, Hannes (NSN - FI/Espoo)" To: "ext Leslie Daigle" , , "Philip Eardley" X-OriginalArrivalTime: 08 Mar 2010 09:03:29.0237 (UTC) FILETIME=[38503050:01CABE9E] Subject: Re: [re-ECN] Draft agenda, prep'ing for Anaheim (IETF77) X-BeenThere: re-ecn@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: re-inserted explicit congestion notification List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 08 Mar 2010 09:03:37 -0000 Hi Leslie,=20 I have a slightly modified proposal. Let us not turn this into rocket science.=20 I would like to simplify the story a bit:=20 * Briefly summarize the findings of data usage (there are a few papers to talk about).=20 Figure out whether people agree that there is a problem.=20 =20 [The chairs could give that presentation.]=20 * Explain what the state the art is.=20 This has to include the work Comcast is done with their FairShare [I could imagine that Ric would be a perfect speaker.] * Why is the state-of-the-art not sufficient?=20 The presentation would cover gaps in the existing solutions.=20 What are the desired properties of a system we would like to have. [Maybe an operator or an equipment vendor could provide some insight.] Finally, leave enough time for discussion. I am sure that people have interesting insight into the state of the art and what is wrong with it. There are at least a couple of companies on this list that ship stuff to operators while we speak (just not Conex). Ciao Hannes >-----Original Message----- >From: re-ecn-bounces@ietf.org [mailto:re-ecn-bounces@ietf.org]=20 >On Behalf Of ext Leslie Daigle >Sent: 08 March, 2010 01:51 >To: re-ecn@ietf.org; Philip Eardley >Subject: [re-ECN] Draft agenda, prep'ing for Anaheim (IETF77) > > >Hi, > >I wanted to give a bit of an update on planning for the=20 >Anaheim meeting.=20 > Also, we're probably getting to be delinquent on filing an agenda.=20 >That's partly because Phil & I have been working with Lars on=20 >the scheduling problem: we're currently scheduled into 2=20 >approx 1 hour slots that are NOT back to back on Wednesday. =20 >That's suboptimal at the best of times, but made worse by the=20 >fact that the one we're advised will be the best shot at=20 >getting RTG players into the room is the 2nd one. We're=20 >trying to find a way to take the (currently) first slot and=20 >reschedule it for later in the week. Options are few. We may=20 >just cancel that session. > >With all that -- we've been thinking about how to use a 1-hour=20 >slot to articulate the motivation for CONEX and lay out a=20 >sensible workplan for an eventual working group. > >So, proposed: > >1 hour slot Wed 3.10-4.10pm >We will finish promptly due to the plenary in the same room > > >* overview of conex > - Leslie or Phil > - only the high-level, architectural issue >* architectural overview of the problem > - Mark H (tbc) > - the problem of congestion >* traffic mgt problems - whole internet perspective > - Mat Ford (tbc), overall perspective - briefing panel at > last ietf >* Network perspective > - Rich Woundy (tbc) > - yes, ISPs think there's aproblem > - current solutions have drawbacks, hence want conex >* Lay out the CONEX proposed approach (charter) > - Phil or Leslie >* 20-30 mins discussion > - how to structure? > - hum on charter again? > >I'll note that, if we don't think we can achieve what we need=20 >to in the one hour slot, we (collectively) may seriously need=20 >to consider scramming the BoF for Anaheim, and review whether=20 >we can take it up again later in Maastricht, if we can be=20 >scheduled better. > >Leslie. > >--=20 > >------------------------------------------------------------------- >"Reality: > Yours to discover." > -- ThinkingCat Leslie Daigle=20 >leslie@thinkingcat.com >------------------------------------------------------------------- >_______________________________________________ >re-ECN mailing list >re-ECN@ietf.org >https://www.ietf.org/mailman/listinfo/re-ecn > From leslie@thinkingcat.com Mon Mar 8 09:21:33 2010 Return-Path: X-Original-To: re-ecn@core3.amsl.com Delivered-To: re-ecn@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 1317E3A68B2 for ; Mon, 8 Mar 2010 09:21:33 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, J_CHICKENPOX_43=0.6] 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 6hcFh45oOb0V for ; Mon, 8 Mar 2010 09:21:32 -0800 (PST) Received: from zeke.ecotroph.net (zeke.ecotroph.net [70.164.19.155]) by core3.amsl.com (Postfix) with ESMTP id B41BF3A69D3 for ; Mon, 8 Mar 2010 09:21:31 -0800 (PST) Received: from beethoven.local ([::ffff:81.253.82.223]) (AUTH: PLAIN leslie, SSL: TLSv1/SSLv3,256bits,AES256-SHA) by zeke.ecotroph.net with esmtp; Mon, 08 Mar 2010 12:21:31 -0500 id 015AC507.4B95321B.00000B63 Message-ID: <4B953212.5020402@thinkingcat.com> Date: Mon, 08 Mar 2010 12:21:22 -0500 From: Leslie Daigle User-Agent: Thunderbird 2.0.0.23 (Macintosh/20090812) MIME-Version: 1.0 To: "Tschofenig, Hannes (NSN - FI/Espoo)" References: <4B943BE9.40304@thinkingcat.com> <3D3C75174CB95F42AD6BCC56E5555B45024AD4E6@FIESEXC015.nsn-intra.net> In-Reply-To: <3D3C75174CB95F42AD6BCC56E5555B45024AD4E6@FIESEXC015.nsn-intra.net> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: re-ecn@ietf.org Subject: Re: [re-ECN] Draft agenda, prep'ing for Anaheim (IETF77) X-BeenThere: re-ecn@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: re-inserted explicit congestion notification List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 08 Mar 2010 17:21:33 -0000 Hi Hannes, I think we're agreeing on the overall structure, except 1/ I've added some brief intro of what "it" is (otherwise we'll flail, again!) 2/ I'd like to leave enough time for discussion. But, see the issue about scheduling -- we may have only 1 usable hour of meeting time, and our options will be to either run with that, or wait and see if we can get better scheduling in Maastricht. To be clear -- I *do not* want to push this discussion off to Maastricht -- we had momentum in Hiroshima, and that doesn't last forever. But, I'm pretty stymied by the inability to get more than 1 usable hour of meeting time. Leslie. Tschofenig, Hannes (NSN - FI/Espoo) wrote: > Hi Leslie, > > I have a slightly modified proposal. Let us not turn this into rocket > science. > > I would like to simplify the story a bit: > > * Briefly summarize the findings of data usage (there are a few papers > to talk about). > Figure out whether people agree that there is a problem. > > [The chairs could give that presentation.] > > * Explain what the state the art is. > This has to include the work Comcast is done with their FairShare > > [I could imagine that Ric would be a perfect speaker.] > > * Why is the state-of-the-art not sufficient? > The presentation would cover gaps in the existing solutions. > What are the desired properties of a system we would like to have. > > [Maybe an operator or an equipment vendor could provide some insight.] > > Finally, leave enough time for discussion. I am sure that people have > interesting insight into the state of the art and what is wrong with it. > There are at least a couple of companies on this list that ship stuff to > operators while we speak (just not Conex). > > Ciao > Hannes > > >> -----Original Message----- >> From: re-ecn-bounces@ietf.org [mailto:re-ecn-bounces@ietf.org] >> On Behalf Of ext Leslie Daigle >> Sent: 08 March, 2010 01:51 >> To: re-ecn@ietf.org; Philip Eardley >> Subject: [re-ECN] Draft agenda, prep'ing for Anaheim (IETF77) >> >> >> Hi, >> >> I wanted to give a bit of an update on planning for the >> Anaheim meeting. >> Also, we're probably getting to be delinquent on filing an agenda. >> That's partly because Phil & I have been working with Lars on >> the scheduling problem: we're currently scheduled into 2 >> approx 1 hour slots that are NOT back to back on Wednesday. >> That's suboptimal at the best of times, but made worse by the >> fact that the one we're advised will be the best shot at >> getting RTG players into the room is the 2nd one. We're >> trying to find a way to take the (currently) first slot and >> reschedule it for later in the week. Options are few. We may >> just cancel that session. >> >> With all that -- we've been thinking about how to use a 1-hour >> slot to articulate the motivation for CONEX and lay out a >> sensible workplan for an eventual working group. >> >> So, proposed: >> >> 1 hour slot Wed 3.10-4.10pm >> We will finish promptly due to the plenary in the same room >> >> >> * overview of conex >> - Leslie or Phil >> - only the high-level, architectural issue >> * architectural overview of the problem >> - Mark H (tbc) >> - the problem of congestion >> * traffic mgt problems - whole internet perspective >> - Mat Ford (tbc), overall perspective - briefing panel at >> last ietf >> * Network perspective >> - Rich Woundy (tbc) >> - yes, ISPs think there's aproblem >> - current solutions have drawbacks, hence want conex >> * Lay out the CONEX proposed approach (charter) >> - Phil or Leslie >> * 20-30 mins discussion >> - how to structure? >> - hum on charter again? >> >> I'll note that, if we don't think we can achieve what we need >> to in the one hour slot, we (collectively) may seriously need >> to consider scramming the BoF for Anaheim, and review whether >> we can take it up again later in Maastricht, if we can be >> scheduled better. >> >> Leslie. >> >> -- >> >> ------------------------------------------------------------------- >> "Reality: >> Yours to discover." >> -- ThinkingCat Leslie Daigle >> leslie@thinkingcat.com >> ------------------------------------------------------------------- >> _______________________________________________ >> re-ECN mailing list >> re-ECN@ietf.org >> https://www.ietf.org/mailman/listinfo/re-ecn >> > -- ------------------------------------------------------------------- "Reality: Yours to discover." -- ThinkingCat Leslie Daigle leslie@thinkingcat.com ------------------------------------------------------------------- From acooper@cdt.org Mon Mar 8 14:52:21 2010 Return-Path: X-Original-To: re-ecn@core3.amsl.com Delivered-To: re-ecn@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id CFD643A6A82 for ; Mon, 8 Mar 2010 14:52:21 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.608 X-Spam-Level: X-Spam-Status: No, score=-2.608 tagged_above=-999 required=5 tests=[AWL=-0.009, 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 mEGA0Ah-5O4x for ; Mon, 8 Mar 2010 14:52:20 -0800 (PST) Received: from mail.maclaboratory.net (mail.maclaboratory.net [209.190.215.232]) by core3.amsl.com (Postfix) with ESMTP id 891523A63D3 for ; Mon, 8 Mar 2010 14:52:20 -0800 (PST) Received: from [10.0.205.31] ([129.67.117.92]) (authenticated user acooper@cdt.org) by mail.maclaboratory.net (using TLSv1/SSLv3 with cipher AES128-SHA (128 bits)) for re-ecn@ietf.org; Mon, 8 Mar 2010 17:52:17 -0500 Message-Id: From: Alissa Cooper To: re-ecn@ietf.org Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v936) Date: Mon, 8 Mar 2010 22:52:13 +0000 References: <20100308224721.BEBE93A6AA1@core3.amsl.com> X-Mailer: Apple Mail (2.936) Subject: [re-ECN] Fwd: New Version Notification for draft-tschofenig-conex-ps-02 X-BeenThere: re-ecn@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: re-inserted explicit congestion notification List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 08 Mar 2010 22:52:21 -0000 FYI -- This update still has a bunch of gaps but gives an idea of the problem statement framework that has been discussed on the list. Alissa Begin forwarded message: > From: IETF I-D Submission Tool > Date: March 8, 2010 10:47:21 PM GMT > To: Hannes.Tschofenig@gmx.net > Cc: acooper@cdt.org > Subject: New Version Notification for draft-tschofenig-conex-ps-02 > > > A new version of I-D, draft-tschofenig-conex-ps-02.txt has been > successfuly submitted by Hannes Tschofenig and posted to the IETF > repository. > > Filename: draft-tschofenig-conex-ps > Revision: 02 > Title: Congestion Exposure Problem Statement > Creation_date: 2010-03-08 > WG ID: Independent Submission > Number_of_pages: 17 > > Abstract: > The increasingly ubiquitous availability of broadband, together with > flat-rate pricing, have made for increasing congestion problems on > the network, which are often caused by a small number of users > consuming a large amount of bandwidth. In some cases, building out > more capacity to handle this new congestion may be infeasible or > unwarranted. As a result, network operators have sought other ways > to manage congestion both from their own users and from other > networks. These different types of solutions have different > strengths and weaknesses, but all of them are limited in a number of > key ways. > > This document discusses the problems created for operators by high- > consuming users and describes the strengths and weaknesses of a > number of techniques operators are currently using to cope with high > bandwidth usage. The discussion of these solutions ultimately points > to a need for a new kind of congestion accounting. > > > > The IETF Secretariat. > > > From rbriscoe@jungle.bt.co.uk Mon Mar 8 14:53:04 2010 Return-Path: X-Original-To: re-ecn@core3.amsl.com Delivered-To: re-ecn@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 3BC923A6A02 for ; Mon, 8 Mar 2010 14:53:04 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.03 X-Spam-Level: X-Spam-Status: No, score=-2.03 tagged_above=-999 required=5 tests=[AWL=0.087, BAYES_00=-2.599, DNS_FROM_RFC_BOGUSMX=1.482, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 7VIuhp3R3eEr for ; Mon, 8 Mar 2010 14:52:56 -0800 (PST) Received: from smtp4.smtp.bt.com (smtp4.smtp.bt.com [217.32.164.151]) by core3.amsl.com (Postfix) with ESMTP id 104C23A6AE2 for ; Mon, 8 Mar 2010 14:52:55 -0800 (PST) Received: from i2kc06-ukbr.domain1.systemhost.net ([193.113.197.70]) by smtp4.smtp.bt.com with Microsoft SMTPSVC(6.0.3790.3959); Mon, 8 Mar 2010 22:52:59 +0000 Received: from cbibipnt05.iuser.iroot.adidom.com ([147.149.196.177]) by i2kc06-ukbr.domain1.systemhost.net with Microsoft SMTPSVC(6.0.3790.3959); Mon, 8 Mar 2010 22:52:59 +0000 Received: From bagheera.jungle.bt.co.uk ([132.146.168.158]) by cbibipnt05.iuser.iroot.adidom.com (WebShield SMTP v4.5 MR1a P0803.399); id 126808877823; Mon, 8 Mar 2010 22:52:58 +0000 Received: from MUT.jungle.bt.co.uk ([10.73.64.63]) by bagheera.jungle.bt.co.uk (8.13.5/8.12.8) with ESMTP id o28Mqrmv001407; Mon, 8 Mar 2010 22:52:53 GMT Message-Id: <201003082252.o28Mqrmv001407@bagheera.jungle.bt.co.uk> X-Mailer: QUALCOMM Windows Eudora Version 7.1.0.9 Date: Mon, 08 Mar 2010 22:52:55 +0000 To: Alissa Cooper From: Bob Briscoe In-Reply-To: References: <4A916DBC72536E419A0BD955EDECEDEC06363E9B@E03MVB1-UKBR.domain1.systemhost.net> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-Scanned-By: MIMEDefang 2.56 on 132.146.168.158 X-OriginalArrivalTime: 08 Mar 2010 22:52:59.0376 (UTC) FILETIME=[19A0B700:01CABF12] Cc: re-ecn@ietf.org Subject: Re: [re-ECN] draft-tschofenig-conex-ps and our recommendation for the group X-BeenThere: re-ecn@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: re-inserted explicit congestion notification List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 08 Mar 2010 22:53:04 -0000 Alissa, I agree multi-domain could be brought out more. But I don't believe it can or should be the focus. Imagine a doc that focused on multi-domain congestion accountability. It would have to start by explaining what congestion accountability is and why it's important. Only once we have the primary new idea - the congestion metric - can we introduce the secondary idea of using it between provider networks, not just between provider and customer. As Rich freely admits, the Comcast solution doesn't actually measure congestion. It measures per-customer volume during high utilisation, which may be somewhat related to congestion. As the doc says, that doesn't incentivise low congestion transports like LEDBAT. That proves that current network technology doesn't really have the wherewithall to measure congestion - the primary unique contribution of ConEx. Regarding setting aside DoS aspects. I imagine one para somewhere near the end saying, "This doc focuses on the primary contribution ConEx claims to provide: accountability for contributing to congestion. ConEx has also been claimed to help with the other Internet problems listed below, along with references to further reading for those interested: - mitigating DDoS [xxx] - preventing congestion collapse [yyy] - etc" We're getting out of time for updating the prob statement before the deadline. But this conversation is still v useful for focusing the materials to be used in the BoF. Bob At 20:47 07/03/2010, Alissa Cooper wrote: >Phil and Bob, > >On Mar 5, 2010, at 7:27 PM, > wrote: > >>I think reason (2) is the key one - the inter-network aspect. This is >>the new thing. >>If the only problem of interest is an intra-network one (eg if >>congestion is always in just one network), then there will be several >>possible solutions. The livingwood draft documents an interesting one >>for instance. DPI-based solutions would be another method of different >>interest. can imagine conex-based solutions as well (see moncaster & >>other drafts). > >This is, I think, what Hannes and I have been trying to elucidate. >Here's Bob's list of selling points: > >>>We're left with the following unique selling points: >>>a) Incentivize customer-controlled prioritization of app >>>bandwidth usage >>>c) Enable unambiguous transparent network operations for >>>current & future apps >>>d) Drive capacity investment where financially warranted >>>f) Enable e2e congestion mgmt between networks as well as by >>>single networks >>>i) Enable DDoS mitigation [only to mention in passing] > > >I think the list is more or less on target -- but identifying all of >the great things about conex (the selling points) is not the same as >identifying the problem that the work is supposed to solve. I'm not >saying that there isn't a need to emphasize the selling points, but I >am saying that if the selling points are in the problem statement, >there needs to be some demonstration of the problem that they solve. >Thus far, the links between the problems of lack of transparency and >inter-network congestion management have not been so strongly linked >to (c) and (f), respectively, and (i) might better be saved for later >so as not to distract. > >But, if the central problem is that there's no way to manage inter- >network congestion as Phil says, that's what the problem statement >should focus on, and not all of these other things. Neither of the >drafts do that right now. > >I'm not trying to be critical, I'm just hoping to get us to a place >where the IESG sees the value of the work. > > >>---- >> >>Looking at the list of "requirements for a solution" prompts the >>thought >>that we should distinguish two things: >> >>- the conex "building block" - the ability for any node to see the >>rest-of-path congestion (& the whole path congestion) >>- the solutions to various aspects of 'congestion mgt' that can be >>built >>using the conex "building block" >> >>The conex draft charter proposes work on the first of these (ie to >>standardise the IP header bits so that whole-path congestion info is >>exposed (visible) to all nodes on the path, and to define a TCP-based >>mechanism that allows a TCP destination to tell the source the >>whole-path info, & hence the IP header can be set by the source) >> >>The conex draft charter only proposes a little work on the second of >>these. This work item is to encourage experiments on some "use cases" >>and document about them. I guess the "use cases" would be tests >>towards >>a solution (to some aspect of congestion mgt) that might get >>deployed by >>an operator. > >I don't see anything wrong with this approach. The use cases are bound >to come up all the time though, since it can sometimes be difficult to >conceptualize the building block without an example of what you would >do with the building block. That's probably also why we end up with >solutions discussions in problem statement documents. :) > >Alissa > >> >>We should be clear: the charter doesn't propose to standardise a full >>solution that would get deployed. Rather it standardises a capability >>which would be used to build a solution. >> >>Not sure if everyone will agree with this! >> >>phil >> >>>-----Original Message----- >>>From: re-ecn-bounces@ietf.org >>>[mailto:re-ecn-bounces@ietf.org] On Behalf Of Bob Briscoe >>>Sent: 05 March 2010 18:09 >>>To: Alissa Cooper >>>Cc: re-ecn@ietf.org >>>Subject: Re: [re-ECN] draft-tschofenig-conex-ps and our >>>recommendation for the group >>> >>> >>>Alissa, >>> >>>At 15:14 04/03/2010, Alissa Cooper wrote: >>>>Bob, >>>> >>>>Couple of thoughts inline. >>>> >>>>On Mar 3, 2010, at 4:23 PM, Bob Briscoe wrote: >>>>>I thought draft-moncaster-conex-problem hit about the right >>>spot - it >>>>>focuses on the problem of accountability for causing congestion. >>>>>Admittedly, it mentions some other things ConEx could solve, but it >>>>>keeps focus on the one problem fairly well. >>>>> >>>>>Incidentally, Rich Woundy has done a presentation on what >>>additional >>>>>benefits re-ECN would provide over ComCast's solution: It's >>>under the >>>>>link to all the speaker presentations in the article >>>>>here: >>>>>Specifically: >>>>> >>>> >>>>I think there is a lot to like in draft-moncaster-problem, >>>and it does >>>>focus to some extent on congestion accountability. But I think there >>>>could be a clearer statement of what problem congestion >>>accountability >>>>would be solving. From reading the problem statement and looking at >>>>Rich's slides, there seem to be three congestion-related >>>problems that >>>>congestion exposure could help to solve >>>> >>>>1) LEDBAT-style congestion control is not currently incentivized >>>>because operators who use volume accounting treat apps that >>>use it just >>>>like everything else. This is thoroughly discussed in draft- >>>>moncaster-problem. >>> >>>yes >>> >>> >>>>2) Operators have no way to know, within the network, the volume of >>>>congestion being created by other networks, and therefore no way to >>>>hold those other networks accountable. This is not so thoroughly >>>>discussed in draft-moncaster-problem. >>> >>>Yes. >>>And you're right that draft-moncaster-problem doesn't do this aspect >>>as much justice. >>> >>> >>>>3) Users/apps need more information about congestion in order to be >>>>able to respond better. This is not really discussed in draft- >>>>moncaster-problem. >>> >>>Don't agree with this one. It's not actually true to say users/apps >>>don't have congestion info - they have full visibility of >>>their congestion. >>> >>>But this congestion information has no *significance* to users/apps, >>>while they know that networks cannot see it. >>> >>> >>>>I think it would be helpful for the group to have some sense >>>of which >>>>subset of these problems we are trying to solve. Then, >>>ticking through >>>>the mechanisms that already exist to solve the problems and >>>showing how >>>>they are deficient could lead to the conclusion that the congestion >>>>exposure work is warranted (draft-moncaster-problem already >>>does this >>>>to some extent, but in my reading at least the link between >>>the stated >>>>problems, the inadequacies of the existing solutions, and >>>the reasons >>>>why conex would improve the situation is somewhat weak). >>> >>>OK. Agreed. >>>We also need to make sure this same approach comes across in the BoF >>>presentations. >>> >>> From Rich's presentation, we have the following that match your >>>list, and add to it: >>>==Requirements for a long term solution:== >>>a) Incentivize customer-directed prioritization of >>>application bandwidth usage >>>b) Avoid 'cat and mouse game' with the detection and mitigation of >>>specific protocols >>>c) Enable transparency of network operation for current and >>>future applications >>>d) Support growth in per-customer average and peak bandwidth >>>e) Avoid uneconomic capacity upgrades that benefit only 5% of heavy >>>usage customers >>>==Advantages of re-ECN over FairShare:== >>>f) Re-ECN enables end-to-end congestion management >>>g) Re-ECN signals the presence of congestion to user applications and >>>to all devices on the network path >>>h) Re-ECN enables additional user and/or application >>>responses to congestion >>>i) Re-ECN enables DDoS mitigation and other capabilities >>> >>>a) = your #1) >>>b) ConEx is not unique in this respect >>>c) = perhaps an additional particularly strong point of ConEx? >>>d) & e) supply side strengths of ConEx >>>f) = your #2) >>>g) = your #3) but I say the Internet already does this well >>>h) = your #1 again >>>i) another strength of ConEx, but only to be mentioned in passing; >>> >>>We're left with the following unique selling points: >>>a) Incentivize customer-controlled prioritization of app >>>bandwidth usage >>>c) Enable unambiguous transparent network operations for >>>current & future apps >>>d) Drive capacity investment where financially warranted >>>f) Enable e2e congestion mgmt between networks as well as by >>>single networks >>>i) Enable DDoS mitigation [only to mention in passing] >>> >>>HTH >>> >>> >>>Bob >>> >>>>Alissa >>>> >>>>>HTH >>>>> >>>>> >>>>>Bob >>>>> >>>>>At 13:44 02/03/2010, Tschofenig, Hannes (NSN - FI/Espoo) wrote: >>>>>>Hi all, >>>>>> >>>>>>we wanted to provide a bit of details of why Alissa and I >>>worked on >>>>>>draft-tschofenig-conex-ps. >>>>>> >>>>>>Our goal for the problem statement document was >>>>>>1) to offer a writeup that does not talk about the solution >>>>>>2) to focus on one aspect of the perceived problem only. >>>>>> >>>>>>While there may be the other problems problems out there that a >>>>>>specific solution can solve (e.g. denial of service >>>attacks, trouble- >>>>>>shooting of network problems) we really think that one >>>needs to focus >>>>>>on one thing >>>>>>at the time because otherwise you run into what I call the >>>>>>HIP-effect(*). >>>>>> >>>>>>The problem needs to be well understood and documented >>>before one can >>>>>>go forward with the next step. The lack of a clear problem >>>statement >>>>>>discussion was for me recognizable at the BOF. >>>>>> >>>>>>Once people agree on the problem then it is interesting to capture >>>>>>the state of the art as far as what tools operators are >>>already using >>>>>>to solve the problem. Since a number of operator believe >>>they have a >>>>>>problem there is a wide range of solutions they are deploying >>>>>>today. The >>>>>>excellent writeup by Jason and Ric (see >>>>>>draft-livingood-woundy-congestion-mgmt) is one example of >>>a solution >>>>>>that offers very interesting properties already (such as being >>>>>>protocol >>>>>>agnostic). There are other solution approaches that other >>>>>>operators >>>>>>are >>>>>>deploying but they are less well documented. Every solution has >>>>>>pros and >>>>>>cons and, from what we can tell, there is no one-size fits all >>>>>>approach. >>>>>> >>>>>> >>>>>>Unfortunately, we have not seen a lot of discussions about what is >>>>>>being done and why the group considers them as insufficient. This >>>>>>leads to the >>>>>>next point, namely to document what is not good enough with the >>>>>>available techniques. If there is a specific problem identified, >>>>>>and the >>>>>>inadequacies of the existing solutions are compelling, that argues >>>>>>that >>>>>>there is space for new work in this area. >>>>>> >>>>>>So, in a summary we would suggest the following approach >>>and this is >>>>>>also the approach we will try to take as we rev our problem >>>>>>statement (although there will certainly still be gaps), and there >>>>>>are some elements of it in the draft-moncaster problem >>>statement, but >>>>>>we wanted >>>>>>to frame the thought process before posting a new version: >>>>>> >>>>>>A) Figure out whether most people agree to a description of the >>>>>>problem. >>>>>> >>>>>>(There may be multiple sub-problems.) >>>>>> >>>>>>B) Document the state-of-the-art (and why people have chosen a >>>>>>certain approaches). >>>>>> >>>>>>C) Document the gaps that are not covered by state-of-the-art >>>>>>solutions that would require additional work. For me a really >>>>>>important question >>>>>>is what are the incentives for someone to deploy anything in >>>>>>addition to >>>>>>draft-livingood-woundy-congestion-mgmt? >>>>>> >>>>>>There are other ways to approach the topic but we believe >>>that this >>>>>>is the appropriate way in this case. >>>>>> >>>>>>Ciao >>>>>>Hannes & Alissa >>>>>> >>>>>>(*): A solution that solves all problems but none really well. >>>>>> >>>>>>_______________________________________________ >>>>>>re-ECN mailing list >>>>>>re-ECN@ietf.org >>>>>>https://www.ietf.org/mailman/listinfo/re-ecn >>>>> >>>>>________________________________________________________________ >>>>>Bob Briscoe, BT Innovate & Design >>>>>_______________________________________________ >>>>>re-ECN mailing list >>>>>re-ECN@ietf.org >>>>>https://www.ietf.org/mailman/listinfo/re-ecn >>> >>>________________________________________________________________ >>>Bob Briscoe, BT Innovate & Design >>> >>>_______________________________________________ >>>re-ECN mailing list >>>re-ECN@ietf.org >>>https://www.ietf.org/mailman/listinfo/re-ecn ________________________________________________________________ Bob Briscoe, BT Innovate & Design From rbriscoe@jungle.bt.co.uk Mon Mar 8 15:21:48 2010 Return-Path: X-Original-To: re-ecn@core3.amsl.com Delivered-To: re-ecn@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 3933D3A6BA8 for ; Mon, 8 Mar 2010 15:21:45 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.039 X-Spam-Level: X-Spam-Status: No, score=-2.039 tagged_above=-999 required=5 tests=[AWL=0.078, BAYES_00=-2.599, DNS_FROM_RFC_BOGUSMX=1.482, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id PEN7aqTCFmzG for ; Mon, 8 Mar 2010 15:21:35 -0800 (PST) Received: from smtp1.smtp.bt.com (smtp1.smtp.bt.com [217.32.164.137]) by core3.amsl.com (Postfix) with ESMTP id A96073A6A1C for ; Mon, 8 Mar 2010 15:21:25 -0800 (PST) Received: from i2kc08-ukbr.domain1.systemhost.net ([193.113.197.71]) by smtp1.smtp.bt.com with Microsoft SMTPSVC(6.0.3790.3959); Mon, 8 Mar 2010 23:21:29 +0000 Received: from cbibipnt08.iuser.iroot.adidom.com ([147.149.100.81]) by i2kc08-ukbr.domain1.systemhost.net with Microsoft SMTPSVC(6.0.3790.3959); Mon, 8 Mar 2010 23:21:28 +0000 Received: From bagheera.jungle.bt.co.uk ([132.146.168.158]) by cbibipnt08.iuser.iroot.adidom.com (WebShield SMTP v4.5 MR1a P0803.399); id 1268090488282; Mon, 8 Mar 2010 23:21:28 +0000 Received: from MUT.jungle.bt.co.uk ([10.73.64.63]) by bagheera.jungle.bt.co.uk (8.13.5/8.12.8) with ESMTP id o28NLNTW001623; Mon, 8 Mar 2010 23:21:23 GMT Message-Id: <201003082321.o28NLNTW001623@bagheera.jungle.bt.co.uk> X-Mailer: QUALCOMM Windows Eudora Version 7.1.0.9 Date: Mon, 08 Mar 2010 23:21:25 +0000 To: Hannes Tschofenig From: Bob Briscoe In-Reply-To: <4B8F75A4.7090107@gmx.net> References: <3D3C75174CB95F42AD6BCC56E5555B4502424066@FIESEXC015.nsn-intra.net> <201003031622.o23GMuIE004096@bagheera.jungle.bt.co.uk> <4B8F75A4.7090107@gmx.net> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-Scanned-By: MIMEDefang 2.56 on 132.146.168.158 X-OriginalArrivalTime: 08 Mar 2010 23:21:28.0906 (UTC) FILETIME=[14964AA0:01CABF16] Cc: "Tschofenig, Hannes \(NSN - FI/Espoo\)" , re-ecn@ietf.org Subject: Re: [re-ECN] Another Approach ... .Re: draft-tschofenig-conex-ps and our recommendation for the group X-BeenThere: re-ecn@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: re-inserted explicit congestion notification List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 08 Mar 2010 23:21:48 -0000 Hannes, At 08:56 04/03/2010, Hannes Tschofenig wrote: > From your mail I believe that you would like to approach the topic > in a different way, namely similar to what I had suggested as a > note in http://www.ietf.org/mail-archive/web/re-ecn/current/msg00328.html > >When I read the draft-moncaster-conex-problem I had gotten that this >is essentially the introduction chapter of reECN rather than attempt >to investigate the larger picture. I believe the intention was to try to describe why a protocol that exposes congestion is necessary. However, given re-ECN is the only example of such a thing, an abstract problem statement understandably needs to use re-ECN as the example. >The story is as follows: Instead of going through a lengthy analysis >of what the requirements are, what people do in the industry, etc. >you just standardize a solution and see what happens. In my opinion >this is the way how the work in LEDBAT came to exist. The positive >side about LEDBAT was that the algorithm was already deployed and >hence standardizing it was seen as more natural instead of going >through a more lenghty route of investigating the entire space. > >The ALTO work was not all that different. The group got scheduled >with a very specific solution approach in mind. I was in fact >stating several times that the requirements and the problem >statement and requirements work was a waste of time. > >Do you think that this would be a better route for the congestion >exposure work in the IETF? The specific solution approach works for protocols like LEDBAT & ALTO. But with ConEx it's a much more general proposition that seems to need to change IP. IMO, that warrants an attempt to explain the problem being addressed, and not solely from the perspective of one solution. I believe some on the IESG were grateful that there was a problem statement to read. Nonetheless, we also need to show that a concrete solution exists. And we need to be honest that there isn't much chance that a very different solution will address the same problem, because it took years to find even one way to address the problem that would be incrementally deployable etc. But we should expect that a w-g will be able to improve the proposed solution (as is happening with LEDBAT & ALTO). >Ciao >Hannes > >PS: You created the expectation that reECN would change the whole >Internet. That obviously raised the bar a bit. Yes. But creating expectations was somewhat justified... It offers an e2e control model for sharing capacity & most aspects of QoS with ultimate control in the network. It offers the potential to mitigate DDoS. It could even potentially drive multi-access control of access networks at L2. People are having thoughts on using it within PWEs, PCE etc and possibly for traffic engineering. It wouldn't be worth changing IP unless it was for something that could have a big impact and could be useful for more than originally envisaged. Bob >Bob Briscoe wrote: >>Hannes, >> >>Yes, I could see what you were trying to do with that draft. I'd >>like draft-tschofenig-conex-ps a lot more if it talked about >>traffic-management in general rather than p2p-traffic-management. I >>know you wanted to be very specific, but p2p was too specific. >>Talking only about p2p causes allergic reactions depending on what >>the reader's interests are. There's the same problem with video >>traffic - who decides which traffic isn't worth providing capacity for? >> >>Sally Floyd taught me well about solutions that solve all problems >>but none really well (what you call the HIP effect, but I don't >>like that association - it may be perjorative ;) >> >>I don't think re-ECN has a jack-of-all-trades-master-of-none >>problem. It has the problem that people find it difficult to >>imagine know how much better the Internet could be. This is better >>described as the "80-20 problem". But if you have a hack that >>solves 80% of the problem, what if it actually only solves 40% or >>60% of the problem longer term - because we don't have a good >>handle on how broad the problem will really be in the future? >> >>The classic example is NATs. They seemed to solve 80% of the >>addressing problem when they were first deployed, but they have >>prevented a lot of other things happening - ie. how we define what >>is included in 100% of the problem determines whether we've solved >>80% or only 10%. >> >>Similarly, some might say DPI solves 80% of the traffic management >>problem, but it has created other undesirable interactions. DPI >>doesn't encourage mutual co-operation between willing transports - >>so does it really solve 80% or 30% or 10%? >> >>I thought draft-moncaster-conex-problem hit about the right spot - >>it focuses on the problem of accountability for causing congestion. >>Admittedly, it mentions some other things ConEx could solve, but it >>keeps focus on the one problem fairly well. >> >>Incidentally, Rich Woundy has done a presentation on what >>additional benefits re-ECN would provide over ComCast's solution: >>It's under the link to all the speaker presentations in the article >>here: >>Specifically: >> >>HTH >> >> >>Bob >> >>At 13:44 02/03/2010, Tschofenig, Hannes (NSN - FI/Espoo) wrote: >>>Hi all, >>> >>>we wanted to provide a bit of details of why Alissa and I worked on >>>draft-tschofenig-conex-ps. >>> >>>Our goal for the problem statement document was >>>1) to offer a writeup that does not talk about the solution >>>2) to focus on one aspect of the perceived problem only. >>> >>>While there may be the other problems problems out there that a specific >>>solution can solve (e.g. denial of service attacks, trouble-shooting of >>>network problems) we really think that one needs to focus on one thing >>>at the time because otherwise you run into what I call the >>>HIP-effect(*). >>> >>>The problem needs to be well understood and documented before one can go >>>forward with the next step. The lack of a clear problem statement >>>discussion was for me recognizable at the BOF. >>> >>>Once people agree on the problem then it is interesting to capture the >>>state of the art as far as what tools operators are already using to >>>solve the problem. Since a number of operator believe they have a >>>problem there is a wide range of solutions they are deploying today. The >>>excellent writeup by Jason and Ric (see >>>draft-livingood-woundy-congestion-mgmt) is one example of a solution >>>that offers very interesting properties already (such as being protocol >>>agnostic). There are other solution approaches that other operators are >>>deploying but they are less well documented. Every solution has pros and >>>cons and, from what we can tell, there is no one-size fits all approach. >>> >>> >>>Unfortunately, we have not seen a lot of discussions about what is being >>>done and why the group considers them as insufficient. This leads to the >>>next point, namely to document what is not good enough with the >>>available techniques. If there is a specific problem identified, and the >>>inadequacies of the existing solutions are compelling, that argues that >>>there is space for new work in this area. >>> >>>So, in a summary we would suggest the following approach and this is >>>also the approach we will try to take as we rev our problem statement >>>(although there will certainly still be gaps), and there are some >>>elements of it in the draft-moncaster problem statement, but we wanted >>>to frame the thought process before posting a new version: >>> >>>A) Figure out whether most people agree to a description of the problem. >>> >>>(There may be multiple sub-problems.) >>> >>>B) Document the state-of-the-art (and why people have chosen a certain >>>approaches). >>> >>>C) Document the gaps that are not covered by state-of-the-art solutions >>>that would require additional work. For me a really important question >>>is what are the incentives for someone to deploy anything in addition to >>>draft-livingood-woundy-congestion-mgmt? >>> >>>There are other ways to approach the topic but we believe that this is >>>the appropriate way in this case. >>> >>>Ciao >>>Hannes & Alissa >>> >>>(*): A solution that solves all problems but none really well. >>> >>>_______________________________________________ >>>re-ECN mailing list >>>re-ECN@ietf.org >>>https://www.ietf.org/mailman/listinfo/re-ecn >> >>________________________________________________________________ >>Bob Briscoe, BT Innovate & Design >>_______________________________________________ >>re-ECN mailing list >>re-ECN@ietf.org >>https://www.ietf.org/mailman/listinfo/re-ecn > >________________________________________________________________ >Bob Briscoe, BT Innovate & Design From rbriscoe@jungle.bt.co.uk Tue Mar 9 02:45:33 2010 Return-Path: X-Original-To: re-ecn@core3.amsl.com Delivered-To: re-ecn@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 195EF3A67D4 for ; Tue, 9 Mar 2010 02:45:33 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.059 X-Spam-Level: X-Spam-Status: No, score=-2.059 tagged_above=-999 required=5 tests=[AWL=0.058, BAYES_00=-2.599, DNS_FROM_RFC_BOGUSMX=1.482, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id XUl-78aMXHG4 for ; Tue, 9 Mar 2010 02:45:26 -0800 (PST) Received: from smtp4.smtp.bt.com (smtp4.smtp.bt.com [217.32.164.151]) by core3.amsl.com (Postfix) with ESMTP id AE3C63A67A1 for ; Tue, 9 Mar 2010 02:45:25 -0800 (PST) Received: from i2kc06-ukbr.domain1.systemhost.net ([193.113.197.70]) by smtp4.smtp.bt.com with Microsoft SMTPSVC(6.0.3790.3959); Tue, 9 Mar 2010 10:45:29 +0000 Received: from cbibipnt05.iuser.iroot.adidom.com ([147.149.196.177]) by i2kc06-ukbr.domain1.systemhost.net with Microsoft SMTPSVC(6.0.3790.3959); Tue, 9 Mar 2010 10:45:28 +0000 Received: From bagheera.jungle.bt.co.uk ([132.146.168.158]) by cbibipnt05.iuser.iroot.adidom.com (WebShield SMTP v4.5 MR1a P0803.399); id 1268131527122; Tue, 9 Mar 2010 10:45:27 +0000 Received: from MUT.jungle.bt.co.uk ([10.73.4.121]) by bagheera.jungle.bt.co.uk (8.13.5/8.12.8) with ESMTP id o29AjLuN010981; Tue, 9 Mar 2010 10:45:22 GMT Message-Id: <201003091045.o29AjLuN010981@bagheera.jungle.bt.co.uk> X-Mailer: QUALCOMM Windows Eudora Version 7.1.0.9 Date: Tue, 09 Mar 2010 10:45:24 +0000 To: "EARDLEY, Phil" , Leslie Daigle From: Bob Briscoe In-Reply-To: <504109EA-8E16-407A-91A0-89AC12FCC30B@nokia.com> References: <4B88F60F.9070908@cisco.com> <504109EA-8E16-407A-91A0-89AC12FCC30B@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: 09 Mar 2010 10:45:28.0065 (UTC) FILETIME=[A1D4FF10:01CABF75] Cc: "re-ecn@ietf.org list" Subject: Re: [re-ECN] CONEX IESG comments #2 X-BeenThere: re-ecn@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: re-inserted explicit congestion notification List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 09 Mar 2010 10:45:33 -0000 Phil, Leslie, Perhaps now the I-D deadline has past we'll see some discussion of the IESG comments #1 (I posted a few days ago). In the meantime, here's my suggested response to IESG comments #2, inline... At 15:33 01/03/2010, Lars Eggert wrote: >Hi, CONEX group, > >I'm going to forward a few issues that were raised during the IESG >discussion of the charter to the list, and CC the IESG so that the >discussion can happen directly, without me being the bottleneck in the middle. > >(I'd like to thank the ADs who wrote up their issues in this way - >this will make it much easier to progress the discussion!) > >Lars > >Begin forwarded message: > > The charter says: > > > > "With the output of CONEX, it will be possible to provide sufficient > > information in each IP datagram so that any node in the network can see > > the expected rest-of-path congestion." > > > > With the scope that I heard on the call which was operation at the > > provider level, and the suggestion from Jari that this might be applied > > to PWE3, the issue of how to make this work in MPLS has to addressed. > > Indeed If the goal is operation at the SP level and PWE3, failure to > > find an acceptable MPLS solution would be a showstopper. > > > > However if the goal is only to provide a solution that operates at parts > > of the network where the packet is visible as IP and this is clearly > > stated in the requirements then the work has some merit as an experiment. To be concrete I will only talk about the specific protocol, re-ECN, as a candidate ConEx protocol. Re-ECN was designed to ensure the sender exposes congestion from any lower layer forwarding element not just IP. It was also designed to expose congestion whether that congestion exhibits as drop or as explicit markings. However, if a network wants to precisely and quickly detect that packets are under-declaring congestion, its best strategy will be to ensure that congested forwarding elements can notify congestion explicitly. If congestion could be at MPLS nodes, integrity checking of re-ECN signals has been designed to be precise if the switches comply with RFC5129, which specifies both ECN marking at a label switch and propagation of those markings up the layers to IP. There will always be nodes on the path that do not support ECN, and only drop packets when congested. The re-ECN protocol specifies that the source must declare these congestion events by re-inserting congestion feedback into the network. If support for re-ECN is implemented in the network stack of the host, it would be difficult but not impossible for an attacker to make the transport under-declare the presence of drops. A network concerned about such cheating can prevent it by deploying explicit congestion notification at potential points of congestion and deploying policing elements like those described in outline in draft-briscoe-tsvwg-re-ecn-tcp-motivation. The latest policer designs (reviewed but to appear) mitigate congestion from DDoS and a range of malicious attacks on the system. More details: ------------ Re-ECN involves two congestion notification signals in the IP header: * expected congestion (whole path) inserted by the source and immutable * actual congestion so far (upstream path), introduced into the outer header by congested forwarding elements (routers, switches). The full benefits of re-ECN quoted in the charter come from being able to subtract the latter from the former to measure downstream congestion at any IP node. While a packet is traversing a lower-layer network that supports ECN, only the actual congestion field will be visible in the outer header, while the expected congestion field will be buried in an encapsulated IP header. Whenever the IP header is decapsulated at an IP node, it will be possible to see both. The uses proposed so far for re-ECN are only relevant at trust boundaries, either customer-network or network-network. Although there are some proposals to operate MPLS across trust boundaries without coming up to the IP layer, the design of re-ECN was on the basis that IP is considered the protocol for inter-networking. If networks wish to use MPLS as an internetworking protocol, it can only be assumed they have their own trust relationship or bespoke trust mechanisms in place. > > > > I agree with Adrian that this work looks experimental and really ought > > to be an IRTF project, and only when it has been shown to work correctly > > in an experimental environment should we do the heavy weight engineering > > needed to make this a robust protocol suitable for deployment in the > > operational Internet. As in response to comment #1: Experimental track: yes. But that doesn't mean IRTF. It has been researched to death already. It may not be appreciated that re-ECN requires no changes to IETF data plane standards. HTH Bob >_______________________________________________ >re-ECN mailing list >re-ECN@ietf.org >https://www.ietf.org/mailman/listinfo/re-ecn ________________________________________________________________ Bob Briscoe, BT Innovate & Design From mirja.kuehlewind@ikr.uni-stuttgart.de Tue Mar 9 05:02:13 2010 Return-Path: X-Original-To: re-ecn@core3.amsl.com Delivered-To: re-ecn@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id B2B7A3A6800 for ; Tue, 9 Mar 2010 05:02:13 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.249 X-Spam-Level: X-Spam-Status: No, score=-2.249 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_DE=0.35] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id r397qerzsBQT for ; Tue, 9 Mar 2010 05:02:12 -0800 (PST) Received: from mailsrv.ikr.uni-stuttgart.de (mailsrv.ikr.uni-stuttgart.de [129.69.170.2]) by core3.amsl.com (Postfix) with ESMTP id 04CE53A67FA for ; Tue, 9 Mar 2010 05:02:11 -0800 (PST) Received: from netsrv1.ikr.uni-stuttgart.de (netsrv1-c [10.11.12.12]) by mailsrv.ikr.uni-stuttgart.de (Postfix) with ESMTP id C93DA43A07 for ; Tue, 9 Mar 2010 14:02:14 +0100 (CET) Received: from localhost (inode21 [10.21.18.11]) by netsrv1.ikr.uni-stuttgart.de (Postfix) with ESMTP id BAB1DBC07E for ; Tue, 9 Mar 2010 14:02:14 +0100 (CET) From: Mirja Kuehlewind Organization: University of Stuttgart (Germany), IKR To: re-ecn@ietf.org Date: Tue, 9 Mar 2010 14:02:12 +0100 User-Agent: KMail/1.9.10 (enterprise35 0.20090731.1005176) References: <88061F01C2B84E8FB392C3CB0F0B96DA@your029b8cecfe> <201003041227.o24CRLMV022433@bagheera.jungle.bt.co.uk> In-Reply-To: <201003041227.o24CRLMV022433@bagheera.jungle.bt.co.uk> X-KMail-QuotePrefix: > MIME-Version: 1.0 Content-Type: Text/Plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-Id: <201003091402.13215.mirja.kuehlewind@ikr.uni-stuttgart.de> Subject: Re: [re-ECN] CONEX IESG comments #1 X-BeenThere: re-ecn@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: re-inserted explicit congestion notification List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 09 Mar 2010 13:02:13 -0000 Hi, see comments inline... > > > 1. This looks like really interesting research work with a > > > potential outcome > > > that could provide substantial benefit. But why is this not > > > proposed as work > > > in the IRTF? > > [BB]: Research on the protocol is all done. It started in 2003 and > it's baked enough for standards - at least experimental (see below). > For instance, collected on the re-ECN project home page there's: > - 18 papers on re-ECN, including > - 4 assessments by other researchers or organisations > (the protocol went through two evolutions in response to attacks > proposed by researchers in these papers and more informally on mailing > lists) - 2 implementations plus simulator implementations > - 8 articles from the technical media > > Yes, there is research going on the IRTF (ICCRG) on the implications > for congestion control of ConEx. But the protocol itself is not > research any more. It is a pre-requisite for a branch of the ICCRG's > research, hence bringing it the IETF. Yes, I think so too. Research at least on re-ECN as a starting point for a congestion exposure protocol is done. To form a working group which will get a protocol ready for standardization would be a good next step at this point. Furthermore, I think will should make clear that a conex protocol is a signaling protocol. Such a protocol will signal congestion information to network component. This will not change any network behavior so far. Just a soon as a policer comes into action by e.g. dropping packets or the application developers use new congestion control mechanisms the traffic will change. So from my view the deployment and usage work (see #3) might be a topic for IRTF research. But how to do research on this without having a protocol and/or framework which provides any kind of congestion accountibility...? > > > > 2. The charter seems to be trying to say that the work will be > > > > Experimental > > > > > (which sounds like a grand goal), but fails dismally! I see... > > > The output of the CONEX WG are Informational and Experimental > > > documents, apart from work item #2 which is tentatively slated for > > > Standards Track. Depending on the bits that are proposed to be used > > > in the IP header and their semantics (e.g., Bit 48 in IPv4, "ECN > > > Nonce"), there may need to be further Standards Track or Informational > > > documents to reassign those bits from their current definitions > > > (which would be subject to appropriate IESG and IETF review as > > > necessary). > > > But #2 is... > > > Specification of IPv4 and IPv6 packet structures to carry CONEX > > > information (header bits, interpretation) > > > And, in fact, no other documents listed would be appropriate as > > > Experimental. > > > Why are the protocol specifications not also listed as > > Experimental? If (and > > > this is clearly not known yet because the protocol specs have not been > > > written) it is necessary to use some bits, bytes, or codepoints that > > > currently require standards action, then it would be appropriate > > > to write a > > > standards action document to reassign those fields as experimental. > > > This document would be distinct from the protocol specification. > > We should ask for the main protocol docs to be IETF experimental > track which may require necessary stds track docs to change the > status of relevant fields in existing RFCs (e.g. from reserved to > experimental). > > Assessment of whether adoption will happen is one of the most common > uses for the experimental track. > IRTF isn't appropriate, as the protocol has been researched to death. This is another point for forming a working group. We probably need a standard track doc to change the status of the relevant bits. But it should be more clear what we want to achieve; Standard track or Experimental? As there has been already discussion about this on the list, I have the feeling we do not really have an agreement about that on the list, do we? > > > 3. Deployment and usage models > > > According to the charter, it appears that the deployment and usage work > > > is intended to follow on from the protocol specification and BCPs. I > > > > feel that > > > > > there is considerable lack of clarity about how/where the proposed > > > mechanisms would be deployed. That is, it is unclear whether "...any > > > node along the network path..." is meant to mean what it says. > > > - Why is the deployment model not part of the problem spec? > > > - Is there an assumption that there is IP forwarding at every hop? > > > - Is there an implication that MPLS extensions will also be developed? > > > - Can you show some deployment examples? > > I know of at least two groups of folks are already working on > deployment scenarios, and incentives. Both are part of > industry-academic consortia: > - one hosted by David Clark's group at MIT. > - the other is part of the Trilogy project. > > These have both been helped a lot by Matt Mathis's suggestions on this > list. > > If this milestone was brought forward, I'm sure material created by > both/either of these groups would be ready in time for inclusion. > Plus, of course, additional IETF work itself - and any other people > working in this space that I'm not aware of. Maybe we should state clearly why the usage models are not part of the charter. (I would say because its a too wide field...) But we might want to focus more strongly on the benefits of conex in charter on a higher level. This might come along with the points Alissa stated: - enable 'better' or appropriate congestion control, e.g. LEDBAT - congestion accountability between ISPs And there is one further point we did not talk about so far: re-ECN will enable the use of ECN. Today no one wants to use ECN because (beside that it might no work at all) you will have a disadvantage against someone not using ECN. Or say it the other way around; you might have an advantage not using ECN. re-ECN will creating an advantage for using ECN. > > > > 4. ISP support > > > Somewhat tied to the previous point is the issue I cannot find > > > > supporters in > > > > > the operational departments of ISPs. I have been trying, because I feel > > > it is important to understand their views. But the most I can get back > > > is "We will watch it in case it goes somewhere." Unfortunately, I also > > > hear a lot of "Our company does not support this work. We believe it > > > will waste industry resources and cause confusion. We do not understand > > > how we could deploy it within our business model, and have no plans to > > > deploy it." - Where is the ISP support for this? > > If I were an ISP, I wouldn't necessarily have developed a policy on > using ConEx at this stage. For comparison (without implying any > equivalence between Diffserv & ConEx) at the Diffserv BoF in April > 1997 few of the operational people in ISPs had policies on deploying > Diffserv. > > However, on this list it would be great to see messages of > interest/support from operational/commercial people in ISPs. I have > pointed this list at the interest expressed in the assessment of > ConEx at Probably ISPs are more interested in the deployment and usage models of conex. As we separated this from the protocol, I can imagined that the benefits of conex are not clear. This seems to make a lot of people conex automatically connected to congestion charging/pricing. I still think we should explicit try to break this link. I'm still not sure how to do this. Maybe enumerate the benefits of conex explicit as basically suggested by Alissa. (I wouldn't wanne talk about 'selling points'... ;-) ) > > > > 5. Security > > > The charter does give a passing nod to the existence of security and > > > trust issues. These need to be addressed up front. An architecture that > > > > relies on > > > > > ISPs not gaming the system and not lying is critical in this area. The > > > security and veracity of the information shared will also be critical. > > > - Where is the security and trust model described? > > There's been a huge amount of work on the integrity of the info > provided by ConEx / re-ECN. The main doc on this is > draft-briscoe-tsvwg-re-ecn-tcp-motivation > > In addition, I have prepared a comprehensive report giving pseudocode > of policers/droppers etc, attack models, defences, simulations of the > defence mechanisms etc. But I still cannot publish it because my > company's IPR department (still) haven't given me permission to > publish. Rest assured it will be available for when the w-g needs it tho. > > I am also aware of others who are working on their own designs for > the security elements of a ConEx system. As a conex protocol is a signaling protocol it will not change any traffic characteristics. Many effects I have seen when investigating re-ECN are based on ECN or RED mechanism. When using the conex information you have to be aware of the mechanisms the conex protocol will be based on and you have to consider influences of other inter-working protocol. But enabling conex or re-ECN alone in the endsystem will not change the traffic. Another point is to make sure the conex information is declared honestly. Therefore you might need a dropper or something in the network or at network egress. This elements needs to considered when designing a conex protocol. At least requirements on such a element need to be phrased, from my point of view. However, policer design will be part of the deployment cases. We should not mention the policer in respect to any security analysis. BR, Mirja From mirja.kuehlewind@ikr.uni-stuttgart.de Tue Mar 9 05:18:56 2010 Return-Path: X-Original-To: re-ecn@core3.amsl.com Delivered-To: re-ecn@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 276CE3A67F6 for ; Tue, 9 Mar 2010 05:18:53 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.949 X-Spam-Level: X-Spam-Status: No, score=-1.949 tagged_above=-999 required=5 tests=[AWL=-0.300, BAYES_00=-2.599, HELO_EQ_DE=0.35, J_CHICKENPOX_43=0.6] 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 ZBBiDVZHQsCo for ; Tue, 9 Mar 2010 05:18:42 -0800 (PST) Received: from mailsrv.ikr.uni-stuttgart.de (mailsrv.ikr.uni-stuttgart.de [129.69.170.2]) by core3.amsl.com (Postfix) with ESMTP id D7A8E3A680B for ; Tue, 9 Mar 2010 05:18:33 -0800 (PST) Received: from netsrv1.ikr.uni-stuttgart.de (netsrv1-c [10.11.12.12]) by mailsrv.ikr.uni-stuttgart.de (Postfix) with ESMTP id 4C4D343A07 for ; Tue, 9 Mar 2010 14:18:36 +0100 (CET) Received: from localhost (inode21 [10.21.18.11]) by netsrv1.ikr.uni-stuttgart.de (Postfix) with ESMTP id 37E2EBC07E for ; Tue, 9 Mar 2010 14:18:36 +0100 (CET) From: Mirja Kuehlewind Organization: University of Stuttgart (Germany), IKR To: re-ecn@ietf.org Date: Tue, 9 Mar 2010 14:18:34 +0100 User-Agent: KMail/1.9.10 (enterprise35 0.20090731.1005176) References: <4B943BE9.40304@thinkingcat.com> <3D3C75174CB95F42AD6BCC56E5555B45024AD4E6@FIESEXC015.nsn-intra.net> <4B953212.5020402@thinkingcat.com> In-Reply-To: <4B953212.5020402@thinkingcat.com> X-KMail-QuotePrefix: > MIME-Version: 1.0 Content-Type: Text/Plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Content-Disposition: inline Message-Id: <201003091418.34691.mirja.kuehlewind@ikr.uni-stuttgart.de> Subject: Re: [re-ECN] Draft agenda, prep'ing for Anaheim (IETF77) X-BeenThere: re-ecn@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: re-inserted explicit congestion notification List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 09 Mar 2010 13:19:03 -0000 Hi Leslie, I agree with Hannes. I would like to see the agenda more focused. Up to now= =20 the agenda looks quite packed for an one hour slot and also quite similar t= o=20 the agenda of the last bof (at least from my point of view).=20 To have an intro what conex is (without any reference to re-ECN) is probabl= y a=20 good idea. But the first step before this might be to show up the problem a= nd=20 make everybody in the room understand the problem.=20 Then I like the approach of showing current practice and where the gaps are= =2E=20 This (hopefully) will lead to a clear statement what the benefits/selling=20 points of conex are. I would like to see a slide which says 1. enable CC li= ke=20 LEDBAT, 2. congestion accountability bt. ISPs, 3. enable ECN and so one at= =20 the end of the presentations to start the discussion.=20 I think we should use this one our slot at least to keep conex in the=20 discussion. But of course it is more challenging to keep focused on the mai= n=20 points. But this can also help to make the people understand some single=20 aspects of congestion exposure without trying to map the protocol on the=20 various deployment scenarios all the times. BR, Mirja On Monday 08 March 2010 18:21:22 Leslie Daigle wrote: > Hi Hannes, > > I think we're agreeing on the overall structure, except > > 1/ I've added some brief intro of what "it" is (otherwise we'll flail, > again!) > > 2/ I'd like to leave enough time for discussion. But, see the issue > about scheduling -- we may have only 1 usable hour of meeting time, and > our options will be to either run with that, or wait and see if we can > get better scheduling in Maastricht. > > To be clear -- I *do not* want to push this discussion off to Maastricht > -- we had momentum in Hiroshima, and that doesn't last forever. But, > I'm pretty stymied by the inability to get more than 1 usable hour of > meeting time. > > Leslie. > > Tschofenig, Hannes (NSN - FI/Espoo) wrote: > > Hi Leslie, > > > > I have a slightly modified proposal. Let us not turn this into rocket > > science. > > > > I would like to simplify the story a bit: > > > > * Briefly summarize the findings of data usage (there are a few papers > > to talk about). > > Figure out whether people agree that there is a problem. > > > > [The chairs could give that presentation.] > > > > * Explain what the state the art is. > > This has to include the work Comcast is done with their FairShare > > > > [I could imagine that Ric would be a perfect speaker.] > > > > * Why is the state-of-the-art not sufficient? > > The presentation would cover gaps in the existing solutions. > > What are the desired properties of a system we would like to have. > > > > [Maybe an operator or an equipment vendor could provide some insight.] > > > > Finally, leave enough time for discussion. I am sure that people have > > interesting insight into the state of the art and what is wrong with it. > > There are at least a couple of companies on this list that ship stuff to > > operators while we speak (just not Conex). > > > > Ciao > > Hannes > > > >> -----Original Message----- > >> From: re-ecn-bounces@ietf.org [mailto:re-ecn-bounces@ietf.org] > >> On Behalf Of ext Leslie Daigle > >> Sent: 08 March, 2010 01:51 > >> To: re-ecn@ietf.org; Philip Eardley > >> Subject: [re-ECN] Draft agenda, prep'ing for Anaheim (IETF77) > >> > >> > >> Hi, > >> > >> I wanted to give a bit of an update on planning for the > >> Anaheim meeting. > >> Also, we're probably getting to be delinquent on filing an agenda. > >> That's partly because Phil & I have been working with Lars on > >> the scheduling problem: we're currently scheduled into 2 > >> approx 1 hour slots that are NOT back to back on Wednesday. > >> That's suboptimal at the best of times, but made worse by the > >> fact that the one we're advised will be the best shot at > >> getting RTG players into the room is the 2nd one. We're > >> trying to find a way to take the (currently) first slot and > >> reschedule it for later in the week. Options are few. We may > >> just cancel that session. > >> > >> With all that -- we've been thinking about how to use a 1-hour > >> slot to articulate the motivation for CONEX and lay out a > >> sensible workplan for an eventual working group. > >> > >> So, proposed: > >> > >> 1 hour slot Wed 3.10-4.10pm > >> We will finish promptly due to the plenary in the same room > >> > >> > >> * overview of conex > >> - Leslie or Phil > >> - only the high-level, architectural issue > >> * architectural overview of the problem > >> - Mark H (tbc) > >> - the problem of congestion > >> * traffic mgt problems - whole internet perspective > >> - Mat Ford (tbc), overall perspective - briefing panel at > >> last ietf > >> * Network perspective > >> - Rich Woundy (tbc) > >> - yes, ISPs think there's aproblem > >> - current solutions have drawbacks, hence want conex > >> * Lay out the CONEX proposed approach (charter) > >> - Phil or Leslie > >> * 20-30 mins discussion > >> - how to structure? > >> - hum on charter again? > >> > >> I'll note that, if we don't think we can achieve what we need > >> to in the one hour slot, we (collectively) may seriously need > >> to consider scramming the BoF for Anaheim, and review whether > >> we can take it up again later in Maastricht, if we can be > >> scheduled better. > >> > >> Leslie. > >> > >> -- > >> > >> ------------------------------------------------------------------- > >> "Reality: > >> Yours to discover." > >> -- ThinkingCat Leslie Daigle > >> leslie@thinkingcat.com > >> ------------------------------------------------------------------- > >> _______________________________________________ > >> re-ECN mailing list > >> re-ECN@ietf.org > >> https://www.ietf.org/mailman/listinfo/re-ecn =2D-=20 =2D------------------------------------------------------------------ Dipl.-Ing. Mirja K=FChlewind Institute of Communication Networks and Computer Engineering (IKR) University of Stuttgart, Germany Pfaffenwaldring 47, D-70569 Stuttgart web: www.ikr.uni-stuttgart.de email: mirja.kuehlewind@ikr.uni-stuttgart.de tel: +49(0)711/685-67973 =2D------------------------------------------------------------------ From hannes.tschofenig@nsn.com Wed Mar 10 00:40:55 2010 Return-Path: X-Original-To: re-ecn@core3.amsl.com Delivered-To: re-ecn@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id D2DB23A68C2 for ; Wed, 10 Mar 2010 00:40:55 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.551 X-Spam-Level: X-Spam-Status: No, score=-2.551 tagged_above=-999 required=5 tests=[AWL=0.048, 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 4ineNnNthIMf for ; Wed, 10 Mar 2010 00:40:53 -0800 (PST) Received: from demumfd002.nsn-inter.net (demumfd002.nsn-inter.net [93.183.12.31]) by core3.amsl.com (Postfix) with ESMTP id D2B953A680A for ; Wed, 10 Mar 2010 00:40:49 -0800 (PST) Received: from demuprx017.emea.nsn-intra.net ([10.150.129.56]) by demumfd002.nsn-inter.net (8.12.11.20060308/8.12.11) with ESMTP id o2A8eXJO010739 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Wed, 10 Mar 2010 09:40:33 +0100 Received: from demuexc022.nsn-intra.net (demuexc022.nsn-intra.net [10.150.128.35]) by demuprx017.emea.nsn-intra.net (8.12.11.20060308/8.12.11) with ESMTP id o2A8eTdN011157; Wed, 10 Mar 2010 09:40:30 +0100 Received: from FIESEXC015.nsn-intra.net ([10.159.0.23]) by demuexc022.nsn-intra.net with Microsoft SMTPSVC(6.0.3790.3959); Wed, 10 Mar 2010 09:40:29 +0100 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Wed, 10 Mar 2010 10:39:56 +0200 Message-ID: <3D3C75174CB95F42AD6BCC56E5555B45024DACE0@FIESEXC015.nsn-intra.net> In-Reply-To: <201003082252.o28Mqrmv001407@bagheera.jungle.bt.co.uk> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [re-ECN] draft-tschofenig-conex-ps and our recommendation for the group Thread-Index: Acq/EiOTpWxUKuZxTViqSv+/CVHNsAATo0Cg References: <4A916DBC72536E419A0BD955EDECEDEC06363E9B@E03MVB1-UKBR.domain1.systemhost.net> <201003082252.o28Mqrmv001407@bagheera.jungle.bt.co.uk> From: "Tschofenig, Hannes (NSN - FI/Espoo)" To: "ext Bob Briscoe" , "Alissa Cooper" X-OriginalArrivalTime: 10 Mar 2010 08:40:29.0940 (UTC) FILETIME=[5703AB40:01CAC02D] Cc: re-ecn@ietf.org Subject: Re: [re-ECN] draft-tschofenig-conex-ps and our recommendation for the group X-BeenThere: re-ecn@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: re-inserted explicit congestion notification List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 10 Mar 2010 08:40:56 -0000 Hi Bob,=20 Alissa will likely repond to your mail but I had to add my notes here as well.=20 >Alissa, > >I agree multi-domain could be brought out more. But I don't=20 >believe it can or should be the focus. Imagine a doc that=20 >focused on multi-domain congestion accountability. It would=20 >have to start by explaining what congestion accountability is=20 >and why it's important.=20 >Only once we have the primary new idea - the congestion metric=20 >- can we introduce the secondary idea of using it between=20 >provider networks, not just between provider and customer. But if one of the core benefits of reECN over Comcast's FairShare is the multi-domain usage then you better describe that benefit.=20 In general, if you cannot explain a benefit easily to people then you will have a hard time to "sell" it.=20 The problem is not really with educating the research and the standardization community but those who buy the products and operate networks. To be honest, I see it as quite difficult for a lot of people (from the operator community) to understand why they shouldn't invest in DPI for congestion management and to better use a protocol agnostic mechanism. > >As Rich freely admits, the Comcast solution doesn't actually=20 >measure congestion. It measures per-customer volume during=20 >high utilisation, which may be somewhat related to congestion.=20 >As the doc says, that doesn't incentivise low congestion=20 >transports like LEDBAT. That proves that current network=20 >technology doesn't really have the wherewithall to measure=20 >congestion - the primary unique contribution of ConEx. This is probably more a terminology problem rather than something else IMHO.=20 The FairShare determines pre-congestion within selected nodes and then starts marking to avoid running into a congestion situation.=20 > >Regarding setting aside DoS aspects. I imagine one para=20 >somewhere near the end saying, "This doc focuses on the=20 >primary contribution ConEx claims to provide: accountability=20 >for contributing to congestion. ConEx has also been claimed to=20 >help with the other Internet problems listed below, along with=20 >references to further reading for those interested: >- mitigating DDoS [xxx] >- preventing congestion collapse [yyy] >- etc" There might be some value in including references but the DDoS aspect has not received a lot of attention and the community on this list might be the wrong audience anyway.=20 > >We're getting out of time for updating the prob statement=20 >before the deadline. But this conversation is still v useful=20 >for focusing the materials to be used in the BoF. Yep. I think we are getting there.=20 Ciao Hannes > > >Bob > >At 20:47 07/03/2010, Alissa Cooper wrote: >>Phil and Bob, >> >>On Mar 5, 2010, at 7:27 PM, =20 >> wrote: >> >>>I think reason (2) is the key one - the inter-network=20 >aspect. This is=20 >>>the new thing. >>>If the only problem of interest is an intra-network one (eg if=20 >>>congestion is always in just one network), then there will=20 >be several=20 >>>possible solutions. The livingwood draft documents an=20 >interesting one=20 >>>for instance. DPI-based solutions would be another method of=20 >different=20 >>>interest. can imagine conex-based solutions as well (see moncaster &=20 >>>other drafts). >> >>This is, I think, what Hannes and I have been trying to elucidate. >>Here's Bob's list of selling points: >> >>>>We're left with the following unique selling points: >>>>a) Incentivize customer-controlled prioritization of app bandwidth=20 >>>>usage >>>>c) Enable unambiguous transparent network operations for current &=20 >>>>future apps >>>>d) Drive capacity investment where financially warranted >>>>f) Enable e2e congestion mgmt between networks as well as by single=20 >>>>networks >>>>i) Enable DDoS mitigation [only to mention in passing] >> >> >>I think the list is more or less on target -- but identifying all of=20 >>the great things about conex (the selling points) is not the same as=20 >>identifying the problem that the work is supposed to solve. I'm not=20 >>saying that there isn't a need to emphasize the selling points, but I=20 >>am saying that if the selling points are in the problem statement,=20 >>there needs to be some demonstration of the problem that they solve. >>Thus far, the links between the problems of lack of transparency and=20 >>inter-network congestion management have not been so strongly=20 >linked to=20 >>(c) and (f), respectively, and (i) might better be saved for later so=20 >>as not to distract. >> >>But, if the central problem is that there's no way to manage inter-=20 >>network congestion as Phil says, that's what the problem statement=20 >>should focus on, and not all of these other things. Neither of the=20 >>drafts do that right now. >> >>I'm not trying to be critical, I'm just hoping to get us to a place=20 >>where the IESG sees the value of the work. >> >> >>>---- >>> >>>Looking at the list of "requirements for a solution" prompts the=20 >>>thought that we should distinguish two things: >>> >>>- the conex "building block" - the ability for any node to see the=20 >>>rest-of-path congestion (& the whole path congestion) >>>- the solutions to various aspects of 'congestion mgt' that can be=20 >>>built using the conex "building block" >>> >>>The conex draft charter proposes work on the first of these (ie to=20 >>>standardise the IP header bits so that whole-path congestion info is=20 >>>exposed (visible) to all nodes on the path, and to define a=20 >TCP-based=20 >>>mechanism that allows a TCP destination to tell the source the=20 >>>whole-path info, & hence the IP header can be set by the source) >>> >>>The conex draft charter only proposes a little work on the second of=20 >>>these. This work item is to encourage experiments on some "use cases" >>>and document about them. I guess the "use cases" would be tests=20 >>>towards a solution (to some aspect of congestion mgt) that might get=20 >>>deployed by an operator. >> >>I don't see anything wrong with this approach. The use cases=20 >are bound=20 >>to come up all the time though, since it can sometimes be=20 >difficult to=20 >>conceptualize the building block without an example of what you would=20 >>do with the building block. That's probably also why we end up with=20 >>solutions discussions in problem statement documents. :) >> >>Alissa >> >>> >>>We should be clear: the charter doesn't propose to=20 >standardise a full=20 >>>solution that would get deployed. Rather it standardises a=20 >capability=20 >>>which would be used to build a solution. >>> >>>Not sure if everyone will agree with this! >>> >>>phil >>> >>>>-----Original Message----- >>>>From: re-ecn-bounces@ietf.org >>>>[mailto:re-ecn-bounces@ietf.org] On Behalf Of Bob Briscoe >>>>Sent: 05 March 2010 18:09 >>>>To: Alissa Cooper >>>>Cc: re-ecn@ietf.org >>>>Subject: Re: [re-ECN] draft-tschofenig-conex-ps and our=20 >>>>recommendation for the group >>>> >>>> >>>>Alissa, >>>> >>>>At 15:14 04/03/2010, Alissa Cooper wrote: >>>>>Bob, >>>>> >>>>>Couple of thoughts inline. >>>>> >>>>>On Mar 3, 2010, at 4:23 PM, Bob Briscoe wrote: >>>>>>I thought draft-moncaster-conex-problem hit about the right >>>>spot - it >>>>>>focuses on the problem of accountability for causing congestion. >>>>>>Admittedly, it mentions some other things ConEx could=20 >solve, but it=20 >>>>>>keeps focus on the one problem fairly well. >>>>>> >>>>>>Incidentally, Rich Woundy has done a presentation on what >>>>additional >>>>>>benefits re-ECN would provide over ComCast's solution: It's >>>>under the >>>>>>link to all the speaker presentations in the article >>>>>>here: >>>>>>Specifically: >>>>>> >>>>> >>>>>I think there is a lot to like in draft-moncaster-problem, >>>>and it does >>>>>focus to some extent on congestion accountability. But I=20 >think there=20 >>>>>could be a clearer statement of what problem congestion >>>>accountability >>>>>would be solving. From reading the problem statement and=20 >looking at=20 >>>>>Rich's slides, there seem to be three congestion-related >>>>problems that >>>>>congestion exposure could help to solve >>>>> >>>>>1) LEDBAT-style congestion control is not currently incentivized=20 >>>>>because operators who use volume accounting treat apps that >>>>use it just >>>>>like everything else. This is thoroughly discussed in draft-=20 >>>>>moncaster-problem. >>>> >>>>yes >>>> >>>> >>>>>2) Operators have no way to know, within the network, the=20 >volume of=20 >>>>>congestion being created by other networks, and therefore=20 >no way to=20 >>>>>hold those other networks accountable. This is not so thoroughly=20 >>>>>discussed in draft-moncaster-problem. >>>> >>>>Yes. >>>>And you're right that draft-moncaster-problem doesn't do=20 >this aspect=20 >>>>as much justice. >>>> >>>> >>>>>3) Users/apps need more information about congestion in=20 >order to be=20 >>>>>able to respond better. This is not really discussed in draft-=20 >>>>>moncaster-problem. >>>> >>>>Don't agree with this one. It's not actually true to say users/apps=20 >>>>don't have congestion info - they have full visibility of their=20 >>>>congestion. >>>> >>>>But this congestion information has no *significance* to=20 >users/apps,=20 >>>>while they know that networks cannot see it. >>>> >>>> >>>>>I think it would be helpful for the group to have some sense >>>>of which >>>>>subset of these problems we are trying to solve. Then, >>>>ticking through >>>>>the mechanisms that already exist to solve the problems and >>>>showing how >>>>>they are deficient could lead to the conclusion that the=20 >congestion=20 >>>>>exposure work is warranted (draft-moncaster-problem already >>>>does this >>>>>to some extent, but in my reading at least the link between >>>>the stated >>>>>problems, the inadequacies of the existing solutions, and >>>>the reasons >>>>>why conex would improve the situation is somewhat weak). >>>> >>>>OK. Agreed. >>>>We also need to make sure this same approach comes across=20 >in the BoF=20 >>>>presentations. >>>> >>>> From Rich's presentation, we have the following that match your=20 >>>>list, and add to it: >>>>=3D=3DRequirements for a long term solution:=3D=3D >>>>a) Incentivize customer-directed prioritization of application=20 >>>>bandwidth usage >>>>b) Avoid 'cat and mouse game' with the detection and mitigation of=20 >>>>specific protocols >>>>c) Enable transparency of network operation for current and future=20 >>>>applications >>>>d) Support growth in per-customer average and peak bandwidth >>>>e) Avoid uneconomic capacity upgrades that benefit only 5% of heavy=20 >>>>usage customers =3D=3DAdvantages of re-ECN over FairShare:=3D=3D >>>>f) Re-ECN enables end-to-end congestion management >>>>g) Re-ECN signals the presence of congestion to user=20 >applications and=20 >>>>to all devices on the network path >>>>h) Re-ECN enables additional user and/or application responses to=20 >>>>congestion >>>>i) Re-ECN enables DDoS mitigation and other capabilities >>>> >>>>a) =3D your #1) >>>>b) ConEx is not unique in this respect >>>>c) =3D perhaps an additional particularly strong point of ConEx? >>>>d) & e) supply side strengths of ConEx >>>>f) =3D your #2) >>>>g) =3D your #3) but I say the Internet already does this well >>>>h) =3D your #1 again >>>>i) another strength of ConEx, but only to be mentioned in passing; >>>> >>>>We're left with the following unique selling points: >>>>a) Incentivize customer-controlled prioritization of app bandwidth=20 >>>>usage >>>>c) Enable unambiguous transparent network operations for current &=20 >>>>future apps >>>>d) Drive capacity investment where financially warranted >>>>f) Enable e2e congestion mgmt between networks as well as by single=20 >>>>networks >>>>i) Enable DDoS mitigation [only to mention in passing] >>>> >>>>HTH >>>> >>>> >>>>Bob >>>> >>>>>Alissa >>>>> >>>>>>HTH >>>>>> >>>>>> >>>>>>Bob >>>>>> >>>>>>At 13:44 02/03/2010, Tschofenig, Hannes (NSN - FI/Espoo) wrote: >>>>>>>Hi all, >>>>>>> >>>>>>>we wanted to provide a bit of details of why Alissa and I >>>>worked on >>>>>>>draft-tschofenig-conex-ps. >>>>>>> >>>>>>>Our goal for the problem statement document was >>>>>>>1) to offer a writeup that does not talk about the solution >>>>>>>2) to focus on one aspect of the perceived problem only. >>>>>>> >>>>>>>While there may be the other problems problems out there that a=20 >>>>>>>specific solution can solve (e.g. denial of service >>>>attacks, trouble- >>>>>>>shooting of network problems) we really think that one >>>>needs to focus >>>>>>>on one thing >>>>>>>at the time because otherwise you run into what I call the=20 >>>>>>>HIP-effect(*). >>>>>>> >>>>>>>The problem needs to be well understood and documented >>>>before one can >>>>>>>go forward with the next step. The lack of a clear problem >>>>statement >>>>>>>discussion was for me recognizable at the BOF. >>>>>>> >>>>>>>Once people agree on the problem then it is interesting=20 >to capture=20 >>>>>>>the state of the art as far as what tools operators are >>>>already using >>>>>>>to solve the problem. Since a number of operator believe >>>>they have a >>>>>>>problem there is a wide range of solutions they are deploying=20 >>>>>>>today. The excellent writeup by Jason and Ric (see >>>>>>>draft-livingood-woundy-congestion-mgmt) is one example of >>>>a solution >>>>>>>that offers very interesting properties already (such as being=20 >>>>>>>protocol agnostic). There are other solution approaches=20 >that other=20 >>>>>>>operators are deploying but they are less well documented. Every=20 >>>>>>>solution has pros and cons and, from what we can tell,=20 >there is no=20 >>>>>>>one-size fits all approach. >>>>>>> >>>>>>> >>>>>>>Unfortunately, we have not seen a lot of discussions=20 >about what is=20 >>>>>>>being done and why the group considers them as=20 >insufficient. This=20 >>>>>>>leads to the next point, namely to document what is not good=20 >>>>>>>enough with the available techniques. If there is a specific=20 >>>>>>>problem identified, and the inadequacies of the existing=20 >solutions=20 >>>>>>>are compelling, that argues that there is space for new work in=20 >>>>>>>this area. >>>>>>> >>>>>>>So, in a summary we would suggest the following approach >>>>and this is >>>>>>>also the approach we will try to take as we rev our problem=20 >>>>>>>statement (although there will certainly still be gaps),=20 >and there=20 >>>>>>>are some elements of it in the draft-moncaster problem >>>>statement, but >>>>>>>we wanted >>>>>>>to frame the thought process before posting a new version: >>>>>>> >>>>>>>A) Figure out whether most people agree to a description of the=20 >>>>>>>problem. >>>>>>> >>>>>>>(There may be multiple sub-problems.) >>>>>>> >>>>>>>B) Document the state-of-the-art (and why people have chosen a=20 >>>>>>>certain approaches). >>>>>>> >>>>>>>C) Document the gaps that are not covered by state-of-the-art=20 >>>>>>>solutions that would require additional work. For me a really=20 >>>>>>>important question is what are the incentives for someone to=20 >>>>>>>deploy anything in addition to=20 >>>>>>>draft-livingood-woundy-congestion-mgmt? >>>>>>> >>>>>>>There are other ways to approach the topic but we believe >>>>that this >>>>>>>is the appropriate way in this case. >>>>>>> >>>>>>>Ciao >>>>>>>Hannes & Alissa >>>>>>> >>>>>>>(*): A solution that solves all problems but none really well. >>>>>>> >>>>>>>_______________________________________________ >>>>>>>re-ECN mailing list >>>>>>>re-ECN@ietf.org >>>>>>>https://www.ietf.org/mailman/listinfo/re-ecn >>>>>> >>>>>>________________________________________________________________ >>>>>>Bob Briscoe, BT Innovate & Design >>>>>>_______________________________________________ >>>>>>re-ECN mailing list >>>>>>re-ECN@ietf.org >>>>>>https://www.ietf.org/mailman/listinfo/re-ecn >>>> >>>>________________________________________________________________ >>>>Bob Briscoe, BT Innovate & Design >>>> >>>>_______________________________________________ >>>>re-ECN mailing list >>>>re-ECN@ietf.org >>>>https://www.ietf.org/mailman/listinfo/re-ecn > >________________________________________________________________ >Bob Briscoe, BT Innovate & Design=20 > >_______________________________________________ >re-ECN mailing list >re-ECN@ietf.org >https://www.ietf.org/mailman/listinfo/re-ecn > From leslie@thinkingcat.com Wed Mar 10 01:17:25 2010 Return-Path: X-Original-To: re-ecn@core3.amsl.com Delivered-To: re-ecn@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id BB58B3A680A for ; Wed, 10 Mar 2010 01:17:25 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.299 X-Spam-Level: X-Spam-Status: No, score=-2.299 tagged_above=-999 required=5 tests=[AWL=0.300, 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 6uGxfeqOiAh8 for ; Wed, 10 Mar 2010 01:17:23 -0800 (PST) Received: from zeke.ecotroph.net (zeke.ecotroph.net [70.164.19.155]) by core3.amsl.com (Postfix) with ESMTP id AE2953A67DA for ; Wed, 10 Mar 2010 01:17:23 -0800 (PST) Received: from beethoven.local ([::ffff:81.253.82.217]) (AUTH: PLAIN leslie, SSL: TLSv1/SSLv3,256bits,AES256-SHA) by zeke.ecotroph.net with esmtp; Wed, 10 Mar 2010 04:17:26 -0500 id 015AC513.4B9763A6.000001C4 Message-ID: <4B97639C.8020501@thinkingcat.com> Date: Wed, 10 Mar 2010 04:17:16 -0500 From: Leslie Daigle User-Agent: Thunderbird 2.0.0.23 (Macintosh/20090812) MIME-Version: 1.0 To: "re-ecn@ietf.org" Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: [re-ECN] CONEX scheduling change at IETF 77 X-BeenThere: re-ecn@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: re-inserted explicit congestion notification List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 10 Mar 2010 09:17:25 -0000 Hi, Just making sure you've seen this scheduling change: > Wednesday 0900-1015 Morning Session I > California D IRTF iccrg Internet Congestion Control Research > Group > -Moved from Thursday Afternoon Session II 1510-1610 > > Thursday 1510-1610 Afternoon Session II > California B TSV conex Congestion Exposure BOF > -Moved from Wednesday Morning Session I 0900-1015 > > > Thursday 0900-1130 Morning Session I > California C APP core Constrained RESTful Environments > -Previously known as Application Protocols for Low-power V6 Networks BOF > (6lowapp) From my/Phil's perspective, this is good news -- we can do the intro session on Wednesday (when there aren't RTG conflicts), and then have a further session afterwards. We'll be back with proposed agenda update based on list discussion. Leslie. -- ------------------------------------------------------------------- "Reality: Yours to discover." -- ThinkingCat Leslie Daigle leslie@thinkingcat.com ------------------------------------------------------------------- From rbriscoe@jungle.bt.co.uk Wed Mar 10 07:19:27 2010 Return-Path: X-Original-To: re-ecn@core3.amsl.com Delivered-To: re-ecn@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id DE0513A68C1 for ; Wed, 10 Mar 2010 07:19:26 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.07 X-Spam-Level: X-Spam-Status: No, score=-2.07 tagged_above=-999 required=5 tests=[AWL=0.047, BAYES_00=-2.599, DNS_FROM_RFC_BOGUSMX=1.482, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 6t85YSiQJr4l for ; Wed, 10 Mar 2010 07:19:19 -0800 (PST) Received: from smtp3.smtp.bt.com (smtp3.smtp.bt.com [217.32.164.138]) by core3.amsl.com (Postfix) with ESMTP id 903983A68BB for ; Wed, 10 Mar 2010 07:19:19 -0800 (PST) Received: from i2kc08-ukbr.domain1.systemhost.net ([193.113.197.71]) by smtp3.smtp.bt.com with Microsoft SMTPSVC(6.0.3790.3959); Wed, 10 Mar 2010 15:19:22 +0000 Received: from cbibipnt08.iuser.iroot.adidom.com ([147.149.100.81]) by i2kc08-ukbr.domain1.systemhost.net with Microsoft SMTPSVC(6.0.3790.3959); Wed, 10 Mar 2010 15:19:23 +0000 Received: From bagheera.jungle.bt.co.uk ([132.146.168.158]) by cbibipnt08.iuser.iroot.adidom.com (WebShield SMTP v4.5 MR1a P0803.399); id 1268234362792; Wed, 10 Mar 2010 15:19:22 +0000 Received: from MUT.jungle.bt.co.uk ([10.215.130.87]) by bagheera.jungle.bt.co.uk (8.13.5/8.12.8) with ESMTP id o2AFJJ2w008231; Wed, 10 Mar 2010 15:19:20 GMT Message-Id: <201003101519.o2AFJJ2w008231@bagheera.jungle.bt.co.uk> X-Mailer: QUALCOMM Windows Eudora Version 7.1.0.9 Date: Wed, 10 Mar 2010 15:19:22 +0000 To: "Tschofenig, Hannes (NSN - FI/Espoo)" From: Bob Briscoe In-Reply-To: <3D3C75174CB95F42AD6BCC56E5555B45024DACE0@FIESEXC015.nsn-in tra.net> References: <4A916DBC72536E419A0BD955EDECEDEC06363E9B@E03MVB1-UKBR.domain1.systemhost.net> <201003082252.o28Mqrmv001407@bagheera.jungle.bt.co.uk> <3D3C75174CB95F42AD6BCC56E5555B45024DACE0@FIESEXC015.nsn-intra.net> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-Scanned-By: MIMEDefang 2.56 on 132.146.168.158 X-OriginalArrivalTime: 10 Mar 2010 15:19:23.0041 (UTC) FILETIME=[10411110:01CAC065] Cc: re-ecn@ietf.org Subject: Re: [re-ECN] draft-tschofenig-conex-ps and our recommendation for the group X-BeenThere: re-ecn@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: re-inserted explicit congestion notification List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 10 Mar 2010 15:19:27 -0000 Hannes, Agree with your other comments, but one stands out... At 08:39 10/03/2010, Tschofenig, Hannes (NSN - FI/Espoo) wrote: > >As Rich freely admits, the Comcast solution doesn't actually > >measure congestion. It measures per-customer volume during > >high utilisation, which may be somewhat related to congestion. > >As the doc says, that doesn't incentivise low congestion > >transports like LEDBAT. That proves that current network > >technology doesn't really have the wherewithall to measure > >congestion - the primary unique contribution of ConEx. > >This is probably more a terminology problem rather than something else >IMHO. > >The FairShare determines pre-congestion within selected nodes and then >starts marking to avoid running into a congestion situation. If one transport (e.g. LEDBAT) can contribute a lot less to congestion than another, while sending more volume during high utilisation,... then FairShare is using a proxy for a congestion metric that is not sufficient. Don't get me wrong, I think FairShare is a great step forward. But we all agree FairShare doesn't create the incentives to use LEDBAT-like transports, which proves volume-during-high-utilisation is not an ideal proxy for a congestion metric. We have a crisis of people's imaginations for how much further we can go by extending approaches like LEDBAT - we need to show this with some real code I guess. This isn't terminology. It's because we, as a community, have a weak understanding of what can be done during millisecond timescales by computers. Instead we think in terms of utilisation because it is measured at human timescales averaged over minutes. And we find it difficult to imagine a wide range of different responses to congestion, because in practice we have largely experienced just two dominant modes: TCP and unresponsive. Bob ________________________________________________________________ Bob Briscoe, BT Innovate & Design From acooper@cdt.org Thu Mar 11 13:06:46 2010 Return-Path: X-Original-To: re-ecn@core3.amsl.com Delivered-To: re-ecn@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id BA4C63A67A8 for ; Thu, 11 Mar 2010 13:06:46 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.607 X-Spam-Level: X-Spam-Status: No, score=-2.607 tagged_above=-999 required=5 tests=[AWL=-0.008, 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 zWrzr+LTRi6j for ; Thu, 11 Mar 2010 13:06:44 -0800 (PST) Received: from mail.maclaboratory.net (mail.maclaboratory.net [209.190.215.232]) by core3.amsl.com (Postfix) with ESMTP id CCEB83A6800 for ; Thu, 11 Mar 2010 13:06:30 -0800 (PST) Received: from catz-493a.stcatz.ox.ac.uk ([129.67.49.58]) (authenticated user acooper@cdt.org) by mail.maclaboratory.net (using TLSv1/SSLv3 with cipher AES128-SHA (128 bits)); Thu, 11 Mar 2010 16:06:25 -0500 Message-Id: From: Alissa Cooper To: Bob Briscoe In-Reply-To: <201003082252.o28Mqrmv001407@bagheera.jungle.bt.co.uk> Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v936) Date: Thu, 11 Mar 2010 21:06:22 +0000 References: <4A916DBC72536E419A0BD955EDECEDEC06363E9B@E03MVB1-UKBR.domain1.systemhost.net> <201003082252.o28Mqrmv001407@bagheera.jungle.bt.co.uk> X-Mailer: Apple Mail (2.936) Cc: re-ecn@ietf.org Subject: Re: [re-ECN] draft-tschofenig-conex-ps and our recommendation for the group X-BeenThere: re-ecn@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: re-inserted explicit congestion notification List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 11 Mar 2010 21:06:46 -0000 Hi Bob, Replies inline... On Mar 8, 2010, at 10:52 PM, Bob Briscoe wrote: > Alissa, > > I agree multi-domain could be brought out more. But I don't believe > it can or should be the focus. Imagine a doc that focused on multi- > domain congestion accountability. It would have to start by > explaining what congestion accountability is and why it's important. > Only once we have the primary new idea - the congestion metric - can > we introduce the secondary idea of using it between provider > networks, not just between provider and customer. I think it's fine to introduce the general concept before a more specific concept. But no matter what, the problem statement needs to start with the problem -- not the solution. Congestion accountability is a solution. > > As Rich freely admits, the Comcast solution doesn't actually measure > congestion. It measures per-customer volume during high utilisation, > which may be somewhat related to congestion. As the doc says, that > doesn't incentivise low congestion transports like LEDBAT. That > proves that current network technology doesn't really have the > wherewithall to measure congestion - the primary unique contribution > of ConEx. > Agreed (I disagree with Hannes on this a little bit). > > Regarding setting aside DoS aspects. I imagine one para somewhere > near the end saying, "This doc focuses on the primary contribution > ConEx claims to provide: accountability for contributing to > congestion. ConEx has also been claimed to help with the other > Internet problems listed below, along with references to further > reading for those interested: > - mitigating DDoS [xxx] > - preventing congestion collapse [yyy] > - etc" > Could be fine, I just think we should focus on getting the core right first. Alissa > We're getting out of time for updating the prob statement before the > deadline. But this conversation is still v useful for focusing the > materials to be used in the BoF. > > > Bob > > At 20:47 07/03/2010, Alissa Cooper wrote: >> Phil and Bob, >> >> On Mar 5, 2010, at 7:27 PM, > > wrote: >> >>> I think reason (2) is the key one - the inter-network aspect. This >>> is >>> the new thing. >>> If the only problem of interest is an intra-network one (eg if >>> congestion is always in just one network), then there will be >>> several >>> possible solutions. The livingwood draft documents an interesting >>> one >>> for instance. DPI-based solutions would be another method of >>> different >>> interest. can imagine conex-based solutions as well (see moncaster & >>> other drafts). >> >> This is, I think, what Hannes and I have been trying to elucidate. >> Here's Bob's list of selling points: >> >>>> We're left with the following unique selling points: >>>> a) Incentivize customer-controlled prioritization of app >>>> bandwidth usage >>>> c) Enable unambiguous transparent network operations for >>>> current & future apps >>>> d) Drive capacity investment where financially warranted >>>> f) Enable e2e congestion mgmt between networks as well as by >>>> single networks >>>> i) Enable DDoS mitigation [only to mention in passing] >> >> >> I think the list is more or less on target -- but identifying all of >> the great things about conex (the selling points) is not the same as >> identifying the problem that the work is supposed to solve. I'm not >> saying that there isn't a need to emphasize the selling points, but I >> am saying that if the selling points are in the problem statement, >> there needs to be some demonstration of the problem that they solve. >> Thus far, the links between the problems of lack of transparency and >> inter-network congestion management have not been so strongly linked >> to (c) and (f), respectively, and (i) might better be saved for later >> so as not to distract. >> >> But, if the central problem is that there's no way to manage inter- >> network congestion as Phil says, that's what the problem statement >> should focus on, and not all of these other things. Neither of the >> drafts do that right now. >> >> I'm not trying to be critical, I'm just hoping to get us to a place >> where the IESG sees the value of the work. >> >> >>> ---- >>> >>> Looking at the list of "requirements for a solution" prompts the >>> thought >>> that we should distinguish two things: >>> >>> - the conex "building block" - the ability for any node to see the >>> rest-of-path congestion (& the whole path congestion) >>> - the solutions to various aspects of 'congestion mgt' that can be >>> built >>> using the conex "building block" >>> >>> The conex draft charter proposes work on the first of these (ie to >>> standardise the IP header bits so that whole-path congestion info is >>> exposed (visible) to all nodes on the path, and to define a TCP- >>> based >>> mechanism that allows a TCP destination to tell the source the >>> whole-path info, & hence the IP header can be set by the source) >>> >>> The conex draft charter only proposes a little work on the second of >>> these. This work item is to encourage experiments on some "use >>> cases" >>> and document about them. I guess the "use cases" would be tests >>> towards >>> a solution (to some aspect of congestion mgt) that might get >>> deployed by >>> an operator. >> >> I don't see anything wrong with this approach. The use cases are >> bound >> to come up all the time though, since it can sometimes be difficult >> to >> conceptualize the building block without an example of what you would >> do with the building block. That's probably also why we end up with >> solutions discussions in problem statement documents. :) >> >> Alissa >> >>> >>> We should be clear: the charter doesn't propose to standardise a >>> full >>> solution that would get deployed. Rather it standardises a >>> capability >>> which would be used to build a solution. >>> >>> Not sure if everyone will agree with this! >>> >>> phil >>> >>>> -----Original Message----- >>>> From: re-ecn-bounces@ietf.org >>>> [mailto:re-ecn-bounces@ietf.org] On Behalf Of Bob Briscoe >>>> Sent: 05 March 2010 18:09 >>>> To: Alissa Cooper >>>> Cc: re-ecn@ietf.org >>>> Subject: Re: [re-ECN] draft-tschofenig-conex-ps and our >>>> recommendation for the group >>>> >>>> >>>> Alissa, >>>> >>>> At 15:14 04/03/2010, Alissa Cooper wrote: >>>>> Bob, >>>>> >>>>> Couple of thoughts inline. >>>>> >>>>> On Mar 3, 2010, at 4:23 PM, Bob Briscoe wrote: >>>>>> I thought draft-moncaster-conex-problem hit about the right >>>> spot - it >>>>>> focuses on the problem of accountability for causing congestion. >>>>>> Admittedly, it mentions some other things ConEx could solve, >>>>>> but it >>>>>> keeps focus on the one problem fairly well. >>>>>> >>>>>> Incidentally, Rich Woundy has done a presentation on what >>>> additional >>>>>> benefits re-ECN would provide over ComCast's solution: It's >>>> under the >>>>>> link to all the speaker presentations in the article >>>>>> here: >>>>>> Specifically: >>>>>> >>>>> >>>>> I think there is a lot to like in draft-moncaster-problem, >>>> and it does >>>>> focus to some extent on congestion accountability. But I think >>>>> there >>>>> could be a clearer statement of what problem congestion >>>> accountability >>>>> would be solving. From reading the problem statement and looking >>>>> at >>>>> Rich's slides, there seem to be three congestion-related >>>> problems that >>>>> congestion exposure could help to solve >>>>> >>>>> 1) LEDBAT-style congestion control is not currently incentivized >>>>> because operators who use volume accounting treat apps that >>>> use it just >>>>> like everything else. This is thoroughly discussed in draft- >>>>> moncaster-problem. >>>> >>>> yes >>>> >>>> >>>>> 2) Operators have no way to know, within the network, the volume >>>>> of >>>>> congestion being created by other networks, and therefore no way >>>>> to >>>>> hold those other networks accountable. This is not so thoroughly >>>>> discussed in draft-moncaster-problem. >>>> >>>> Yes. >>>> And you're right that draft-moncaster-problem doesn't do this >>>> aspect >>>> as much justice. >>>> >>>> >>>>> 3) Users/apps need more information about congestion in order to >>>>> be >>>>> able to respond better. This is not really discussed in draft- >>>>> moncaster-problem. >>>> >>>> Don't agree with this one. It's not actually true to say users/apps >>>> don't have congestion info - they have full visibility of >>>> their congestion. >>>> >>>> But this congestion information has no *significance* to users/ >>>> apps, >>>> while they know that networks cannot see it. >>>> >>>> >>>>> I think it would be helpful for the group to have some sense >>>> of which >>>>> subset of these problems we are trying to solve. Then, >>>> ticking through >>>>> the mechanisms that already exist to solve the problems and >>>> showing how >>>>> they are deficient could lead to the conclusion that the >>>>> congestion >>>>> exposure work is warranted (draft-moncaster-problem already >>>> does this >>>>> to some extent, but in my reading at least the link between >>>> the stated >>>>> problems, the inadequacies of the existing solutions, and >>>> the reasons >>>>> why conex would improve the situation is somewhat weak). >>>> >>>> OK. Agreed. >>>> We also need to make sure this same approach comes across in the >>>> BoF >>>> presentations. >>>> >>>> From Rich's presentation, we have the following that match your >>>> list, and add to it: >>>> ==Requirements for a long term solution:== >>>> a) Incentivize customer-directed prioritization of >>>> application bandwidth usage >>>> b) Avoid 'cat and mouse game' with the detection and mitigation of >>>> specific protocols >>>> c) Enable transparency of network operation for current and >>>> future applications >>>> d) Support growth in per-customer average and peak bandwidth >>>> e) Avoid uneconomic capacity upgrades that benefit only 5% of heavy >>>> usage customers >>>> ==Advantages of re-ECN over FairShare:== >>>> f) Re-ECN enables end-to-end congestion management >>>> g) Re-ECN signals the presence of congestion to user applications >>>> and >>>> to all devices on the network path >>>> h) Re-ECN enables additional user and/or application >>>> responses to congestion >>>> i) Re-ECN enables DDoS mitigation and other capabilities >>>> >>>> a) = your #1) >>>> b) ConEx is not unique in this respect >>>> c) = perhaps an additional particularly strong point of ConEx? >>>> d) & e) supply side strengths of ConEx >>>> f) = your #2) >>>> g) = your #3) but I say the Internet already does this well >>>> h) = your #1 again >>>> i) another strength of ConEx, but only to be mentioned in passing; >>>> >>>> We're left with the following unique selling points: >>>> a) Incentivize customer-controlled prioritization of app >>>> bandwidth usage >>>> c) Enable unambiguous transparent network operations for >>>> current & future apps >>>> d) Drive capacity investment where financially warranted >>>> f) Enable e2e congestion mgmt between networks as well as by >>>> single networks >>>> i) Enable DDoS mitigation [only to mention in passing] >>>> >>>> HTH >>>> >>>> >>>> Bob >>>> >>>>> Alissa >>>>> >>>>>> HTH >>>>>> >>>>>> >>>>>> Bob >>>>>> >>>>>> At 13:44 02/03/2010, Tschofenig, Hannes (NSN - FI/Espoo) wrote: >>>>>>> Hi all, >>>>>>> >>>>>>> we wanted to provide a bit of details of why Alissa and I >>>> worked on >>>>>>> draft-tschofenig-conex-ps. >>>>>>> >>>>>>> Our goal for the problem statement document was >>>>>>> 1) to offer a writeup that does not talk about the solution >>>>>>> 2) to focus on one aspect of the perceived problem only. >>>>>>> >>>>>>> While there may be the other problems problems out there that a >>>>>>> specific solution can solve (e.g. denial of service >>>> attacks, trouble- >>>>>>> shooting of network problems) we really think that one >>>> needs to focus >>>>>>> on one thing >>>>>>> at the time because otherwise you run into what I call the >>>>>>> HIP-effect(*). >>>>>>> >>>>>>> The problem needs to be well understood and documented >>>> before one can >>>>>>> go forward with the next step. The lack of a clear problem >>>> statement >>>>>>> discussion was for me recognizable at the BOF. >>>>>>> >>>>>>> Once people agree on the problem then it is interesting to >>>>>>> capture >>>>>>> the state of the art as far as what tools operators are >>>> already using >>>>>>> to solve the problem. Since a number of operator believe >>>> they have a >>>>>>> problem there is a wide range of solutions they are deploying >>>>>>> today. The >>>>>>> excellent writeup by Jason and Ric (see >>>>>>> draft-livingood-woundy-congestion-mgmt) is one example of >>>> a solution >>>>>>> that offers very interesting properties already (such as being >>>>>>> protocol >>>>>>> agnostic). There are other solution approaches that other >>>>>>> operators >>>>>>> are >>>>>>> deploying but they are less well documented. Every solution has >>>>>>> pros and >>>>>>> cons and, from what we can tell, there is no one-size fits all >>>>>>> approach. >>>>>>> >>>>>>> >>>>>>> Unfortunately, we have not seen a lot of discussions about >>>>>>> what is >>>>>>> being done and why the group considers them as insufficient. >>>>>>> This >>>>>>> leads to the >>>>>>> next point, namely to document what is not good enough with the >>>>>>> available techniques. If there is a specific problem identified, >>>>>>> and the >>>>>>> inadequacies of the existing solutions are compelling, that >>>>>>> argues >>>>>>> that >>>>>>> there is space for new work in this area. >>>>>>> >>>>>>> So, in a summary we would suggest the following approach >>>> and this is >>>>>>> also the approach we will try to take as we rev our problem >>>>>>> statement (although there will certainly still be gaps), and >>>>>>> there >>>>>>> are some elements of it in the draft-moncaster problem >>>> statement, but >>>>>>> we wanted >>>>>>> to frame the thought process before posting a new version: >>>>>>> >>>>>>> A) Figure out whether most people agree to a description of the >>>>>>> problem. >>>>>>> >>>>>>> (There may be multiple sub-problems.) >>>>>>> >>>>>>> B) Document the state-of-the-art (and why people have chosen a >>>>>>> certain approaches). >>>>>>> >>>>>>> C) Document the gaps that are not covered by state-of-the-art >>>>>>> solutions that would require additional work. For me a really >>>>>>> important question >>>>>>> is what are the incentives for someone to deploy anything in >>>>>>> addition to >>>>>>> draft-livingood-woundy-congestion-mgmt? >>>>>>> >>>>>>> There are other ways to approach the topic but we believe >>>> that this >>>>>>> is the appropriate way in this case. >>>>>>> >>>>>>> Ciao >>>>>>> Hannes & Alissa >>>>>>> >>>>>>> (*): A solution that solves all problems but none really well. >>>>>>> >>>>>>> _______________________________________________ >>>>>>> re-ECN mailing list >>>>>>> re-ECN@ietf.org >>>>>>> https://www.ietf.org/mailman/listinfo/re-ecn >>>>>> >>>>>> ________________________________________________________________ >>>>>> Bob Briscoe, BT Innovate & Design >>>>>> _______________________________________________ >>>>>> re-ECN mailing list >>>>>> re-ECN@ietf.org >>>>>> https://www.ietf.org/mailman/listinfo/re-ecn >>>> >>>> ________________________________________________________________ >>>> Bob Briscoe, BT Innovate & Design >>>> >>>> _______________________________________________ >>>> re-ECN mailing list >>>> re-ECN@ietf.org >>>> https://www.ietf.org/mailman/listinfo/re-ecn > > ________________________________________________________________ > Bob Briscoe, BT Innovate & Design > From leslie@thinkingcat.com Fri Mar 12 10:41:51 2010 Return-Path: X-Original-To: re-ecn@core3.amsl.com Delivered-To: re-ecn@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 4182B3A689D for ; Fri, 12 Mar 2010 10:41:51 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.11 X-Spam-Level: X-Spam-Status: No, score=-1.11 tagged_above=-999 required=5 tests=[BAYES_05=-1.11] 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 mR4iPiMg7GXf for ; Fri, 12 Mar 2010 10:41:49 -0800 (PST) Received: from zeke.ecotroph.net (zeke.ecotroph.net [70.164.19.155]) by core3.amsl.com (Postfix) with ESMTP id D51C83A6821 for ; Fri, 12 Mar 2010 10:41:47 -0800 (PST) Received: from [172.29.112.54] ([::ffff:80.13.124.136]) (AUTH: PLAIN leslie, SSL: TLSv1/SSLv3,256bits,AES256-SHA) by zeke.ecotroph.net with esmtp; Fri, 12 Mar 2010 13:41:51 -0500 id 015B00BF.4B9A8AEF.00004E3D Message-ID: <4B9A8AE5.7010802@thinkingcat.com> Date: Fri, 12 Mar 2010 13:41:41 -0500 From: Leslie Daigle User-Agent: Thunderbird 2.0.0.23 (Macintosh/20090812) MIME-Version: 1.0 To: "re-ecn@ietf.org" , Philip Eardley Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: [re-ECN] Preliminary agenda posted X-BeenThere: re-ecn@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: re-inserted explicit congestion notification List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 12 Mar 2010 18:41:51 -0000 Hi, With the news of the scheduling change for CONEX, and taking into account the calls for more crispness in the agenda, I've posted the following agenda for our sessions. (We're past due for posting our agenda; we can updated it based on any further discussion if needed). Co-Chairs: Phil Eardley Leslie Daigle Proposed charter: http://www.ietf.org/iesg/evaluation/conex-charter.txt Related drafts: http://tools.ietf.org/html/draft-moncaster-conex-problem-00 http://tools.ietf.org/html/draft-tschofenig-conex-ps-02 Wed 15h10-16h10 [0h00] * Agenda bash [0h05] * Overview of conex - Leslie or Phil - only the high-level, architectural issue [0h10] * Traffic mgt problems (data) - whole internet perspective - Mat Ford (tbc), overall perspective - briefing panel at last ietf [0h20] * High level review of approaches to traffic management to date - ?? presenter - what exists, and what's still left to solve [0h30] * Network perspective - Rich Woundy (tbc) - yes, ISPs think there's a problem - current solutions have drawbacks, hence want conex [0h40] * Lay out the CONEX proposed approach (charter) - Phil or Leslie [0h45] * 15 mins discussion - how to structure? - hum on charter again? [1h00] Thu 15h10-16h10 [0h00] * Agenda bash Subject to change based on outcome of Wed meeting [0h05] * Lay out the CONEX proposed approach (charter) - Phil or Leslie [0h10] * Discussion of problem statement in charter [0h25] * Discussion of necessary work items [0h40] * Discussion of milestones Leslie. -- ------------------------------------------------------------------- "Reality: Yours to discover." -- ThinkingCat Leslie Daigle leslie@thinkingcat.com ------------------------------------------------------------------- From richard_woundy@cable.comcast.com Fri Mar 12 10:51:04 2010 Return-Path: X-Original-To: re-ecn@core3.amsl.com Delivered-To: re-ecn@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id CA3F63A68D3 for ; Fri, 12 Mar 2010 10:51:04 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.13 X-Spam-Level: X-Spam-Status: No, score=-3.13 tagged_above=-999 required=5 tests=[AWL=-2.667, BAYES_00=-2.599, HELO_EQ_MODEMCABLE=0.768, HOST_EQ_MODEMCABLE=1.368] 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 ZoPx5dIGoI2p for ; Fri, 12 Mar 2010 10:51:04 -0800 (PST) Received: from paoakoavas10.cable.comcast.com (paoakoavas10.cable.comcast.com [208.17.35.59]) by core3.amsl.com (Postfix) with ESMTP id C7FA83A67EA for ; Fri, 12 Mar 2010 10:51:03 -0800 (PST) Received: from ([10.52.116.30]) by paoakoavas10.cable.comcast.com with ESMTP id KP-TDCH7.78561159; Fri, 12 Mar 2010 13:50:40 -0500 Received: from pacdcexcmb05.cable.comcast.com ([24.40.15.116]) by PAOAKEXCSMTP01.cable.comcast.com with Microsoft SMTPSVC(6.0.3790.3959); Fri, 12 Mar 2010 13:50:40 -0500 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: base64 Date: Fri, 12 Mar 2010 13:49:53 -0500 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [re-ECN] Preliminary agenda posted Thread-Index: AcrCE7bMCVytPBMzRRiVfsUhTV38rQAARZtY From: "Woundy, Richard" To: , , X-OriginalArrivalTime: 12 Mar 2010 18:50:40.0507 (UTC) FILETIME=[E9705CB0:01CAC214] Subject: Re: [re-ECN] Preliminary agenda posted X-BeenThere: re-ecn@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: re-inserted explicit congestion notification List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 12 Mar 2010 18:51:04 -0000 Pi0gUmljaCBXb3VuZHkgKHRiYykNCg0KSSBjYW4gY29uZmlybTsgd2UgY2FuIHdvcmsgZGV0YWls cyBvZmZsaXN0Lg0KDQpBcG9sb2dpZXMgYXMgSSB3YXMgaWxsIHJlY2VudGx5IGFuZCB0aGVuIGRp Z2dpbmcgb3V0IG9mIG15IHdvcmsgYmFja2xvZyBhcyBhIHJlc3VsdC4NCg0KU29vbiBJIHNob3Vs ZCBwcm92aWRlIHNvbWUgcmVwbGllcyB0byBzb21lIHJlY2VudCByZS1lY24gZW1haWwgdHJhZmZp YyB3aGVyZSBCb2IgYW5kIEhhbm5lcyBoYXZlIGJlZW4gZGViYXRpbmcgd2hhdCBJIG1lYW50IHRv IHNheSBhYm91dCBjb25leC4gOikNCg0KLS0gUmljaA0KDQoNCi0tLS0tIE9yaWdpbmFsIE1lc3Nh Z2UgLS0tLS0NCkZyb206IHJlLWVjbi1ib3VuY2VzQGlldGYub3JnIDxyZS1lY24tYm91bmNlc0Bp ZXRmLm9yZz4NClRvOiByZS1lY25AaWV0Zi5vcmcgPHJlLWVjbkBpZXRmLm9yZz47IFBoaWxpcCBF YXJkbGV5IDxwaGlsaXAuZWFyZGxleUBidC5jb20+DQpTZW50OiBGcmkgTWFyIDEyIDEzOjQxOjQx IDIwMTANClN1YmplY3Q6IFtyZS1FQ05dIFByZWxpbWluYXJ5IGFnZW5kYSBwb3N0ZWQNCg0KDQpI aSwNCg0KV2l0aCB0aGUgbmV3cyBvZiB0aGUgc2NoZWR1bGluZyBjaGFuZ2UgZm9yIENPTkVYLCBh bmQgdGFraW5nIGludG8gDQphY2NvdW50IHRoZSBjYWxscyBmb3IgbW9yZSBjcmlzcG5lc3MgaW4g dGhlIGFnZW5kYSwgSSd2ZSBwb3N0ZWQgdGhlIA0KZm9sbG93aW5nIGFnZW5kYSBmb3Igb3VyIHNl c3Npb25zLiAgKFdlJ3JlIHBhc3QgZHVlIGZvciBwb3N0aW5nIG91ciANCmFnZW5kYTsgd2UgY2Fu IHVwZGF0ZWQgaXQgYmFzZWQgb24gYW55IGZ1cnRoZXIgZGlzY3Vzc2lvbiBpZiBuZWVkZWQpLg0K DQoNCkNvLUNoYWlyczoNCglQaGlsIEVhcmRsZXkNCglMZXNsaWUgRGFpZ2xlDQoNClByb3Bvc2Vk IGNoYXJ0ZXI6IGh0dHA6Ly93d3cuaWV0Zi5vcmcvaWVzZy9ldmFsdWF0aW9uL2NvbmV4LWNoYXJ0 ZXIudHh0DQoNClJlbGF0ZWQgZHJhZnRzOg0KaHR0cDovL3Rvb2xzLmlldGYub3JnL2h0bWwvZHJh ZnQtbW9uY2FzdGVyLWNvbmV4LXByb2JsZW0tMDANCmh0dHA6Ly90b29scy5pZXRmLm9yZy9odG1s L2RyYWZ0LXRzY2hvZmVuaWctY29uZXgtcHMtMDINCg0KDQpXZWQgMTVoMTAtMTZoMTANCg0KWzBo MDBdDQoqIEFnZW5kYSBiYXNoDQpbMGgwNV0NCiogT3ZlcnZpZXcgb2YgY29uZXgNCiAgICAgLSBM ZXNsaWUgb3IgUGhpbA0KICAgICAtIG9ubHkgdGhlIGhpZ2gtbGV2ZWwsIGFyY2hpdGVjdHVyYWwg aXNzdWUNClswaDEwXQ0KKiBUcmFmZmljIG1ndCBwcm9ibGVtcyAoZGF0YSkgLSB3aG9sZSBpbnRl cm5ldCBwZXJzcGVjdGl2ZQ0KICAgICAtIE1hdCBGb3JkICh0YmMpLCBvdmVyYWxsIHBlcnNwZWN0 aXZlIC0gIGJyaWVmaW5nIHBhbmVsIGF0DQogICAgICAgIGxhc3QgaWV0Zg0KWzBoMjBdDQoqIEhp Z2ggbGV2ZWwgcmV2aWV3IG9mIGFwcHJvYWNoZXMgdG8gdHJhZmZpYyBtYW5hZ2VtZW50IHRvIGRh dGUNCiAgICAgLSA/PyBwcmVzZW50ZXINCiAgICAgLSB3aGF0IGV4aXN0cywgYW5kIHdoYXQncyBz dGlsbCBsZWZ0IHRvIHNvbHZlDQpbMGgzMF0NCiogTmV0d29yayBwZXJzcGVjdGl2ZQ0KICAgICAt IFJpY2ggV291bmR5ICh0YmMpDQogICAgIC0geWVzLCBJU1BzIHRoaW5rIHRoZXJlJ3MgYSBwcm9i bGVtDQogICAgIC0gY3VycmVudCBzb2x1dGlvbnMgaGF2ZSBkcmF3YmFja3MsIGhlbmNlIHdhbnQg Y29uZXgNClswaDQwXQ0KKiBMYXkgb3V0IHRoZSBDT05FWCBwcm9wb3NlZCBhcHByb2FjaCAoY2hh cnRlcikNCiAgICAgLSBQaGlsIG9yIExlc2xpZQ0KWzBoNDVdDQoqIDE1IG1pbnMgZGlzY3Vzc2lv bg0KICAgICAtIGhvdyB0byBzdHJ1Y3R1cmU/DQogICAgIC0gaHVtIG9uIGNoYXJ0ZXIgYWdhaW4/ DQpbMWgwMF0NCg0KDQpUaHUgMTVoMTAtMTZoMTANCg0KWzBoMDBdDQoqIEFnZW5kYSBiYXNoDQog ICAgIFN1YmplY3QgdG8gY2hhbmdlIGJhc2VkIG9uIG91dGNvbWUgb2YgV2VkIG1lZXRpbmcNClsw aDA1XQ0KKiBMYXkgb3V0IHRoZSBDT05FWCBwcm9wb3NlZCBhcHByb2FjaCAoY2hhcnRlcikNCiAg ICAgLSBQaGlsIG9yIExlc2xpZQ0KWzBoMTBdDQoqIERpc2N1c3Npb24gb2YgcHJvYmxlbSBzdGF0 ZW1lbnQgaW4gY2hhcnRlcg0KWzBoMjVdDQoqIERpc2N1c3Npb24gb2YgbmVjZXNzYXJ5IHdvcmsg aXRlbXMNClswaDQwXQ0KKiBEaXNjdXNzaW9uIG9mIG1pbGVzdG9uZXMNCg0KDQoNCkxlc2xpZS4N Cg0KDQotLSANCg0KLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLQ0KIlJlYWxpdHk6DQogICAgICBZb3VycyB0byBkaXNjb3Zl ci4iDQogICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAtLSBUaGlua2luZ0NhdA0KTGVz bGllIERhaWdsZQ0KbGVzbGllQHRoaW5raW5nY2F0LmNvbQ0KLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLQ0KX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18NCnJlLUVDTiBtYWlsaW5nIGxp c3QNCnJlLUVDTkBpZXRmLm9yZw0KaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5m by9yZS1lY24NCg== From jason_livingood@cable.comcast.com Fri Mar 12 11:15:11 2010 Return-Path: X-Original-To: re-ecn@core3.amsl.com Delivered-To: re-ecn@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 947703A68B5 for ; Fri, 12 Mar 2010 11:15:11 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.93 X-Spam-Level: X-Spam-Status: No, score=-5.93 tagged_above=-999 required=5 tests=[AWL=0.466, BAYES_00=-2.599, HELO_EQ_MODEMCABLE=0.768, HOST_EQ_MODEMCABLE=1.368, RCVD_IN_DNSWL_HI=-8, RCVD_NUMERIC_HELO=2.067] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 9+jzOXVDqSWx for ; Fri, 12 Mar 2010 11:15:09 -0800 (PST) Received: from pacdcimo01.cable.comcast.com (PacdcIMO01.cable.comcast.com [24.40.8.145]) by core3.amsl.com (Postfix) with ESMTP id 329D53A6848 for ; Fri, 12 Mar 2010 11:15:06 -0800 (PST) Received: from ([10.52.116.31]) by pacdcimo01.cable.comcast.com with ESMTP id 5503620.74183350; Fri, 12 Mar 2010 14:14:55 -0500 Received: from PACDCEXCMB04.cable.comcast.com ([24.40.15.86]) by PAOAKEXCSMTP02.cable.comcast.com with Microsoft SMTPSVC(6.0.3790.3959); Fri, 12 Mar 2010 14:14:55 -0500 Received: from 147.191.227.88 ([147.191.227.88]) by PACDCEXCMB04.cable.comcast.com ([24.40.15.86]) via Exchange Front-End Server webmail.comcast.com ([24.40.8.153]) with Microsoft Exchange Server HTTP-DAV ; Fri, 12 Mar 2010 19:14:54 +0000 User-Agent: Microsoft-Entourage/12.23.0.091001 Date: Fri, 12 Mar 2010 14:14:56 -0500 From: Jason Livingood To: Hannes Tschofenig , ext Bob Briscoe , Alissa Cooper Message-ID: Thread-Topic: [re-ECN] draft-tschofenig-conex-ps and our recommendation for the group Thread-Index: Acq/EiOTpWxUKuZxTViqSv+/CVHNsAATo0CgAK3nGdM= In-Reply-To: <3D3C75174CB95F42AD6BCC56E5555B45024DACE0@FIESEXC015.nsn-intra.net> Mime-version: 1.0 Content-type: text/plain; charset="US-ASCII" Content-transfer-encoding: 7bit X-OriginalArrivalTime: 12 Mar 2010 19:14:55.0478 (UTC) FILETIME=[4CAB5160:01CAC218] Cc: re-ecn@ietf.org Subject: Re: [re-ECN] draft-tschofenig-conex-ps and our recommendation for the group X-BeenThere: re-ecn@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: re-inserted explicit congestion notification List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 12 Mar 2010 19:15:11 -0000 A few comments inline below. -- Jason On 3/10/10 3:39 AM, "Hannes Tschofenig" wrote: > In general, if you cannot explain a benefit easily to people then you > will have a hard time to "sell" it. > The problem is not really with educating the research and the > standardization community but those who buy the products and operate > networks. To be honest, I see it as quite difficult for a lot of people > (from the operator community) to understand why they shouldn't invest in > DPI for congestion management and to better use a protocol agnostic > mechanism. Well, such a system is certainly less expensive that deploying DPI. And ISPs like any commercial organization are sensitive cost. ;-) >> >> As Rich freely admits, the Comcast solution doesn't actually >> measure congestion. It measures per-customer volume during >> high utilisation, which may be somewhat related to congestion. >> As the doc says, that doesn't incentivise low congestion >> transports like LEDBAT. That proves that current network >> technology doesn't really have the wherewithall to measure >> congestion - the primary unique contribution of ConEx. > > This is probably more a terminology problem rather than something else > IMHO. > > The FairShare determines pre-congestion within selected nodes and then > starts marking to avoid running into a congestion situation. What Hannes says is largely accurate, but the system by no means *avoids* congestion. Congestion can still occur; it is simply that the system distributes the effects of such congestion to those few flows (users) responsible for contributing the most to the heavy utilization. This is highly beneficial to the ISP, as when congestion effects strong affect users who were not those primary traffic contributors you tend to have dissatisfaction and get phone calls from end users, etc. From jason_livingood@cable.comcast.com Fri Mar 12 11:22:02 2010 Return-Path: X-Original-To: re-ecn@core3.amsl.com Delivered-To: re-ecn@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id C62C53A6848 for ; Fri, 12 Mar 2010 11:22:02 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.047 X-Spam-Level: X-Spam-Status: No, score=-6.047 tagged_above=-999 required=5 tests=[AWL=0.349, BAYES_00=-2.599, HELO_EQ_MODEMCABLE=0.768, HOST_EQ_MODEMCABLE=1.368, RCVD_IN_DNSWL_HI=-8, RCVD_NUMERIC_HELO=2.067] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Z+mmodtKJA5W for ; Fri, 12 Mar 2010 11:22:01 -0800 (PST) Received: from pacdcimo01.cable.comcast.com (PacdcIMO01.cable.comcast.com [24.40.8.145]) by core3.amsl.com (Postfix) with ESMTP id B31593A695A for ; Fri, 12 Mar 2010 11:21:01 -0800 (PST) Received: from ([10.195.246.152]) by pacdcimo01.cable.comcast.com with ESMTP id 5503620.74184293; Fri, 12 Mar 2010 14:21:06 -0500 Received: from PACDCEXCMB04.cable.comcast.com ([24.40.15.86]) by NJMDCEXCRLY01.cable.comcast.com with Microsoft SMTPSVC(6.0.3790.3959); Fri, 12 Mar 2010 14:21:07 -0500 Received: from 147.191.227.88 ([147.191.227.88]) by PACDCEXCMB04.cable.comcast.com ([24.40.15.86]) via Exchange Front-End Server webmail.comcast.com ([24.40.8.153]) with Microsoft Exchange Server HTTP-DAV ; Fri, 12 Mar 2010 19:21:06 +0000 User-Agent: Microsoft-Entourage/12.23.0.091001 Date: Fri, 12 Mar 2010 14:20:59 -0500 From: Jason Livingood To: Bob Briscoe , Hannes Tschofenig Message-ID: Thread-Topic: [re-ECN] draft-tschofenig-conex-ps and our recommendation for the group Thread-Index: AcrCGSVYuDo2Edp2Lk+fu9XFx/rtsA== In-Reply-To: <201003101519.o2AFJJ2w008231@bagheera.jungle.bt.co.uk> Mime-version: 1.0 Content-type: text/plain; charset="US-ASCII" Content-transfer-encoding: 7bit X-OriginalArrivalTime: 12 Mar 2010 19:21:07.0403 (UTC) FILETIME=[2A5A91B0:01CAC219] Cc: re-ecn@ietf.org Subject: Re: [re-ECN] draft-tschofenig-conex-ps and our recommendation for the group X-BeenThere: re-ecn@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: re-inserted explicit congestion notification List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 12 Mar 2010 19:22:02 -0000 A few comments inline in this message as well. -- Jason On 3/10/10 10:19 AM, "Bob Briscoe" wrote: > If one transport (e.g. LEDBAT) can contribute a lot less to > congestion than another, while sending more volume during high > utilisation,... then FairShare is using a proxy for a congestion > metric that is not sufficient. Don't get me wrong, I think FairShare > is a great step forward. But we all agree FairShare doesn't create > the incentives to use LEDBAT-like transports, which proves > volume-during-high-utilisation is not an ideal proxy for a congestion metric. I don't think we've fully considered all of the interactions between our two FairShare traffic classes (Priority Best Effort, PBE, and Best Effort, BE) and LEDBAT use. One alternative may be to always classify LEDBAT traffic as BE and, if so, possibly also to not consider it when scanning for flows to mark down from PBE to BE during times of pre-congestion / near-congestion. Another incentive may be to subtract BE bytes from being counted against monthly byte usage limits (again, speaking hypothetically). But Rich may have some thoughts here as well. From jason_livingood@cable.comcast.com Fri Mar 12 11:24:51 2010 Return-Path: X-Original-To: re-ecn@core3.amsl.com Delivered-To: re-ecn@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id D28893A695A for ; Fri, 12 Mar 2010 11:24:51 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.117 X-Spam-Level: X-Spam-Status: No, score=-6.117 tagged_above=-999 required=5 tests=[AWL=0.279, BAYES_00=-2.599, HELO_EQ_MODEMCABLE=0.768, HOST_EQ_MODEMCABLE=1.368, RCVD_IN_DNSWL_HI=-8, RCVD_NUMERIC_HELO=2.067] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id KTvddRYOBDLj for ; Fri, 12 Mar 2010 11:24:51 -0800 (PST) Received: from pacdcimo01.cable.comcast.com (PacdcIMO01.cable.comcast.com [24.40.8.145]) by core3.amsl.com (Postfix) with ESMTP id D02873A6993 for ; Fri, 12 Mar 2010 11:24:11 -0800 (PST) Received: from ([10.52.116.31]) by pacdcimo01.cable.comcast.com with ESMTP id 5503620.74184682; Fri, 12 Mar 2010 14:24:01 -0500 Received: from PACDCEXCMB04.cable.comcast.com ([24.40.15.86]) by PAOAKEXCSMTP02.cable.comcast.com with Microsoft SMTPSVC(6.0.3790.3959); Fri, 12 Mar 2010 14:24:01 -0500 Received: from 147.191.227.88 ([147.191.227.88]) by PACDCEXCMB04.cable.comcast.com ([24.40.15.86]) via Exchange Front-End Server webmail.comcast.com ([24.40.8.153]) with Microsoft Exchange Server HTTP-DAV ; Fri, 12 Mar 2010 19:24:01 +0000 User-Agent: Microsoft-Entourage/12.23.0.091001 Date: Fri, 12 Mar 2010 14:24:01 -0500 From: Jason Livingood To: Jason Livingood , Hannes Tschofenig , ext Bob Briscoe , Alissa Cooper Message-ID: Thread-Topic: [re-ECN] draft-tschofenig-conex-ps and our recommendation for the group Thread-Index: Acq/EiOTpWxUKuZxTViqSv+/CVHNsAATo0CgAK3nGdMAAFE3uw== In-Reply-To: Mime-version: 1.0 Content-type: text/plain; charset="US-ASCII" Content-transfer-encoding: 7bit X-OriginalArrivalTime: 12 Mar 2010 19:24:01.0577 (UTC) FILETIME=[922B6990:01CAC219] Cc: re-ecn@ietf.org Subject: Re: [re-ECN] draft-tschofenig-conex-ps and our recommendation for the group X-BeenThere: re-ecn@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: re-inserted explicit congestion notification List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 12 Mar 2010 19:24:51 -0000 I have noticed I have completely bizarre sentence in here that I should correct. > What Hannes says is largely accurate, but the system by no means *avoids* > congestion. Congestion can still occur; it is simply that the system > distributes the effects of such congestion to those few flows (users) > responsible for contributing the most to the heavy utilization. This is > highly beneficial to the ISP, as when congestion effects strong affect users > who were not those primary traffic contributors you tend to have > dissatisfaction and get phone calls from end users, etc. Last sentence should say: This is highly beneficial to the ISP, as when congestion effects strongLY IMPACT users who were not those primary traffic contributors you tend to have dissatisfaction and get phone calls from end users, etc. From ford@isoc.org Sun Mar 14 05:52:40 2010 Return-Path: X-Original-To: re-ecn@core3.amsl.com Delivered-To: re-ecn@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id C57AE3A679C for ; Sun, 14 Mar 2010 05:52:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.599 X-Spam-Level: X-Spam-Status: No, score=-103.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Diyk-SKy5sgj for ; Sun, 14 Mar 2010 05:52:40 -0700 (PDT) Received: from smtp180.iad.emailsrvr.com (smtp180.iad.emailsrvr.com [207.97.245.180]) by core3.amsl.com (Postfix) with ESMTP id DD4663A67CF for ; Sun, 14 Mar 2010 05:52:39 -0700 (PDT) Received: from relay18.relay.iad.mlsrvr.com (localhost [127.0.0.1]) by relay18.relay.iad.mlsrvr.com (SMTP Server) with ESMTP id 8B9BE1B405A for ; Sun, 14 Mar 2010 08:52:46 -0400 (EDT) Received: by relay18.relay.iad.mlsrvr.com (Authenticated sender: ford-AT-isoc.org) with ESMTPSA id 8C7FC1B4003 for ; Sun, 14 Mar 2010 08:52:44 -0400 (EDT) Message-ID: <4B9CDC0F.9000102@isoc.org> Date: Sun, 14 Mar 2010 12:52:31 +0000 From: Matthew Ford User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.6; en-GB; rv:1.9.1.8) Gecko/20100227 Thunderbird/3.0.3 MIME-Version: 1.0 To: re-ecn@ietf.org References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: [re-ECN] draft-tschofenig-conex-ps and our recommendation for the group X-BeenThere: re-ecn@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: re-inserted explicit congestion notification List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 14 Mar 2010 12:52:40 -0000 Hi Jason, one comment, inline. - Mat On 12/03/2010 19:20, Jason Livingood wrote: > On 3/10/10 10:19 AM, "Bob Briscoe" wrote: > >> If one transport (e.g. LEDBAT) can contribute a lot less to >> congestion than another, while sending more volume during high >> utilisation,... then FairShare is using a proxy for a congestion >> metric that is not sufficient. Don't get me wrong, I think FairShare >> is a great step forward. But we all agree FairShare doesn't create >> the incentives to use LEDBAT-like transports, which proves >> volume-during-high-utilisation is not an ideal proxy for a congestion metric. > > I don't think we've fully considered all of the interactions between our two > FairShare traffic classes (Priority Best Effort, PBE, and Best Effort, BE) > and LEDBAT use. One alternative may be to always classify LEDBAT traffic as How do you identify it? From mirja.kuehlewind@ikr.uni-stuttgart.de Tue Mar 16 03:06:21 2010 Return-Path: X-Original-To: re-ecn@core3.amsl.com Delivered-To: re-ecn@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 92AAE3A682E for ; Tue, 16 Mar 2010 03:06:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.799 X-Spam-Level: X-Spam-Status: No, score=-0.799 tagged_above=-999 required=5 tests=[AWL=-1.150, 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 BD0YBPRejhFb for ; Tue, 16 Mar 2010 03:06:20 -0700 (PDT) Received: from mailsrv.ikr.uni-stuttgart.de (mailsrv.ikr.uni-stuttgart.de [129.69.170.2]) by core3.amsl.com (Postfix) with ESMTP id 1D3773A6358 for ; Tue, 16 Mar 2010 03:06:19 -0700 (PDT) Received: from netsrv1.ikr.uni-stuttgart.de (netsrv1-c [10.11.12.12]) by mailsrv.ikr.uni-stuttgart.de (Postfix) with ESMTP id 3D35B439F4 for ; Tue, 16 Mar 2010 11:06:27 +0100 (CET) Received: from vpn-1-cl15 (vpn-1-cl15 [10.88.11.25]) by netsrv1.ikr.uni-stuttgart.de (Postfix) with ESMTP id 29655BC07E for ; Tue, 16 Mar 2010 11:06:27 +0100 (CET) From: Mirja Kuehlewind Organization: University of Stuttgart (Germany), IKR To: re-ecn@ietf.org Date: Tue, 16 Mar 2010 11:06:24 +0100 User-Agent: KMail/1.9.10 (enterprise35 0.20090731.1005176) References: <4B9A8AE5.7010802@thinkingcat.com> In-Reply-To: <4B9A8AE5.7010802@thinkingcat.com> X-KMail-QuotePrefix: > MIME-Version: 1.0 Content-Type: Text/Plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Content-Disposition: inline Message-Id: <201003161106.24882.mirja.kuehlewind@ikr.uni-stuttgart.de> Subject: Re: [re-ECN] Preliminary agenda posted X-BeenThere: re-ecn@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: re-inserted explicit congestion notification List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 16 Mar 2010 10:06:21 -0000 Hi, I'm still missing the point where we say what the benefits of Conex are. Up= to=20 now we are just describing the problem and what the drawbacks of current=20 solutions are, but not why conex is better. So my suggestion is: Instead to lay out the charter in the first session we= =20 can have a slide with some buttlet points what the benefits are. Than=20 hopefully get people convinced in the follow up discussion that these point= s=20 are desirable.=20 In the second session we can put up the charter and have another discussion= =20 which is more focus on the working group focus. We can also think about shifting Rich's presentation in the second slot as= =20 this one is more about the question if there is enough support to form a=20 working group and what a beneficial outcome would be... Mirja On Friday 12 March 2010 19:41:41 Leslie Daigle wrote: > Hi, > > With the news of the scheduling change for CONEX, and taking into > account the calls for more crispness in the agenda, I've posted the > following agenda for our sessions. (We're past due for posting our > agenda; we can updated it based on any further discussion if needed). > > > Co-Chairs: > Phil Eardley > Leslie Daigle > > Proposed charter: http://www.ietf.org/iesg/evaluation/conex-charter.txt > > Related drafts: > http://tools.ietf.org/html/draft-moncaster-conex-problem-00 > http://tools.ietf.org/html/draft-tschofenig-conex-ps-02 > > > Wed 15h10-16h10 > > [0h00] > * Agenda bash > [0h05] > * Overview of conex > - Leslie or Phil > - only the high-level, architectural issue > [0h10] > * Traffic mgt problems (data) - whole internet perspective > - Mat Ford (tbc), overall perspective - briefing panel at > last ietf > [0h20] > * High level review of approaches to traffic management to date > - ?? presenter > - what exists, and what's still left to solve > [0h30] > * Network perspective > - Rich Woundy (tbc) > - yes, ISPs think there's a problem > - current solutions have drawbacks, hence want conex > [0h40] > * Lay out the CONEX proposed approach (charter) > - Phil or Leslie > [0h45] > * 15 mins discussion > - how to structure? > - hum on charter again? > [1h00] > > > Thu 15h10-16h10 > > [0h00] > * Agenda bash > Subject to change based on outcome of Wed meeting > [0h05] > * Lay out the CONEX proposed approach (charter) > - Phil or Leslie > [0h10] > * Discussion of problem statement in charter > [0h25] > * Discussion of necessary work items > [0h40] > * Discussion of milestones > > > > Leslie. =2D-=20 =2D------------------------------------------------------------------ Dipl.-Ing. Mirja K=FChlewind Institute of Communication Networks and Computer Engineering (IKR) University of Stuttgart, Germany Pfaffenwaldring 47, D-70569 Stuttgart web: www.ikr.uni-stuttgart.de email: mirja.kuehlewind@ikr.uni-stuttgart.de tel: +49(0)711/685-67973 =2D------------------------------------------------------------------ From philip.eardley@bt.com Tue Mar 16 03:23:59 2010 Return-Path: X-Original-To: re-ecn@core3.amsl.com Delivered-To: re-ecn@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 7035B3A68DC for ; Tue, 16 Mar 2010 03:23:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.509 X-Spam-Level: X-Spam-Status: No, score=-3.509 tagged_above=-999 required=5 tests=[AWL=0.090, 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 TIC4sgLw52jw for ; Tue, 16 Mar 2010 03:23:58 -0700 (PDT) Received: from smtp3.smtp.bt.com (smtp3.smtp.bt.com [217.32.164.138]) by core3.amsl.com (Postfix) with ESMTP id 670193A68B4 for ; Tue, 16 Mar 2010 03:23:58 -0700 (PDT) Received: from E03MVB1-UKBR.domain1.systemhost.net ([193.113.197.111]) by smtp3.smtp.bt.com with Microsoft SMTPSVC(6.0.3790.3959); Tue, 16 Mar 2010 10:24:04 +0000 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Tue, 16 Mar 2010 10:24:04 -0000 Message-ID: <4A916DBC72536E419A0BD955EDECEDEC06363ED5@E03MVB1-UKBR.domain1.systemhost.net> In-Reply-To: <504109EA-8E16-407A-91A0-89AC12FCC30B@nokia.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [re-ECN] CONEX IESG comments #2 Thread-Index: Acq5VUiM9p83PqJ9RE2SRRvyimF/rgLnOW6A From: To: , X-OriginalArrivalTime: 16 Mar 2010 10:24:04.0960 (UTC) FILETIME=[CDEEF600:01CAC4F2] Subject: Re: [re-ECN] CONEX IESG comments #2 X-BeenThere: re-ecn@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: re-inserted explicit congestion notification List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 16 Mar 2010 10:23:59 -0000 In-line Best wishes phil > -----Original Message----- > From: re-ecn-bounces@ietf.org=20 > [mailto:re-ecn-bounces@ietf.org] On Behalf Of Lars Eggert > Sent: 01 March 2010 15:34 > To: re-ecn@ietf.org list > Cc: The IESG > Subject: [re-ECN] CONEX IESG comments #2 >=20 >=20 > Hi, CONEX group, >=20 > I'm going to forward a few issues that were raised during the=20 > IESG discussion of the charter to the list, and CC the IESG=20 > so that the discussion can happen directly, without me being=20 > the bottleneck in the middle. >=20 > (I'd like to thank the ADs who wrote up their issues in this=20 > way - this will make it much easier to progress the discussion!) >=20 > Lars >=20 > Begin forwarded message: > > The charter says: > >=20 > > "With the output of CONEX, it will be possible to provide sufficient > > information in each IP datagram so that any node in the=20 > network can see=20 > > the expected rest-of-path congestion." > >=20 > > With the scope that I heard on the call which was operation at the > > provider level, and the suggestion from Jari that this=20 > might be applied=20 > > to PWE3, the issue of how to make this work in MPLS has to=20 > addressed.=20 > > Indeed If the goal is operation at the SP level and PWE3,=20 > failure to=20 > > find an acceptable MPLS solution would be a showstopper. > >=20 > > However if the goal is only to provide a solution that operates at=20 > > parts > > of the network where the packet is visible as IP and this=20 > is clearly=20 > > stated in the requirements then the work has some merit as=20 > an experiment. > >=20 > > I agree with Adrian that this work looks experimental and=20 > really ought > > to be an IRTF project, and only when it has been shown to=20 > work correctly=20 > > in an experimental environment should we do the heavy=20 > weight engineering=20 > > needed to make this a robust protocol suitable for=20 > deployment in the=20 > > operational Internet. Yes, the intention is for a solution that operates where the packet is visible as IP. More precisely, rest-of-path (& whole path) congestion is only visible where the packet is IP; congestion info can be set where the packet is MPLS using rfc5129. >=20 >=20 From philip.eardley@bt.com Tue Mar 16 03:26:53 2010 Return-Path: X-Original-To: re-ecn@core3.amsl.com Delivered-To: re-ecn@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id A443B3A6823 for ; Tue, 16 Mar 2010 03:26:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.517 X-Spam-Level: X-Spam-Status: No, score=-3.517 tagged_above=-999 required=5 tests=[AWL=0.082, 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 JZJjfMfOLAX3 for ; Tue, 16 Mar 2010 03:26:52 -0700 (PDT) Received: from smtp1.smtp.bt.com (smtp1.smtp.bt.com [217.32.164.137]) by core3.amsl.com (Postfix) with ESMTP id 178B43A6358 for ; Tue, 16 Mar 2010 03:26:51 -0700 (PDT) Received: from E03MVB1-UKBR.domain1.systemhost.net ([193.113.197.111]) by smtp1.smtp.bt.com with Microsoft SMTPSVC(6.0.3790.3959); Tue, 16 Mar 2010 10:26:59 +0000 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Tue, 16 Mar 2010 10:26:58 -0000 Message-ID: <4A916DBC72536E419A0BD955EDECEDEC06363ED6@E03MVB1-UKBR.domain1.systemhost.net> In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [re-ECN] CONEX IESG comments #1 Thread-Index: Acq5VQ5JvOCoH85tSsiEDT2Z2YVWAALmKqIQ From: To: , X-OriginalArrivalTime: 16 Mar 2010 10:26:59.0414 (UTC) FILETIME=[35EA8760:01CAC4F3] Subject: Re: [re-ECN] CONEX IESG comments #1 X-BeenThere: re-ecn@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: re-inserted explicit congestion notification List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 16 Mar 2010 10:26:53 -0000 Some comments in-line from my personal perspective. And thanks to the IESG for their comments phil > -----Original Message----- > From: re-ecn-bounces@ietf.org=20 > [mailto:re-ecn-bounces@ietf.org] On Behalf Of Lars Eggert > Sent: 01 March 2010 15:33 > To: re-ecn@ietf.org list > Cc: The IESG > Subject: [re-ECN] CONEX IESG comments #1 >=20 >=20 > Hi, CONEX group, >=20 > I'm going to forward a few issues that were raised during the=20 > IESG discussion of the charter to the list, and CC the IESG=20 > so that the discussion can happen directly, without me being=20 > the bottleneck in the middle. >=20 > (I'd like to thank the ADs who wrote up their issues in this=20 > way - this will make it much easier to progress the discussion!) >=20 > Lars >=20 > Begin forwarded message: > > In no particular order... > >=20 > > 1. This looks like really interesting research work with a=20 > potential=20 > > outcome > > that could provide substantial benefit. But why is this not=20 > proposed as work=20 > > in the IRTF? I agree with others that enough research has been done. I don't think further research in the IRTF would help. Personally I think "it's now or never" - either there's consensus that there's enough motivation and momentum to form an IETF WG, or there isn't.=20 > >=20 > > 2. The charter seems to be trying to say that the work will be=20 > > Experimental > > (which sounds like a grand goal), but fails dismally! I see... > > The output of the CONEX WG are Informational and Experimental > > documents, apart from work item #2 which is tentatively slated for > > Standards Track. Depending on the bits that are proposed to be used > > in the IP header and their semantics (e.g., Bit 48 in IPv4, "ECN > > Nonce"), there may need to be further Standards Track or=20 > Informational > > documents to reassign those bits from their current definitions > > (which would be subject to appropriate IESG and IETF review as > > necessary). > > But #2 is... > > Specification of IPv4 and IPv6 packet structures to carry CONEX > > information (header bits, interpretation) > >=20 > > And, in fact, no other documents listed would be appropriate as > > Experimental. > > Why are the protocol specifications not also listed as=20 > Experimental? If (and=20 > > this is clearly not known yet because the protocol specs=20 > have not been=20 > > written) it is necessary to use some bits, bytes, or=20 > codepoints that=20 > > currently require standards action, then it would be=20 > appropriate to write a=20 > > standards action document to reassign those fields as=20 > experimental. This=20 > > document would be distinct from the protocol specification. Several points here: The draft charter lists items as - INFO, for #1 (Applicability statement) and #4 (Use cases) - STD, for #2 (spec of v4 & v6 packet structure) - EXPT, for #3 (spec of TCP mod for transporting cong info from destination to sender; and spec of one mechanism to ensure trustworthiness of conex info) So the items under #3 are listed as Experimental. The packet structure (#2) is listed as Standards track. To me redefining the IP header feels like standards track rather than experimental (compare DSCP definition in rfc2474). But if everyone else is happy with Experimental, then that's ok with me. (Side-note: a question is how to confine the experiment. The re-ecn proposal seems to naturally self-limit since bit48 should be ignored by non-aware routers [and some preliminary expts showed this was ~ true].) > >=20 > > 3. Deployment and usage models > > According to the charter, it appears that the deployment and usage=20 > > work is > > intended to follow on from the protocol specification and=20 > BCPs. I feel that=20 > > there is considerable lack of clarity about how/where the proposed=20 > > mechanisms would be deployed. That is, it is unclear=20 > whether "...any node=20 > > along the network path..." is meant to mean what it says. > > - Why is the deployment model not part of the problem spec? > > - Is there an assumption that there is IP forwarding at every hop? > > - Is there an implication that MPLS extensions will also be=20 > developed? > > - Can you show some deployment examples? Several points: The deployment and usage work was intended to be in parallel with the protocol spec. The final Milestone for Use cases is a little later, to allow capture of the "results" of the experiments that use conex info - we figured that the results would be the last thing to be completed. But I agree this should be clearer.=20 "Problem spec" =3D ? There isn't a Milestone on a problem statement. = Work item #1 is an applicability statement: "including its architectural features, limitations and assumptions..." - so it's nearer to an Architecture doc that a Problem statement.=20 [Personally I think that the purpose of problem statement docs is to motivate the work and setting up of a WG, but they tend to be a distraction within a WG.] The draft charter limits the scope by assuming IP forwarding at every hop. As Bob detailed, MPLS nodes can already ECN-mark pkts, using RFC5129, or drop them; but it would need work beyond the charter if MPLS nodes were to see the rest-of-path (or whole path) congestion. Conclusion: you're right, the text should be corrected: "...any node along the network path..." Finally, (to repeat a comment I made earlier on the ML) I'd distinguish two things: - the conex "building block" - the ability for any node to see the rest-of-path congestion (& the whole path congestion) - the solutions to various aspects of 'congestion mgt' that can be built using the conex "building block" The conex draft charter proposes work on the first of these (ie to standardise the IP header bits so that whole-path congestion info is exposed (visible) to all nodes on the path, and to define a TCP-based mechanism that allows a TCP destination to tell the source the whole-path info, & hence the IP header can be set by the source) The conex draft charter only proposes a little work on the second of these. This work item is to encourage experiments on some "use cases" and document about them. I guess the "use cases" would be tests towards a solution (to some aspect of congestion mgt) that might get deployed by an operator.=20 We should be clear: the charter doesn't propose to standardise a full solution that would get deployed. Rather it standardises a capability which would be used to build a solution.=20 > >=20 > > 4. ISP support > > Somewhat tied to the previous point is the issue I cannot find=20 > > supporters in > > the operational departments of ISPs. I have been trying,=20 > because I feel it=20 > > is important to understand their views. But the most I can=20 > get back is "We=20 > > will watch it in case it goes somewhere." Unfortunately, I=20 > also hear a lot=20 > > of "Our company does not support this work. We believe it=20 > will waste=20 > > industry resources and cause confusion. We do not=20 > understand how we could=20 > > deploy it within our business model, and have no plans to=20 > deploy it." > > - Where is the ISP support for this? > >=20 > > 5. Security > > The charter does give a passing nod to the existence of=20 > security and=20 > > trust > > issues. These need to be addressed up front. An=20 > architecture that relies on=20 > > ISPs not gaming the system and not lying is critical in=20 > this area. The=20 > > security and veracity of the information shared will also=20 > be critical. > > - Where is the security and trust model described? If I get the question right: - item #1 includes describing the threats [=3D trust model?]=20 - item #3 includes work to ensure trustworthiness of the conex info Best wishes phil >=20 >=20 From ingemar.s.johansson@ericsson.com Tue Mar 16 05:15:40 2010 Return-Path: X-Original-To: re-ecn@core3.amsl.com Delivered-To: re-ecn@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 725B83A69BF for ; Tue, 16 Mar 2010 05:15:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.385 X-Spam-Level: X-Spam-Status: No, score=-3.385 tagged_above=-999 required=5 tests=[AWL=0.214, 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 erjQ+25lLyop for ; Tue, 16 Mar 2010 05:15:39 -0700 (PDT) Received: from mailgw10.se.ericsson.net (mailgw10.se.ericsson.net [193.180.251.61]) by core3.amsl.com (Postfix) with ESMTP id DFE783A6907 for ; Tue, 16 Mar 2010 05:15:38 -0700 (PDT) X-AuditID: c1b4fb3d-b7bf6ae000005bec-9e-4b9f76710852 Received: from esessmw0197.eemea.ericsson.se (Unknown_Domain [153.88.253.125]) by mailgw10.se.ericsson.net (Symantec Brightmail Gateway) with SMTP id 23.DF.23532.1767F9B4; Tue, 16 Mar 2010 13:15:46 +0100 (CET) Received: from ESESSCMS0356.eemea.ericsson.se ([169.254.2.100]) by esessmw0197.eemea.ericsson.se ([153.88.115.87]) with mapi; Tue, 16 Mar 2010 13:15:37 +0100 From: Ingemar Johansson S To: "re-ecn@ietf.org" Date: Tue, 16 Mar 2010 13:15:36 +0100 Thread-Topic: ConEx and MPLS (Was Re: CONEX IESG comments #1 (philip.eardley@bt.com)) Thread-Index: AcrE8vKBAKCoffg8RWG0oNVM/+I3NAADMgMA Message-ID: <548FC4B9D57A4043AAFFE888A39429031D01EF10B9@ESESSCMS0356.eemea.ericsson.se> References: In-Reply-To: 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== Subject: [re-ECN] ConEx and MPLS (Was Re: CONEX IESG comments #1 (philip.eardley@bt.com)) X-BeenThere: re-ecn@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: re-inserted explicit congestion notification List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 16 Mar 2010 12:15:40 -0000 Hi A question from a non-MPLS geek.=20 What are the arguments against extending ConEx to MPLS?.=20 I guess one obvious answer is the limited 3-bit field but are there more re= asons against this?.=20 My understanding is that the MPLS limitation is problematic only if one wis= h to ConEx-police traffic that comes from another ISP and that traffic is M= PLS.=20 It is still possible to do ConEx policing at the label edge routers. Of cou= rse the policing point will then not be at the border.=20 Regards Ingemar > -----Original Message----- > From: re-ecn-bounces@ietf.org=20 > [mailto:re-ecn-bounces@ietf.org] On Behalf Of re-ecn-request@ietf.org > Sent: den 16 mars 2010 11:24 > To: re-ecn@ietf.org > Subject: re-ECN Digest, Vol 13, Issue 45 >=20 > If you have received this digest without all the individual=20 > message attachments you will need to update your digest=20 > options in your list subscription. To do so, go to=20 >=20 > https://www.ietf.org/mailman/listinfo/re-ecn >=20 > Click the 'Unsubscribe or edit options' button, log in, and=20 > set "Get MIME or Plain Text Digests?" to MIME. You can set=20 > this option globally for all the list digests you receive at=20 > this point. >=20 >=20 >=20 > Send re-ECN mailing list submissions to > re-ecn@ietf.org >=20 > To subscribe or unsubscribe via the World Wide Web, visit > https://www.ietf.org/mailman/listinfo/re-ecn > or, via email, send a message with subject or body 'help' to > re-ecn-request@ietf.org >=20 > You can reach the person managing the list at > re-ecn-owner@ietf.org >=20 > When replying, please edit your Subject line so it is more=20 > specific than "Re: Contents of re-ECN digest..." >=20 >=20 > Today's Topics: >=20 > 1. Re: CONEX IESG comments #2 (philip.eardley@bt.com) >=20 >=20 > ---------------------------------------------------------------------- >=20 > Message: 1 > Date: Tue, 16 Mar 2010 10:24:04 -0000 > From: > Subject: Re: [re-ECN] CONEX IESG comments #2 > To: , > Message-ID: > =09 > <4A916DBC72536E419A0BD955EDECEDEC06363ED5@E03MVB1-UKBR.domain1 > .systemhost.net> > =09 > Content-Type: text/plain; charset=3D"us-ascii" >=20 > In-line > Best wishes > phil >=20 > > -----Original Message----- > > From: re-ecn-bounces@ietf.org > > [mailto:re-ecn-bounces@ietf.org] On Behalf Of Lars Eggert > > Sent: 01 March 2010 15:34 > > To: re-ecn@ietf.org list > > Cc: The IESG > > Subject: [re-ECN] CONEX IESG comments #2 > >=20 > >=20 > > Hi, CONEX group, > >=20 > > I'm going to forward a few issues that were raised during the IESG=20 > > discussion of the charter to the list, and CC the IESG so that the=20 > > discussion can happen directly, without me being the=20 > bottleneck in the=20 > > middle. > >=20 > > (I'd like to thank the ADs who wrote up their issues in this way -=20 > > this will make it much easier to progress the discussion!) > >=20 > > Lars > >=20 > > Begin forwarded message: > > > The charter says: > > >=20 > > > "With the output of CONEX, it will be possible to provide=20 > sufficient=20 > > > information in each IP datagram so that any node in the > > network can see > > > the expected rest-of-path congestion." > > >=20 > > > With the scope that I heard on the call which was=20 > operation at the=20 > > > provider level, and the suggestion from Jari that this > > might be applied > > > to PWE3, the issue of how to make this work in MPLS has to > > addressed.=20 > > > Indeed If the goal is operation at the SP level and PWE3, > > failure to > > > find an acceptable MPLS solution would be a showstopper. > > >=20 > > > However if the goal is only to provide a solution that=20 > operates at=20 > > > parts of the network where the packet is visible as IP and this > > is clearly > > > stated in the requirements then the work has some merit as > > an experiment. > > >=20 > > > I agree with Adrian that this work looks experimental and > > really ought > > > to be an IRTF project, and only when it has been shown to > > work correctly > > > in an experimental environment should we do the heavy > > weight engineering > > > needed to make this a robust protocol suitable for > > deployment in the > > > operational Internet. >=20 > Yes, the intention is for a solution that operates where the packet is > visible as IP. More precisely, rest-of-path (& whole path)=20 > congestion is > only visible where the packet is IP; congestion info can be set where > the packet is MPLS using rfc5129. >=20 > >=20 > >=20 >=20 >=20 > ------------------------------ >=20 > _______________________________________________ > re-ECN mailing list > re-ECN@ietf.org > https://www.ietf.org/mailman/listinfo/re-ecn >=20 >=20 > End of re-ECN Digest, Vol 13, Issue 45 > ************************************** > = From philip.eardley@bt.com Tue Mar 16 09:03:15 2010 Return-Path: X-Original-To: re-ecn@core3.amsl.com Delivered-To: re-ecn@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id CD6C23A6AD0 for ; Tue, 16 Mar 2010 09:03:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.524 X-Spam-Level: X-Spam-Status: No, score=-3.524 tagged_above=-999 required=5 tests=[AWL=0.075, 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 UOB1NJsbdWlP for ; Tue, 16 Mar 2010 09:03:14 -0700 (PDT) Received: from smtp1.smtp.bt.com (smtp1.smtp.bt.com [217.32.164.137]) by core3.amsl.com (Postfix) with ESMTP id A3D443A6B31 for ; Tue, 16 Mar 2010 09:03:06 -0700 (PDT) Received: from E03MVB1-UKBR.domain1.systemhost.net ([193.113.197.111]) by smtp1.smtp.bt.com with Microsoft SMTPSVC(6.0.3790.3959); Tue, 16 Mar 2010 16:03:14 +0000 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Date: Tue, 16 Mar 2010 16:03:12 -0000 Message-ID: <4A916DBC72536E419A0BD955EDECEDEC06363EDE@E03MVB1-UKBR.domain1.systemhost.net> In-Reply-To: <201003161106.24882.mirja.kuehlewind@ikr.uni-stuttgart.de> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [re-ECN] Preliminary agenda posted Thread-Index: AcrE8F65PprUmREHR7eCfpkoukpVewAMN+hw From: To: , X-OriginalArrivalTime: 16 Mar 2010 16:03:14.0415 (UTC) FILETIME=[2F275FF0:01CAC522] Subject: Re: [re-ECN] Preliminary agenda posted X-BeenThere: re-ecn@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: re-inserted explicit congestion notification List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 16 Mar 2010 16:03:15 -0000 Mirja, I agree that the benefits of conex must be explicitly brought out. Think = we should make sure this is part of the 2nd /3rd talks We wanted to get to the charter in the first session since this is the = one that we hope the iesg commentatros will come to (and they may not = make the 2nd slot). But squeezing into this time is challenging. Thanks phil > -----Original Message----- > From: re-ecn-bounces@ietf.org=20 > [mailto:re-ecn-bounces@ietf.org] On Behalf Of Mirja Kuehlewind > Sent: 16 March 2010 10:06 > To: re-ecn@ietf.org > Subject: Re: [re-ECN] Preliminary agenda posted >=20 >=20 > Hi, >=20 > I'm still missing the point where we say what the benefits of=20 > Conex are. Up to=20 > now we are just describing the problem and what the drawbacks=20 > of current=20 > solutions are, but not why conex is better. > So my suggestion is: Instead to lay out the charter in the=20 > first session we=20 > can have a slide with some buttlet points what the benefits are. Than=20 > hopefully get people convinced in the follow up discussion=20 > that these points=20 > are desirable.=20 >=20 > In the second session we can put up the charter and have=20 > another discussion=20 > which is more focus on the working group focus. >=20 > We can also think about shifting Rich's presentation in the=20 > second slot as=20 > this one is more about the question if there is enough=20 > support to form a=20 > working group and what a beneficial outcome would be... >=20 > Mirja >=20 >=20 > On Friday 12 March 2010 19:41:41 Leslie Daigle wrote: > > Hi, > > > > With the news of the scheduling change for CONEX, and taking into=20 > > account the calls for more crispness in the agenda, I've posted the=20 > > following agenda for our sessions. (We're past due for posting our=20 > > agenda; we can updated it based on any further discussion=20 > if needed). > > > > > > Co-Chairs: > > Phil Eardley > > Leslie Daigle > > > > Proposed charter:=20 > > http://www.ietf.org/iesg/evaluation/conex-charter.txt > > > > Related drafts:=20 > > http://tools.ietf.org/html/draft-moncaster-conex-problem-00 > > http://tools.ietf.org/html/draft-tschofenig-conex-ps-02 > > > > > > Wed 15h10-16h10 > > > > [0h00] > > * Agenda bash > > [0h05] > > * Overview of conex > > - Leslie or Phil > > - only the high-level, architectural issue > > [0h10] > > * Traffic mgt problems (data) - whole internet perspective > > - Mat Ford (tbc), overall perspective - briefing panel at > > last ietf > > [0h20] > > * High level review of approaches to traffic management to date > > - ?? presenter > > - what exists, and what's still left to solve > > [0h30] > > * Network perspective > > - Rich Woundy (tbc) > > - yes, ISPs think there's a problem > > - current solutions have drawbacks, hence want conex [0h40] > > * Lay out the CONEX proposed approach (charter) > > - Phil or Leslie > > [0h45] > > * 15 mins discussion > > - how to structure? > > - hum on charter again? > > [1h00] > > > > > > Thu 15h10-16h10 > > > > [0h00] > > * Agenda bash > > Subject to change based on outcome of Wed meeting > > [0h05] > > * Lay out the CONEX proposed approach (charter) > > - Phil or Leslie > > [0h10] > > * Discussion of problem statement in charter > > [0h25] > > * Discussion of necessary work items > > [0h40] > > * Discussion of milestones > > > > > > > > Leslie. >=20 >=20 >=20 > --=20 > ------------------------------------------------------------------- > Dipl.-Ing. Mirja K=FChlewind > Institute of Communication Networks and Computer Engineering (IKR) > University of Stuttgart, Germany > Pfaffenwaldring 47, D-70569 Stuttgart >=20 > web: www.ikr.uni-stuttgart.de > email: mirja.kuehlewind@ikr.uni-stuttgart.de > tel: +49(0)711/685-67973 > ------------------------------------------------------------------- > _______________________________________________ > re-ECN mailing list > re-ECN@ietf.org > https://www.ietf.org/mailman/listinfo/re-ecn >=20 From philip.eardley@bt.com Wed Mar 17 02:35:15 2010 Return-Path: X-Original-To: re-ecn@core3.amsl.com Delivered-To: re-ecn@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 50EE43A690A for ; Wed, 17 Mar 2010 02:35:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.965 X-Spam-Level: X-Spam-Status: No, score=-2.965 tagged_above=-999 required=5 tests=[AWL=-0.496, BAYES_00=-2.599, DNS_FROM_OPENWHOIS=1.13, 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 znkc2ylFX40N for ; Wed, 17 Mar 2010 02:35:14 -0700 (PDT) Received: from smtp3.smtp.bt.com (smtp3.smtp.bt.com [217.32.164.138]) by core3.amsl.com (Postfix) with ESMTP id 235BC3A67E5 for ; Wed, 17 Mar 2010 02:35:13 -0700 (PDT) Received: from E03MVB1-UKBR.domain1.systemhost.net ([193.113.197.111]) by smtp3.smtp.bt.com with Microsoft SMTPSVC(6.0.3790.3959); Wed, 17 Mar 2010 09:35:20 +0000 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Wed, 17 Mar 2010 09:34:28 -0000 Message-ID: <4A916DBC72536E419A0BD955EDECEDEC06363EE7@E03MVB1-UKBR.domain1.systemhost.net> In-Reply-To: <4A916DBC72536E419A0BD955EDECEDEC06363E71@E03MVB1-UKBR.domain1.systemhost.net> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [re-ECN] CONEX IESG comments #2 Thread-Index: Acq5VUiM9p83PqJ9RE2SRRvyimF/rgBls6NwArIqH2A= From: To: X-OriginalArrivalTime: 17 Mar 2010 09:35:20.0819 (UTC) FILETIME=[296C3430:01CAC5B5] Subject: Re: [re-ECN] CONEX IESG comments #2 X-BeenThere: re-ecn@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: re-inserted explicit congestion notification List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 17 Mar 2010 09:35:15 -0000 Hi, We need to put together a consolidated reply to the iesg comments. Please send any more comments today; then Leslie & I will do the consolidation thanks > -----Original Message----- > From: re-ecn-bounces@ietf.org=20 > [mailto:re-ecn-bounces@ietf.org] On Behalf Of philip.eardley@bt.com > Sent: 03 March 2010 18:41 > To: lars.eggert@nokia.com; re-ecn@ietf.org > Cc: iesg@ietf.org > Subject: Re: [re-ECN] CONEX IESG comments #2 >=20 >=20 > Thanks for your commets and also in Comments #1. >=20 > We think the best thing is if we work on the mailing list to=20 > put together a consolidated reply to the comments, which we=20 > will then send to the iesg. Hopefully a good timing for this=20 > would be over the next 2 weeks, ie reply before the ietf. >=20 > Thanks > Phil & Leslie >=20 > > -----Original Message----- > > From: re-ecn-bounces@ietf.org > > [mailto:re-ecn-bounces@ietf.org] On Behalf Of Lars Eggert > > Sent: 01 March 2010 15:34 > > To: re-ecn@ietf.org list > > Cc: The IESG > > Subject: [re-ECN] CONEX IESG comments #2 > >=20 > >=20 > > Hi, CONEX group, > >=20 > > I'm going to forward a few issues that were raised during the > > IESG discussion of the charter to the list, and CC the IESG=20 > > so that the discussion can happen directly, without me being=20 > > the bottleneck in the middle. > >=20 > > (I'd like to thank the ADs who wrote up their issues in this > > way - this will make it much easier to progress the discussion!) > >=20 > > Lars > >=20 > > Begin forwarded message: > > > The charter says: > > >=20 > > > "With the output of CONEX, it will be possible to provide=20 > sufficient=20 > > > information in each IP datagram so that any node in the > > network can see > > > the expected rest-of-path congestion." > > >=20 > > > With the scope that I heard on the call which was=20 > operation at the=20 > > > provider level, and the suggestion from Jari that this > > might be applied > > > to PWE3, the issue of how to make this work in MPLS has to > > addressed. > > > Indeed If the goal is operation at the SP level and PWE3, > > failure to > > > find an acceptable MPLS solution would be a showstopper. > > >=20 > > > However if the goal is only to provide a solution that operates at > > > parts > > > of the network where the packet is visible as IP and this=20 > > is clearly > > > stated in the requirements then the work has some merit as > > an experiment. > > >=20 > > > I agree with Adrian that this work looks experimental and > > really ought > > > to be an IRTF project, and only when it has been shown to > > work correctly > > > in an experimental environment should we do the heavy > > weight engineering > > > needed to make this a robust protocol suitable for > > deployment in the > > > operational Internet. > >=20 > >=20 > _______________________________________________ > re-ECN mailing list > re-ECN@ietf.org > https://www.ietf.org/mailman/listinfo/re-ecn >=20 From rbriscoe@jungle.bt.co.uk Wed Mar 17 09:26:49 2010 Return-Path: X-Original-To: re-ecn@core3.amsl.com Delivered-To: re-ecn@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id D479528C0F4 for ; Wed, 17 Mar 2010 09:26:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.322 X-Spam-Level: X-Spam-Status: No, score=-1.322 tagged_above=-999 required=5 tests=[AWL=-0.335, BAYES_00=-2.599, DNS_FROM_OPENWHOIS=1.13, 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 07tIiGyOFF+B for ; Wed, 17 Mar 2010 09:26:42 -0700 (PDT) Received: from smtp1.smtp.bt.com (smtp1.smtp.bt.com [217.32.164.137]) by core3.amsl.com (Postfix) with ESMTP id E6E693A6977 for ; Wed, 17 Mar 2010 09:26:15 -0700 (PDT) Received: from i2kc06-ukbr.domain1.systemhost.net ([193.113.197.70]) by smtp1.smtp.bt.com with Microsoft SMTPSVC(6.0.3790.3959); Wed, 17 Mar 2010 16:26:24 +0000 Received: from cbibipnt05.iuser.iroot.adidom.com ([147.149.196.177]) by i2kc06-ukbr.domain1.systemhost.net with Microsoft SMTPSVC(6.0.3790.3959); Wed, 17 Mar 2010 16:26:24 +0000 Received: From bagheera.jungle.bt.co.uk ([132.146.168.158]) by cbibipnt05.iuser.iroot.adidom.com (WebShield SMTP v4.5 MR1a P0803.399); id 1268843183519; Wed, 17 Mar 2010 16:26:23 +0000 Received: from MUT.jungle.bt.co.uk ([10.215.130.87]) by bagheera.jungle.bt.co.uk (8.13.5/8.12.8) with ESMTP id o2HGQENJ012231; Wed, 17 Mar 2010 16:26:14 GMT Message-Id: <201003171626.o2HGQENJ012231@bagheera.jungle.bt.co.uk> X-Mailer: QUALCOMM Windows Eudora Version 7.1.0.9 Date: Wed, 17 Mar 2010 16:26:15 +0000 To: Ingemar Johansson S From: Bob Briscoe In-Reply-To: <548FC4B9D57A4043AAFFE888A39429031D01EF10B9@ESESSCMS0356.ee mea.ericsson.se> References: <548FC4B9D57A4043AAFFE888A39429031D01EF10B9@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: 17 Mar 2010 16:26:24.0848 (UTC) FILETIME=[96545D00:01CAC5EE] Cc: "re-ecn@ietf.org" Subject: Re: [re-ECN] ConEx and MPLS (Was Re: CONEX IESG comments #1 (philip.eardley@bt.com)) X-BeenThere: re-ecn@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: re-inserted explicit congestion notification List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 17 Mar 2010 16:26:49 -0000 Ingemar, At 12:15 16/03/2010, Ingemar Johansson S wrote: >Hi > >A question from a non-MPLS geek. >What are the arguments against extending ConEx to MPLS?. >I guess one obvious answer is the limited 3-bit field but are there >more reasons against this?. I assume you mean making the outer MPLS shim expose *both* components of congestion (upstream and whole path) at every MPLS switch. If so, I would put 3 arguments against: 1) as you say, no more room in 3 bits (and probably not anywhere else) 2) MPLS encapsulation doesn't always copy the CoS* field to the new outer anyway, when using the pipe model [RFC2983] 3) No need. ConEx info is mostly intended for use at trust boundaries between meshed networks, where IP can usually be inspected... ...But if ConEx took off, and some future ConEx w-g wanted to standardise ConEx for MPLS interconnect, I'm sure it could be done. Note: Re-ECN (as an example of ConEx) does not require any changes to MPLS switch standards or IP router standards. If congested MPLS switches drop packets, re-ECN exposes this congestion - it just works. In addition, RFC5129 allows the 3-bit MPLS CoS* field to be used both for Diffserv codepoints and ECN marking. And it propagates ECN markings from MPLS up to IP on decapsulation. I know of at least two vendors that have implemented 5129 in MPLS hardware. * CoS = class of service, which was previously known as EXP (experimental) >My understanding is that the MPLS limitation is problematic only if >one wish to ConEx-police traffic that comes from another ISP and >that traffic is MPLS. Correct. >It is still possible to do ConEx policing at the label edge routers. >Of course the policing point will then not be at the border. Correct. Cheers Bob >Regards >Ingemar > > -----Original Message----- > > From: re-ecn-bounces@ietf.org > > [mailto:re-ecn-bounces@ietf.org] On Behalf Of re-ecn-request@ietf.org > > Sent: den 16 mars 2010 11:24 > > To: re-ecn@ietf.org > > Subject: re-ECN Digest, Vol 13, Issue 45 > > > > If you have received this digest without all the individual > > message attachments you will need to update your digest > > options in your list subscription. To do so, go to > > > > https://www.ietf.org/mailman/listinfo/re-ecn > > > > Click the 'Unsubscribe or edit options' button, log in, and > > set "Get MIME or Plain Text Digests?" to MIME. You can set > > this option globally for all the list digests you receive at > > this point. > > > > > > > > Send re-ECN mailing list submissions to > > re-ecn@ietf.org > > > > To subscribe or unsubscribe via the World Wide Web, visit > > https://www.ietf.org/mailman/listinfo/re-ecn > > or, via email, send a message with subject or body 'help' to > > re-ecn-request@ietf.org > > > > You can reach the person managing the list at > > re-ecn-owner@ietf.org > > > > When replying, please edit your Subject line so it is more > > specific than "Re: Contents of re-ECN digest..." > > > > > > Today's Topics: > > > > 1. Re: CONEX IESG comments #2 (philip.eardley@bt.com) > > > > > > ---------------------------------------------------------------------- > > > > Message: 1 > > Date: Tue, 16 Mar 2010 10:24:04 -0000 > > From: > > Subject: Re: [re-ECN] CONEX IESG comments #2 > > To: , > > Message-ID: > > > > <4A916DBC72536E419A0BD955EDECEDEC06363ED5@E03MVB1-UKBR.domain1 > > .systemhost.net> > > > > Content-Type: text/plain; charset="us-ascii" > > > > In-line > > Best wishes > > phil > > > > > -----Original Message----- > > > From: re-ecn-bounces@ietf.org > > > [mailto:re-ecn-bounces@ietf.org] On Behalf Of Lars Eggert > > > Sent: 01 March 2010 15:34 > > > To: re-ecn@ietf.org list > > > Cc: The IESG > > > Subject: [re-ECN] CONEX IESG comments #2 > > > > > > > > > Hi, CONEX group, > > > > > > I'm going to forward a few issues that were raised during the IESG > > > discussion of the charter to the list, and CC the IESG so that the > > > discussion can happen directly, without me being the > > bottleneck in the > > > middle. > > > > > > (I'd like to thank the ADs who wrote up their issues in this way - > > > this will make it much easier to progress the discussion!) > > > > > > Lars > > > > > > Begin forwarded message: > > > > The charter says: > > > > > > > > "With the output of CONEX, it will be possible to provide > > sufficient > > > > information in each IP datagram so that any node in the > > > network can see > > > > the expected rest-of-path congestion." > > > > > > > > With the scope that I heard on the call which was > > operation at the > > > > provider level, and the suggestion from Jari that this > > > might be applied > > > > to PWE3, the issue of how to make this work in MPLS has to > > > addressed. > > > > Indeed If the goal is operation at the SP level and PWE3, > > > failure to > > > > find an acceptable MPLS solution would be a showstopper. > > > > > > > > However if the goal is only to provide a solution that > > operates at > > > > parts of the network where the packet is visible as IP and this > > > is clearly > > > > stated in the requirements then the work has some merit as > > > an experiment. > > > > > > > > I agree with Adrian that this work looks experimental and > > > really ought > > > > to be an IRTF project, and only when it has been shown to > > > work correctly > > > > in an experimental environment should we do the heavy > > > weight engineering > > > > needed to make this a robust protocol suitable for > > > deployment in the > > > > operational Internet. > > > > Yes, the intention is for a solution that operates where the packet is > > visible as IP. More precisely, rest-of-path (& whole path) > > congestion is > > only visible where the packet is IP; congestion info can be set where > > the packet is MPLS using rfc5129. > > > > > > > > > > > > > > ------------------------------ > > > > _______________________________________________ > > re-ECN mailing list > > re-ECN@ietf.org > > https://www.ietf.org/mailman/listinfo/re-ecn > > > > > > End of re-ECN Digest, Vol 13, Issue 45 > > ************************************** > > >_______________________________________________ >re-ECN mailing list >re-ECN@ietf.org >https://www.ietf.org/mailman/listinfo/re-ecn ________________________________________________________________ Bob Briscoe, BT Innovate & Design From richard_woundy@cable.comcast.com Wed Mar 17 23:35:38 2010 Return-Path: X-Original-To: re-ecn@core3.amsl.com Delivered-To: re-ecn@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 8B68D3A683F for ; Wed, 17 Mar 2010 23:35:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.498 X-Spam-Level: X-Spam-Status: No, score=-5.498 tagged_above=-999 required=5 tests=[AWL=1.835, BAYES_00=-2.599, DNS_FROM_OPENWHOIS=1.13, HELO_EQ_MODEMCABLE=0.768, HOST_EQ_MODEMCABLE=1.368, RCVD_IN_DNSWL_HI=-8] 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 QLRnaquSRCSV for ; Wed, 17 Mar 2010 23:35:35 -0700 (PDT) Received: from pacdcimo01.cable.comcast.com (PacdcIMO01.cable.comcast.com [24.40.8.145]) by core3.amsl.com (Postfix) with ESMTP id 867CB3A6359 for ; Wed, 17 Mar 2010 23:35:35 -0700 (PDT) Received: from ([10.195.246.152]) by pacdcimo01.cable.comcast.com with ESMTP id 5503620.74606361; Thu, 18 Mar 2010 02:35:44 -0400 Received: from pacdcexcmb05.cable.comcast.com ([24.40.15.116]) by NJMDCEXCRLY01.cable.comcast.com with Microsoft SMTPSVC(6.0.3790.3959); Thu, 18 Mar 2010 02:35:45 -0400 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Thu, 18 Mar 2010 02:31:04 -0400 Message-ID: In-Reply-To: <3D3C75174CB95F42AD6BCC56E5555B450246E35A@FIESEXC015.nsn-intra.net> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [re-ECN] What Comcast's FairShare Solution does not provide... Thread-Index: Acq7g9bWAaZlOY4OSoeJd00SSOGFFgK3FCfA References: <3D3C75174CB95F42AD6BCC56E5555B450246E35A@FIESEXC015.nsn-intra.net> From: "Woundy, Richard" To: "Tschofenig, Hannes (NSN - FI/Espoo)" , X-OriginalArrivalTime: 18 Mar 2010 06:35:45.0093 (UTC) FILETIME=[3D00A750:01CAC665] Subject: Re: [re-ECN] What Comcast's FairShare Solution does not provide... X-BeenThere: re-ecn@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: re-inserted explicit congestion notification List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 18 Mar 2010 06:35:38 -0000 Hannes, I want to re-visit one point in this email. >* Comcast's FairShare approach is not an end-to-end solution >I would say: So what? As an argument for an ISP that has a problem to solve now that's probably not an interesting argument for further work. Fairshare focuses on the broadband access network, and it does a reasonable job at that. (It would be nice to incentivize LEDBAT of course, but that's another point.) While a lot of our internal focus has been on broadband access congestion, that's not the only congestion point that impacts our customers' experience. Another potential spot for congestion can be the interconnects between backbones. What makes interconnects unique is that they require coordination between two parties, whose business interests and priorities are not necessarily aligned. One party may be more concerned about congestion over a particular interconnect link that the other party, but both parties need to cooperate for any upgrade. In the year following our deployment of Fairshare, we were accused several times of blocking or throttling specific application traffic (I won't name them here). From what I understand, the root cause was traced to either interconnect congestion or overload conditions in application data centers. That's why end-to-end visibility of congestion would be quite useful to us. -- Rich -----Original Message----- From: re-ecn-bounces@ietf.org [mailto:re-ecn-bounces@ietf.org] On Behalf Of Tschofenig, Hannes (NSN - FI/Espoo) Sent: Thursday, March 04, 2010 5:17 AM To: re-ecn@ietf.org Subject: [re-ECN] What Comcast's FairShare Solution does not provide... Bob pointed to a slide set by Ric that talks about the Comcast congestion management solution. Here is the slide set:=20 http://giic.org/pdf/GIIC-CapShare-01-Woundy-Comcast.pdf I tried to re-word the arguments to avoid the solution specific touch.=20 Ric provided a few arguments what he believes is missing from their current solution that might require future work:=20 * Comcast's FairShare approach is not an end-to-end solution I would say: So what? As an argument for an ISP that has a problem to solve now that's probably not an interesting argument for further work.=20 * It does not signal congestion to user applications nor to devices along the path.=20 True.=20 Only devices within the Comcast network would see the DiffServ marking when the increased traffic leads to traffic marking (from PBE to BE).=20 * It does not enable application response.=20 I don't agree with that. Packet dropping will give applications an implicit indication.=20 * Re-ECN enables DDoS mitigation and other capabilities This is too unspecific to me to convince anyone.=20 Do we have a few more arguments?=20 Ciao Hannes _______________________________________________ re-ECN mailing list re-ECN@ietf.org https://www.ietf.org/mailman/listinfo/re-ecn From richard_woundy@cable.comcast.com Wed Mar 17 23:35:41 2010 Return-Path: X-Original-To: re-ecn@core3.amsl.com Delivered-To: re-ecn@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id A6F963A6894 for ; Wed, 17 Mar 2010 23:35:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.504 X-Spam-Level: X-Spam-Status: No, score=-4.504 tagged_above=-999 required=5 tests=[AWL=0.229, BAYES_50=0.001, DNS_FROM_OPENWHOIS=1.13, HELO_EQ_MODEMCABLE=0.768, HOST_EQ_MODEMCABLE=1.368, RCVD_IN_DNSWL_HI=-8] 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 ZqomSyGeiZ0p for ; Wed, 17 Mar 2010 23:35:38 -0700 (PDT) Received: from pacdcimo01.cable.comcast.com (PacdcIMO01.cable.comcast.com [24.40.8.145]) by core3.amsl.com (Postfix) with ESMTP id 532BA3A6806 for ; Wed, 17 Mar 2010 23:35:36 -0700 (PDT) Received: from ([10.195.246.152]) by pacdcimo01.cable.comcast.com with ESMTP id 5503620.74606364; Thu, 18 Mar 2010 02:35:44 -0400 Received: from pacdcexcmb05.cable.comcast.com ([24.40.15.116]) by NJMDCEXCRLY01.cable.comcast.com with Microsoft SMTPSVC(6.0.3790.3959); Thu, 18 Mar 2010 02:35:44 -0400 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Thu, 18 Mar 2010 02:31:03 -0400 Message-ID: In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [re-ECN] CONEX IESG comments #1 Thread-Index: Acq5VQ4+5WisaeBIQ1ajT/qOHrClAwCiUxEA References: <88061F01C2B84E8FB392C3CB0F0B96DA@your029b8cecfe> From: "Woundy, Richard" To: "Lars Eggert" , X-OriginalArrivalTime: 18 Mar 2010 06:35:44.0874 (UTC) FILETIME=[3CDF3CA0:01CAC665] Subject: Re: [re-ECN] CONEX IESG comments #1 X-BeenThere: re-ecn@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: re-inserted explicit congestion notification List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 18 Mar 2010 06:35:41 -0000 I definitely need to comment on "ISP support". Please note that I am expressing a personal opinion here, not any official Comcast position. > 4. ISP support > Somewhat tied to the previous point is the issue I cannot find=20 > supporters in the operational departments of ISPs. I have been trying, > because I feel it is important to understand their views. But the most > I can get back is "We will watch it in case it goes somewhere."=20 > Unfortunately, I also hear a lot of "Our company does not support this > work. We believe it will waste industry resources and cause confusion. > We do not understand how we could deploy it within our business model, and have no plans to deploy it." > - Where is the ISP support for this? In the IESG comments, I see three different topics intertwined: (1) how would an ISP leverage Conex, (2) when would an ISP roll out Conex technologies ("we will watch it in case it goes somewhere"), and (3) how would Conex fit within the current ISP business model or change it ("we do not understand how we could deploy it within our business model"). Let me start with 'how an ISP could leverage Conex'. I believe there are two potential use cases that could apply to our current network: using congestion volume instead of absolute volume as input to a congestion management system (aka FairShare), and discovering and diagnosing congestion issues outside of the broadband access network. In the first use case, the intent is to create an incentive for applications to use LEDBAT congestion control through the (future) behavior of congestion management. In the second use case, it would be helpful to capture information about congestion conditions that occur on our backbone (particularly our interconnects with other backbones), in other ISP networks (as they relate to our customers' traffic), and perhaps in remote data centers belonging to content and application providers. Note that it is tricky enough to diagnose application performance issues as they occur, and almost impossible to diagnose after the fact (particularly when it is off-network). There may be additional use cases like DDOS mitigation, which require further investigation. (Note that I did not mention 'congestion pricing' here on purpose -- see below.) Next let me tackle 'when would an ISP roll out Conex'. This is a difficult question to answer directly. Assuming that Conex becomes an IETF standards activity, there are two Conex ecosystems that need to be created: a software implementation ecosystem (operating systems, appliance firmware, network elements including routers and broadband access equipment, network management systems, etc), and a network deployment ecosystem (ISPs, application and content providers, consumer networks including home gateways perhaps, etc). If Conex relies on ECN (one of the current proposals), then the network deployment ecosystem needs to address ECN network deployment as well. Participants in both ecosystems will need their own business justifications about how they benefit from Conex implementation and deployment, of course, and there need to be prototypes, lab testing, and trial deployments before full Conex production. This could easily take 2-3 years. On a related note, I'm not sure that further academic research is going to speed up the timeline. Finally, let me tackle 'how Conex relates to the current ISP business model'. Note that my use cases above are strongly correlated to my employer's current business model. I also know that several folks have proposed using Conex for 'congestion pricing', and there are some solid technical and economic arguments for why the ISP business model should embrace congestion pricing, e.g. aligning 'cost' allocations to infrastructure capacity upgrades. But I still have a few reasons to hesitate before embracing this model (personally). While volume accounting is fairly straightforward as an engineer, many ISPs still find it difficult to communicate to customers how application usage translates to volume. (As an ironic example, I can explain how the Comcast Usage Meter works, but I have no idea why my own January household usage was three times higher than February's. Except I have teenage kids. :) I don't know how to start to communicate what congestion volume and pricing means to customers and their service. There are also potentially consumer policy and regulatory concerns. As an example, the typical peak usage time for broadband access providers also happens to be 'prime time' for TV viewing, so some might wonder what impact congestion pricing will have on Internet video distribution (even if that has nothing to do with the intent). I can discuss this during the Conex session next week. -- Rich -----Original Message----- From: re-ecn-bounces@ietf.org [mailto:re-ecn-bounces@ietf.org] On Behalf Of Lars Eggert Sent: Monday, March 01, 2010 10:33 AM To: re-ecn@ietf.org list Cc: The IESG Subject: [re-ECN] CONEX IESG comments #1 Hi, CONEX group, I'm going to forward a few issues that were raised during the IESG discussion of the charter to the list, and CC the IESG so that the discussion can happen directly, without me being the bottleneck in the middle. (I'd like to thank the ADs who wrote up their issues in this way - this will make it much easier to progress the discussion!) Lars Begin forwarded message: > In no particular order... >=20 > 1. This looks like really interesting research work with a potential=20 > outcome that could provide substantial benefit. But why is this not=20 > proposed as work in the IRTF? >=20 > 2. The charter seems to be trying to say that the work will be=20 > Experimental (which sounds like a grand goal), but fails dismally! I see... > The output of the CONEX WG are Informational and Experimental =20 > documents, apart from work item #2 which is tentatively slated for =20 > Standards Track. Depending on the bits that are proposed to be used =20 > in the IP header and their semantics (e.g., Bit 48 in IPv4, "ECN =20 > Nonce"), there may need to be further Standards Track or Informational > documents to reassign those bits from their current definitions =20 > (which would be subject to appropriate IESG and IETF review as =20 > necessary). > But #2 is... > Specification of IPv4 and IPv6 packet structures to carry CONEX =20 > information (header bits, interpretation) >=20 > And, in fact, no other documents listed would be appropriate as=20 > Experimental. > Why are the protocol specifications not also listed as Experimental?=20 > If (and this is clearly not known yet because the protocol specs have=20 > not been > written) it is necessary to use some bits, bytes, or codepoints that=20 > currently require standards action, then it would be appropriate to=20 > write a standards action document to reassign those fields as=20 > experimental. This document would be distinct from the protocol specification. >=20 > 3. Deployment and usage models > According to the charter, it appears that the deployment and usage=20 > work is intended to follow on from the protocol specification and=20 > BCPs. I feel that there is considerable lack of clarity about=20 > how/where the proposed mechanisms would be deployed. That is, it is=20 > unclear whether "...any node along the network path..." is meant to mean what it says. > - Why is the deployment model not part of the problem spec? > - Is there an assumption that there is IP forwarding at every hop? > - Is there an implication that MPLS extensions will also be developed? > - Can you show some deployment examples? >=20 > 4. ISP support > Somewhat tied to the previous point is the issue I cannot find=20 > supporters in the operational departments of ISPs. I have been trying, > because I feel it is important to understand their views. But the most > I can get back is "We will watch it in case it goes somewhere."=20 > Unfortunately, I also hear a lot of "Our company does not support this > work. We believe it will waste industry resources and cause confusion. > We do not understand how we could deploy it within our business model, and have no plans to deploy it." > - Where is the ISP support for this? >=20 > 5. Security > The charter does give a passing nod to the existence of security and=20 > trust issues. These need to be addressed up front. An architecture=20 > that relies on ISPs not gaming the system and not lying is critical in > this area. The security and veracity of the information shared will also be critical. > - Where is the security and trust model described? From richard_woundy@cable.comcast.com Wed Mar 17 23:35:54 2010 Return-Path: X-Original-To: re-ecn@core3.amsl.com Delivered-To: re-ecn@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 52A863A6892 for ; Wed, 17 Mar 2010 23:35:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.836 X-Spam-Level: X-Spam-Status: No, score=-1.836 tagged_above=-999 required=5 tests=[AWL=-2.503, BAYES_00=-2.599, DNS_FROM_OPENWHOIS=1.13, HELO_EQ_MODEMCABLE=0.768, HOST_EQ_MODEMCABLE=1.368] 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 flhlKGCWGSmR for ; Wed, 17 Mar 2010 23:35:51 -0700 (PDT) Received: from paoakoavas09.cable.comcast.com (paoakoavas09.cable.comcast.com [208.17.35.58]) by core3.amsl.com (Postfix) with ESMTP id A4E433A6822 for ; Wed, 17 Mar 2010 23:35:51 -0700 (PDT) Received: from ([10.52.116.30]) by paoakoavas09.cable.comcast.com with ESMTP id KP-NTF18.88554598; Thu, 18 Mar 2010 02:35:44 -0400 Received: from pacdcexcmb05.cable.comcast.com ([24.40.15.116]) by PAOAKEXCSMTP01.cable.comcast.com with Microsoft SMTPSVC(6.0.3790.3959); Thu, 18 Mar 2010 02:35:45 -0400 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Thu, 18 Mar 2010 02:31:04 -0400 Message-ID: In-Reply-To: <4B8F78A9.1050805@gmx.net> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [re-ECN] Capturing Current Deployments ... was Re: Call for Comments: draft-livingood-woundy-congestion-mgmt-03 Thread-Index: Acq7enBy+er894a0T6qWtgeIVVMA2AK5yPqQ References: <4B8F78A9.1050805@gmx.net> From: "Woundy, Richard" To: "Hannes Tschofenig" , "Livingood, Jason" X-OriginalArrivalTime: 18 Mar 2010 06:35:45.0030 (UTC) FILETIME=[3CF70A60:01CAC665] Cc: Matt Mathis , re-ecn@ietf.org Subject: Re: [re-ECN] Capturing Current Deployments ... was Re: Call for Comments: draft-livingood-woundy-congestion-mgmt-03 X-BeenThere: re-ecn@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: re-inserted explicit congestion notification List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 18 Mar 2010 06:35:54 -0000 > PS: Jason, if you indeed extend your solution to other access technologies then I am wondering whether this shouldn't be a work item in a future group working. I don't oppose having the IETF work on the Comcast solution. I do tend to think it is out of scope for Conex, though. As I just said in another email: "FairShare is a network policing mechanism. Conex is a network measurement and packet marking mechanism. They can place nicely together (I believe) but they are still independent mechanisms." -- Rich -----Original Message----- From: re-ecn-bounces@ietf.org [mailto:re-ecn-bounces@ietf.org] On Behalf Of Hannes Tschofenig Sent: Thursday, March 04, 2010 4:09 AM To: Livingood, Jason Cc: Matt Mathis; re-ecn@ietf.org Subject: [re-ECN] Capturing Current Deployments ... was Re: Call for Comments: draft-livingood-woundy-congestion-mgmt-03 I was a bit surprised to hear that the Comcast approach of dealing with=20 congestion is not known to all folks in this group (given that it is=20 highly relevant for the work in this group). This makes me wonder what is known about the currently deployed=20 solutions in general. Unfortunately, many of the solutions being deployed are not published in such as nice writeup as the Comcast solution is (if they are public at all). Maybe some operators with interest in this problem space are willing to=20 discuss their approach. Ciao Hannes PS: Jason, if you indeed extend your solution to other access=20 technologies then I am wondering whether this shouldn't be a work item=20 in a future group working. I believe that it has a lot of properties=20 that many operators would be interested to look at. Given the current=20 state of deployment in this area I believe that it could for many years=20 be probably the most useful output a future group. Jason Livingood wrote: > Thanks for your response Matt (and for reading the draft of course). Some > replies inline below. > > > On 3/1/10 3:01 PM, "Matt Mathis" wrote: > > =20 >> Interesting draft. What are your plans for it? >> =20 > > Heck if I know! ;-) Just kidding. We have the system in production for a > little over a year and a quarter now, so soliciting comments on the overall > design continues to be interesting to us and helps improve it. I'd also > like to see it become an informational RFC at some point. First off, that > provides a stable and easily consumable reference point for the document and > it can be a reference in related work at the IETF. > =20 > =20 >> What do you gain by monitoring the CMTS total load? >> =20 > > We actually monitor individual upstream and downstream ports on the CMTS > (I'll have to re-read the relevant sections to ensure I'm communicating that > the best I can). That enables us to detect when a particular segment of the > network is approaching a time of possible congestion. So we use it as an > early warning system of sorts, at which point we proactively mark some > traffic with a lower best effort QoS so that if congestion does actually > occur we are prepared in advance (as compared to doing such analysis & > action at that time precise of congestion, which is hard to get right). > > =20 >> If you are not >> near congestion I would not expect BE vs PBE marking to make any >> difference to the traffic. >> =20 > =20 > Correct. It is only at times of actual congestion that BE vs PBE has any > effect whatsoever. > =20 > =20 >> I did not notice anything in the draft, other than the terminology, >> that seemed to be DOCSIS or cable specific. The algorithm seems as >> though it is completely general, and could recast for any technology. >> Am I correct, or did I overlook something? >> =20 > > I think that is a fair conclusion to reach. We've gotten a few questions > from parties involved in operating or supplying operators of different > network types, and as we've explained the system it is apparent to us that > it is a generalized system (it was not really apparent at first, but we were > thinking only of how to solve our problem initially). In the next version > of the I-D I will probably add a section describing the applicability of the > system to other access network technologies and indeed to other network > segments other than just the last mile portion. > > =20 >> 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. >> >> >> >> On Fri, Feb 12, 2010 at 10:38 AM, Jason Livingood >> wrote: >> =20 >>> This is a call for comments on an individual draft regarding a >>> protocol-agnostic congestion management system, which is related to some of >>> the reason that Conex is starting up. I and my co-authors would like >>> feedback on the latest revision of this draft at >>> http://tools.ietf.org/html/draft-livingood-woundy-congestion-mgmt-03. >>> >>> If you have any comments, please send them to me privately for >>> consideration. >>> >>> Thank you, >>> Jason >>> =20 > > _______________________________________________ > re-ECN mailing list > re-ECN@ietf.org > https://www.ietf.org/mailman/listinfo/re-ecn > =20 _______________________________________________ re-ECN mailing list re-ECN@ietf.org https://www.ietf.org/mailman/listinfo/re-ecn From richard_woundy@cable.comcast.com Wed Mar 17 23:35:58 2010 Return-Path: X-Original-To: re-ecn@core3.amsl.com Delivered-To: re-ecn@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 962A13A683F for ; Wed, 17 Mar 2010 23:35:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.524 X-Spam-Level: X-Spam-Status: No, score=-1.524 tagged_above=-999 required=5 tests=[AWL=-2.191, BAYES_00=-2.599, DNS_FROM_OPENWHOIS=1.13, HELO_EQ_MODEMCABLE=0.768, HOST_EQ_MODEMCABLE=1.368] 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 qScEK29WtKEv for ; Wed, 17 Mar 2010 23:35:57 -0700 (PDT) Received: from paoakoavas10.cable.comcast.com (paoakoavas10.cable.comcast.com [208.17.35.59]) by core3.amsl.com (Postfix) with ESMTP id 2601B3A6983 for ; Wed, 17 Mar 2010 23:35:57 -0700 (PDT) Received: from ([10.52.116.30]) by paoakoavas10.cable.comcast.com with ESMTP id KP-TDCH7.78776271; Thu, 18 Mar 2010 02:35:44 -0400 Received: from pacdcexcmb05.cable.comcast.com ([24.40.15.116]) by PAOAKEXCSMTP01.cable.comcast.com with Microsoft SMTPSVC(6.0.3790.3959); Thu, 18 Mar 2010 02:35:44 -0400 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Thu, 18 Mar 2010 02:27:03 -0400 Message-ID: In-Reply-To: <548FC4B9D57A4043AAFFE888A39429031CEF85F7D4@ESESSCMS0356.eemea.ericsson.se> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [re-ECN] Call for Comments:draft-livingood-woundy-congestion-mgmt-03 Thread-Index: Acqr/UYLBg6/Vo3LSmSbUP2chJ/RdQEmXa8wBXLRP4A= References: <548FC4B9D57A4043AAFFE888A39429031CEF85F7D4@ESESSCMS0356.eemea.ericsson.se> From: "Woundy, Richard" To: "Ingemar Johansson S" , X-OriginalArrivalTime: 18 Mar 2010 06:35:44.0593 (UTC) FILETIME=[3CB45C10:01CAC665] Subject: Re: [re-ECN] Call for Comments:draft-livingood-woundy-congestion-mgmt-03 X-BeenThere: re-ecn@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: re-inserted explicit congestion notification List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 18 Mar 2010 06:35:58 -0000 Ingemar, A belated thanks for the feedback. :) Let me see if I can re-state your points below. First, the per-device wireless capacity may vary dynamically based on signal quality (with impacts due to distance, interference), so it may be difficult to assess how a single subscriber contributes to congestion for a single access node or base station. Second, with wireless handoffs for mobility, it may be the case that a subscriber contributes to congestion on one node/station but not the subsequent one. Is that correct? Are wireless ISPs selling different bandwidth tiers? Other than distinguishing 2.5G vs 3G vs 4G service? -- Rich -----Original Message----- From: re-ecn-bounces@ietf.org [mailto:re-ecn-bounces@ietf.org] On Behalf Of Ingemar Johansson S Sent: Thursday, February 18, 2010 7:55 AM To: re-ecn@ietf.org Subject: Re: [re-ECN] Call for Comments:draft-livingood-woundy-congestion-mgmt-03 Hi Thanks for the report.=20 I read through it but did perhaps not get all the details.=20 As far as I understand it the concept builds upon the fact that users have a provisioned bandwith, say 10Mbps in e.g the downlink. Once congetsion sets in the network the congestion manager will enforce some special treatment on flows that consumes data with a bitrate that is larger than e.g 80% of their provisioned bandwidth over a given amount of time.=20 The problem I see is that, when I try to transform this concept to wirless access, is that it is in general difficult to talk about a provisioned bandwidth for best effort traffic esp. over a multiuser wireless network with mobility support. The 10Mbs, 1.4Mbs or whatever figures written in boldface on the boxes are in reality limited by the laws of physics. In addition, whatever provisioned bandwidth that one may possibly come up with is likely to change over time due to changed radio conditions or handover between different access types. The thing I find attractive with ConEx is that it has potential to work in these scenarios, the question is of course if the problem needs a solution like ConEx... It is possible that I miss some details here, please enlighten me. Regards Ingeamr > ---------------------------------------------------------------------- >=20 > Message: 1 > Date: Fri, 12 Feb 2010 10:38:49 -0500 > From: Jason Livingood > Subject: [re-ECN] Call for Comments: > draft-livingood-woundy-congestion-mgmt-03 > To: > Message-ID: > Content-Type: text/plain; charset=3D"us-ascii" >=20 > This is a call for comments on an individual draft regarding=20 > a protocol-agnostic congestion management system, which is=20 > related to some of the reason that Conex is starting up. I=20 > and my co-authors would like feedback on the latest revision=20 > of this draft at=20 > http://tools.ietf.org/html/draft-livingood-woundy-congestion-mgmt-03. >=20 > If you have any comments, please send them to me privately=20 > for consideration. >=20 > Thank you, > Jason >=20 > -------------- next part -------------- > An HTML attachment was scrubbed... > URL:=20 > 212/99c6f607/attachment.htm> >=20 > ------------------------------ >=20 > _______________________________________________ > re-ECN mailing list > re-ECN@ietf.org > https://www.ietf.org/mailman/listinfo/re-ecn >=20 >=20 > End of re-ECN Digest, Vol 12, Issue 24 > ************************************** >=20 _______________________________________________ re-ECN mailing list re-ECN@ietf.org https://www.ietf.org/mailman/listinfo/re-ecn From richard_woundy@cable.comcast.com Wed Mar 17 23:50:38 2010 Return-Path: X-Original-To: re-ecn@core3.amsl.com Delivered-To: re-ecn@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id A08F53A6765 for ; Wed, 17 Mar 2010 23:50:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.965 X-Spam-Level: X-Spam-Status: No, score=-4.965 tagged_above=-999 required=5 tests=[AWL=2.368, BAYES_00=-2.599, DNS_FROM_OPENWHOIS=1.13, HELO_EQ_MODEMCABLE=0.768, HOST_EQ_MODEMCABLE=1.368, RCVD_IN_DNSWL_HI=-8] 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 YabzM0FFNr93 for ; Wed, 17 Mar 2010 23:50:37 -0700 (PDT) Received: from pacdcimo01.cable.comcast.com (PacdcIMO01.cable.comcast.com [24.40.8.145]) by core3.amsl.com (Postfix) with ESMTP id F295C3A6359 for ; Wed, 17 Mar 2010 23:50:36 -0700 (PDT) Received: from ([10.52.116.30]) by pacdcimo01.cable.comcast.com with ESMTP id 5503620.74606360; Thu, 18 Mar 2010 02:35:44 -0400 Received: from pacdcexcmb05.cable.comcast.com ([24.40.15.116]) by PAOAKEXCSMTP01.cable.comcast.com with Microsoft SMTPSVC(6.0.3790.3959); Thu, 18 Mar 2010 02:35:44 -0400 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Thu, 18 Mar 2010 02:31:04 -0400 Message-ID: In-Reply-To: <4B9CDC0F.9000102@isoc.org> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [re-ECN] draft-tschofenig-conex-ps and our recommendation for the group Thread-Index: AcrDdUQyaQO0GH8BTMOro80Kb0TIGwC6VlPg References: <4B9CDC0F.9000102@isoc.org> From: "Woundy, Richard" To: "Matthew Ford" , X-OriginalArrivalTime: 18 Mar 2010 06:35:44.0811 (UTC) FILETIME=[3CD59FB0:01CAC665] Subject: Re: [re-ECN] draft-tschofenig-conex-ps and our recommendation for the group X-BeenThere: re-ecn@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: re-inserted explicit congestion notification List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 18 Mar 2010 06:50:38 -0000 I think FairShare could be adapted to leverage congestion volume instead of (and/or in addition to) total volume. But I think we still need Conex to make this work. FairShare is a network policing mechanism. Conex is a network measurement and packet marking mechanism. They can place nicely together (I believe) but they are still independent mechanisms. -- Rich -----Original Message----- From: re-ecn-bounces@ietf.org [mailto:re-ecn-bounces@ietf.org] On Behalf Of Matthew Ford Sent: Sunday, March 14, 2010 8:53 AM To: re-ecn@ietf.org Subject: Re: [re-ECN] draft-tschofenig-conex-ps and our recommendation for the group Hi Jason, one comment, inline. - Mat On 12/03/2010 19:20, Jason Livingood wrote: > On 3/10/10 10:19 AM, "Bob Briscoe" wrote: > >> If one transport (e.g. LEDBAT) can contribute a lot less to >> congestion than another, while sending more volume during high >> utilisation,... then FairShare is using a proxy for a congestion >> metric that is not sufficient. Don't get me wrong, I think FairShare >> is a great step forward. But we all agree FairShare doesn't create >> the incentives to use LEDBAT-like transports, which proves >> volume-during-high-utilisation is not an ideal proxy for a congestion metric. > > I don't think we've fully considered all of the interactions between our two > FairShare traffic classes (Priority Best Effort, PBE, and Best Effort, BE) > and LEDBAT use. One alternative may be to always classify LEDBAT traffic as How do you identify it? _______________________________________________ re-ECN mailing list re-ECN@ietf.org https://www.ietf.org/mailman/listinfo/re-ecn From ingemar.s.johansson@ericsson.com Thu Mar 18 03:02:23 2010 Return-Path: X-Original-To: re-ecn@core3.amsl.com Delivered-To: re-ecn@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 1B3DD3A6B53 for ; Thu, 18 Mar 2010 03:02:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.347 X-Spam-Level: X-Spam-Status: No, score=-2.347 tagged_above=-999 required=5 tests=[AWL=-0.878, BAYES_00=-2.599, DNS_FROM_OPENWHOIS=1.13] 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 ELvOVRQSUjhW for ; Thu, 18 Mar 2010 03:02:21 -0700 (PDT) Received: from mailgw9.se.ericsson.net (mailgw9.se.ericsson.net [193.180.251.57]) by core3.amsl.com (Postfix) with ESMTP id 1F0D93A68EA for ; Thu, 18 Mar 2010 03:02:20 -0700 (PDT) X-AuditID: c1b4fb39-b7b85ae000005cbc-79-4ba1fa37600b Received: from esessmw0247.eemea.ericsson.se (Unknown_Domain [153.88.253.125]) by mailgw9.se.ericsson.net (Symantec Brightmail Gateway) with SMTP id 56.41.23740.73AF1AB4; Thu, 18 Mar 2010 11:02:31 +0100 (CET) Received: from ESESSCMS0356.eemea.ericsson.se ([169.254.2.100]) by esessmw0247.eemea.ericsson.se ([10.2.3.116]) with mapi; Thu, 18 Mar 2010 11:02:29 +0100 From: Ingemar Johansson S To: "Woundy, Richard" , "re-ecn@ietf.org" Date: Thu, 18 Mar 2010 11:02:27 +0100 Thread-Topic: [re-ECN] Call for Comments:draft-livingood-woundy-congestion-mgmt-03 Thread-Index: Acqr/UYLBg6/Vo3LSmSbUP2chJ/RdQEmXa8wBXLRP4AABnj5sA== Message-ID: <548FC4B9D57A4043AAFFE888A39429031D01F3ED65@ESESSCMS0356.eemea.ericsson.se> References: <548FC4B9D57A4043AAFFE888A39429031CEF85F7D4@ESESSCMS0356.eemea.ericsson.se> In-Reply-To: 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 Subject: Re: [re-ECN] Call for Comments:draft-livingood-woundy-congestion-mgmt-03 X-BeenThere: re-ecn@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: re-inserted explicit congestion notification List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 18 Mar 2010 10:02:23 -0000 Hi I don't believe wireless ISP's sell different bandwidths at least when it c= omes to shared access like HSPA or LTE. This depends a little if we are tal= king GBR* or non-GBR bearers.=20 I would belive that we in this group talk mainly about non-GBR bearers whic= h in IETF language translates to Best Effort or DF. As the non-GBR QCIs** h= ave the lowest prio they will yield to GBR traffic, it comes quite natural = then that the per-device bandwidth for best effort traffic will then vary d= ependent on factors such as deployment, coverage, amount of higher priority= traffic and number of concurrent users.=20 *GBR =3D Guaranteed Bit Rate, IMS VoIP will typically use a GBR bearer whic= h will strive as mcuh as possible to guarantee a given bitrate, regardless = of the conditions, see link below for a more nuanced definition. **QCI =3D QoS Class Indentifier 3GPP TS 23.203 table 6.1.7 http://www.3gpp.= org/ftp/Specs/archive/23_series/23.203/23203-930.zip PS.. It is not to me totally clear that ConEx is needed with the above arra= ngement as the scheduling will likely ensure that devices will share the li= mited bandwidth pool in a fair way. What ConEx may be helpful with is to ma= ke the device aware on the congestion it causes and also to distribute its = limited share of bandwidth between flows in the smartest way. We also have = the potential issue with DoS (or DDoS) attacks but I am not clear here how = ConEx is helpful here. Regards Ingemar > -----Original Message----- > From: Woundy, Richard [mailto:Richard_Woundy@cable.comcast.com]=20 > Sent: den 18 mars 2010 07:27 > To: Ingemar Johansson S; re-ecn@ietf.org > Subject: RE: [re-ECN] Call for=20 > Comments:draft-livingood-woundy-congestion-mgmt-03 >=20 > Ingemar, >=20 > A belated thanks for the feedback. :) >=20 > Let me see if I can re-state your points below. First, the=20 > per-device wireless capacity may vary dynamically based on=20 > signal quality (with impacts due to distance, interference),=20 > so it may be difficult to assess how a single subscriber=20 > contributes to congestion for a single access node or base=20 > station. Second, with wireless handoffs for mobility, it may=20 > be the case that a subscriber contributes to congestion on=20 > one node/station but not the subsequent one. Is that correct? >=20 > Are wireless ISPs selling different bandwidth tiers? Other=20 > than distinguishing 2.5G vs 3G vs 4G service? >=20 > -- Rich >=20 > -----Original Message----- > From: re-ecn-bounces@ietf.org=20 > [mailto:re-ecn-bounces@ietf.org] On Behalf Of Ingemar Johansson S > Sent: Thursday, February 18, 2010 7:55 AM > To: re-ecn@ietf.org > Subject: Re: [re-ECN] Call for > Comments:draft-livingood-woundy-congestion-mgmt-03 >=20 > Hi >=20 > Thanks for the report.=20 > I read through it but did perhaps not get all the details.=20 > As far as I understand it the concept builds upon the fact=20 > that users have a provisioned bandwith, say 10Mbps in e.g the=20 > downlink. Once congetsion sets in the network the congestion=20 > manager will enforce some special treatment on flows that=20 > consumes data with a bitrate that is larger than e.g 80% of=20 > their provisioned bandwidth over a given amount of time.=20 >=20 > The problem I see is that, when I try to transform this=20 > concept to wirless access, is that it is in general difficult=20 > to talk about a provisioned bandwidth for best effort traffic=20 > esp. over a multiuser wireless network with mobility support.=20 > The 10Mbs, 1.4Mbs or whatever figures written in boldface on=20 > the boxes are in reality limited by the laws of physics. > In addition, whatever provisioned bandwidth that one may=20 > possibly come up with is likely to change over time due to=20 > changed radio conditions or handover between different access=20 > types. The thing I find attractive with ConEx is that it has=20 > potential to work in these scenarios, the question is of=20 > course if the problem needs a solution like ConEx... >=20 > It is possible that I miss some details here, please enlighten me. >=20 > Regards > Ingeamr >=20 > >=20 > ---------------------------------------------------------------------- > >=20 > > Message: 1 > > Date: Fri, 12 Feb 2010 10:38:49 -0500 > > From: Jason Livingood > > Subject: [re-ECN] Call for Comments: > > draft-livingood-woundy-congestion-mgmt-03 > > To: > > Message-ID: > > Content-Type: text/plain; charset=3D"us-ascii" > >=20 > > This is a call for comments on an individual draft regarding a=20 > > protocol-agnostic congestion management system, which is related to=20 > > some of the reason that Conex is starting up. I and my co-authors=20 > > would like feedback on the latest revision of this draft at=20 > >=20 > http://tools.ietf.org/html/draft-livingood-woundy-congestion-mgmt-03. > >=20 > > If you have any comments, please send them to me privately for=20 > > consideration. > >=20 > > Thank you, > > Jason > >=20 > > -------------- next part -------------- An HTML attachment was=20 > > scrubbed... > > URL:=20 > > > 212/99c6f607/attachment.htm> > >=20 > > ------------------------------ > >=20 > > _______________________________________________ > > re-ECN mailing list > > re-ECN@ietf.org > > https://www.ietf.org/mailman/listinfo/re-ecn > >=20 > >=20 > > End of re-ECN Digest, Vol 12, Issue 24 > > ************************************** > >=20 > _______________________________________________ > re-ECN mailing list > re-ECN@ietf.org > https://www.ietf.org/mailman/listinfo/re-ecn > = From leslie@thinkingcat.com Thu Mar 18 15:33:07 2010 Return-Path: X-Original-To: re-ecn@core3.amsl.com Delivered-To: re-ecn@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 074E13A6452 for ; Thu, 18 Mar 2010 15:33:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.427 X-Spam-Level: X-Spam-Status: No, score=-0.427 tagged_above=-999 required=5 tests=[AWL=-1.372, BAYES_40=-0.185, DNS_FROM_OPENWHOIS=1.13] 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 Zgg6UYKjiCRj for ; Thu, 18 Mar 2010 15:33:06 -0700 (PDT) Received: from zeke.ecotroph.net (zeke.ecotroph.net [70.164.19.155]) by core3.amsl.com (Postfix) with ESMTP id B806E3A67D7 for ; Thu, 18 Mar 2010 15:33:02 -0700 (PDT) Received: from beethoven.local ([::ffff:173.71.206.39]) (AUTH: PLAIN leslie, SSL: TLSv1/SSLv3,256bits,AES256-SHA) by zeke.ecotroph.net with esmtp; Thu, 18 Mar 2010 18:33:12 -0400 id 015B009A.4BA2AA28.00005B81 Message-ID: <4BA2AA20.4060601@thinkingcat.com> Date: Thu, 18 Mar 2010 18:33:04 -0400 From: Leslie Daigle User-Agent: Thunderbird 2.0.0.23 (Macintosh/20090812) MIME-Version: 1.0 To: "re-ecn@ietf.org" , Philip Eardley Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: [re-ECN] Volunteer minutes-takers? X-BeenThere: re-ecn@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: re-inserted explicit congestion notification List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 18 Mar 2010 22:33:07 -0000 Hi, It seems not too soon to ask if there are any volunteer note-takers for next week's CONEX BoF meetings? Thanks, Leslie. -- ------------------------------------------------------------------- "Reality: Yours to discover." -- ThinkingCat Leslie Daigle leslie@thinkingcat.com ------------------------------------------------------------------- From rbriscoe@jungle.bt.co.uk Sun Mar 21 06:33:41 2010 Return-Path: X-Original-To: re-ecn@core3.amsl.com Delivered-To: re-ecn@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id D07A93A6910 for ; Sun, 21 Mar 2010 06:33:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.081 X-Spam-Level: X-Spam-Status: No, score=0.081 tagged_above=-999 required=5 tests=[AWL=-1.532, BAYES_50=0.001, DNS_FROM_OPENWHOIS=1.13, 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 qpMfT9LVUHvI for ; Sun, 21 Mar 2010 06:33:35 -0700 (PDT) Received: from smtp1.smtp.bt.com (smtp1.smtp.bt.com [217.32.164.137]) by core3.amsl.com (Postfix) with ESMTP id 4CF293A6906 for ; Sun, 21 Mar 2010 06:33:32 -0700 (PDT) Received: from i2kc06-ukbr.domain1.systemhost.net ([193.113.197.70]) by smtp1.smtp.bt.com with Microsoft SMTPSVC(6.0.3790.3959); Sun, 21 Mar 2010 13:33:48 +0000 Received: from cbibipnt05.iuser.iroot.adidom.com ([147.149.196.177]) by i2kc06-ukbr.domain1.systemhost.net with Microsoft SMTPSVC(6.0.3790.3959); Sun, 21 Mar 2010 13:33:47 +0000 Received: From bagheera.jungle.bt.co.uk ([132.146.168.158]) by cbibipnt05.iuser.iroot.adidom.com (WebShield SMTP v4.5 MR1a P0803.399); id 1269178427187; Sun, 21 Mar 2010 13:33:47 +0000 Received: from MUT.jungle.bt.co.uk ([10.73.128.74]) by bagheera.jungle.bt.co.uk (8.13.5/8.12.8) with ESMTP id o2LDXfU7006975; Sun, 21 Mar 2010 13:33:42 GMT Message-Id: <201003211333.o2LDXfU7006975@bagheera.jungle.bt.co.uk> X-Mailer: QUALCOMM Windows Eudora Version 7.1.0.9 Date: Sun, 21 Mar 2010 13:33:40 +0000 To: Jason Livingood , "Woundy, Richard" From: Bob Briscoe Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-Scanned-By: MIMEDefang 2.56 on 132.146.168.158 X-OriginalArrivalTime: 21 Mar 2010 13:33:47.0951 (UTC) FILETIME=[22CA4BF0:01CAC8FB] Cc: ConEx IETF list Subject: Re: [re-ECN] Call for Comments: draft-livingood-woundy-congestion-mgmt-03 X-BeenThere: re-ecn@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: re-inserted explicit congestion notification List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 21 Mar 2010 13:33:41 -0000 Jason, Rich, Following Rich's useful email on this list about how Comcast used congestion for traffic management within its existing business model... It would be useful to have a section of your draft-livingood-woundy-congestion-mgmt detailing any changes to Comcast's customer contract as a result of deploying FairShare. Even if the title says "Contractual Changes" and the text says "None". However, I suspect there will be more to say there. You had the FCC looking over you, so I guess you wanted to publicly commit to being protocol agnostic - now that you had the technical means. I'd also be interested if there was any change to your Fair Use Policy, or your Acceptable Use Policy. PS. What are you planning to do with the doc, and with the comments people have been sending - like the nine I sent (see below) and those Matt sent? My take would be to freeze it fairly soon, as a record of what you did. Rather than widen it further (which ought to go in a second doc). Cheers Bob >Date: Thu, 04 Mar 2010 23:52:00 +0000 >To: Jason Livingood >From: Bob Briscoe >Subject: Re: [re-ECN] Call for Comments: >draft-livingood-woundy-congestion-mgmt-03 >Cc: Matt Mathis , re-ecn@ietf.org > >Jason, > >I had read the draft before, and it will be a useful ref. I would >advise that you publish soon before things move on, rather than >trying to add stuff on applicability to non-cable networks (even tho >that would be interesting - perhaps best as a separate short draft). > >I have some hopefully constructive comments below from my reading of >the latest -03 rev. > > >1/ [snip] ________________________________________________________________ Bob Briscoe, BT Innovate & Design From rbriscoe@jungle.bt.co.uk Sun Mar 21 11:50:56 2010 Return-Path: X-Original-To: re-ecn@core3.amsl.com Delivered-To: re-ecn@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id C27BE3A68E0 for ; Sun, 21 Mar 2010 11:50:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.285 X-Spam-Level: X-Spam-Status: No, score=0.285 tagged_above=-999 required=5 tests=[AWL=-1.328, BAYES_50=0.001, DNS_FROM_OPENWHOIS=1.13, 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 9Nsb5BmcTUHv for ; Sun, 21 Mar 2010 11:50:50 -0700 (PDT) Received: from smtp1.smtp.bt.com (smtp1.smtp.bt.com [217.32.164.137]) by core3.amsl.com (Postfix) with ESMTP id 17AD63A68DC for ; Sun, 21 Mar 2010 11:50:48 -0700 (PDT) Received: from i2kc08-ukbr.domain1.systemhost.net ([193.113.197.71]) by smtp1.smtp.bt.com with Microsoft SMTPSVC(6.0.3790.3959); Sun, 21 Mar 2010 18:51:04 +0000 Received: from cbibipnt08.iuser.iroot.adidom.com ([147.149.100.81]) by i2kc08-ukbr.domain1.systemhost.net with Microsoft SMTPSVC(6.0.3790.3959); Sun, 21 Mar 2010 18:51:04 +0000 Received: From bagheera.jungle.bt.co.uk ([132.146.168.158]) by cbibipnt08.iuser.iroot.adidom.com (WebShield SMTP v4.5 MR1a P0803.399); id 1269197463506; Sun, 21 Mar 2010 18:51:03 +0000 Received: from MUT.jungle.bt.co.uk ([10.73.128.74]) by bagheera.jungle.bt.co.uk (8.13.5/8.12.8) with ESMTP id o2LIp0r4013358 for ; Sun, 21 Mar 2010 18:51:01 GMT Message-Id: <201003211851.o2LIp0r4013358@bagheera.jungle.bt.co.uk> X-Mailer: QUALCOMM Windows Eudora Version 7.1.0.9 Date: Sun, 21 Mar 2010 18:50:57 +0000 To: ConEx IETF list From: Bob Briscoe Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-Scanned-By: MIMEDefang 2.56 on 132.146.168.158 X-OriginalArrivalTime: 21 Mar 2010 18:51:04.0514 (UTC) FILETIME=[75774A20:01CAC927] Subject: [re-ECN] Support requested: Start of WGLC for Tunnelling of ECN (draft-ietf-tsvwg-ecn-tunnel) X-BeenThere: re-ecn@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: re-inserted explicit congestion notification List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 21 Mar 2010 18:50:56 -0000 ConEx folks, Note the ecn-tunnel draft is now in w-g last call. Having a single consistent treatment of the ECN field through tunnels will be important for ConEx. The TSVWG Chairs are looking for messages of support (or not) on the tsvwg@ietf.org list. Tunnel behaviour has diverged in its treatment of the ECN field. At ingress, IPsec tunnels copy it, but some non-IPsec tunnels do a partial copy. This draft proposes to harmonise all tunnelling so the ECN field is copied, as IPsec does. Preferably post your messages to tsvwg before Monday's TSVWG session, altho you have until 12 Apr. See below, which includes a link to the draft for the whole story. Cheers Bob >Date: Fri, 12 Mar 2010 15:03:45 +0000 >From: Gorry Fairhurst >Reply-To: gorry@erg.abdn.ac.uk >Organization: The University of Aberdeen is a charity registered in Scotland, > No SC013683. >To: tsvwg WG >CC: Bob Briscoe , > tsvwg chair >Subject: Start of WGLC for Tunnelling of ECN (draft-ietf-tsvwg-ecn-tunnel) > > >This email announces the beginning of a working group last call for >draft-ietf-tsvwg-ecn-tunnel-08, "Tunnelling of Explicit Congestion >Notification". This document is now thought by the authors to be >ready to proceed to be published as a Proposed Standard. Please send >any comments to the TSVWG list. > >The draft is available at: >https://datatracker.ietf.org/doc/draft-ietf-tsvwg-ecn-tunnel/ > >The document will be forwarded in parallel to the Security Directorate >for a Security Review. > >The last call will run for FOUR weeks, ending Monday, 12th April >2010 (since it will cover an IETF meeting period). Emails saying "I >support" or "I don't support" are also most helpful in judging the consensus. > >James and Gorry >(TSVWG Chairs) > > >P.S. A copy of this mail will be sent also to the PCN WG for info. ________________________________________________________________ Bob Briscoe, BT Innovate & Design From jason_livingood@cable.comcast.com Sun Mar 21 18:50:05 2010 Return-Path: X-Original-To: re-ecn@core3.amsl.com Delivered-To: re-ecn@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 6DD963A68E6 for ; Sun, 21 Mar 2010 18:50:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.666 X-Spam-Level: X-Spam-Status: No, score=-2.666 tagged_above=-999 required=5 tests=[BAYES_50=0.001, DNS_FROM_OPENWHOIS=1.13, HELO_EQ_MODEMCABLE=0.768, HOST_EQ_MODEMCABLE=1.368, RCVD_IN_DNSWL_HI=-8, RCVD_NUMERIC_HELO=2.067] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id k7zaRi0Nj71V for ; Sun, 21 Mar 2010 18:50:04 -0700 (PDT) Received: from pacdcimo01.cable.comcast.com (PacdcIMO01.cable.comcast.com [24.40.8.145]) by core3.amsl.com (Postfix) with ESMTP id CECB13A63EC for ; Sun, 21 Mar 2010 18:50:00 -0700 (PDT) Received: from ([24.40.15.92]) by pacdcimo01.cable.comcast.com with ESMTP id 5503620.74855452; Sun, 21 Mar 2010 21:50:15 -0400 Received: from PACDCEXCMB04.cable.comcast.com ([24.40.15.86]) by PACDCEXCSMTP03.cable.comcast.com with Microsoft SMTPSVC(6.0.3790.3959); Sun, 21 Mar 2010 21:50:14 -0400 Received: from 75.242.58.174 ([75.242.58.174]) by PACDCEXCMB04.cable.comcast.com ([24.40.15.86]) via Exchange Front-End Server webmail.comcast.com ([24.40.8.154]) with Microsoft Exchange Server HTTP-DAV ; Mon, 22 Mar 2010 01:50:14 +0000 User-Agent: Microsoft-Entourage/12.24.0.100205 Date: Sun, 21 Mar 2010 18:54:37 -0400 From: Jason Livingood To: Bob Briscoe , Rich Woundy Message-ID: Thread-Topic: [re-ECN] Call for Comments: draft-livingood-woundy-congestion-mgmt-03 Thread-Index: AcrJSXsv+LGCF/VFvUazYdb3ZMG7pg== In-Reply-To: <201003211333.o2LDXfU7006975@bagheera.jungle.bt.co.uk> Mime-version: 1.0 Content-type: text/plain; charset="US-ASCII" Content-transfer-encoding: 7bit X-OriginalArrivalTime: 22 Mar 2010 01:50:14.0451 (UTC) FILETIME=[03FF2030:01CAC962] Cc: ConEx IETF list Subject: Re: [re-ECN] Call for Comments: draft-livingood-woundy-congestion-mgmt-03 X-BeenThere: re-ecn@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: re-inserted explicit congestion notification List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 22 Mar 2010 01:50:05 -0000 Good suggestion to add some new content, Bob. As to what we plan to do, your comments and others are in my I-D work queue to be evaluated for addition into the next rev. I might even have time to do some of that this week, but I usually underestimate my work load during IETF meetings. ;-) After that is done, I agree strongly with you that it's time to freeze it and I hope to do so prior to IETF 78. If in CONEX we want to take some of the concepts and content into a new doc, that's cool but I think it's also helpful to have an informational snapshot of the system as a stable reference point. Jason On 3/21/10 9:33 AM, "Bob Briscoe" wrote: > Jason, Rich, > > Following Rich's useful email on this list about how Comcast used > congestion for traffic management within its existing business model... > > It would be useful to have a section of your > draft-livingood-woundy-congestion-mgmt detailing any changes to > Comcast's customer contract as a result of deploying FairShare. > > Even if the title says "Contractual Changes" and the text says "None". > > However, I suspect there will be more to say there. You had the FCC > looking over you, so I guess you wanted to publicly commit to being > protocol agnostic - now that you had the technical means. I'd also be > interested if there was any change to your Fair Use Policy, or your > Acceptable Use Policy. > > PS. What are you planning to do with the doc, and with the comments > people have been sending - like the nine I sent (see below) and those > Matt sent? My take would be to freeze it fairly soon, as a record of > what you did. Rather than widen it further (which ought to go in a second > doc). > > Cheers > > > > Bob > > > >> Date: Thu, 04 Mar 2010 23:52:00 +0000 >> To: Jason Livingood >> From: Bob Briscoe >> Subject: Re: [re-ECN] Call for Comments: >> draft-livingood-woundy-congestion-mgmt-03 >> Cc: Matt Mathis , re-ecn@ietf.org >> >> Jason, >> >> I had read the draft before, and it will be a useful ref. I would >> advise that you publish soon before things move on, rather than >> trying to add stuff on applicability to non-cable networks (even tho >> that would be interesting - perhaps best as a separate short draft). >> >> I have some hopefully constructive comments below from my reading of >> the latest -03 rev. >> >> >> 1/ > > [snip] > > > ________________________________________________________________ > Bob Briscoe, BT Innovate & Design > From jason_livingood@cable.comcast.com Sun Mar 21 18:50:06 2010 Return-Path: X-Original-To: re-ecn@core3.amsl.com Delivered-To: re-ecn@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 1AD4B3A63EC for ; Sun, 21 Mar 2010 18:50:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.966 X-Spam-Level: X-Spam-Status: No, score=-3.966 tagged_above=-999 required=5 tests=[AWL=1.300, BAYES_00=-2.599, DNS_FROM_OPENWHOIS=1.13, HELO_EQ_MODEMCABLE=0.768, HOST_EQ_MODEMCABLE=1.368, RCVD_IN_DNSWL_HI=-8, RCVD_NUMERIC_HELO=2.067] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id rADIEDflE3dB for ; Sun, 21 Mar 2010 18:50:05 -0700 (PDT) Received: from pacdcimo01.cable.comcast.com (PacdcIMO01.cable.comcast.com [24.40.8.145]) by core3.amsl.com (Postfix) with ESMTP id D0B7E3A68B0 for ; Sun, 21 Mar 2010 18:50:00 -0700 (PDT) Received: from ([24.40.15.118]) by pacdcimo01.cable.comcast.com with ESMTP id 5503620.74855451; Sun, 21 Mar 2010 21:50:14 -0400 Received: from PACDCEXCMB04.cable.comcast.com ([24.40.15.86]) by PACDCEXCSMTP04.cable.comcast.com with Microsoft SMTPSVC(6.0.3790.3959); Sun, 21 Mar 2010 21:50:12 -0400 Received: from 75.242.58.174 ([75.242.58.174]) by PACDCEXCMB04.cable.comcast.com ([24.40.15.86]) via Exchange Front-End Server webmail.comcast.com ([24.40.8.154]) with Microsoft Exchange Server HTTP-DAV ; Mon, 22 Mar 2010 01:50:13 +0000 User-Agent: Microsoft-Entourage/12.24.0.100205 Date: Sun, 21 Mar 2010 18:50:04 -0400 From: Jason Livingood To: Matthew Ford , Message-ID: Thread-Topic: [re-ECN] draft-tschofenig-conex-ps and our recommendation for the group Thread-Index: AcrJSNh3Gw6C7YDc4UeSOa+0Xxx7EQ== In-Reply-To: <4B9CDC0F.9000102@isoc.org> Mime-version: 1.0 Content-type: text/plain; charset="US-ASCII" Content-transfer-encoding: 7bit X-OriginalArrivalTime: 22 Mar 2010 01:50:12.0400 (UTC) FILETIME=[02C62B00:01CAC962] Subject: Re: [re-ECN] draft-tschofenig-conex-ps and our recommendation for the group X-BeenThere: re-ecn@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: re-inserted explicit congestion notification List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 22 Mar 2010 01:50:06 -0000 >> I don't think we've fully considered all of the interactions between our two >> FairShare traffic classes (Priority Best Effort, PBE, and Best Effort, BE) >> and LEDBAT use. One alternative may be to always classify LEDBAT traffic as > > How do you identify it? Great question, but no clear answer yes. We'll have to see how LEDBAT develops. Certainly a host could self-identify traffic as LEDBAT. Jason From rbriscoe@jungle.bt.co.uk Mon Mar 22 13:04:20 2010 Return-Path: X-Original-To: re-ecn@core3.amsl.com Delivered-To: re-ecn@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 3758A3A6B7B for ; Mon, 22 Mar 2010 13:04:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.86 X-Spam-Level: X-Spam-Status: No, score=-0.86 tagged_above=-999 required=5 tests=[AWL=0.127, BAYES_00=-2.599, DNS_FROM_OPENWHOIS=1.13, 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 HwP7JQGrAbfW for ; Mon, 22 Mar 2010 13:04:13 -0700 (PDT) Received: from smtp1.smtp.bt.com (smtp1.smtp.bt.com [217.32.164.137]) by core3.amsl.com (Postfix) with ESMTP id 72AD23A6B30 for ; Mon, 22 Mar 2010 13:03:46 -0700 (PDT) Received: from i2kc06-ukbr.domain1.systemhost.net ([193.113.197.70]) by smtp1.smtp.bt.com with Microsoft SMTPSVC(6.0.3790.3959); Mon, 22 Mar 2010 20:04:02 +0000 Received: from cbibipnt05.iuser.iroot.adidom.com ([147.149.196.177]) by i2kc06-ukbr.domain1.systemhost.net with Microsoft SMTPSVC(6.0.3790.3959); Mon, 22 Mar 2010 20:04:02 +0000 Received: From bagheera.jungle.bt.co.uk ([132.146.168.158]) by cbibipnt05.iuser.iroot.adidom.com (WebShield SMTP v4.5 MR1a P0803.399); id 1269288240431; Mon, 22 Mar 2010 20:04:00 +0000 Received: from MUT.jungle.bt.co.uk ([10.73.208.246]) by bagheera.jungle.bt.co.uk (8.13.5/8.12.8) with ESMTP id o2MK3f7U003855; Mon, 22 Mar 2010 20:03:57 GMT Message-Id: <201003222003.o2MK3f7U003855@bagheera.jungle.bt.co.uk> X-Mailer: QUALCOMM Windows Eudora Version 7.1.0.9 Date: Mon, 22 Mar 2010 18:14:31 +0000 To: Jason Livingood From: Bob Briscoe In-Reply-To: References: <4B9CDC0F.9000102@isoc.org> 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 Mar 2010 20:04:02.0253 (UTC) FILETIME=[D136FFD0:01CAC9FA] Cc: re-ecn@ietf.org Subject: Re: [re-ECN] draft-tschofenig-conex-ps and our recommendation for the group X-BeenThere: re-ecn@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: re-inserted explicit congestion notification List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 22 Mar 2010 20:04:20 -0000 Jason, At 22:50 21/03/2010, Jason Livingood wrote: > >> I don't think we've fully considered all of the interactions > between our two > >> FairShare traffic classes (Priority Best Effort, PBE, and Best Effort, BE) > >> and LEDBAT use. One alternative may be to always classify > LEDBAT traffic as > > > > How do you identify it? > >Great question, but no clear answer yes. We'll have to see how LEDBAT >develops. Certainly a host could self-identify traffic as LEDBAT. There lie monsters. Then you encourage developers to self-identify traffic as LEDBAT that doesn't actually behave like LEDBAT. Or it is LEDBAT trying to behave nicely, but not actually able to succeed. Rather than go by what the traffic *claims* to be, go by how much it actually succeeds in not contributing to congestion. That's what ConEx was designed for. Absent ConEx, it's nearly impossible to get a measure that both sides won't argue about. Bob >Jason > >_______________________________________________ >re-ECN mailing list >re-ECN@ietf.org >https://www.ietf.org/mailman/listinfo/re-ecn ________________________________________________________________ Bob Briscoe, BT Innovate & Design From rbriscoe@jungle.bt.co.uk Mon Mar 22 13:04:28 2010 Return-Path: X-Original-To: re-ecn@core3.amsl.com Delivered-To: re-ecn@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 5E75A3A6B7B for ; Mon, 22 Mar 2010 13:04:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.066 X-Spam-Level: X-Spam-Status: No, score=0.066 tagged_above=-999 required=5 tests=[AWL=-0.806, BAYES_20=-0.74, DNS_FROM_OPENWHOIS=1.13, 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 7kqC65IiM0ly for ; Mon, 22 Mar 2010 13:04:22 -0700 (PDT) Received: from smtp3.smtp.bt.com (smtp3.smtp.bt.com [217.32.164.138]) by core3.amsl.com (Postfix) with ESMTP id BFC213A6B6E for ; Mon, 22 Mar 2010 13:03:49 -0700 (PDT) Received: from i2kc08-ukbr.domain1.systemhost.net ([193.113.197.71]) by smtp3.smtp.bt.com with Microsoft SMTPSVC(6.0.3790.3959); Mon, 22 Mar 2010 20:04:07 +0000 Received: from cbibipnt08.iuser.iroot.adidom.com ([147.149.100.81]) by i2kc08-ukbr.domain1.systemhost.net with Microsoft SMTPSVC(6.0.3790.3959); Mon, 22 Mar 2010 20:04:06 +0000 Received: From bagheera.jungle.bt.co.uk ([132.146.168.158]) by cbibipnt08.iuser.iroot.adidom.com (WebShield SMTP v4.5 MR1a P0803.399); id 1269288245725; Mon, 22 Mar 2010 20:04:05 +0000 Received: from MUT.jungle.bt.co.uk ([10.73.208.246]) by bagheera.jungle.bt.co.uk (8.13.5/8.12.8) with ESMTP id o2MK3f7W003855; Mon, 22 Mar 2010 20:04:01 GMT Message-Id: <201003222004.o2MK3f7W003855@bagheera.jungle.bt.co.uk> X-Mailer: QUALCOMM Windows Eudora Version 7.1.0.9 Date: Mon, 22 Mar 2010 18:23:29 +0000 To: Alissa Cooper From: Bob Briscoe In-Reply-To: References: <4A916DBC72536E419A0BD955EDECEDEC06363E9B@E03MVB1-UKBR.domain1.systemhost.net> <201003082252.o28Mqrmv001407@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: 22 Mar 2010 20:04:06.0821 (UTC) FILETIME=[D3F00550:01CAC9FA] Cc: re-ecn@ietf.org Subject: Re: [re-ECN] draft-tschofenig-conex-ps and our recommendation for the group X-BeenThere: re-ecn@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: re-inserted explicit congestion notification List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 22 Mar 2010 20:04:28 -0000 Alissa, Sorry, I missed your earlier post... one response... At 21:06 11/03/2010, Alissa Cooper wrote: >On Mar 8, 2010, at 10:52 PM, Bob Briscoe wrote: > >>Alissa, >> >>I agree multi-domain could be brought out more. But I don't believe >>it can or should be the focus. Imagine a doc that focused on multi- >>domain congestion accountability. It would have to start by >>explaining what congestion accountability is and why it's important. >>Only once we have the primary new idea - the congestion metric - can >>we introduce the secondary idea of using it between provider >>networks, not just between provider and customer. > >I think it's fine to introduce the general concept before a more >specific concept. But no matter what, the problem statement needs to >start with the problem -- not the solution. Congestion accountability >is a solution. A need for congestion accountability is certainly not what most people think the problem is. But it is actually a very precise statement of what the problem turns out to be when you delve deeply into the traffic maangement problem. That's very different from a solution. I should know; having finally understood that the problem was really congestion accountability (back in 2003), it was really tough to find a way to actually do it. Bob ________________________________________________________________ Bob Briscoe, BT Innovate & Design From shalunov@bittorrent.com Mon Mar 22 13:35:31 2010 Return-Path: X-Original-To: re-ecn@core3.amsl.com Delivered-To: re-ecn@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 606D83A68E0 for ; Mon, 22 Mar 2010 13:35:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.753 X-Spam-Level: * X-Spam-Status: No, score=1.753 tagged_above=-999 required=5 tests=[BAYES_50=0.001, DNS_FROM_OPENWHOIS=1.13, FM_FORGED_GMAIL=0.622] 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 w0GV3Sl2vmL2 for ; Mon, 22 Mar 2010 13:35:28 -0700 (PDT) Received: from mail-qy0-f196.google.com (mail-qy0-f196.google.com [209.85.221.196]) by core3.amsl.com (Postfix) with ESMTP id 5B93B3A6A3B for ; Mon, 22 Mar 2010 13:35:28 -0700 (PDT) Received: by qyk34 with SMTP id 34so82793qyk.22 for ; Mon, 22 Mar 2010 13:35:43 -0700 (PDT) MIME-Version: 1.0 Received: by 10.229.128.82 with SMTP id j18mr2295383qcs.61.1269290142772; Mon, 22 Mar 2010 13:35:42 -0700 (PDT) In-Reply-To: References: <201003211333.o2LDXfU7006975@bagheera.jungle.bt.co.uk> Date: Mon, 22 Mar 2010 13:35:42 -0700 Message-ID: <6c82d1361003221335j365075adi3bdade1cdcef95e4@mail.gmail.com> From: Stanislav Shalunov To: Jason Livingood Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: Rich Woundy , ConEx IETF list Subject: Re: [re-ECN] Call for Comments: draft-livingood-woundy-congestion-mgmt-03 X-BeenThere: re-ecn@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: re-inserted explicit congestion notification List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 22 Mar 2010 20:35:31 -0000 Jason, I don't know if you'd consider this pertinent to your draft, but it would seem related to re-ECN/Conex area -- If I understand correctly, a monthly usage cap is combined with the actual enforcement mechanism described in the draft. It would seem that you have all the machinery that, in a network engineering approximation, detects when the access network is in the state of congestion. The relationship between the economic (usage cap) and the technical enforcement mechanism would seem to be, in the general sense, the topic of Conex. In the spirit of congestion pricing, transmitted data might count differently towards the cap during periods of congestion and outside of such periods. In particular, bits sent when the network isn't congested might be counted as a fraction or not at all, and the overall cap could be adjusted. Additionally, the "Exposure" part in "Congestion Exposure" might be related to making the current measured state of the network and of the subscriber's line known to the subscriber. It might even be that the two are related: If the user doesn't know when the network is congested, how can he change the utilization patterns to relieve the congestion? I'm sure you've given this a lot of thought. Anything you could share? Thanks, -- Stas On Sun, Mar 21, 2010 at 3:54 PM, Jason Livingood wrote: > Good suggestion to add some new content, Bob. > > As to what we plan to do, your comments and others are in my I-D work que= ue > to be evaluated for addition into the next rev. =A0I might even have time= to > do some of that this week, but I usually underestimate my work load durin= g > IETF meetings. =A0;-) > > After that is done, I agree strongly with you that it's time to freeze it > and I hope to do so prior to IETF 78. =A0If in CONEX we want to take some= of > the concepts and content into a new doc, that's cool but I think it's als= o > helpful to have an informational snapshot of the system as a stable > reference point. > > Jason > > > On 3/21/10 9:33 AM, "Bob Briscoe" wrote: > >> Jason, Rich, >> >> Following Rich's useful email on this list about how Comcast used >> congestion for traffic management within its existing business model... >> >> It would be useful to have a section of your >> draft-livingood-woundy-congestion-mgmt detailing any changes to >> Comcast's customer contract as a result of deploying FairShare. >> >> Even if the title says "Contractual Changes" and the text says "None". >> >> However, I suspect there will be more to say there. You had the FCC >> looking over you, so I guess you wanted to publicly commit to being >> protocol agnostic - now that you had the technical means. I'd also be >> interested if there was any change to your Fair Use Policy, or your >> Acceptable Use Policy. >> >> PS. What are you planning to do with the doc, and with the comments >> people have been sending - like the nine I sent (see below) and those >> Matt sent? My take would be to freeze it fairly soon, as a record of >> what you did. Rather than widen it further (which ought to go in a secon= d >> doc). >> >> Cheers >> >> >> >> Bob >> >> >> >>> Date: Thu, 04 Mar 2010 23:52:00 +0000 >>> To: Jason Livingood >>> From: Bob Briscoe >>> Subject: Re: [re-ECN] Call for Comments: >>> draft-livingood-woundy-congestion-mgmt-03 >>> Cc: Matt Mathis , re-ecn@ietf.org >>> >>> Jason, >>> >>> I had read the draft before, and it will be a useful ref. I would >>> advise that you publish soon before things move on, rather than >>> trying to add stuff on applicability to non-cable networks (even tho >>> that would be interesting - perhaps best as a separate short draft). >>> >>> I have some hopefully constructive comments below from my reading of >>> the latest -03 rev. >>> >>> >>> 1/ >> >> [snip] >> >> >> ________________________________________________________________ >> Bob Briscoe, =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0= =A0BT Innovate & Design >> > > > _______________________________________________ > re-ECN mailing list > re-ECN@ietf.org > https://www.ietf.org/mailman/listinfo/re-ecn > --=20 Stanislav Shalunov BitTorrent Inc shalunov@bittorrent.com personal: http://shlang.com From jason_livingood@cable.comcast.com Mon Mar 22 15:03:58 2010 Return-Path: X-Original-To: re-ecn@core3.amsl.com Delivered-To: re-ecn@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 50D593A680C for ; Mon, 22 Mar 2010 15:03:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.351 X-Spam-Level: X-Spam-Status: No, score=-2.351 tagged_above=-999 required=5 tests=[BAYES_50=0.001, DNS_FROM_OPENWHOIS=1.13, HELO_EQ_MODEMCABLE=0.768, HOST_EQ_MODEMCABLE=1.368, RCVD_IN_DNSWL_HI=-8, RCVD_NUMERIC_HELO=2.067, SARE_MILLIONSOF=0.315] 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 abDNzm+jTmqS for ; Mon, 22 Mar 2010 15:03:56 -0700 (PDT) Received: from pacdcimo01.cable.comcast.com (PacdcIMO01.cable.comcast.com [24.40.8.145]) by core3.amsl.com (Postfix) with ESMTP id 886043A67E1 for ; Mon, 22 Mar 2010 15:03:50 -0700 (PDT) Received: from ([24.40.15.92]) by pacdcimo01.cable.comcast.com with ESMTP id 5503620.74927878; Mon, 22 Mar 2010 18:04:05 -0400 Received: from PACDCEXCMB04.cable.comcast.com ([24.40.15.86]) by PACDCEXCSMTP03.cable.comcast.com with Microsoft SMTPSVC(6.0.3790.3959); Mon, 22 Mar 2010 18:04:04 -0400 Received: from 130.129.26.85 ([130.129.26.85]) by PACDCEXCMB04.cable.comcast.com ([24.40.15.86]) via Exchange Front-End Server webmail.comcast.com ([24.40.8.154]) with Microsoft Exchange Server HTTP-DAV ; Mon, 22 Mar 2010 22:04:04 +0000 User-Agent: Microsoft-Entourage/12.24.0.100205 Date: Mon, 22 Mar 2010 15:04:03 -0700 From: Jason Livingood To: Stanislav Shalunov Message-ID: Thread-Topic: [re-ECN] Call for Comments: draft-livingood-woundy-congestion-mgmt-03 Thread-Index: AcrKC5UxPddcTpYyvUGs0MItdwCFuQ== In-Reply-To: <6c82d1361003221335j365075adi3bdade1cdcef95e4@mail.gmail.com> Mime-version: 1.0 Content-type: text/plain; charset="US-ASCII" Content-transfer-encoding: 7bit X-OriginalArrivalTime: 22 Mar 2010 22:04:04.0185 (UTC) FILETIME=[95E69C90:01CACA0B] Cc: Rich Woundy , ConEx IETF list Subject: Re: [re-ECN] Call for Comments: draft-livingood-woundy-congestion-mgmt-03 X-BeenThere: re-ecn@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: re-inserted explicit congestion notification List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 22 Mar 2010 22:03:58 -0000 Inline below - Jason On 3/22/10 1:35 PM, "Stanislav Shalunov" wrote: > If I understand correctly, a monthly usage cap is combined with the > actual enforcement mechanism described in the draft. It would seem > that you have all the machinery that, in a network engineering > approximation, detects when the access network is in the state of > congestion. In operation these are independent processes, though both usage metering and congestion management rely upon volumetric accounting data contained in IP Detail Records (IPDR). Also, someone could certainly exceed such a usage limit without necessarily contributing heavily to congestion. So tool each has its place. The usage limit is a tool to help maintain a flat-rate price structure and the congestion management system helps distribute the effects of congestion (should it occur) upon the users contributing most heavily to said congestion at the time of congestion. > The relationship between the economic (usage cap) and the technical > enforcement mechanism would seem to be, in the general sense, the > topic of Conex. Agreed. > In the spirit of congestion pricing, transmitted data might count > differently towards the cap during periods of congestion and outside > of such periods. In particular, bits sent when the network isn't > congested might be counted as a fraction or not at all, and the > overall cap could be adjusted. Indeed! The first step though is to establish the basic byte accounting system we have now*, after which it's possible to contemplate the kinds of extensions you describe. It would be interesting to be able to differentiate between congestion contribution usage, regular usage, and less than best effort usage, and to vary how these are counted as you describe. * When I say we have it now, the backend systems are in place but we're still mid-way through rolling out a user-facing usage meter. We're more than 50% complete and have deployed it to millions of users in just the past few weeks. The meter looks like this: http://networkmanagement.comcast.net/datausagemeter.jpg And this is an independent analysis of our meter system: http://netforecast.com/documents/NFR5101_Comcast_Usage_Meter_Accuracy.pdf > Additionally, the "Exposure" part in "Congestion Exposure" might be > related to making the current measured state of the network and of the > subscriber's line known to the subscriber. Agree > It might even be that the two are related: If the user doesn't know > when the network is congested, how can he change the utilization > patterns to relieve the congestion? I think this is a very good point. And by user adjustment, I include applications in that as well so that an app could choose via its logic to make real-time adjustments - though exposure to users is interesting as well since this can influence application choice, application usage and settings, etc. From rbriscoe@jungle.bt.co.uk Mon Mar 22 16:23:17 2010 Return-Path: X-Original-To: re-ecn@core3.amsl.com Delivered-To: re-ecn@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 2734C28C237 for ; Mon, 22 Mar 2010 16:23:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.091 X-Spam-Level: X-Spam-Status: No, score=0.091 tagged_above=-999 required=5 tests=[AWL=-0.781, BAYES_20=-0.74, DNS_FROM_OPENWHOIS=1.13, 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 Lc+dp+4viKze for ; Mon, 22 Mar 2010 16:23:11 -0700 (PDT) Received: from smtp4.smtp.bt.com (smtp4.smtp.bt.com [217.32.164.151]) by core3.amsl.com (Postfix) with ESMTP id 45F5728C233 for ; Mon, 22 Mar 2010 16:23:11 -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); Mon, 22 Mar 2010 23:23:28 +0000 Received: from cbibipnt05.iuser.iroot.adidom.com ([147.149.196.177]) by i2kc06-ukbr.domain1.systemhost.net with Microsoft SMTPSVC(6.0.3790.3959); Mon, 22 Mar 2010 23:23:28 +0000 Received: From bagheera.jungle.bt.co.uk ([132.146.168.158]) by cbibipnt05.iuser.iroot.adidom.com (WebShield SMTP v4.5 MR1a P0803.399); id 1269300206893; Mon, 22 Mar 2010 23:23:26 +0000 Received: from MUT.jungle.bt.co.uk ([10.73.80.76]) by bagheera.jungle.bt.co.uk (8.13.5/8.12.8) with ESMTP id o2MNNKqO007497; Mon, 22 Mar 2010 23:23:23 GMT Message-Id: <201003222323.o2MNNKqO007497@bagheera.jungle.bt.co.uk> X-Mailer: QUALCOMM Windows Eudora Version 7.1.0.9 Date: Mon, 22 Mar 2010 23:22:23 +0000 To: Jason Livingood , Stanislav Shalunov From: Bob Briscoe In-Reply-To: References: <6c82d1361003221335j365075adi3bdade1cdcef95e4@mail.gmail.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: 22 Mar 2010 23:23:28.0527 (UTC) FILETIME=[ADAB81F0:01CACA16] Cc: Rich Woundy , ConEx IETF list Subject: Re: [re-ECN] Call for Comments: draft-livingood-woundy-congestion-mgmt-03 X-BeenThere: re-ecn@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: re-inserted explicit congestion notification List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 22 Mar 2010 23:23:17 -0000 Stas, Jason, responses to you both inline... At 22:04 22/03/2010, Jason Livingood wrote: >Inline below >- Jason > >On 3/22/10 1:35 PM, "Stanislav Shalunov" wrote: > > In the spirit of congestion pricing, transmitted data might count > > differently towards the cap during periods of congestion and outside > > of such periods. In particular, bits sent when the network isn'ts to you > > congested might be counted as a fraction or not at all, and the > > overall cap could be adjusted. Just to be clear, ConEx (if done as re-ECN) doesn't have to be mediated by any central management system that detects when the system is congested and triggers 'network congested mode'. When queues are marking packets beyond their AQM threshold, more of the volume will be marked, and when they're not it won't. Simple. >Indeed! The first step though is to establish the basic byte accounting >system we have now*, after which it's possible to contemplate the kinds of >extensions you describe. It would be interesting to be able to >differentiate between congestion contribution usage, regular usage, and less >than best effort usage, and to vary how these are counted as you describe. If you just count marked congestion-volume, it just works. You don't have to know that a transport is LBE. The network just measures less congestion when that app is using the net, merely because it is causing less congestion. Bob ________________________________________________________________ Bob Briscoe, BT Innovate & Design From ingemar.s.johansson@ericsson.com Wed Mar 24 17:59:41 2010 Return-Path: X-Original-To: re-ecn@core3.amsl.com Delivered-To: re-ecn@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 507EF3A6BF8 for ; Wed, 24 Mar 2010 17:59:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.034 X-Spam-Level: X-Spam-Status: No, score=-0.034 tagged_above=-999 required=5 tests=[AWL=1.435, BAYES_00=-2.599, DNS_FROM_OPENWHOIS=1.13] 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 AXysbjYdTjlC for ; Wed, 24 Mar 2010 17:59:40 -0700 (PDT) Received: from mailgw9.se.ericsson.net (mailgw9.se.ericsson.net [193.180.251.57]) by core3.amsl.com (Postfix) with ESMTP id 6292F3A6A5B for ; Wed, 24 Mar 2010 17:59:38 -0700 (PDT) X-AuditID: c1b4fb39-b7b85ae000005cbc-b4-4baab58b84b7 Received: from esessmw0197.eemea.ericsson.se (Unknown_Domain [153.88.253.125]) by mailgw9.se.ericsson.net (Symantec Brightmail Gateway) with SMTP id 16.51.23740.B85BAAB4; Thu, 25 Mar 2010 01:59:55 +0100 (CET) Received: from ESESSCMS0356.eemea.ericsson.se ([169.254.2.100]) by esessmw0197.eemea.ericsson.se ([153.88.115.87]) with mapi; Thu, 25 Mar 2010 01:59:55 +0100 From: Ingemar Johansson S To: "re-ecn@ietf.org" Date: Thu, 25 Mar 2010 01:59:42 +0100 Thread-Topic: Wireless aspects of the ConEx work Thread-Index: AcrLtnQHKFiin1sGRz+Pee5BwMXhXg== Message-ID: <548FC4B9D57A4043AAFFE888A39429031D01FA5351@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: [re-ECN] Wireless aspects of the ConEx work X-BeenThere: re-ecn@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: re-inserted explicit congestion notification List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 25 Mar 2010 00:59:41 -0000 Hi As a followup to my comment at the mike at todays re-BoF :-) The document that discusses congestion as seen from a wireless access persp= ective=20 http://tools.ietf.org/id/draft-johansson-wireless-congestion-properties-00.= txt This document was written as a kind of input to the Conex work a few months= ago.=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 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 karagian@cs.utwente.nl Thu Mar 25 07:55:38 2010 Return-Path: X-Original-To: re-ecn@core3.amsl.com Delivered-To: re-ecn@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id C8EEE3A6A71 for ; Thu, 25 Mar 2010 07:55:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 3.322 X-Spam-Level: *** X-Spam-Status: No, score=3.322 tagged_above=-999 required=5 tests=[AWL=-1.300, BAYES_50=0.001, DNS_FROM_OPENWHOIS=1.13, HELO_EQ_NL=0.55, HOST_EQ_NL=1.545, MIME_QP_LONG_LINE=1.396] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id m6GjnBmArUkg for ; Thu, 25 Mar 2010 07:55:37 -0700 (PDT) Received: from denhaag.ewi.utwente.nl (denhaag.ewi.utwente.nl [130.89.10.11]) by core3.amsl.com (Postfix) with ESMTP id 89C0E3A6A38 for ; Thu, 25 Mar 2010 07:55:29 -0700 (PDT) Received: from webmail.cs.utwente.nl (janus.ewi.utwente.nl [130.89.10.26]) by denhaag.ewi.utwente.nl (8.13.6/8.13.6) with SMTP id o2PEtc8E015215; Thu, 25 Mar 2010 15:55:38 +0100 (MET) Received: from 130.129.30.6 (auth. user karagian@imap1.ewi.utwente.nl) by webmail.cs.utwente.nl with HTTP; Thu, 25 Mar 2010 14:55:40 +0000 To: re-ecn@ietf.org Date: Thu, 25 Mar 2010 14:55:39 +0000 X-Mailer: IlohaMail/0.8.13 (On: webmail.cs.utwente.nl) Message-ID: From: "Georgios Karagiannis" Bounce-To: "Georgios Karagiannis" Errors-To: "Georgios Karagiannis" MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable X-Scanned-By: MIMEDefang 2.52 on 130.89.10.11 X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-3.0rc3 (denhaag.ewi.utwente.nl [130.89.10.11]); Thu, 25 Mar 2010 15:55:49 +0100 (MET) Subject: [re-ECN] Comments regarding Conex charter X-BeenThere: re-ecn@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: re-inserted explicit congestion notification List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 25 Mar 2010 14:55:38 -0000 Hi all I agree with the argumentation given in the different available Conex drafts that such work is needed and that it is useful to start a Working group in the area oc Congestion exposure. However the current charter is not clear to me. The current charter mentions the following WG description: "The purpose of the CONEX working group is to develop a mechanism to allow senders to inform the network of the level of congestion they expect their packets to encounter end-to-end. This information is currently only visible at the transport layer in the end systems. With the CONEX mechanism, it will be possible to provide sufficient information in each IP datagram so that any node along the network path can see the expected rest-of-path congestion. Once any node can see the impact it causes (and suffers) by sending or forwarding packets, it will be possible to hold senders and whole networks accountable for the congestion they cause downstream. The CONEX mechanism could be used for mitigating distributed denial of service (DDoS) attacks; simplifying differentiation of quality of service (QoS); policing compliance to congestion control; and so on." >From this description is not clear to me whether the working group will specify: o) How the network will detect congestion? o) How the network informs the source about this congestion? o) How the network will use the information provided by the source regarding the level of congestion? In the above paragraph is mentioned =93it will possible hold senders and whole networks accountable for the congestion they cause downstream.=94 . It is not clear to me whether you want to say that the =93network by using the information provided by the senders could predict and mitigate or reduce possible congestion situation that are occurring or could occur in the immediate future.=94 Moreover, regarding the protocol solutions, in the given work items I could find only find the following information: "2. Specification Specification of IPv4 and IPv6 packet structures to carry CONEX information (header bits, interpretation) 3. Best Practices Transport-related best practices and specifications for =09A. the timely transport of congestion information from the destination to the sender =09B. ensuring the trustworthiness of the CONEX information (to mitigate the threats identified in 1C)" I do not see any work items on how the timely transport of congestion information from the destination to the sender will be used. According to the re-ECN solution, see URL below, the network adds pre-congestion marking in the forward data path, the egress (or destination) feeds its level back to the ingress (or sender), then the ingress gateway (or sender) re-echoes it into the forward data path by blanking the RE flag. Then at any border of a domain, the pre-congestion marking that every passing packet will be expected to experience downstream can be measured to be the RE blanking fraction minus the congestion marking fraction. http://www.watersprings.org/pub/id/draft-briscoe-tsvwg-re-ecn-border-cheat-01= txt In my opinion two more work items could be identified, see below: o) provide a solution on how the sender re-echoes the feedback information into the network, and how the network uses this re-echoed information. o) provide a solution on how the network could predict and mitigate or reduce possible congestion situation that are occurring or could occur in the immediate future by using the information provided by the senders Best regards, Georgios From john@jlc.net Thu Mar 25 08:46:45 2010 Return-Path: X-Original-To: re-ecn@core3.amsl.com Delivered-To: re-ecn@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 36CA43A690C for ; Thu, 25 Mar 2010 08:46:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.869 X-Spam-Level: X-Spam-Status: No, score=-2.869 tagged_above=-999 required=5 tests=[BAYES_50=0.001, DNS_FROM_OPENWHOIS=1.13, 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 ICcLU0Jfdeag for ; Thu, 25 Mar 2010 08:46:44 -0700 (PDT) Received: from mailhost.jlc.net (mailhost.jlc.net [199.201.159.9]) by core3.amsl.com (Postfix) with ESMTP id 3F7413A63C9 for ; Thu, 25 Mar 2010 08:46:44 -0700 (PDT) Received: by mailhost.jlc.net (Postfix, from userid 104) id 6E7EC33C74; Thu, 25 Mar 2010 11:47:06 -0400 (EDT) Date: Thu, 25 Mar 2010 11:47:06 -0400 From: John Leslie To: Georgios Karagiannis Message-ID: <20100325154706.GA39172@verdi> References: Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.4.1i Cc: re-ecn@ietf.org Subject: Re: [re-ECN] Comments regarding Conex charter X-BeenThere: re-ecn@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: re-inserted explicit congestion notification List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 25 Mar 2010 15:46:45 -0000 Georgios Karagiannis wrote: > > I agree with the argumentation given in the different available Conex > drafts that such work is needed and that it is useful to start a Working > group in the area oc Congestion exposure. :^) > However the current charter is not clear to me. Then we should fix it! > From this description is not clear to me whether the working group will > specify: > > o) How the network will detect congestion? Likely not... (personally, I'm not sure we could reach an agreement what we mean by "congestion"...) > o) How the network informs the source about this congestion? I believe we're intending that we only treat how to inform the _recipient_ and leave up to a transport protocol to inform the sender. > o) How the network will use the information provided by the source > regarding the level of congestion? This is a major area of work for the proposed WG. I don't believe we want to limit usage at chartering time. The intent is clear that any network router can know rest-of-path expected congestion, and determine somehow whether congestion-so-far exceeds the "expected congestion". Exactly what it might do in such a case, IMHO, we do not intend to specify. My personal view is that there might be formal or informal settlements -- leading to cost justification for infrastructure upgrades. But I do not believe that is a charter issue. > It is not clear to me whether you want to say that the > ?network by using the information provided by the senders could > predict and mitigate or reduce possible congestion situation that > are occurring or could occur in the immediate future.? My view is that settlements are a good path to justify upgrades; and that conversely, "deadbeat" network peers that refuse to pay settlements deserve a lower priority for their traffic -- perhaps _lower_ priority than traffic without any ConEx marking. YMMV, of course... > Moreover, regarding the protocol solutions, in the given work items > I could find only find the following information: > > > I do not see any work items on how the timely transport of congestion > information from the destination to the sender will be used. IMHO, any such specification would be premature: I expect various mechanisms to be tried. > In my opinion two more work items could be identified, see below: > > o) provide a solution on how the sender re-echoes the feedback > information into the network, and how the network uses this > re-echoed information. I think that specification of how to specify expected congestion when an IP packet originates is the limit of our work. How a sender might calculate that number seems out-of-scope. > o) provide a solution on how the network could predict and mitigate > or reduce possible congestion situation that are occurring or > could occur in the immediate future by using the information > provided by the senders I would be happy to participate in such work; but I'm not sure whether it is a necessary part of ConEx work. IMHO, it would be a bad thing to even _suggest_ that there should be only one way... -- John Leslie From zhouboyj@gmail.com Thu Mar 25 09:06:34 2010 Return-Path: X-Original-To: re-ecn@core3.amsl.com Delivered-To: re-ecn@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 69AF63A6BF7 for ; Thu, 25 Mar 2010 09:06:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.021 X-Spam-Level: X-Spam-Status: No, score=0.021 tagged_above=-999 required=5 tests=[BAYES_05=-1.11, DNS_FROM_OPENWHOIS=1.13, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id jDiK8+j70sC5 for ; Thu, 25 Mar 2010 09:06:33 -0700 (PDT) Received: from mail-pz0-f204.google.com (mail-pz0-f204.google.com [209.85.222.204]) by core3.amsl.com (Postfix) with ESMTP id 640473A6A21 for ; Thu, 25 Mar 2010 09:05:50 -0700 (PDT) Received: by pzk42 with SMTP id 42so544628pzk.32 for ; Thu, 25 Mar 2010 09:06:10 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:in-reply-to:references :date:message-id:subject:from:to:cc:content-type; bh=Opwm1miGV0czcdU5vws1UDWtT7GdjjqF9xIrLPsRjc4=; b=xqI84Y/2rYxW5hS4H0nvgcUGrFlC+KtrLu7lnaX71bmrQlzFgDlNHAc9Qa1FSL8L4j 59Ih+l8G8q9MZIbRN05lfHe6yeGapquaTWjG0PTu5WwR+8Q/iV0Hy1drJWubicRCKrbx r4N0xZ7QLGSkADX8HeeOh0JKPqmUyxYf67QFc= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; b=R1VwRn5V0HdpydpqskJ+otCDXc8Y/f7tefh5xf9+dV+U7XWGMYVaq+9YDpEfZ98ekk 1IDH3YLYQcbMy4YokeB0hQ1dq6BOhhD8W6renSKUwvWtqpU/POAmo72bg7ps0ijyO4Rk HVFB3686TWgh3GiGcSwgeiNixKSnskRHtpLkc= MIME-Version: 1.0 Received: by 10.114.8.15 with SMTP id 15mr7599295wah.178.1269533169564; Thu, 25 Mar 2010 09:06:09 -0700 (PDT) In-Reply-To: <548FC4B9D57A4043AAFFE888A39429031D01FA5351@ESESSCMS0356.eemea.ericsson.se> References: <548FC4B9D57A4043AAFFE888A39429031D01FA5351@ESESSCMS0356.eemea.ericsson.se> Date: Fri, 26 Mar 2010 00:06:09 +0800 Message-ID: <36a593231003250906s5a68a53n47f3565da107a914@mail.gmail.com> From: bo zhou To: Ingemar Johansson S Content-Type: multipart/alternative; boundary=00504502e17b9a3b350482a239a9 Cc: "re-ecn@ietf.org" Subject: Re: [re-ECN] Wireless aspects of the ConEx work X-BeenThere: re-ecn@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: re-inserted explicit congestion notification List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 25 Mar 2010 16:06:34 -0000 --00504502e17b9a3b350482a239a9 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Hi All, What Ingemar mentioned sounds reasonable. I am worry about current charter defined E2E focus on fixed network only. I believe in the future, E2E Internet traffic will be found more in wireless/mobile network rather than fixed network (maybe my prediction is wrong, but who knows). In such way, we can predict the bottleneck will be happened in air interface and mobile backhaul rather than bearer network, not prediction result, it happened today. I believe Congestion Exposure is a good and right idea working as a WG in IETF. But only cover fixed network is not enough, especially mobile Interne= t traffic raise up very quickly these years. Shall we consider wireless/mobile network congestion in the scope? Regards, Bo On Thu, Mar 25, 2010 at 8:59 AM, Ingemar Johansson S < ingemar.s.johansson@ericsson.com> wrote: > Hi > > As a followup to my comment at the mike at todays re-BoF :-) > > The document that discusses congestion as seen from a wireless access > perspective > > http://tools.ietf.org/id/draft-johansson-wireless-congestion-properties-0= 0.txt > This document was written as a kind of input to the Conex work a few mont= hs > ago. > > 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. > Senior Research Engineer > > 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 > 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 > _______________________________________________ > re-ECN mailing list > re-ECN@ietf.org > https://www.ietf.org/mailman/listinfo/re-ecn > --=20 Regards, Bo Zhou China Mobile --00504502e17b9a3b350482a239a9 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable

Hi All,

What Ingemar mentioned sounds reasonable.
I am worry about current c= harter defined E2E focus on fixed network only. I believe in the future, E2= E Internet traffic will be found more in wireless/mobile network rather tha= n fixed network (maybe my prediction is wrong, but who knows). In such way,= we can predict the bottleneck will be happened in air interface and mobile= backhaul rather than bearer network, not prediction result, it happened to= day.
I believe Congestion Exposure is a good and right idea working as a WG in I= ETF. But only cover fixed network is not enough, especially mobile Internet= traffic raise up very quickly these years.
Shall we consider wireless/= mobile network congestion in the scope?

Regards,

Bo

On Thu, Mar 25, 2010 at 8:59 AM, Ingemar Johanss= on S <ingemar.s.johansson@ericsson.com> wrote:
Hi

As a followup to my co= mment at the mike at todays re-BoF :-)

The document that discusses c= ongestion as seen from a wireless access perspective
http://tools.ietf.org/id/draft-johansson-= wireless-congestion-properties-00.txt
This document was written as a= kind of input to the Conex work a few months ago.

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 = =A0M.Sc.
Senior Research Engineer

Ericsson AB
Multimedia Techn= ologies
Labratoriegr=E4nd 11
971 28, Lule=E5, Sweden
Phone +46-107= 1 43042
SMS/MMS +46-73 078 3289
ingemar.s.johansson@ericsson.com
www.ericsson.com
Vis= it http://labs.eric= sson.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
_______________________________________________=
re-ECN mailing list
re-ECN@ietf.o= rg
https://www.ietf.org/mailman/listinfo/re-ecn



--
Regards,

= Bo Zhou
China Mobile
--00504502e17b9a3b350482a239a9-- From Dirk.Kutscher@nw.neclab.eu Thu Mar 25 09:33:22 2010 Return-Path: X-Original-To: re-ecn@core3.amsl.com Delivered-To: re-ecn@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id CFD983A6B1E for ; Thu, 25 Mar 2010 09:33:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.131 X-Spam-Level: * X-Spam-Status: No, score=1.131 tagged_above=-999 required=5 tests=[BAYES_50=0.001, DNS_FROM_OPENWHOIS=1.13] 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 ASNKo7IbzQu1 for ; Thu, 25 Mar 2010 09:33:21 -0700 (PDT) Received: from smtp0.neclab.eu (smtp0.neclab.eu [195.37.70.41]) by core3.amsl.com (Postfix) with ESMTP id 2FD2C3A6CA5 for ; Thu, 25 Mar 2010 09:33:09 -0700 (PDT) Received: from localhost (localhost.localdomain [127.0.0.1]) by smtp0.neclab.eu (Postfix) with ESMTP id 19E622C000C16; Thu, 25 Mar 2010 17:33:31 +0100 (CET) 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 m9c3zi-665yT; Thu, 25 Mar 2010 17:33:31 +0100 (CET) Received: from VENUS.office (mx1.office [192.168.24.3]) by smtp0.neclab.eu (Postfix) with ESMTP id EB5182C000C15; Thu, 25 Mar 2010 17:33:15 +0100 (CET) X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Thu, 25 Mar 2010 17:33:14 +0100 Message-ID: <547F018265F92642B577B986577D671C012A3768@VENUS.office> In-reply-to: <548FC4B9D57A4043AAFFE888A39429031D01F3ED65@ESESSCMS0356.eemea.ericsson.se> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [re-ECN] Call for Comments:draft-livingood-woundy-congestion-mgmt-03 Thread-Index: Acqr/UYLBg6/Vo3LSmSbUP2chJ/RdQEmXa8wBXLRP4AABnj5sAFucgxw References: <548FC4B9D57A4043AAFFE888A39429031CEF85F7D4@ESESSCMS0356.eemea.ericsson.se> <548FC4B9D57A4043AAFFE888A39429031D01F3ED65@ESESSCMS0356.eemea.ericsson.se> From: "Dirk Kutscher" To: "Ingemar Johansson S" , "Woundy, Richard" , Subject: Re: [re-ECN] Call for Comments:draft-livingood-woundy-congestion-mgmt-03 X-BeenThere: re-ecn@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: re-inserted explicit congestion notification List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 25 Mar 2010 16:33:22 -0000 Hi Ingemar, I agree that from today's perspective on 3GPP's QoS concepts, Conex = appears to be mainly relevant for non-GBR (best-effort) traffic. = However, considering traffic volume, non-GBR might already by the = dominant QoS class (by far). Moreover, from a different perspective though, congestion exposure (and = transport & application layer adaptation) could render strict QoS = classes a bit less interesting, so that non-GBR will be the default. Concerning scheduler-enforced "fair sharing", I am not sure whether this = is really the objective, because the whole congestion exposure approach = is actually challenging fair sharing. In summary, I would propose to certainly consider current QoS bearer = concept in specific architectures such as LTE/SAE, without constraining = the Conex work too much. Best regards, Dirk -- NEC Laboratories Europe NEC Europe Limited | Registered Office: NEC House, 1 Victoria Road, = London W3 6BL | Registered in England 2832014 > -----Original Message----- > From: re-ecn-bounces@ietf.org [mailto:re-ecn-bounces@ietf.org] On > Behalf Of Ingemar Johansson S > Sent: Thursday, March 18, 2010 11:02 AM > To: Woundy, Richard; re-ecn@ietf.org > Cc: Ingemar Johansson S > Subject: Re: [re-ECN] Call for Comments:draft-livingood-woundy- > congestion-mgmt-03 >=20 > Hi >=20 > I don't believe wireless ISP's sell different bandwidths at least when > it comes to shared access like HSPA or LTE. This depends a little if = we > are talking GBR* or non-GBR bearers. > I would belive that we in this group talk mainly about non-GBR bearers > which in IETF language translates to Best Effort or DF. As the non-GBR > QCIs** have the lowest prio they will yield to GBR traffic, it comes > quite natural then that the per-device bandwidth for best effort > traffic will then vary dependent on factors such as deployment, > coverage, amount of higher priority traffic and number of concurrent > users. >=20 > *GBR =3D Guaranteed Bit Rate, IMS VoIP will typically use a GBR bearer > which will strive as mcuh as possible to guarantee a given bitrate, > regardless of the conditions, see link below for a more nuanced > definition. >=20 > **QCI =3D QoS Class Indentifier 3GPP TS 23.203 table 6.1.7 > http://www.3gpp.org/ftp/Specs/archive/23_series/23.203/23203-930.zip >=20 > PS.. It is not to me totally clear that ConEx is needed with the above > arrangement as the scheduling will likely ensure that devices will > share the limited bandwidth pool in a fair way. What ConEx may be > helpful with is to make the device aware on the congestion it causes > and also to distribute its limited share of bandwidth between flows in > the smartest way. We also have the potential issue with DoS (or DDoS) > attacks but I am not clear here how ConEx is helpful here. >=20 > Regards > Ingemar >=20 > > -----Original Message----- > > From: Woundy, Richard [mailto:Richard_Woundy@cable.comcast.com] > > Sent: den 18 mars 2010 07:27 > > To: Ingemar Johansson S; re-ecn@ietf.org > > Subject: RE: [re-ECN] Call for > > Comments:draft-livingood-woundy-congestion-mgmt-03 > > > > Ingemar, > > > > A belated thanks for the feedback. :) > > > > Let me see if I can re-state your points below. First, the > > per-device wireless capacity may vary dynamically based on > > signal quality (with impacts due to distance, interference), > > so it may be difficult to assess how a single subscriber > > contributes to congestion for a single access node or base > > station. Second, with wireless handoffs for mobility, it may > > be the case that a subscriber contributes to congestion on > > one node/station but not the subsequent one. Is that correct? > > > > Are wireless ISPs selling different bandwidth tiers? Other > > than distinguishing 2.5G vs 3G vs 4G service? > > > > -- Rich > > > > -----Original Message----- > > From: re-ecn-bounces@ietf.org > > [mailto:re-ecn-bounces@ietf.org] On Behalf Of Ingemar Johansson S > > Sent: Thursday, February 18, 2010 7:55 AM > > To: re-ecn@ietf.org > > Subject: Re: [re-ECN] Call for > > Comments:draft-livingood-woundy-congestion-mgmt-03 > > > > Hi > > > > Thanks for the report. > > I read through it but did perhaps not get all the details. > > As far as I understand it the concept builds upon the fact > > that users have a provisioned bandwith, say 10Mbps in e.g the > > downlink. Once congetsion sets in the network the congestion > > manager will enforce some special treatment on flows that > > consumes data with a bitrate that is larger than e.g 80% of > > their provisioned bandwidth over a given amount of time. > > > > The problem I see is that, when I try to transform this > > concept to wirless access, is that it is in general difficult > > to talk about a provisioned bandwidth for best effort traffic > > esp. over a multiuser wireless network with mobility support. > > The 10Mbs, 1.4Mbs or whatever figures written in boldface on > > the boxes are in reality limited by the laws of physics. > > In addition, whatever provisioned bandwidth that one may > > possibly come up with is likely to change over time due to > > changed radio conditions or handover between different access > > types. The thing I find attractive with ConEx is that it has > > potential to work in these scenarios, the question is of > > course if the problem needs a solution like ConEx... > > > > It is possible that I miss some details here, please enlighten me. > > > > Regards > > Ingeamr > > > > > > > = --------------------------------------------------------------------- > - > > > > > > Message: 1 > > > Date: Fri, 12 Feb 2010 10:38:49 -0500 > > > From: Jason Livingood > > > Subject: [re-ECN] Call for Comments: > > > draft-livingood-woundy-congestion-mgmt-03 > > > To: > > > Message-ID: > > > Content-Type: text/plain; charset=3D"us-ascii" > > > > > > This is a call for comments on an individual draft regarding a > > > protocol-agnostic congestion management system, which is related = to > > > some of the reason that Conex is starting up. I and my co-authors > > > would like feedback on the latest revision of this draft at > > > > > = http://tools.ietf.org/html/draft-livingood-woundy-congestion-mgmt-03. > > > > > > If you have any comments, please send them to me privately for > > > consideration. > > > > > > Thank you, > > > Jason > > > > > > -------------- next part -------------- An HTML attachment was > > > scrubbed... > > > URL: > > > > > 212/99c6f607/attachment.htm> > > > > > > ------------------------------ > > > > > > _______________________________________________ > > > re-ECN mailing list > > > re-ECN@ietf.org > > > https://www.ietf.org/mailman/listinfo/re-ecn > > > > > > > > > End of re-ECN Digest, Vol 12, Issue 24 > > > ************************************** > > > > > _______________________________________________ > > re-ECN mailing list > > re-ECN@ietf.org > > https://www.ietf.org/mailman/listinfo/re-ecn > > > _______________________________________________ > re-ECN mailing list > re-ECN@ietf.org > https://www.ietf.org/mailman/listinfo/re-ecn From Dirk.Kutscher@nw.neclab.eu Thu Mar 25 09:44:39 2010 Return-Path: X-Original-To: re-ecn@core3.amsl.com Delivered-To: re-ecn@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 545053A6CDE for ; Thu, 25 Mar 2010 09:44:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.131 X-Spam-Level: * X-Spam-Status: No, score=1.131 tagged_above=-999 required=5 tests=[BAYES_50=0.001, DNS_FROM_OPENWHOIS=1.13] 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 xZxBYt4dT7oc for ; Thu, 25 Mar 2010 09:44:38 -0700 (PDT) Received: from smtp0.neclab.eu (smtp0.neclab.eu [195.37.70.41]) by core3.amsl.com (Postfix) with ESMTP id A07B03A69DB for ; Thu, 25 Mar 2010 09:44:18 -0700 (PDT) Received: from localhost (localhost.localdomain [127.0.0.1]) by smtp0.neclab.eu (Postfix) with ESMTP id 81B5F2C000C15; Thu, 25 Mar 2010 17:44:40 +0100 (CET) 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 H0Jl4LrbE49H; Thu, 25 Mar 2010 17:44:40 +0100 (CET) Received: from VENUS.office (mx1.office [192.168.24.3]) by smtp0.neclab.eu (Postfix) with ESMTP id 648C72C000C16; Thu, 25 Mar 2010 17:44:25 +0100 (CET) X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Date: Thu, 25 Mar 2010 17:44:24 +0100 Message-ID: <547F018265F92642B577B986577D671C012A376E@VENUS.office> In-reply-to: <36a593231003250906s5a68a53n47f3565da107a914@mail.gmail.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [re-ECN] Wireless aspects of the ConEx work Thread-Index: AcrMNT5kORKj0XC9TES527ye/ov3pgABBn7w References: <548FC4B9D57A4043AAFFE888A39429031D01FA5351@ESESSCMS0356.eemea.ericsson.se> <36a593231003250906s5a68a53n47f3565da107a914@mail.gmail.com> From: "Dirk Kutscher" To: "bo zhou" , "Ingemar Johansson S" Cc: re-ecn@ietf.org Subject: Re: [re-ECN] Wireless aspects of the ConEx work X-BeenThere: re-ecn@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: re-inserted explicit congestion notification List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 25 Mar 2010 16:44:39 -0000 Hi Bo, Looking at http://www.ietf.org/iesg/evaluation/conex-charter.txt, I = don't see the current charter limiting the scope to fixed networks. (Could not follow the on-line discussions this week though). I agree that it should not be constrained to specific systems (or even = L2 technologies). There is an applicability statement document on the charter, which is = fine. Best regards, Dirk -- NEC Laboratories Europe NEC Europe Limited | Registered Office: NEC House, 1 Victoria Road, = London W3 6BL | Registered in England 2832014 > -----Original Message----- > From: re-ecn-bounces@ietf.org [mailto:re-ecn-bounces@ietf.org] On > Behalf Of bo zhou > Sent: Thursday, March 25, 2010 5:06 PM > To: Ingemar Johansson S > Cc: re-ecn@ietf.org > Subject: Re: [re-ECN] Wireless aspects of the ConEx work >=20 > Hi All, >=20 > What Ingemar mentioned sounds reasonable. > I am worry about current charter defined E2E focus on fixed network > only. I believe in the future, E2E Internet traffic will be found more > in wireless/mobile network rather than fixed network (maybe my > prediction is wrong, but who knows). In such way, we can predict the > bottleneck will be happened in air interface and mobile backhaul = rather > than bearer network, not prediction result, it happened today. > I believe Congestion Exposure is a good and right idea working as a WG > in IETF. But only cover fixed network is not enough, especially mobile > Internet traffic raise up very quickly these years. > Shall we consider wireless/mobile network congestion in the scope? >=20 > Regards, >=20 > Bo >=20 >=20 >=20 > On Thu, Mar 25, 2010 at 8:59 AM, Ingemar Johansson S > wrote: >=20 >=20 > Hi >=20 > As a followup to my comment at the mike at todays re-BoF :-) >=20 > The document that discusses congestion as seen from a wireless > access perspective > http://tools.ietf.org/id/draft-johansson-wireless-congestion- > properties-00.txt > This document was written as a kind of input to the Conex work a > few months ago. >=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. > 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 > 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 > _______________________________________________ > re-ECN mailing list > re-ECN@ietf.org > https://www.ietf.org/mailman/listinfo/re-ecn >=20 >=20 >=20 >=20 >=20 > -- > Regards, >=20 > Bo Zhou > China Mobile From ingemar.s.johansson@ericsson.com Thu Mar 25 09:50:50 2010 Return-Path: X-Original-To: re-ecn@core3.amsl.com Delivered-To: re-ecn@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 0D94C3A6B6F for ; Thu, 25 Mar 2010 09:50:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.788 X-Spam-Level: X-Spam-Status: No, score=0.788 tagged_above=-999 required=5 tests=[AWL=-0.343, BAYES_50=0.001, DNS_FROM_OPENWHOIS=1.13] 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 cmi3qquRZcf8 for ; Thu, 25 Mar 2010 09:50:48 -0700 (PDT) Received: from mailgw9.se.ericsson.net (mailgw9.se.ericsson.net [193.180.251.57]) by core3.amsl.com (Postfix) with ESMTP id CF9CC3A6A8D for ; Thu, 25 Mar 2010 09:50:45 -0700 (PDT) X-AuditID: c1b4fb39-b7b85ae000005cbc-5a-4bab947a7dbd Received: from esessmw0184.eemea.ericsson.se (Unknown_Domain [153.88.253.125]) by mailgw9.se.ericsson.net (Symantec Brightmail Gateway) with SMTP id A9.32.23740.A749BAB4; Thu, 25 Mar 2010 17:51:06 +0100 (CET) Received: from ESESSCMS0356.eemea.ericsson.se ([169.254.2.100]) by esessmw0184.eemea.ericsson.se ([153.88.115.81]) with mapi; Thu, 25 Mar 2010 17:51:05 +0100 From: Ingemar Johansson S To: Dirk Kutscher , "Woundy, Richard" , "re-ecn@ietf.org" Date: Thu, 25 Mar 2010 17:51:04 +0100 Thread-Topic: [re-ECN] Call for Comments:draft-livingood-woundy-congestion-mgmt-03 Thread-Index: Acqr/UYLBg6/Vo3LSmSbUP2chJ/RdQEmXa8wBXLRP4AABnj5sAFucgxwAAEFpZA= Message-ID: <548FC4B9D57A4043AAFFE888A39429031D01FA59BC@ESESSCMS0356.eemea.ericsson.se> References: <548FC4B9D57A4043AAFFE888A39429031CEF85F7D4@ESESSCMS0356.eemea.ericsson.se> <548FC4B9D57A4043AAFFE888A39429031D01F3ED65@ESESSCMS0356.eemea.ericsson.se> <547F018265F92642B577B986577D671C012A3768@VENUS.office> In-Reply-To: <547F018265F92642B577B986577D671C012A3768@VENUS.office> 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 Subject: Re: [re-ECN] Call for Comments:draft-livingood-woundy-congestion-mgmt-03 X-BeenThere: re-ecn@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: re-inserted explicit congestion notification List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 25 Mar 2010 16:50:50 -0000 Hi My personal views, I guess this can be debated quite alot depending on whic= h principle is the best. I would agree that ConEx is a challenge against scheduler enforced "fair sh= aring" if one look at it on a short (second by second) time scale. However = I for instance see good reasons for a user to halt a large download if e.g = the coverage is poor, it is then better to use the available capacity to mo= re prioritized tasks. Seen from a (large aggregate of users) I would belive that the best total t= roughput over a longer timescale is acheived if throughput to "hard to reac= h" users is limited, the simple reason is that these users likely cost a lo= t in terms of transmission power. If endpoints are made aware of these rule= s they can themselves prioritize what the temporary thorughput should be us= ed for. I believe that would fit well with the ConEx way of looking at fair= ness. Hope I got this clear (translating thoughts from swedish to english is not = my stongest asset:-) =20 Regards Ingemar > -----Original Message----- > From: Dirk Kutscher [mailto:Dirk.Kutscher@nw.neclab.eu]=20 > Sent: den 25 mars 2010 09:33 > To: Ingemar Johansson S; Woundy, Richard; re-ecn@ietf.org > Subject: RE: [re-ECN] Call for=20 > Comments:draft-livingood-woundy-congestion-mgmt-03 >=20 > Hi Ingemar, >=20 > I agree that from today's perspective on 3GPP's QoS concepts,=20 > Conex appears to be mainly relevant for non-GBR (best-effort)=20 > traffic. However, considering traffic volume, non-GBR might=20 > already by the dominant QoS class (by far). >=20 > Moreover, from a different perspective though, congestion=20 > exposure (and transport & application layer adaptation) could=20 > render strict QoS classes a bit less interesting, so that=20 > non-GBR will be the default. >=20 > Concerning scheduler-enforced "fair sharing", I am not sure=20 > whether this is really the objective, because the whole=20 > congestion exposure approach is actually challenging fair sharing. >=20 > In summary, I would propose to certainly consider current QoS=20 > bearer concept in specific architectures such as LTE/SAE,=20 > without constraining the Conex work too much. >=20 > Best regards, >=20 > Dirk >=20 > -- > NEC Laboratories Europe >=20 > NEC Europe Limited | Registered Office: NEC House, 1 Victoria=20 > Road, London W3 6BL | Registered in England 2832014 >=20 >=20 >=20 >=20 >=20 >=20 >=20 > > -----Original Message----- > > From: re-ecn-bounces@ietf.org [mailto:re-ecn-bounces@ietf.org] On=20 > > Behalf Of Ingemar Johansson S > > Sent: Thursday, March 18, 2010 11:02 AM > > To: Woundy, Richard; re-ecn@ietf.org > > Cc: Ingemar Johansson S > > Subject: Re: [re-ECN] Call for Comments:draft-livingood-woundy- > > congestion-mgmt-03 > >=20 > > Hi > >=20 > > I don't believe wireless ISP's sell different bandwidths at=20 > least when=20 > > it comes to shared access like HSPA or LTE. This depends a=20 > little if=20 > > we are talking GBR* or non-GBR bearers. > > I would belive that we in this group talk mainly about=20 > non-GBR bearers=20 > > which in IETF language translates to Best Effort or DF. As=20 > the non-GBR > > QCIs** have the lowest prio they will yield to GBR traffic,=20 > it comes=20 > > quite natural then that the per-device bandwidth for best effort=20 > > traffic will then vary dependent on factors such as deployment,=20 > > coverage, amount of higher priority traffic and number of=20 > concurrent=20 > > users. > >=20 > > *GBR =3D Guaranteed Bit Rate, IMS VoIP will typically use a=20 > GBR bearer=20 > > which will strive as mcuh as possible to guarantee a given bitrate,=20 > > regardless of the conditions, see link below for a more nuanced=20 > > definition. > >=20 > > **QCI =3D QoS Class Indentifier 3GPP TS 23.203 table 6.1.7=20 > > http://www.3gpp.org/ftp/Specs/archive/23_series/23.203/23203-930.zip > >=20 > > PS.. It is not to me totally clear that ConEx is needed=20 > with the above=20 > > arrangement as the scheduling will likely ensure that devices will=20 > > share the limited bandwidth pool in a fair way. What ConEx may be=20 > > helpful with is to make the device aware on the congestion=20 > it causes=20 > > and also to distribute its limited share of bandwidth=20 > between flows in=20 > > the smartest way. We also have the potential issue with DoS=20 > (or DDoS)=20 > > attacks but I am not clear here how ConEx is helpful here. > >=20 > > Regards > > Ingemar > >=20 > > > -----Original Message----- > > > From: Woundy, Richard [mailto:Richard_Woundy@cable.comcast.com] > > > Sent: den 18 mars 2010 07:27 > > > To: Ingemar Johansson S; re-ecn@ietf.org > > > Subject: RE: [re-ECN] Call for > > > Comments:draft-livingood-woundy-congestion-mgmt-03 > > > > > > Ingemar, > > > > > > A belated thanks for the feedback. :) > > > > > > Let me see if I can re-state your points below. First, the=20 > > > per-device wireless capacity may vary dynamically based on signal=20 > > > quality (with impacts due to distance, interference), so=20 > it may be=20 > > > difficult to assess how a single subscriber contributes to=20 > > > congestion for a single access node or base station. Second, with=20 > > > wireless handoffs for mobility, it may be the case that a=20 > subscriber=20 > > > contributes to congestion on one node/station but not the=20 > subsequent=20 > > > one. Is that correct? > > > > > > Are wireless ISPs selling different bandwidth tiers? Other than=20 > > > distinguishing 2.5G vs 3G vs 4G service? > > > > > > -- Rich > > > > > > -----Original Message----- > > > From: re-ecn-bounces@ietf.org > > > [mailto:re-ecn-bounces@ietf.org] On Behalf Of Ingemar Johansson S > > > Sent: Thursday, February 18, 2010 7:55 AM > > > To: re-ecn@ietf.org > > > Subject: Re: [re-ECN] Call for > > > Comments:draft-livingood-woundy-congestion-mgmt-03 > > > > > > Hi > > > > > > Thanks for the report. > > > I read through it but did perhaps not get all the details. > > > As far as I understand it the concept builds upon the fact that=20 > > > users have a provisioned bandwith, say 10Mbps in e.g the=20 > downlink.=20 > > > Once congetsion sets in the network the congestion manager will=20 > > > enforce some special treatment on flows that consumes data with a=20 > > > bitrate that is larger than e.g 80% of their provisioned=20 > bandwidth=20 > > > over a given amount of time. > > > > > > The problem I see is that, when I try to transform this=20 > concept to=20 > > > wirless access, is that it is in general difficult to=20 > talk about a=20 > > > provisioned bandwidth for best effort traffic esp. over a=20 > multiuser=20 > > > wireless network with mobility support. > > > The 10Mbs, 1.4Mbs or whatever figures written in boldface on the=20 > > > boxes are in reality limited by the laws of physics. > > > In addition, whatever provisioned bandwidth that one may possibly=20 > > > come up with is likely to change over time due to changed radio=20 > > > conditions or handover between different access types.=20 > The thing I=20 > > > find attractive with ConEx is that it has potential to=20 > work in these=20 > > > scenarios, the question is of course if the problem needs=20 > a solution=20 > > > like ConEx... > > > > > > It is possible that I miss some details here, please enlighten me. > > > > > > Regards > > > Ingeamr > > > > > > > > > >=20 > -------------------------------------------------------------------- > > > - > > - > > > > > > > > Message: 1 > > > > Date: Fri, 12 Feb 2010 10:38:49 -0500 > > > > From: Jason Livingood > > > > Subject: [re-ECN] Call for Comments: > > > > draft-livingood-woundy-congestion-mgmt-03 > > > > To: > > > > Message-ID: > > > > Content-Type: text/plain; charset=3D"us-ascii" > > > > > > > > This is a call for comments on an individual draft regarding a=20 > > > > protocol-agnostic congestion management system, which=20 > is related=20 > > > > to some of the reason that Conex is starting up. I and my=20 > > > > co-authors would like feedback on the latest revision of this=20 > > > > draft at > > > > > > >=20 > http://tools.ietf.org/html/draft-livingood-woundy-congestion-mgmt-03. > > > > > > > > If you have any comments, please send them to me privately for=20 > > > > consideration. > > > > > > > > Thank you, > > > > Jason > > > > > > > > -------------- next part -------------- An HTML attachment was=20 > > > > scrubbed... > > > > URL: > > > > > > > 212/99c6f607/attachment.htm> > > > > > > > > ------------------------------ > > > > > > > > _______________________________________________ > > > > re-ECN mailing list > > > > re-ECN@ietf.org > > > > https://www.ietf.org/mailman/listinfo/re-ecn > > > > > > > > > > > > End of re-ECN Digest, Vol 12, Issue 24 > > > > ************************************** > > > > > > > _______________________________________________ > > > re-ECN mailing list > > > re-ECN@ietf.org > > > https://www.ietf.org/mailman/listinfo/re-ecn > > > > > _______________________________________________ > > re-ECN mailing list > > re-ECN@ietf.org > > https://www.ietf.org/mailman/listinfo/re-ecn > = From dave.mcdysan@verizon.com Thu Mar 25 10:26:35 2010 Return-Path: X-Original-To: re-ecn@core3.amsl.com Delivered-To: re-ecn@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 109053A6E35 for ; Thu, 25 Mar 2010 10:26:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.009 X-Spam-Level: X-Spam-Status: No, score=-0.009 tagged_above=-999 required=5 tests=[AWL=-0.140, BAYES_50=0.001, DNS_FROM_OPENWHOIS=1.13, 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 On-n7FvZSpso for ; Thu, 25 Mar 2010 10:26:33 -0700 (PDT) Received: from sacmail2.verizon.com (sacmail2.verizon.com [192.76.84.41]) by core3.amsl.com (Postfix) with ESMTP id ED2C73A6E8A for ; Thu, 25 Mar 2010 10:17:17 -0700 (PDT) Received: from irvintrmemf3.verizon.com (irvintrmemf3.verizon.com [138.83.34.103]) by sacmail2.verizon.com (8.13.7+Sun/8.13.3) with ESMTP id o2PHH7t7024782; Thu, 25 Mar 2010 13:17:23 -0400 (EDT) X-AuditID: 8a532267-b7bffae000007c42-e0-4bab9aa3b456 Received: from smtptpa3.verizon.com ( [138.83.71.176]) by irvintrmemf3.verizon.com (Symantec Mail Security) with SMTP id CA.45.31810.3AA9BAB4; Thu, 25 Mar 2010 12:17:23 -0500 (CDT) Received: from FHDP1CCMXCG01.us.one.verizon.com ([166.68.240.33]) by smtptpa3.verizon.com (8.13.3/8.13.3) with ESMTP id o2PHHJmM017652; Thu, 25 Mar 2010 13:17:23 -0400 (EDT) Received: from FHDP1LUMXCV14.us.one.verizon.com ([166.68.125.35]) by FHDP1CCMXCG01.us.one.verizon.com with Microsoft SMTPSVC(6.0.3790.3959); Thu, 25 Mar 2010 13:17:23 -0400 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: quoted-printable Date: Thu, 25 Mar 2010 13:17:17 -0400 Message-ID: <793F49BA1FC821409F99F10862A0E4DB06454596@FHDP1LUMXCV14.us.one.verizon.com> In-Reply-To: <548FC4B9D57A4043AAFFE888A39429031D01FA59BC@ESESSCMS0356.eemea.ericsson.se> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [re-ECN] Call for Comments:draft-livingood-woundy-congestion-mgmt-03 Thread-Index: Acqr/UYLBg6/Vo3LSmSbUP2chJ/RdQEmXa8wBXLRP4AABnj5sAFucgxwAAEFpZAAAS0J8A== References: <548FC4B9D57A4043AAFFE888A39429031CEF85F7D4@ESESSCMS0356.eemea.ericsson.se><548FC4B9D57A4043AAFFE888A39429031D01F3ED65@ESESSCMS0356.eemea.ericsson.se><547F018265F92642B577B986577D671C012A3768@VENUS.office> <548FC4B9D57A4043AAFFE888A39429031D01FA59BC@ESESSCMS0356.eemea.ericsson.se> From: "Mcdysan, David E" To: "Ingemar Johansson S" , "Dirk Kutscher" , "Woundy, Richard" , X-OriginalArrivalTime: 25 Mar 2010 17:17:23.0008 (UTC) FILETIME=[08708C00:01CACC3F] X-Brightmail-Tracker: AAAAAA== Subject: Re: [re-ECN] Call for Comments:draft-livingood-woundy-congestion-mgmt-03 X-BeenThere: re-ecn@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: re-inserted explicit congestion notification List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 25 Mar 2010 17:26:35 -0000 Hi, My personal view. The sort of time shifting behavior that a user, content provider, or delivery mechanism (e.g., P2P) could make use of exposed congestion feedback are all examples of what I see as an important goal of Conex. I recently joined this list and am catching up on the history. However, I believe Ingemar brings up an important point that "Congestion" is not only due to queuing, but can be caused by other conditions (e.g., changing radio coverage as a mobile device moves about). Dave=20 > -----Original Message----- > From: re-ecn-bounces@ietf.org=20 > [mailto:re-ecn-bounces@ietf.org] On Behalf Of Ingemar Johansson S > Sent: Thursday, March 25, 2010 12:51 PM > To: Dirk Kutscher; Woundy, Richard; re-ecn@ietf.org > Cc: Ingemar Johansson S > Subject: Re: [re-ECN] Call for=20 > Comments:draft-livingood-woundy-congestion-mgmt-03 >=20 > Hi >=20 > My personal views, I guess this can be debated quite alot=20 > depending on which principle is the best. > I would agree that ConEx is a challenge against scheduler=20 > enforced "fair sharing" if one look at it on a short (second=20 > by second) time scale. However I for instance see good=20 > reasons for a user to halt a large download if e.g the=20 > coverage is poor, it is then better to use the available=20 > capacity to more prioritized tasks. > Seen from a (large aggregate of users) I would belive that=20 > the best total troughput over a longer timescale is acheived=20 > if throughput to "hard to reach" users is limited, the simple=20 > reason is that these users likely cost a lot in terms of=20 > transmission power. If endpoints are made aware of these=20 > rules they can themselves prioritize what the temporary=20 > thorughput should be used for. I believe that would fit well=20 > with the ConEx way of looking at fairness. > Hope I got this clear (translating thoughts from swedish to=20 > english is not my stongest asset:-) > =20 > Regards > Ingemar >=20 > > -----Original Message----- > > From: Dirk Kutscher [mailto:Dirk.Kutscher@nw.neclab.eu] > > Sent: den 25 mars 2010 09:33 > > To: Ingemar Johansson S; Woundy, Richard; re-ecn@ietf.org > > Subject: RE: [re-ECN] Call for > > Comments:draft-livingood-woundy-congestion-mgmt-03 > >=20 > > Hi Ingemar, > >=20 > > I agree that from today's perspective on 3GPP's QoS concepts, Conex=20 > > appears to be mainly relevant for non-GBR (best-effort) traffic.=20 > > However, considering traffic volume, non-GBR might already by the=20 > > dominant QoS class (by far). > >=20 > > Moreover, from a different perspective though, congestion exposure=20 > > (and transport & application layer adaptation) could render=20 > strict QoS=20 > > classes a bit less interesting, so that non-GBR will be the default. > >=20 > > Concerning scheduler-enforced "fair sharing", I am not sure whether=20 > > this is really the objective, because the whole congestion exposure=20 > > approach is actually challenging fair sharing. > >=20 > > In summary, I would propose to certainly consider current=20 > QoS bearer=20 > > concept in specific architectures such as LTE/SAE, without=20 > > constraining the Conex work too much. > >=20 > > Best regards, > >=20 > > Dirk > >=20 > > -- > > NEC Laboratories Europe > >=20 > > NEC Europe Limited | Registered Office: NEC House, 1 Victoria Road,=20 > > London W3 6BL | Registered in England 2832014 > >=20 > >=20 > >=20 > >=20 > >=20 > >=20 > >=20 > > > -----Original Message----- > > > From: re-ecn-bounces@ietf.org [mailto:re-ecn-bounces@ietf.org] On=20 > > > Behalf Of Ingemar Johansson S > > > Sent: Thursday, March 18, 2010 11:02 AM > > > To: Woundy, Richard; re-ecn@ietf.org > > > Cc: Ingemar Johansson S > > > Subject: Re: [re-ECN] Call for Comments:draft-livingood-woundy- > > > congestion-mgmt-03 > > >=20 > > > Hi > > >=20 > > > I don't believe wireless ISP's sell different bandwidths at > > least when > > > it comes to shared access like HSPA or LTE. This depends a > > little if > > > we are talking GBR* or non-GBR bearers. > > > I would belive that we in this group talk mainly about > > non-GBR bearers > > > which in IETF language translates to Best Effort or DF. As > > the non-GBR > > > QCIs** have the lowest prio they will yield to GBR traffic, > > it comes > > > quite natural then that the per-device bandwidth for best effort=20 > > > traffic will then vary dependent on factors such as deployment,=20 > > > coverage, amount of higher priority traffic and number of > > concurrent > > > users. > > >=20 > > > *GBR =3D Guaranteed Bit Rate, IMS VoIP will typically use a > > GBR bearer > > > which will strive as mcuh as possible to guarantee a=20 > given bitrate,=20 > > > regardless of the conditions, see link below for a more nuanced=20 > > > definition. > > >=20 > > > **QCI =3D QoS Class Indentifier 3GPP TS 23.203 table 6.1.7=20 > > >=20 > http://www.3gpp.org/ftp/Specs/archive/23_series/23.203/23203-930.zip > > >=20 > > > PS.. It is not to me totally clear that ConEx is needed > > with the above > > > arrangement as the scheduling will likely ensure that=20 > devices will=20 > > > share the limited bandwidth pool in a fair way. What ConEx may be=20 > > > helpful with is to make the device aware on the congestion > > it causes > > > and also to distribute its limited share of bandwidth > > between flows in > > > the smartest way. We also have the potential issue with DoS > > (or DDoS) > > > attacks but I am not clear here how ConEx is helpful here. > > >=20 > > > Regards > > > Ingemar > > >=20 > > > > -----Original Message----- > > > > From: Woundy, Richard [mailto:Richard_Woundy@cable.comcast.com] > > > > Sent: den 18 mars 2010 07:27 > > > > To: Ingemar Johansson S; re-ecn@ietf.org > > > > Subject: RE: [re-ECN] Call for > > > > Comments:draft-livingood-woundy-congestion-mgmt-03 > > > > > > > > Ingemar, > > > > > > > > A belated thanks for the feedback. :) > > > > > > > > Let me see if I can re-state your points below. First, the=20 > > > > per-device wireless capacity may vary dynamically based=20 > on signal=20 > > > > quality (with impacts due to distance, interference), so > > it may be > > > > difficult to assess how a single subscriber contributes to=20 > > > > congestion for a single access node or base station.=20 > Second, with=20 > > > > wireless handoffs for mobility, it may be the case that a > > subscriber > > > > contributes to congestion on one node/station but not the > > subsequent > > > > one. Is that correct? > > > > > > > > Are wireless ISPs selling different bandwidth tiers? Other than=20 > > > > distinguishing 2.5G vs 3G vs 4G service? > > > > > > > > -- Rich > > > > > > > > -----Original Message----- > > > > From: re-ecn-bounces@ietf.org > > > > [mailto:re-ecn-bounces@ietf.org] On Behalf Of Ingemar=20 > Johansson S > > > > Sent: Thursday, February 18, 2010 7:55 AM > > > > To: re-ecn@ietf.org > > > > Subject: Re: [re-ECN] Call for > > > > Comments:draft-livingood-woundy-congestion-mgmt-03 > > > > > > > > Hi > > > > > > > > Thanks for the report. > > > > I read through it but did perhaps not get all the details. > > > > As far as I understand it the concept builds upon the fact that=20 > > > > users have a provisioned bandwith, say 10Mbps in e.g the > > downlink.=20 > > > > Once congetsion sets in the network the congestion manager will=20 > > > > enforce some special treatment on flows that consumes=20 > data with a=20 > > > > bitrate that is larger than e.g 80% of their provisioned > > bandwidth > > > > over a given amount of time. > > > > > > > > The problem I see is that, when I try to transform this > > concept to > > > > wirless access, is that it is in general difficult to > > talk about a > > > > provisioned bandwidth for best effort traffic esp. over a > > multiuser > > > > wireless network with mobility support. > > > > The 10Mbs, 1.4Mbs or whatever figures written in=20 > boldface on the=20 > > > > boxes are in reality limited by the laws of physics. > > > > In addition, whatever provisioned bandwidth that one=20 > may possibly=20 > > > > come up with is likely to change over time due to changed radio=20 > > > > conditions or handover between different access types. > > The thing I > > > > find attractive with ConEx is that it has potential to > > work in these > > > > scenarios, the question is of course if the problem needs > > a solution > > > > like ConEx... > > > > > > > > It is possible that I miss some details here, please=20 > enlighten me. > > > > > > > > Regards > > > > Ingeamr > > > > > > > > > > > > >=20 > > -------------------------------------------------------------------- > > > > - > > > - > > > > > > > > > > Message: 1 > > > > > Date: Fri, 12 Feb 2010 10:38:49 -0500 > > > > > From: Jason Livingood > > > > > Subject: [re-ECN] Call for Comments: > > > > > draft-livingood-woundy-congestion-mgmt-03 > > > > > To: > > > > > Message-ID: > > > > > Content-Type: text/plain; charset=3D"us-ascii" > > > > > > > > > > This is a call for comments on an individual draft=20 > regarding a=20 > > > > > protocol-agnostic congestion management system, which > > is related > > > > > to some of the reason that Conex is starting up. I and my=20 > > > > > co-authors would like feedback on the latest revision of this=20 > > > > > draft at > > > > > > > > >=20 > >=20 > http://tools.ietf.org/html/draft-livingood-woundy-congestion-mgmt-03. > > > > > > > > > > If you have any comments, please send them to me=20 > privately for=20 > > > > > consideration. > > > > > > > > > > Thank you, > > > > > Jason > > > > > > > > > > -------------- next part -------------- An HTML=20 > attachment was=20 > > > > > scrubbed... > > > > > URL: > > > > > > > > > 212/99c6f607/attachment.htm> > > > > > > > > > > ------------------------------ > > > > > > > > > > _______________________________________________ > > > > > re-ECN mailing list > > > > > re-ECN@ietf.org > > > > > https://www.ietf.org/mailman/listinfo/re-ecn > > > > > > > > > > > > > > > End of re-ECN Digest, Vol 12, Issue 24 > > > > > ************************************** > > > > > > > > > _______________________________________________ > > > > re-ECN mailing list > > > > re-ECN@ietf.org > > > > https://www.ietf.org/mailman/listinfo/re-ecn > > > > > > > _______________________________________________ > > > re-ECN mailing list > > > re-ECN@ietf.org > > > https://www.ietf.org/mailman/listinfo/re-ecn > >=20 > _______________________________________________ > re-ECN mailing list > re-ECN@ietf.org > https://www.ietf.org/mailman/listinfo/re-ecn >=20 From philip.eardley@bt.com Thu Mar 25 10:43:35 2010 Return-Path: X-Original-To: re-ecn@core3.amsl.com Delivered-To: re-ecn@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 16E543A6D19 for ; Thu, 25 Mar 2010 10:43:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 2.2 X-Spam-Level: ** X-Spam-Status: No, score=2.2 tagged_above=-999 required=5 tests=[BAYES_50=0.001, DNS_FROM_OPENWHOIS=1.13, HTML_MESSAGE=0.001, MISSING_MIMEOLE=0.001, RCVD_IN_DNSWL_LOW=-1, RCVD_NUMERIC_HELO=2.067] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Bo2SbtEva8l8 for ; Thu, 25 Mar 2010 10:43:33 -0700 (PDT) Received: from smtp3.smtp.bt.com (smtp3.smtp.bt.com [217.32.164.138]) by core3.amsl.com (Postfix) with ESMTP id 4A7DA3A6C15 for ; Thu, 25 Mar 2010 10:41:26 -0700 (PDT) Received: from E03MVB1-UKBR.domain1.systemhost.net ([193.113.197.110]) by smtp3.smtp.bt.com with Microsoft SMTPSVC(6.0.3790.3959); Thu, 25 Mar 2010 17:41:47 +0000 Received: from 193.113.197.149 ([193.113.197.149]) by E03MVB1-UKBR.domain1.systemhost.net ([193.113.197.58]) with Microsoft Exchange Server HTTP-DAV ; Thu, 25 Mar 2010 17:41:07 +0000 From: "Eardley,PL,Philip,DEE1 R" To: "Dirk Kutscher" , "bo zhou" , "Ingemar Johansson S" thread-topic: [re-ECN] Wireless aspects of the ConEx work thread-index: AcrMQlkk8EBBneHgS7ur0gNS/A/zPQ== X-Mailer: Modest 3.1 Content-Type: multipart/alternative; boundary="=-Cyp5brHa/9UIKhpoMu/R"; charset="utf-8" X-MSMail-Priority: Normal X-Priority: 3 Date: Thu, 25 Mar 2010 10:38:33 -0700 Message-ID: <1269538713.4362.35.camel@Nokia-N900-51-1> MIME-Version: 1.0 X-OriginalArrivalTime: 25 Mar 2010 17:41:47.0458 (UTC) FILETIME=[7151E220:01CACC42] Cc: re-ecn@ietf.org Subject: Re: [re-ECN] Wireless aspects of the ConEx work X-BeenThere: re-ecn@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: philip.eardley@bt.com List-Id: re-inserted explicit congestion notification List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 25 Mar 2010 17:43:35 -0000 --=-Cyp5brHa/9UIKhpoMu/R Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=utf-8 Content-ID: <1269538713.4362.32.camel@Nokia-N900-51-1> Hi Bo, The charter wasnt supposed to be limited to wireless. I remember that prompted by ingemar's I-D of a few month's ago we thought briefly about the wireless case and couldnt see what specifically needed changing in the proposed work items best wishes phil ----- Original message ----- > Hi Bo, > > Looking at http://www.ietf.org/iesg/evaluation/conex-charter.txt, I > don't see the current charter limiting the scope to fixed networks. > > (Could not follow the on-line discussions this week though). > > I agree that it should not be constrained to specific systems (or even > L2 technologies). > > There is an applicability statement document on the charter, which is > fine. > > Best regards, > > Dirk > > > -- > NEC Laboratories Europe > > NEC Europe Limited | Registered Office: NEC House, 1 Victoria Road, > London W3 6BL | Registered in England 2832014 > > > > > > > > -----Original Message----- > > From: re-ecn-bounces@ietf.org [mailto:re-ecn-bounces@ietf.org] On > > Behalf Of bo zhou > > Sent: Thursday, March 25, 2010 5:06 PM > > To: Ingemar Johansson S > > Cc: re-ecn@ietf.org > > Subject: Re: [re-ECN] Wireless aspects of the ConEx work > > > > Hi All, > > > > What Ingemar mentioned sounds reasonable. > > I am worry about current charter defined E2E focus on fixed network > > only. I believe in the future, E2E Internet traffic will be found more > > in wireless/mobile network rather than fixed network (maybe my > > prediction is wrong, but who knows). In such way, we can predict the > > bottleneck will be happened in air interface and mobile backhaul > rather > > than bearer network, not prediction result, it happened today. > > I believe Congestion Exposure is a good and right idea working as a WG > > in IETF. But only cover fixed network is not enough, especially mobile > > Internet traffic raise up very quickly these years. > > Shall we consider wireless/mobile network congestion in the scope? > > > > Regards, > > > > Bo > > > > > > > > On Thu, Mar 25, 2010 at 8:59 AM, Ingemar Johansson S > > wrote: > > > > > > Hi > > > > As a followup to my comment at the mike at todays re-BoF :-) > > > > The document that discusses congestion as seen from a wireless > > access perspective > > http://tools.ietf.org/id/draft-johansson-wireless-congestion- > > properties-00.txt > > This document was written as a kind of input to the Conex work a > > few months ago. > > > > Regards > > Ingemar > > ================================= > > INGEMAR JOHANSSON M.Sc. > > Senior Research Engineer > > > > Ericsson AB > > Multimedia Technologies > > Labratoriegränd 11 > > 971 28, Luleå, Sweden > > Phone +46-1071 43042 > > SMS/MMS +46-73 078 3289 > > ingemar.s.johansson@ericsson.com > > www.ericsson.com > > Visit http://labs.ericsson.com ! > > ================================= > > _______________________________________________ > > re-ECN mailing list > > re-ECN@ietf.org > > https://www.ietf.org/mailman/listinfo/re-ecn > > > > > > > > > > > > -- > > Regards, > > > > Bo Zhou > > China Mobile > > _______________________________________________ > re-ECN mailing list > re-ECN@ietf.org > https://www.ietf.org/mailman/listinfo/re-ecn > --=-Cyp5brHa/9UIKhpoMu/R Content-Transfer-Encoding: 7bit Content-Type: text/html; charset=utf-8 Content-ID: <1269538713.4362.34.camel@Nokia-N900-51-1>

Hi Bo,
The charter wasnt supposed to be limited to wireless. I remember that prompted by ingemar's I-D of a few month's ago we thought briefly about the wireless case and couldnt see what specifically needed changing in the proposed work items
best wishes
phil
----- Original message -----
> Hi Bo,
>
> Looking at http://www.ietf.org/iesg/evaluation/conex-charter.txt, I
> don't see the current charter limiting the scope to fixed networks.
>
> (Could not follow the on-line discussions this week though).
>
> I agree that it should not be constrained to specific systems (or even
> L2 technologies).
>
> There is an applicability statement document on the charter, which is
> fine.
>
> Best regards,
>
> Dirk
>
>
> --
> NEC Laboratories Europe
>
> NEC Europe Limited | Registered Office: NEC House, 1 Victoria Road,
> London W3 6BL | Registered in England 2832014
>
>
>
>
>
>
> > -----Original Message-----
> > From: re-ecn-bounces@ietf.org [mailto:re-ecn-bounces@ietf.org] On
> > Behalf Of bo zhou
> > Sent: Thursday, March 25, 2010 5:06 PM
> > To: Ingemar Johansson S
> > Cc: re-ecn@ietf.org
> > Subject: Re: [re-ECN] Wireless aspects of the ConEx work
> >
> > Hi All,
> >
> > What Ingemar mentioned sounds reasonable.
> > I am worry about current charter defined E2E focus on fixed network
> > only. I believe in the future, E2E Internet traffic will be found more
> > in wireless/mobile network rather than fixed network (maybe my
> > prediction is wrong, but who knows). In such way, we can predict the
> > bottleneck will be happened in air interface and mobile backhaul
> rather
> > than bearer network, not prediction result, it happened today.
> > I believe Congestion Exposure is a good and right idea working as a WG
> > in IETF. But only cover fixed network is not enough, especially mobile
> > Internet traffic raise up very quickly these years.
> > Shall we consider wireless/mobile network congestion in the scope?
> >
> > Regards,
> >
> > Bo
> >
> >
> >
> > On Thu, Mar 25, 2010 at 8:59 AM, Ingemar Johansson S
> > <ingemar.s.johansson@ericsson.com> wrote:
> >
> >
> > Hi
> >
> > As a followup to my comment at the mike at todays re-BoF :-)
> >
> > The document that discusses congestion as seen from a wireless
> > access perspective
> > http://tools.ietf.org/id/draft-johansson-wireless-congestion-
> > properties-00.txt
> > This document was written as a kind of input to the Conex work a
> > few months ago.
> >
> > Regards
> > Ingemar
> > =================================
> > INGEMAR JOHANSSON M.Sc.
> > Senior Research Engineer
> >
> > Ericsson AB
> > Multimedia Technologies
> > Labratoriegränd 11
> > 971 28, Luleå, Sweden
> > Phone +46-1071 43042
> > SMS/MMS +46-73 078 3289
> > ingemar.s.johansson@ericsson.com
> > www.ericsson.com <http://www.ericsson.com/>;
> > Visit http://labs.ericsson.com <http://labs.ericsson.com/>; !
> > =================================
> > _______________________________________________
> > re-ECN mailing list
> > re-ECN@ietf.org
> > https://www.ietf.org/mailman/listinfo/re-ecn
> >
> >
> >
> >
> >
> > --
> > Regards,
> >
> > Bo Zhou
> > China Mobile
>
> _______________________________________________
> re-ECN mailing list
> re-ECN@ietf.org
> https://www.ietf.org/mailman/listinfo/re-ecn
>

--=-Cyp5brHa/9UIKhpoMu/R-- From Dirk.Kutscher@nw.neclab.eu Thu Mar 25 10:43:38 2010 Return-Path: X-Original-To: re-ecn@core3.amsl.com Delivered-To: re-ecn@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 52E9C3A6E2E for ; Thu, 25 Mar 2010 10:43:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.131 X-Spam-Level: * X-Spam-Status: No, score=1.131 tagged_above=-999 required=5 tests=[BAYES_50=0.001, DNS_FROM_OPENWHOIS=1.13] 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 8fGEpOxhHnhQ for ; Thu, 25 Mar 2010 10:43:36 -0700 (PDT) Received: from smtp0.neclab.eu (smtp0.neclab.eu [195.37.70.41]) by core3.amsl.com (Postfix) with ESMTP id E61A73A6DEF for ; Thu, 25 Mar 2010 10:41:26 -0700 (PDT) Received: from localhost (localhost.localdomain [127.0.0.1]) by smtp0.neclab.eu (Postfix) with ESMTP id DD19F2C000C17; Thu, 25 Mar 2010 18:41:48 +0100 (CET) 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 LsXxsqBEkqcS; Thu, 25 Mar 2010 18:41:48 +0100 (CET) Received: from VENUS.office (mx1.office [192.168.24.3]) by smtp0.neclab.eu (Postfix) with ESMTP id BE76A2C000C15; Thu, 25 Mar 2010 18:41:33 +0100 (CET) X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Thu, 25 Mar 2010 18:41:32 +0100 Message-ID: <547F018265F92642B577B986577D671C012A377F@VENUS.office> In-reply-to: <548FC4B9D57A4043AAFFE888A39429031D01FA59BC@ESESSCMS0356.eemea.ericsson.se> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [re-ECN] Call for Comments:draft-livingood-woundy-congestion-mgmt-03 Thread-Index: Acqr/UYLBg6/Vo3LSmSbUP2chJ/RdQEmXa8wBXLRP4AABnj5sAFucgxwAAEFpZAAAc4VMA== References: <548FC4B9D57A4043AAFFE888A39429031CEF85F7D4@ESESSCMS0356.eemea.ericsson.se> <548FC4B9D57A4043AAFFE888A39429031D01F3ED65@ESESSCMS0356.eemea.ericsson.se> <547F018265F92642B577B986577D671C012A3768@VENUS.office> <548FC4B9D57A4043AAFFE888A39429031D01FA59BC@ESESSCMS0356.eemea.ericsson.se> From: "Dirk Kutscher" To: "Ingemar Johansson S" , "Woundy, Richard" , Subject: Re: [re-ECN] Call for Comments:draft-livingood-woundy-congestion-mgmt-03 X-BeenThere: re-ecn@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: re-inserted explicit congestion notification List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 25 Mar 2010 17:43:38 -0000 Hi Ingemar, yes, I agree to that. Not sure whether this difference between short and = long time scale is really relevant, but the difficult-to-reach user is a = good motivation for a different way of resource sharing that is not = based on proportional fairness. It is a different question though whether the topic of how congestion is = assessed for certain link layer technology network element is relevant = for Conex standardization work -- it may actually be orthogonal. Best regards, Dirk > -----Original Message----- > From: Ingemar Johansson S [mailto:ingemar.s.johansson@ericsson.com] > Sent: Thursday, March 25, 2010 5:51 PM > To: Dirk Kutscher; Woundy, Richard; re-ecn@ietf.org > Cc: Ingemar Johansson S > Subject: RE: [re-ECN] Call for Comments:draft-livingood-woundy- > congestion-mgmt-03 >=20 > Hi >=20 > My personal views, I guess this can be debated quite alot depending on > which principle is the best. > I would agree that ConEx is a challenge against scheduler enforced > "fair sharing" if one look at it on a short (second by second) time > scale. However I for instance see good reasons for a user to halt a > large download if e.g the coverage is poor, it is then better to use > the available capacity to more prioritized tasks. > Seen from a (large aggregate of users) I would belive that the best > total troughput over a longer timescale is acheived if throughput to > "hard to reach" users is limited, the simple reason is that these = users > likely cost a lot in terms of transmission power. If endpoints are = made > aware of these rules they can themselves prioritize what the temporary > thorughput should be used for. I believe that would fit well with the > ConEx way of looking at fairness. > Hope I got this clear (translating thoughts from swedish to english is > not my stongest asset:-) >=20 > Regards > Ingemar >=20 > > -----Original Message----- > > From: Dirk Kutscher [mailto:Dirk.Kutscher@nw.neclab.eu] > > Sent: den 25 mars 2010 09:33 > > To: Ingemar Johansson S; Woundy, Richard; re-ecn@ietf.org > > Subject: RE: [re-ECN] Call for > > Comments:draft-livingood-woundy-congestion-mgmt-03 > > > > Hi Ingemar, > > > > I agree that from today's perspective on 3GPP's QoS concepts, > > Conex appears to be mainly relevant for non-GBR (best-effort) > > traffic. However, considering traffic volume, non-GBR might > > already by the dominant QoS class (by far). > > > > Moreover, from a different perspective though, congestion > > exposure (and transport & application layer adaptation) could > > render strict QoS classes a bit less interesting, so that > > non-GBR will be the default. > > > > Concerning scheduler-enforced "fair sharing", I am not sure > > whether this is really the objective, because the whole > > congestion exposure approach is actually challenging fair sharing. > > > > In summary, I would propose to certainly consider current QoS > > bearer concept in specific architectures such as LTE/SAE, > > without constraining the Conex work too much. > > > > Best regards, > > > > Dirk > > > > -- > > NEC Laboratories Europe > > > > NEC Europe Limited | Registered Office: NEC House, 1 Victoria > > Road, London W3 6BL | Registered in England 2832014 > > > > > > > > > > > > > > > > > -----Original Message----- > > > From: re-ecn-bounces@ietf.org [mailto:re-ecn-bounces@ietf.org] On > > > Behalf Of Ingemar Johansson S > > > Sent: Thursday, March 18, 2010 11:02 AM > > > To: Woundy, Richard; re-ecn@ietf.org > > > Cc: Ingemar Johansson S > > > Subject: Re: [re-ECN] Call for Comments:draft-livingood-woundy- > > > congestion-mgmt-03 > > > > > > Hi > > > > > > I don't believe wireless ISP's sell different bandwidths at > > least when > > > it comes to shared access like HSPA or LTE. This depends a > > little if > > > we are talking GBR* or non-GBR bearers. > > > I would belive that we in this group talk mainly about > > non-GBR bearers > > > which in IETF language translates to Best Effort or DF. As > > the non-GBR > > > QCIs** have the lowest prio they will yield to GBR traffic, > > it comes > > > quite natural then that the per-device bandwidth for best effort > > > traffic will then vary dependent on factors such as deployment, > > > coverage, amount of higher priority traffic and number of > > concurrent > > > users. > > > > > > *GBR =3D Guaranteed Bit Rate, IMS VoIP will typically use a > > GBR bearer > > > which will strive as mcuh as possible to guarantee a given = bitrate, > > > regardless of the conditions, see link below for a more nuanced > > > definition. > > > > > > **QCI =3D QoS Class Indentifier 3GPP TS 23.203 table 6.1.7 > > > http://www.3gpp.org/ftp/Specs/archive/23_series/23.203/23203- > 930.zip > > > > > > PS.. It is not to me totally clear that ConEx is needed > > with the above > > > arrangement as the scheduling will likely ensure that devices will > > > share the limited bandwidth pool in a fair way. What ConEx may be > > > helpful with is to make the device aware on the congestion > > it causes > > > and also to distribute its limited share of bandwidth > > between flows in > > > the smartest way. We also have the potential issue with DoS > > (or DDoS) > > > attacks but I am not clear here how ConEx is helpful here. > > > > > > Regards > > > Ingemar > > > > > > > -----Original Message----- > > > > From: Woundy, Richard [mailto:Richard_Woundy@cable.comcast.com] > > > > Sent: den 18 mars 2010 07:27 > > > > To: Ingemar Johansson S; re-ecn@ietf.org > > > > Subject: RE: [re-ECN] Call for > > > > Comments:draft-livingood-woundy-congestion-mgmt-03 > > > > > > > > Ingemar, > > > > > > > > A belated thanks for the feedback. :) > > > > > > > > Let me see if I can re-state your points below. First, the > > > > per-device wireless capacity may vary dynamically based on = signal > > > > quality (with impacts due to distance, interference), so > > it may be > > > > difficult to assess how a single subscriber contributes to > > > > congestion for a single access node or base station. Second, = with > > > > wireless handoffs for mobility, it may be the case that a > > subscriber > > > > contributes to congestion on one node/station but not the > > subsequent > > > > one. Is that correct? > > > > > > > > Are wireless ISPs selling different bandwidth tiers? Other than > > > > distinguishing 2.5G vs 3G vs 4G service? > > > > > > > > -- Rich > > > > > > > > -----Original Message----- > > > > From: re-ecn-bounces@ietf.org > > > > [mailto:re-ecn-bounces@ietf.org] On Behalf Of Ingemar Johansson = S > > > > Sent: Thursday, February 18, 2010 7:55 AM > > > > To: re-ecn@ietf.org > > > > Subject: Re: [re-ECN] Call for > > > > Comments:draft-livingood-woundy-congestion-mgmt-03 > > > > > > > > Hi > > > > > > > > Thanks for the report. > > > > I read through it but did perhaps not get all the details. > > > > As far as I understand it the concept builds upon the fact that > > > > users have a provisionedbandwith, say 10Mbps in e.g the > > downlink. > > > > Once congetsion sets in the network the congestion manager will > > > > enforce some special treatment on flows that consumes data with = a > > > > bitrate that is larger than e.g 80% of their provisioned > > bandwidth > > > > over a given amount of time. > > > > > > > > The problem I see is that, when I try to transform this > > concept to > > > > wirless access, is that it is in general difficult to > > talk about a > > > > provisioned bandwidth for best effort traffic esp. over a > > multiuser > > > > wireless network with mobility support. > > > > The 10Mbs, 1.4Mbs or whatever figures written in boldface on the > > > > boxes are in reality limited by the laws of physics. > > > > In addition, whatever provisioned bandwidth that one may = possibly > > > > come up with is likely to change over time due to changed radio > > > > conditions or handover between different access types. > > The thing I > > > > find attractive with ConEx is that it has potential to > > work in these > > > > scenarios, the question is of course if the problem needs > > a solution > > > > like ConEx... > > > > > > > > It is possible that I miss some details here, please enlighten = me. > > > > > > > > Regards > > > > Ingeamr > > > > > > > > > > > > > > > -------------------------------------------------------------------- > > > > - > > > - > > > > > > > > > > Message: 1 > > > > > Date: Fri, 12 Feb 2010 10:38:49 -0500 > > > > > From: Jason Livingood > > > > > Subject: [re-ECN] Call for Comments: > > > > > draft-livingood-woundy-congestion-mgmt-03 > > > > > To: > > > > > Message-ID: > > > > > Content-Type: text/plain; charset=3D"us-ascii" > > > > > > > > > > This is a call for comments on an individual draft regarding a > > > > > protocol-agnostic congestion management system, which > > is related > > > > > to some of the reason that Conex is starting up. I and my > > > > > co-authors would like feedback on the latest revision of this > > > > > draft at > > > > > > > > > > > = http://tools.ietf.org/html/draft-livingood-woundy-congestion-mgmt-03. > > > > > > > > > > If you have any comments, please send them to me privately for > > > > > consideration. > > > > > > > > > > Thank you, > > > > > Jason > > > > > > > > > > -------------- next part -------------- An HTML attachment was > > > > > scrubbed... > > > > > URL: > > > > > > > > > 212/99c6f607/attachment.htm> > > > > > > > > > > ------------------------------ > > > > > > > > > > _______________________________________________ > > > > > re-ECN mailing list > > > > > re-ECN@ietf.org > > > > > https://www.ietf.org/mailman/listinfo/re-ecn > > > > > > > > > > > > > > > End of re-ECN Digest, Vol 12, Issue 24 > > > > > ************************************** > > > > > > > > > _______________________________________________ > > > > re-ECN mailing list > > > > re-ECN@ietf.org > > > > https://www.ietf.org/mailman/listinfo/re-ecn > > > > > > > _______________________________________________ > > > re-ECN mailing list > > > re-ECN@ietf.org > > > https://www.ietf.org/mailman/listinfo/re-ecn > > From zhouboyj@gmail.com Thu Mar 25 10:45:37 2010 Return-Path: X-Original-To: re-ecn@core3.amsl.com Delivered-To: re-ecn@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 8DFE33A6E2E for ; Thu, 25 Mar 2010 10:45:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.576 X-Spam-Level: X-Spam-Status: No, score=0.576 tagged_above=-999 required=5 tests=[AWL=-0.555, BAYES_50=0.001, DNS_FROM_OPENWHOIS=1.13, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Pda5KH+m5fns for ; Thu, 25 Mar 2010 10:45:35 -0700 (PDT) Received: from mail-px0-f192.google.com (mail-px0-f192.google.com [209.85.216.192]) by core3.amsl.com (Postfix) with ESMTP id 2745A3A6878 for ; Thu, 25 Mar 2010 10:44:03 -0700 (PDT) Received: by pxi30 with SMTP id 30so6236674pxi.20 for ; Thu, 25 Mar 2010 10:44:22 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:in-reply-to:references :date:message-id:subject:from:to:cc:content-type; bh=zJBdiQruH7UlOAKqwoxcyD0L7mXQHfbsNzbK6tQYmo0=; b=l8C8KzE+1ug9y7R2QEZ3yXzzHtbEQHUQGx5fDuCucos6yemj7WP3ZbOXB5njywIr1i vmAjSCNiEIBFsQuiv9IGYY4JAAU1X2oIFg3w2CcLdKYEUowrgrZaRRwXadmYSartCjSt Pa5V+OVjrHzSKWfEGhDk8dbGKLdNsrHwq7Aoo= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; b=rEKxlXl7xumEdbj1PEw8aE5n+JslBZev3eD5LDBJRUkSXRDPcKlJJFsn5Z8JzdW574 I0biU0dwczR78PTTvYLmW1Ju7PVubpEY3itULwOH/HcytsCdMml65ShLN3FW2EzbswVL zDoEHh1EUmIPlu/oBCBNzrYKR097a+dHPjBZU= MIME-Version: 1.0 Received: by 10.140.57.2 with SMTP id f2mr6326675rva.210.1269539062327; Thu, 25 Mar 2010 10:44:22 -0700 (PDT) In-Reply-To: <793F49BA1FC821409F99F10862A0E4DB06454596@FHDP1LUMXCV14.us.one.verizon.com> References: <548FC4B9D57A4043AAFFE888A39429031CEF85F7D4@ESESSCMS0356.eemea.ericsson.se> <548FC4B9D57A4043AAFFE888A39429031D01F3ED65@ESESSCMS0356.eemea.ericsson.se> <547F018265F92642B577B986577D671C012A3768@VENUS.office> <548FC4B9D57A4043AAFFE888A39429031D01FA59BC@ESESSCMS0356.eemea.ericsson.se> <793F49BA1FC821409F99F10862A0E4DB06454596@FHDP1LUMXCV14.us.one.verizon.com> Date: Fri, 26 Mar 2010 01:44:22 +0800 Message-ID: <36a593231003251044w2002221fr4bd2ae763a5e4ec3@mail.gmail.com> From: bo zhou To: "Mcdysan, David E" Content-Type: multipart/alternative; boundary=001636b2b01cd6a9bb0482a398e0 Cc: Ingemar Johansson S , "Woundy, Richard" , re-ecn@ietf.org, Dirk Kutscher Subject: Re: [re-ECN] Call for Comments:draft-livingood-woundy-congestion-mgmt-03 X-BeenThere: re-ecn@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: re-inserted explicit congestion notification List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 25 Mar 2010 17:45:37 -0000 --001636b2b01cd6a9bb0482a398e0 Content-Type: text/plain; charset=ISO-8859-1 Hi David, Inline. On Fri, Mar 26, 2010 at 1:17 AM, Mcdysan, David E wrote: > Hi, > > My personal view. The sort of time shifting behavior that a user, > content provider, or delivery mechanism (e.g., P2P) could make use of > exposed congestion feedback are all examples of what I see as an > important goal of Conex. > I recently joined this list and am catching up on the history. However, > I believe Ingemar brings up an important point that "Congestion" is not > only due to queuing, but can be caused by other conditions (e.g., > changing radio coverage as a mobile device moves about). > [bo] Support you. Congestions in mobile network have been investigated in air interface and mobile backhaul more than in bearer network. Regards, Bo Zhou > > Dave > > > -----Original Message----- > > From: re-ecn-bounces@ietf.org > > [mailto:re-ecn-bounces@ietf.org] On Behalf Of Ingemar Johansson S > > Sent: Thursday, March 25, 2010 12:51 PM > > To: Dirk Kutscher; Woundy, Richard; re-ecn@ietf.org > > Cc: Ingemar Johansson S > > Subject: Re: [re-ECN] Call for > > Comments:draft-livingood-woundy-congestion-mgmt-03 > > > > Hi > > > > My personal views, I guess this can be debated quite alot > > depending on which principle is the best. > > I would agree that ConEx is a challenge against scheduler > > enforced "fair sharing" if one look at it on a short (second > > by second) time scale. However I for instance see good > > reasons for a user to halt a large download if e.g the > > coverage is poor, it is then better to use the available > > capacity to more prioritized tasks. > > Seen from a (large aggregate of users) I would belive that > > the best total troughput over a longer timescale is acheived > > if throughput to "hard to reach" users is limited, the simple > > reason is that these users likely cost a lot in terms of > > transmission power. If endpoints are made aware of these > > rules they can themselves prioritize what the temporary > > thorughput should be used for. I believe that would fit well > > with the ConEx way of looking at fairness. > > Hope I got this clear (translating thoughts from swedish to > > english is not my stongest asset:-) > > > > Regards > > Ingemar > > > > > -----Original Message----- > > > From: Dirk Kutscher [mailto:Dirk.Kutscher@nw.neclab.eu] > > > Sent: den 25 mars 2010 09:33 > > > To: Ingemar Johansson S; Woundy, Richard; re-ecn@ietf.org > > > Subject: RE: [re-ECN] Call for > > > Comments:draft-livingood-woundy-congestion-mgmt-03 > > > > > > Hi Ingemar, > > > > > > I agree that from today's perspective on 3GPP's QoS concepts, Conex > > > appears to be mainly relevant for non-GBR (best-effort) traffic. > > > However, considering traffic volume, non-GBR might already by the > > > dominant QoS class (by far). > > > > > > Moreover, from a different perspective though, congestion exposure > > > (and transport & application layer adaptation) could render > > strict QoS > > > classes a bit less interesting, so that non-GBR will be the default. > > > > > > Concerning scheduler-enforced "fair sharing", I am not sure whether > > > this is really the objective, because the whole congestion exposure > > > approach is actually challenging fair sharing. > > > > > > In summary, I would propose to certainly consider current > > QoS bearer > > > concept in specific architectures such as LTE/SAE, without > > > constraining the Conex work too much. > > > > > > Best regards, > > > > > > Dirk > > > > > > -- > > > NEC Laboratories Europe > > > > > > NEC Europe Limited | Registered Office: NEC House, 1 Victoria Road, > > > London W3 6BL | Registered in England 2832014 > > > > > > > > > > > > > > > > > > > > > > > > > -----Original Message----- > > > > From: re-ecn-bounces@ietf.org [mailto:re-ecn-bounces@ietf.org] On > > > > Behalf Of Ingemar Johansson S > > > > Sent: Thursday, March 18, 2010 11:02 AM > > > > To: Woundy, Richard; re-ecn@ietf.org > > > > Cc: Ingemar Johansson S > > > > Subject: Re: [re-ECN] Call for Comments:draft-livingood-woundy- > > > > congestion-mgmt-03 > > > > > > > > Hi > > > > > > > > I don't believe wireless ISP's sell different bandwidths at > > > least when > > > > it comes to shared access like HSPA or LTE. This depends a > > > little if > > > > we are talking GBR* or non-GBR bearers. > > > > I would belive that we in this group talk mainly about > > > non-GBR bearers > > > > which in IETF language translates to Best Effort or DF. As > > > the non-GBR > > > > QCIs** have the lowest prio they will yield to GBR traffic, > > > it comes > > > > quite natural then that the per-device bandwidth for best effort > > > > traffic will then vary dependent on factors such as deployment, > > > > coverage, amount of higher priority traffic and number of > > > concurrent > > > > users. > > > > > > > > *GBR = Guaranteed Bit Rate, IMS VoIP will typically use a > > > GBR bearer > > > > which will strive as mcuh as possible to guarantee a > > given bitrate, > > > > regardless of the conditions, see link below for a more nuanced > > > > definition. > > > > > > > > **QCI = QoS Class Indentifier 3GPP TS 23.203 table 6.1.7 > > > > > > http://www.3gpp.org/ftp/Specs/archive/23_series/23.203/23203-930.zip > > > > > > > > PS.. It is not to me totally clear that ConEx is needed > > > with the above > > > > arrangement as the scheduling will likely ensure that > > devices will > > > > share the limited bandwidth pool in a fair way. What ConEx may be > > > > helpful with is to make the device aware on the congestion > > > it causes > > > > and also to distribute its limited share of bandwidth > > > between flows in > > > > the smartest way. We also have the potential issue with DoS > > > (or DDoS) > > > > attacks but I am not clear here how ConEx is helpful here. > > > > > > > > Regards > > > > Ingemar > > > > > > > > > -----Original Message----- > > > > > From: Woundy, Richard [mailto:Richard_Woundy@cable.comcast.com] > > > > > Sent: den 18 mars 2010 07:27 > > > > > To: Ingemar Johansson S; re-ecn@ietf.org > > > > > Subject: RE: [re-ECN] Call for > > > > > Comments:draft-livingood-woundy-congestion-mgmt-03 > > > > > > > > > > Ingemar, > > > > > > > > > > A belated thanks for the feedback. :) > > > > > > > > > > Let me see if I can re-state your points below. First, the > > > > > per-device wireless capacity may vary dynamically based > > on signal > > > > > quality (with impacts due to distance, interference), so > > > it may be > > > > > difficult to assess how a single subscriber contributes to > > > > > congestion for a single access node or base station. > > Second, with > > > > > wireless handoffs for mobility, it may be the case that a > > > subscriber > > > > > contributes to congestion on one node/station but not the > > > subsequent > > > > > one. Is that correct? > > > > > > > > > > Are wireless ISPs selling different bandwidth tiers? Other than > > > > > distinguishing 2.5G vs 3G vs 4G service? > > > > > > > > > > -- Rich > > > > > > > > > > -----Original Message----- > > > > > From: re-ecn-bounces@ietf.org > > > > > [mailto:re-ecn-bounces@ietf.org] On Behalf Of Ingemar > > Johansson S > > > > > Sent: Thursday, February 18, 2010 7:55 AM > > > > > To: re-ecn@ietf.org > > > > > Subject: Re: [re-ECN] Call for > > > > > Comments:draft-livingood-woundy-congestion-mgmt-03 > > > > > > > > > > Hi > > > > > > > > > > Thanks for the report. > > > > > I read through it but did perhaps not get all the details. > > > > > As far as I understand it the concept builds upon the fact that > > > > > users have a provisioned bandwith, say 10Mbps in e.g the > > > downlink. > > > > > Once congetsion sets in the network the congestion manager will > > > > > enforce some special treatment on flows that consumes > > data with a > > > > > bitrate that is larger than e.g 80% of their provisioned > > > bandwidth > > > > > over a given amount of time. > > > > > > > > > > The problem I see is that, when I try to transform this > > > concept to > > > > > wirless access, is that it is in general difficult to > > > talk about a > > > > > provisioned bandwidth for best effort traffic esp. over a > > > multiuser > > > > > wireless network with mobility support. > > > > > The 10Mbs, 1.4Mbs or whatever figures written in > > boldface on the > > > > > boxes are in reality limited by the laws of physics. > > > > > In addition, whatever provisioned bandwidth that one > > may possibly > > > > > come up with is likely to change over time due to changed radio > > > > > conditions or handover between different access types. > > > The thing I > > > > > find attractive with ConEx is that it has potential to > > > work in these > > > > > scenarios, the question is of course if the problem needs > > > a solution > > > > > like ConEx... > > > > > > > > > > It is possible that I miss some details here, please > > enlighten me. > > > > > > > > > > Regards > > > > > Ingeamr > > > > > > > > > > > > > > > > > > > -------------------------------------------------------------------- > > > > > - > > > > - > > > > > > > > > > > > Message: 1 > > > > > > Date: Fri, 12 Feb 2010 10:38:49 -0500 > > > > > > From: Jason Livingood > > > > > > Subject: [re-ECN] Call for Comments: > > > > > > draft-livingood-woundy-congestion-mgmt-03 > > > > > > To: > > > > > > Message-ID: > > > > > > > > Content-Type: text/plain; charset="us-ascii" > > > > > > > > > > > > This is a call for comments on an individual draft > > regarding a > > > > > > protocol-agnostic congestion management system, which > > > is related > > > > > > to some of the reason that Conex is starting up. I and my > > > > > > co-authors would like feedback on the latest revision of this > > > > > > draft at > > > > > > > > > > > > > > > > http://tools.ietf.org/html/draft-livingood-woundy-congestion-mgmt-03. > > > > > > > > > > > > If you have any comments, please send them to me > > privately for > > > > > > consideration. > > > > > > > > > > > > Thank you, > > > > > > Jason > > > > > > > > > > > > -------------- next part -------------- An HTML > > attachment was > > > > > > scrubbed... > > > > > > URL: > > > > > > > > > > > 212/99c6f607/attachment.htm> > > > > > > > > > > > > ------------------------------ > > > > > > > > > > > > _______________________________________________ > > > > > > re-ECN mailing list > > > > > > re-ECN@ietf.org > > > > > > https://www.ietf.org/mailman/listinfo/re-ecn > > > > > > > > > > > > > > > > > > End of re-ECN Digest, Vol 12, Issue 24 > > > > > > ************************************** > > > > > > > > > > > _______________________________________________ > > > > > re-ECN mailing list > > > > > re-ECN@ietf.org > > > > > https://www.ietf.org/mailman/listinfo/re-ecn > > > > > > > > > _______________________________________________ > > > > re-ECN mailing list > > > > re-ECN@ietf.org > > > > https://www.ietf.org/mailman/listinfo/re-ecn > > > > > _______________________________________________ > > re-ECN mailing list > > re-ECN@ietf.org > > https://www.ietf.org/mailman/listinfo/re-ecn > > > _______________________________________________ > re-ECN mailing list > re-ECN@ietf.org > https://www.ietf.org/mailman/listinfo/re-ecn > -- Regards, Bo Zhou China Mobile --001636b2b01cd6a9bb0482a398e0 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
Hi David,
=A0
Inline.

On Fri, Mar 26, 2010 at 1:17 AM, Mcdysan, David = E <dave.mc= dysan@verizon.com> wrote:
Hi,

My personal view. The= sort of time shifting behavior that a user,
content provider, or delive= ry mechanism (e.g., P2P) could make use of
exposed congestion feedback are all examples of what I see as an
importa= nt goal of Conex.

I recently joined this list = and am catching up on the history. However,
I believe Ingemar brings up = an important point that "Congestion" is not
only due to queuing, but can be caused by other conditions (e.g.,
changi= ng radio coverage as a mobile device moves about).
=A0
[bo]=A0Support you.
Congestions in mobile network=A0have been investigated=A0in air interf= ace and mobile backhaul more than in bearer network.
=A0
Regards,
=A0
Bo Zhou
=A0

Dave

> -----Original Message-----
> From: re-ecn-bounces@ietf.org
> [ma= ilto:re-ecn-bounces@ietf.org= ] On Behalf Of Ingemar Johansson S
> Sent: Thursday, March 25, 2010 12:51 PM
> To: = Dirk Kutscher; Woundy, Richard; re-ecn@i= etf.org
> Cc: Ingemar Johansson S
> Subject: Re: [re-ECN] C= all for
> Comments:draft-livingood-woundy-congestion-mgmt-03
>
> Hi<= br>>
> My personal views, I guess this can be debated quite alot> depending on which principle is the best.
> I would agree that= ConEx is a challenge against scheduler
> enforced "fair sharing" if one look at it on a short (second=
> by second) time scale. However I for instance see good
> rea= sons for a user to halt a large download if e.g the
> coverage is poo= r, it is then better to use the available
> capacity to more prioritized tasks.
> Seen from a (large aggrega= te of users) I would belive that
> the best total troughput over a lo= nger timescale is acheived
> if throughput to "hard to reach&quo= t; users is limited, the simple
> reason is that these users likely cost a lot in terms of
> trans= mission power. If endpoints are made aware of these
> rules they can = themselves prioritize what the temporary
> thorughput should be used = for. I believe that would fit well
> with the ConEx way of looking at fairness.
> Hope I got this cle= ar (translating thoughts from swedish to
> english is not my stongest= asset:-)
>
> Regards
> Ingemar
>
> > ----= -Original Message-----
> > From: Dirk Kutscher [mailto:Dirk.Kutscher@nw.neclab.eu]
> > Sent: den 25 mars 201= 0 09:33
> > To: Ingemar Johansson S; Woundy, Richard; re-ecn@ietf.org
> > Subject: RE: [re-ECN] Call for
> > Comments:draft-living= ood-woundy-congestion-mgmt-03
> >
> > Hi Ingemar,
>= >
> > I agree that from today's perspective on 3GPP's = QoS concepts, Conex
> > appears to be mainly relevant for non-GBR (best-effort) traffic.<= br>> > However, considering traffic volume, non-GBR might already by = the
> > dominant QoS class (by far).
> >
> > Mor= eover, from a different perspective though, congestion exposure
> > (and transport & application layer adaptation) could render> strict QoS
> > classes a bit less interesting, so that non-= GBR will be the default.
> >
> > Concerning scheduler-enf= orced "fair sharing", I am not sure whether
> > this is really the objective, because the whole congestion exposu= re
> > approach is actually challenging fair sharing.
> >=
> > In summary, I would propose to certainly consider current
> QoS bearer
> > concept in specific architectures such as LTE/= SAE, without
> > constraining the Conex work too much.
> >= ;
> > Best regards,
> >
> > Dirk
> > > > --
> > NEC Laboratories Europe
> >
> >= NEC Europe Limited | Registered Office: NEC House, 1 Victoria Road,
>= ; > London W3 6BL | Registered in England 2832014
> >
> &= gt;
> >
> >
> >
> >
> >
> > = > -----Original Message-----
> > > From: re-ecn-bounces@ietf.org [mailto:re-ecn-bounces@ietf.org] On
> > > Behalf Of Ingemar Johansson S
> > > Sent: Thursd= ay, March 18, 2010 11:02 AM
> > > To: Woundy, Richard; re-ecn@ietf.org
> > > Cc: Ingem= ar Johansson S
> > > Subject: Re: [re-ECN] Call for Comments:draft-livingood-woun= dy-
> > > congestion-mgmt-03
> > >
> > >= ; Hi
> > >
> > > I don't believe wireless ISP&#= 39;s sell different bandwidths at
> > least when
> > > it comes to shared access like HSPA = or LTE. This depends a
> > little if
> > > we are talk= ing GBR* or non-GBR bearers.
> > > I would belive that we in th= is group talk mainly about
> > non-GBR bearers
> > > which in IETF language translat= es to Best Effort or DF. As
> > the non-GBR
> > > QCIs= ** have the lowest prio they will yield to GBR traffic,
> > it com= es
> > > quite natural then that the per-device bandwidth for best ef= fort
> > > traffic will then vary dependent on factors such as = deployment,
> > > coverage, amount of higher priority traffic a= nd number of
> > concurrent
> > > users.
> > >
> >= ; > *GBR =3D Guaranteed Bit Rate, IMS VoIP will typically use a
> = > GBR bearer
> > > which will strive as mcuh as possible to = guarantee a
> given bitrate,
> > > regardless of the conditions, see lin= k below for a more nuanced
> > > definition.
> > ><= br>> > > **QCI =3D QoS Class Indentifier 3GPP TS 23.203 table 6.1.= 7
> > >
> http://www.3gpp.org/ftp/Spec= s/archive/23_series/23.203/23203-930.zip
> > >
> >= > PS.. It is not to me totally clear that ConEx is needed
> > with the above
> > > arrangement as the scheduling wi= ll likely ensure that
> devices will
> > > share the limi= ted bandwidth pool in a fair way. What ConEx may be
> > > helpf= ul with is to make the device aware on the congestion
> > it causes
> > > and also to distribute its limited sh= are of bandwidth
> > between flows in
> > > the smarte= st way. We also have the potential issue with DoS
> > (or DDoS) > > > attacks but I am not clear here how ConEx is helpful here.> > >
> > > Regards
> > > Ingemar
>= ; > >
> > > > -----Original Message-----
> > = > > From: Woundy, Richard [mailto:Richard_Woundy@cable.comcast.com]
> > > > Sent: den 18 mars 2010 07:27
> > > > To:= Ingemar Johansson S; re-ecn@ietf.org
> > > > Subject: RE: [re-ECN] Call for
> > > &= gt; Comments:draft-livingood-woundy-congestion-mgmt-03
> > > >
> > > > Ingemar,
> > > ><= br>> > > > A belated thanks for the feedback. :)
> > &= gt; >
> > > > Let me see if I can re-state your points be= low. First, the
> > > > per-device wireless capacity may vary dynamically based=
> on signal
> > > > quality (with impacts due to dist= ance, interference), so
> > it may be
> > > > diffi= cult to assess how a single subscriber contributes to
> > > > congestion for a single access node or base station.> Second, with
> > > > wireless handoffs for mobility, i= t may be the case that a
> > subscriber
> > > > con= tributes to congestion on one node/station but not the
> > subsequent
> > > > one. Is that correct?
> &= gt; > >
> > > > Are wireless ISPs selling different ba= ndwidth tiers? Other than
> > > > distinguishing 2.5G vs 3G = vs 4G service?
> > > >
> > > > -- Rich
> > > >> > > > -----Original Message-----
> > > > Fro= m: re-ecn-bounces@ietf.org > > > > [mailto:re-e= cn-bounces@ietf.org] On Behalf Of Ingemar
> Johansson S
> &= gt; > > Sent: Thursday, February 18, 2010 7:55 AM
> > > &= gt; To: re-ecn@ietf.org
> > > > Subject: Re: [re-ECN] Call for
> > > > C= omments:draft-livingood-woundy-congestion-mgmt-03
> > > >> > > > Hi
> > > >
> > > > Thank= s for the report.
> > > > I read through it but did perhaps not get all the detai= ls.
> > > > As far as I understand it the concept builds upo= n the fact that
> > > > users have a provisioned bandwith, s= ay 10Mbps in e.g the
> > downlink.
> > > > Once congetsion sets in the netw= ork the congestion manager will
> > > > enforce some special= treatment on flows that consumes
> data with a
> > > >= ; bitrate that is larger than e.g 80% of their provisioned
> > bandwidth
> > > > over a given amount of time.
= > > > >
> > > > The problem I see is that, when = I try to transform this
> > concept to
> > > > wirl= ess access, is that it is in general difficult to
> > talk about a
> > > > provisioned bandwidth for bes= t effort traffic esp. over a
> > multiuser
> > > > = wireless network with mobility support.
> > > > The 10Mbs, 1= .4Mbs or whatever figures written in
> boldface on the
> > > > boxes are in reality limited by= the laws of physics.
> > > > In addition, whatever provisio= ned bandwidth that one
> may possibly
> > > > come up = with is likely to change over time due to changed radio
> > > > conditions or handover between different access types.<= br>> > The thing I
> > > > find attractive with ConEx = is that it has potential to
> > work in these
> > > &g= t; scenarios, the question is of course if the problem needs
> > a solution
> > > > like ConEx...
> > >= >
> > > > It is possible that I miss some details here, = please
> enlighten me.
> > > >
> > > > = Regards
> > > > Ingeamr
> > > >
> > > > &= gt;
> > > >
> > -----------------------------------= ---------------------------------
> > > > -
> > >= ; -
> > > > >
> > > > > Message: 1
> >= ; > > > Date: Fri, 12 Feb 2010 10:38:49 -0500
> > > &g= t; > From: Jason Livingood <jason_livingood@cable.comcast.com>
> > > > > Subject: [re-ECN] Call for Comments:
> > = > > > =A0 =A0 =A0 draft-livingood-woundy-congestion-mgmt-03
>= ; > > > > To: <re-ecn@iet= f.org>
> > > > > Message-ID: <C79AE039.1C01A%jason_livingood@cable.co= mcast.com>
> > > > > Content-Type: text/plain; cha= rset=3D"us-ascii"
> > > > >
> > > > > This is a call for com= ments on an individual draft
> regarding a
> > > > >= ; protocol-agnostic congestion management system, which
> > is rel= ated
> > > > > to some of the reason that Conex is starting up. = =A0I and my
> > > > > co-authors would like feedback on t= he latest revision of this
> > > > > draft at
> >= ; > > >
> > > >
> >
> http://too= ls.ietf.org/html/draft-livingood-woundy-congestion-mgmt-03.
> >= ; > > >
> > > > > If you have any comments, please send them to me> privately for
> > > > > consideration.
> >= ; > > >
> > > > > Thank you,
> > > &= gt; > Jason
> > > > >
> > > > > -------------- next pa= rt -------------- An HTML
> attachment was
> > > > >= ; scrubbed...
> > > > > URL:
> > > > > = <http://www.ietf.org/mail-archive/web/re-ecn/attachment= s/20100
> > > > > 212/99c6f607/attachment.htm>
> > > = > >
> > > > > ------------------------------
>= ; > > > >
> > > > > _________________________= ______________________
> > > > > re-ECN mailing list
> > > > > re-ECN@ietf.org
> > > >= > https://www.ietf.org/mailman/listinfo/re-ecn
> > > > >
> > > > >
> > > >= > End of re-ECN Digest, Vol 12, Issue 24
> > > > > **= ************************************
> > > > >
> &g= t; > > _______________________________________________
> > > > re-ECN mailing list
> > > > re-ECN@ietf.org
> > > > https:/= /www.ietf.org/mailman/listinfo/re-ecn
> > > >
> > > _____________________________________= __________
> > > re-ECN mailing list
> > > re-ECN@ietf.org
> > > https:/= /www.ietf.org/mailman/listinfo/re-ecn
> >
> _______________________________________________
> r= e-ECN mailing list
> re-ECN@ietf.o= rg
> https://www.ietf.org/mailman/listinfo/re-ecn
>
_______________________________________________
re-ECN mailing l= ist
re-ECN@ietf.org
https://ww= w.ietf.org/mailman/listinfo/re-ecn



--
Regards,
Bo Zhou
China Mobile
--001636b2b01cd6a9bb0482a398e0-- From zhouboyj@gmail.com Thu Mar 25 10:51:38 2010 Return-Path: X-Original-To: re-ecn@core3.amsl.com Delivered-To: re-ecn@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id CA2AB3A6E18 for ; Thu, 25 Mar 2010 10:51:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.154 X-Spam-Level: * X-Spam-Status: No, score=1.154 tagged_above=-999 required=5 tests=[AWL=-0.578, BAYES_50=0.001, DNS_FROM_OPENWHOIS=1.13, HTML_MESSAGE=0.001, J_CHICKENPOX_72=0.6] 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 CQQHhY0QixrX for ; Thu, 25 Mar 2010 10:51:37 -0700 (PDT) Received: from mail-px0-f192.google.com (mail-px0-f192.google.com [209.85.216.192]) by core3.amsl.com (Postfix) with ESMTP id 2DB233A6BBC for ; Thu, 25 Mar 2010 10:50:05 -0700 (PDT) Received: by pxi30 with SMTP id 30so6243963pxi.20 for ; Thu, 25 Mar 2010 10:50:24 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:in-reply-to:references :date:message-id:subject:from:to:cc:content-type; bh=+XWvAZROsoiwM7biaLDYk4ub/nE7D06S7eRRujpg2Oo=; b=gISEAvwkU/ywxa7AEYLo0Gja8dQDmhqFG3FFiGbZm9yZ/ByayEQUbgx5cwWDtUZx9B HsuKhHVAKxkV+riLccsn8JYLcmpVM/0Y7QZ2HCJgaKAYu8ZTtxv73NQ6PaAk9HpD1Jw+ 53m0FRLPJlY3/3grIqJDGeZWk0cuoVuuoSYkw= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; b=eyp9+weo5hQ+Vlb3CuoqJhj0UHWLb6aZSLU/8EgvF9u9sLaSS/wXUJQl/ywGHDtEWV MZZ00aXsbzpsTEW23V1V6NzHbGRFxoTGoEiYFQoEKIXfU219+AVYOiBXlNiT5FwEIJWA IJEl73Dygv8Zv3CkpGvi+mD65A/ah2cyPZcUg= MIME-Version: 1.0 Received: by 10.141.53.9 with SMTP id f9mr3425207rvk.168.1269539424677; Thu, 25 Mar 2010 10:50:24 -0700 (PDT) In-Reply-To: <1269538713.4362.35.camel@Nokia-N900-51-1> References: <1269538713.4362.35.camel@Nokia-N900-51-1> Date: Fri, 26 Mar 2010 01:50:24 +0800 Message-ID: <36a593231003251050x6c01f1e6k933355ed766bced2@mail.gmail.com> From: bo zhou To: philip.eardley@bt.com Content-Type: multipart/alternative; boundary=000e0cd290146fbaa10482a3ae3b Cc: Ingemar Johansson S , re-ecn@ietf.org, Dirk Kutscher Subject: Re: [re-ECN] Wireless aspects of the ConEx work X-BeenThere: re-ecn@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: re-inserted explicit congestion notification List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 25 Mar 2010 17:51:38 -0000 --000e0cd290146fbaa10482a3ae3b Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Hi Philip, Cool. Thank you for your clarify. Regards, Bo Zhou On Fri, Mar 26, 2010 at 1:38 AM, Eardley,PL,Philip,DEE1 R < philip.eardley@bt.com> wrote: > Hi Bo, > The charter wasnt supposed to be limited to wireless. I remember that > prompted by ingemar's I-D of a few month's ago we thought briefly about t= he > wireless case and couldnt see what specifically needed changing in the > proposed work items > best wishes > phil > ----- Original message ----- > > Hi Bo, > > > > Looking at http://www.ietf.org/iesg/evaluation/conex-charter.txt, I > > don't see the current charter limiting the scope to fixed networks. > > > > (Could not follow the on-line discussions this week though). > > > > I agree that it should not be constrained to specific systems (or even > > L2 technologies). > > > > There is an applicability statement document on the charter, which is > > fine. > > > > Best regards, > > > > Dirk > > > > > > -- > > NEC Laboratories Europe > > > > NEC Europe Limited | Registered Office: NEC House, 1 Victoria Road, > > London W3 6BL | Registered in England 2832014 > > > > > > > > > > > > > > > -----Original Message----- > > > From: re-ecn-bounces@ietf.org [mailto:re-ecn-bounces@ietf.org] > On > > > Behalf Of bo zhou > > > Sent: Thursday, March 25, 2010 5:06 PM > > > To: Ingemar Johansson S > > > Cc: re-ecn@ietf.org > > > Subject: Re: [re-ECN] Wireless aspects of the ConEx work > > > > > > Hi All, > > > > > > What Ingemar mentioned sounds reasonable. > > > I am worry about current charter defined E2E focus on fixed network > > > only. I believe in the future, E2E Internet traffic will be found mor= e > > > in wireless/mobile network rather than fixed network (maybe my > > > prediction is wrong, but who knows). In such way, we can predict the > > > bottleneck will be happened in air interface and mobile backhaul > > rather > > > than bearer network, not prediction result, it happened today. > > > I believe Congestion Exposure is a good and right idea working as a W= G > > > in IETF. But only cover fixed network is not enough, especially mobil= e > > > Internet traffic raise up very quickly these years. > > > Shall we consider wireless/mobile network congestion in the scope? > > > > > > Regards, > > > > > > Bo > > > > > > > > > > > > On Thu, Mar 25, 2010 at 8:59 AM, Ingemar Johansson S > > > wrote: > > > > > > > > > Hi > > > > > > As a followup to my comment at the mike at todays re-BoF :-) > > > > > > The document that discusses congestion as seen from a wireless > > > access perspective > > > http://tools.ietf.org/id/draft-johansson-wireless-congestion- > > > properties-00.txt > > > This document was written as a kind of input to the Conex work a > > > few months ago. > > > > > > 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. > > > Senior Research Engineer > > > > > > 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 > > 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 > > > _______________________________________________ > > > re-ECN mailing list > > > re-ECN@ietf.org > > > https://www.ietf.org/mailman/listinfo/re-ecn > > > > > > > > > > > > > > > > > > -- > > > Regards, > > > > > > Bo Zhou > > > China Mobile > > > > _______________________________________________ > > re-ECN mailing list > > re-ECN@ietf.org > > https://www.ietf.org/mailman/listinfo/re-ecn > > > > --=20 Regards, Bo Zhou China Mobile --000e0cd290146fbaa10482a3ae3b Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
Hi Philip,
=A0
Cool.
Thank you for your clarify.
=A0
Regards,
=A0
Bo Zhou

On Fri, Mar 26, 2010 at 1:38 AM, Eardley,PL,Phil= ip,DEE1 R <ph= ilip.eardley@bt.com> wrote:

Hi Bo,
The charter wasnt supposed to be limited to wireless. I remem= ber that prompted by ingemar's I-D of a few month's ago we thought = briefly about the wireless case and couldnt see what specifically needed ch= anging in the proposed work items
best wishes
phil

----- Original message -----
> Hi Bo,
> > Looking at http://www.ietf.org/iesg/evaluation/conex-charter= .txt, I
> don't see the current charter limiting the scope to fixed networks= .
>
> (Could not follow the on-line discussions this week tho= ugh).
>
> I agree that it should not be constrained to specif= ic systems (or even
> L2 technologies).
>
> There is an applicability statemen= t document on the charter, which is
> fine.
>
> Best r= egards,
>
> Dirk
>
>
> --
> NEC L= aboratories Europe
>
> NEC Europe Limited | Registered Office: NEC House, 1 Victoria= Road,
> London W3 6BL | Registered in England 2832014
>
= >
>
>
>
>
> > -----Original Messag= e-----
> > From: re-ecn-bounces@ietf.org [mailto:re-ecn-bounces@ietf.org] On
> > Behal= f Of bo zhou
> > Sent: Thursday, March 25, 2010 5:06 PM
> > To: Ingemar = Johansson S
> > Cc: re-ecn@ietf.org
> > Subject: Re: [re-ECN] Wireless as= pects of the ConEx work
> >
> > Hi All,
> >
> > What Ingemar me= ntioned sounds reasonable.
> > I am worry about current charter d= efined E2E focus on fixed network
> > only. I believe in the futu= re, E2E Internet traffic will be found more
> > in wireless/mobile network rather than fixed network (maybe my > > prediction is wrong, but who knows). In such way, we can predic= t the
> > bottleneck will be happened in air interface and mobile= backhaul
> rather
> > than bearer network, not prediction result, it ha= ppened today.
> > I believe Congestion Exposure is a good and rig= ht idea working as a WG
> > in IETF. But only cover fixed network= is not enough, especially mobile
> > Internet traffic raise up very quickly these years.
> >= Shall we consider wireless/mobile network congestion in the scope?
>= ; >
> > Regards,
> >
> > Bo
> > =
> >
> >
> > On Thu, Mar 25, 2010 at 8:59 AM, Inge= mar Johansson S
> > <ingemar.s.johansson@ericsson.com> wrote= :
> >
> >
> > Hi
> >
> > As a f= ollowup to my comment at the mike at todays re-BoF :-)
> >
&g= t; > The document that discusses congestion as seen from a wireless
> > access perspective
> > http://tools.ie= tf.org/id/draft-johansson-wireless-congestion-
> > properties= -00.txt
> > This document was written as a kind of input to the Conex work a =
> > few months ago.
> >
> > 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 J= OHANSSON M.Sc.
> > Senior Research Engineer
> >
> > 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 <http://www.ericsson.com/&gt;
> > Visit htt= p://labs.ericsson.com <http://labs.ericsson.com/&gt; !
> > =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
> > _______________________________________________
> > re-ECN mailing list
> > re-ECN@ietf.org
> > <= a href=3D"https://www.ietf.org/mailman/listinfo/re-ecn" target=3D"_blank">h= ttps://www.ietf.org/mailman/listinfo/re-ecn
> >
> >
> >
> >
> >
> = > --
> > Regards,
> >
> > Bo Zhou
>= > China Mobile
>
> ________________________________= _______________
> re-ECN mailing list
> re-ECN@ietf.org
> https://www.ietf= .org/mailman/listinfo/re-ecn
>




--
Regard= s,

Bo Zhou
China Mobile
--000e0cd290146fbaa10482a3ae3b-- From ingemar.s.johansson@ericsson.com Thu Mar 25 10:52:00 2010 Return-Path: X-Original-To: re-ecn@core3.amsl.com Delivered-To: re-ecn@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 0263A3A6B4F for ; Thu, 25 Mar 2010 10:52:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.701 X-Spam-Level: * X-Spam-Status: No, score=1.701 tagged_above=-999 required=5 tests=[AWL=-1.085, BAYES_40=-0.185, DNS_FROM_OPENWHOIS=1.13, HTML_MESSAGE=0.001, J_CHICKENPOX_72=0.6, SARE_LWSHORTT=1.24] 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 3fozlzCg7obY for ; Thu, 25 Mar 2010 10:51:58 -0700 (PDT) Received: from mailgw9.se.ericsson.net (mailgw9.se.ericsson.net [193.180.251.57]) by core3.amsl.com (Postfix) with ESMTP id B20983A69B8 for ; Thu, 25 Mar 2010 10:50:26 -0700 (PDT) X-AuditID: c1b4fb39-b7b85ae000005cbc-e5-4baba277251f Received: from esessmw0256.eemea.ericsson.se (Unknown_Domain [153.88.253.125]) by mailgw9.se.ericsson.net (Symantec Brightmail Gateway) with SMTP id 4F.26.23740.772ABAB4; Thu, 25 Mar 2010 18:50:47 +0100 (CET) Received: from ESESSCMS0356.eemea.ericsson.se ([169.254.2.100]) by esessmw0256.eemea.ericsson.se ([10.2.3.125]) with mapi; Thu, 25 Mar 2010 18:50:47 +0100 From: Ingemar Johansson S To: "philip.eardley@bt.com" , Dirk Kutscher , bo zhou Date: Thu, 25 Mar 2010 18:50:45 +0100 Thread-Topic: [re-ECN] Wireless aspects of the ConEx work Thread-Index: AcrMQlkk8EBBneHgS7ur0gNS/A/zPQAAJvag Message-ID: <548FC4B9D57A4043AAFFE888A39429031D01FA59F2@ESESSCMS0356.eemea.ericsson.se> References: <1269538713.4362.35.camel@Nokia-N900-51-1> In-Reply-To: <1269538713.4362.35.camel@Nokia-N900-51-1> 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: multipart/alternative; boundary="_000_548FC4B9D57A4043AAFFE888A39429031D01FA59F2ESESSCMS0356e_" MIME-Version: 1.0 X-Brightmail-Tracker: AAAAAA== Cc: Ingemar Johansson S , "re-ecn@ietf.org" Subject: Re: [re-ECN] Wireless aspects of the ConEx work X-BeenThere: re-ecn@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: re-inserted explicit congestion notification List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 25 Mar 2010 17:52:00 -0000 --_000_548FC4B9D57A4043AAFFE888A39429031D01FA59F2ESESSCMS0356e_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Hi I wrote up the doc a couple of months ago to hightlight properties of moder= n wireless networks. I don't believe that the particular properties of wireless networks has any= impact on the short term work in ConEx, I can however imagine that the din= amic nature and increased RTT when wireless access is a part of the transmi= ssion path may put additional requirements on policers and incentive droppe= rs in the network but this is possibly a future headache. /Ingemar ________________________________ From: Eardley,PL,Philip,DEE1 R [mailto:philip.eardley@bt.com] Sent: den 25 mars 2010 10:39 To: Dirk Kutscher; bo zhou; Ingemar Johansson S Cc: re-ecn@ietf.org Subject: Re: [re-ECN] Wireless aspects of the ConEx work Hi Bo, The charter wasnt supposed to be limited to wireless. I remember that promp= ted by ingemar's I-D of a few month's ago we thought briefly about the wire= less case and couldnt see what specifically needed changing in the proposed= work items best wishes phil ----- Original message ----- > Hi Bo, > > Looking at http://www.ietf.org/iesg/evaluation/conex-charter.txt, I > don't see the current charter limiting the scope to fixed networks. > > (Could not follow the on-line discussions this week though). > > I agree that it should not be constrained to specific systems (or even > L2 technologies). > > There is an applicability statement document on the charter, which is > fine. > > Best regards, > > Dirk > > > -- > NEC Laboratories Europe > > NEC Europe Limited | Registered Office: NEC House, 1 Victoria Road, > London W3 6BL | Registered in England 2832014 > > > > > > > > -----Original Message----- > > From: re-ecn-bounces@ietf.org [mailto:r= e-ecn-bounces@ietf.org] On > > Behalf Of bo zhou > > Sent: Thursday, March 25, 2010 5:06 PM > > To: Ingemar Johansson S > > Cc: re-ecn@ietf.org > > Subject: Re: [re-ECN] Wireless aspects of the ConEx work > > > > Hi All, > > > > What Ingemar mentioned sounds reasonable. > > I am worry about current charter defined E2E focus on fixed network > > only. I believe in the future, E2E Internet traffic will be found more > > in wireless/mobile network rather than fixed network (maybe my > > prediction is wrong, but who knows). In such way, we can predict the > > bottleneck will be happened in air interface and mobile backhaul > rather > > than bearer network, not prediction result, it happened today. > > I believe Congestion Exposure is a good and right idea working as a WG > > in IETF. But only cover fixed network is not enough, especially mobile > > Internet traffic raise up very quickly these years. > > Shall we consider wireless/mobile network congestion in the scope? > > > > Regards, > > > > Bo > > > > > > > > On Thu, Mar 25, 2010 at 8:59 AM, Ingemar Johansson S > > > wrote: > > > > > > Hi > > > > As a followup to my comment at the mike at todays re-BoF :-) > > > > The document that discusses congestion as seen from a wireless > > access perspective > > http://tools.ietf.org/id/draft-johansson-wireless-congestion- > > properties-00.txt > > This document was written as a kind of input to the Conex work a > > few months ago. > > > > 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. > > Senior Research Engineer > > > > 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 ; > > 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 > > _______________________________________________ > > re-ECN mailing list > > re-ECN@ietf.org > > https://www.ietf.org/mailman/listinfo/re-ecn > > > > > > > > > > > > -- > > Regards, > > > > Bo Zhou > > China Mobile > > _______________________________________________ > re-ECN mailing list > re-ECN@ietf.org > https://www.ietf.org/mailman/listinfo/re-ecn > --_000_548FC4B9D57A4043AAFFE888A39429031D01FA59F2ESESSCMS0356e_ Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable
Hi
 
I wrote up the doc a couple of months ago to hight= light=20 properties of modern wireless networks.
I don't believe that the particular properties of = wireless=20 networks has any impact on the short term work in ConEx, I can however imag= ine=20 that the dinamic nature and increased RTT when wireless access is a part of= the=20 transmission path may put additional requirements on policers and incentive= =20 droppers in the network but this is possibly a future=20 headache.
 
/Ingemar
From: Eardley,PL,Philip,DEE1 R=20 [mailto:philip.eardley@bt.com]
Sent: den 25 mars 2010=20 10:39
To: Dirk Kutscher; bo zhou; Ingemar Johansson S
Cc:= =20 re-ecn@ietf.org
Subject: Re: [re-ECN] Wireless aspects of the C= onEx=20 work

Hi Bo,
The charter wasnt supposed to be limited to wireless. I rem= ember=20 that prompted by ingemar's I-D of a few month's ago we thought briefly ab= out=20 the wireless case and couldnt see what specifically needed changing in th= e=20 proposed work items
best wishes
phil
----- Original message -= ----=20
> Hi Bo,
>
> Looking at http://www= .ietf.org/iesg/evaluation/conex-charter.txt,=20 I
> don't see the current charter limiting the scope to fixed netw= orks.=20
>
> (Could not follow the on-line discussions this week tho= ugh).=20
>
> I agree that it should not be constrained to specific=20 systems (or even
> L2 technologies).
>
> There is an= =20 applicability statement document on the charter, which is
> fine.= =20
>
> Best regards,
>
> Dirk
>
>= =20
> --
> NEC Laboratories Europe
>
> NEC Europe= =20 Limited | Registered Office: NEC House, 1 Victoria Road,
> London = W3=20 6BL | Registered in England 2832014
>
>
>
>=20
>
>
> > -----Original Message-----
> > = From:=20 re-ecn-bounces@ietf.org [<= A=20 href=3D"mailto:re-ecn-bounces@ietf.org">mailto:re-ecn-bounces@ietf.org] On=20
> > Behalf Of bo zhou
> > Sent: Thursday, March 25, 2= 010=20 5:06 PM
> > To: Ingemar Johansson S
> > Cc: re-ecn@ietf.org
> > Subject= : Re:=20 [re-ECN] Wireless aspects of the ConEx work
> >
> > H= i=20 All,
> >
> > What Ingemar mentioned sounds reasonable= .=20
> > I am worry about current charter defined E2E focus on fixed= =20 network
> > only. I believe in the future, E2E Internet traffic= will=20 be found more
> > in wireless/mobile network rather than fixed= =20 network (maybe my
> > prediction is wrong, but who knows). In s= uch=20 way, we can predict the
> > bottleneck will be happened in air= =20 interface and mobile backhaul
> rather
> > than bearer=20 network, not prediction result, it happened today.
> > I believ= e=20 Congestion Exposure is a good and right idea working as a WG
> >= ; in=20 IETF. But only cover fixed network is not enough, especially mobile
&= gt;=20 > Internet traffic raise up very quickly these years.
> > Sh= all=20 we consider wireless/mobile network congestion in the scope?
> >= ;=20
> > Regards,
> >
> > Bo
> >
&= gt;=20 >
> >
> > On Thu, Mar 25, 2010 at 8:59 AM, Ingemar= =20 Johansson S
> > <ingemar.s.johansson@eric= sson.com>=20 wrote:
> >
> >
> > Hi
> >
>= ;=20 > As a followup to my comment at the mike at todays re-BoF :-)
>= ;=20 >
> > The document that discusses congestion as seen from a= =20 wireless
> > access perspective
> > ht= tp://tools.ietf.org/id/draft-johansson-wireless-congestion-=20
> > properties-00.txt
> > This document was written a= s a=20 kind of input to the Conex work a
> > few months ago.
> = >=20
> > Regards
> > Ingemar
> >=20 =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
> >
> > Ericss= on AB=20
> > Multimedia Technologies
> > Labratoriegr=E4nd 11= =20
> > 971 28, Lule=E5, Sweden
> > Phone +46-1071 43042= =20
> > SMS/MMS +46-73 078 3289
> > ingemar.s.johansson@eric= sson.com=20
> > www.ericsson.com &l= t;">http://www.ericsson.com/>;
= >=20 > Visit http://labs.ericsson.com<= /A>=20 <">http://labs.ericsson.com/><= /A>; !=20
> > =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
> >=20 _______________________________________________
> > re-ECN mail= ing=20 list
> > re-ECN@ietf.org= =20
> > https://www.ietf.or= g/mailman/listinfo/re-ecn=20
> >
> >
> >
> >
> > >=20 > --
> > Regards,
> >
> > Bo Zhou
&g= t;=20 > China Mobile
>
>=20 _______________________________________________
> re-ECN mailing l= ist=20
> re-ECN@ietf.org
> = https://www.ietf.or= g/mailman/listinfo/re-ecn=20
>

--_000_548FC4B9D57A4043AAFFE888A39429031D01FA59F2ESESSCMS0356e_-- From john@jlc.net Thu Mar 25 10:59:37 2010 Return-Path: X-Original-To: re-ecn@core3.amsl.com Delivered-To: re-ecn@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 163A23A694D for ; Thu, 25 Mar 2010 10:59:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.24 X-Spam-Level: X-Spam-Status: No, score=-3.24 tagged_above=-999 required=5 tests=[AWL=0.371, BAYES_20=-0.74, DNS_FROM_OPENWHOIS=1.13, 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 0MISn6AaTLQ2 for ; Thu, 25 Mar 2010 10:59:36 -0700 (PDT) Received: from mailhost.jlc.net (mailhost.jlc.net [199.201.159.9]) by core3.amsl.com (Postfix) with ESMTP id 58F2F3A6E12 for ; Thu, 25 Mar 2010 10:58:55 -0700 (PDT) Received: by mailhost.jlc.net (Postfix, from userid 104) id 7E9C433C7A; Thu, 25 Mar 2010 13:59:17 -0400 (EDT) Date: Thu, 25 Mar 2010 13:59:17 -0400 From: John Leslie To: "Mcdysan, David E" Message-ID: <20100325175917.GB43441@verdi> References: <548FC4B9D57A4043AAFFE888A39429031D01FA59BC@ESESSCMS0356.eemea.ericsson.se> <793F49BA1FC821409F99F10862A0E4DB06454596@FHDP1LUMXCV14.us.one.verizon.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <793F49BA1FC821409F99F10862A0E4DB06454596@FHDP1LUMXCV14.us.one.verizon.com> User-Agent: Mutt/1.4.1i Cc: re-ecn@ietf.org Subject: [re-ECN] mobile device "congestion" X-BeenThere: re-ecn@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: re-inserted explicit congestion notification List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 25 Mar 2010 17:59:37 -0000 Mcdysan, David E wrote: > > ... "Congestion" is not only due to queuing, but can be caused by > other conditions (e.g., changing radio coverage as a mobile device > moves about). Though mobility is far from the only "strange" case, it's a good example of the variety of cases we need to cover. For strict re-ecn, it's almost true-by-definition that "congestion" is whatever ECN marks as "congestion." However, that does not mean we can look at one ECN spec and draw conclusions about what that means in a "roaming" case. Any spec we write must "just work" if underlying ECN implementations evolve. "Changing radio coverage" might actually occur before a queue for the first radio path fills. And the new path may be well-established before anyone _could_ tell whether the queue for the first path will ever clear sufficiently to deliver its packets over the first path. Most of these issues are out-of-scope for ConEx. There _will_ be non-congestion losses, and there will be cases we'd call "congestion" that never get ECN-marked. And ConEx may well end up with something quite different from ECN defining what will be marked as congestion. Also, wireless mobility cases point out that we can't know how much hysteresis is in the feedback loop. The ConEx intent is that senders estimate congestion along the path a packet may take _when_ it travels that path (which by definition must be _after_ the estimate is made). Though re-ecn has laid out an algorithm for such estimates, I don't believe ConEx intends to rubber-stamp that algorithm. To me, what particular algorithm a sender uses is out-of-scope for ConEx. If, for example, a sender knows the receiver is roaming, there might be an economic case for estimating more congestion than was seen during the last RTT. (There are a number of other that the probability of a roaming handover might be inferred.) -- John Leslie From zhouboyj@gmail.com Thu Mar 25 11:36:24 2010 Return-Path: X-Original-To: re-ecn@core3.amsl.com Delivered-To: re-ecn@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id E42473A6B83 for ; Thu, 25 Mar 2010 11:36:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.253 X-Spam-Level: X-Spam-Status: No, score=-0.253 tagged_above=-999 required=5 tests=[AWL=1.215, BAYES_00=-2.599, DNS_FROM_OPENWHOIS=1.13, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id UKHffubwDVK5 for ; Thu, 25 Mar 2010 11:36:23 -0700 (PDT) Received: from mail-iw0-f191.google.com (mail-iw0-f191.google.com [209.85.223.191]) by core3.amsl.com (Postfix) with ESMTP id 753073A6E8C for ; Thu, 25 Mar 2010 11:33:41 -0700 (PDT) Received: by iwn29 with SMTP id 29so4032646iwn.17 for ; Thu, 25 Mar 2010 11:34:00 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:in-reply-to:references :date:message-id:subject:from:to:cc:content-type; bh=hv4/TOXZcMvO+LpatEAfbI20aKzGhs0zYTk6ZVLHsuQ=; b=FuGaYwLng3RfSS7JC6oM//RFKLSiFrKikTX4VMoGFKR9TkcP3w5KvgInRU6N2pTcD/ 3RALRdVUtgzeovzn+EV8KairdiEraDy4nAFM9VVgJG2TLqYtQhr8ppHeuyAmnnSLzmGl hKP7o2Tlxm8eLop5/fA21jm4THau9ojw4P87A= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; b=O2lrJammAUP+PQ9tWtTfBwp78FMhOcJmHT46yd8X9h71fx42b+QT2teDebt1vvlupQ zP6AYlRYrzuiWaZCUCiBg8KNAImoRFgHJktvOslB3gn85OO8+CpDt3XsjdE1o5oU2btI X5Lak6L5iPK4OEY+Ss2RxFztg1yDsJgmMqEyA= MIME-Version: 1.0 Received: by 10.114.8.15 with SMTP id 15mr7978328wah.178.1269542030522; Thu, 25 Mar 2010 11:33:50 -0700 (PDT) In-Reply-To: <20100325175917.GB43441@verdi> References: <548FC4B9D57A4043AAFFE888A39429031D01FA59BC@ESESSCMS0356.eemea.ericsson.se> <793F49BA1FC821409F99F10862A0E4DB06454596@FHDP1LUMXCV14.us.one.verizon.com> <20100325175917.GB43441@verdi> Date: Fri, 26 Mar 2010 02:33:50 +0800 Message-ID: <36a593231003251133y2347e6d1ncc7e56c1bef55f36@mail.gmail.com> From: bo zhou To: John Leslie Content-Type: multipart/alternative; boundary=00504502e17bc1e2870482a449e2 Cc: re-ecn@ietf.org Subject: Re: [re-ECN] mobile device "congestion" X-BeenThere: re-ecn@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: re-inserted explicit congestion notification List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 25 Mar 2010 18:36:25 -0000 --00504502e17bc1e2870482a449e2 Content-Type: text/plain; charset=ISO-8859-1 Hi John, >From your point, the re-ECN only do which can implement "re-ECN" mark in the transmission path. I am not sure this can bring the End-user the real congestion information during transmission path. For example, fixed network implement Ethernet based VPN for its backhaul transmission or others L2 transmission technologies, which cannot mark "re-ECN" in my mind. But from real network case, more fixed network congestion is happened in the backhaul. Another example is mobile network, only in GI interface the IP packet can be found. before that, the traffic will go through air-interface, mobile-backhaul and GTP tunnel, all these parts cannot do "re-ECN" mark as well. But all these part of missing-"re-ECN" path are major congestion point in mobile network. Regards, Bo Zhou On Fri, Mar 26, 2010 at 1:59 AM, John Leslie wrote: > Mcdysan, David E wrote: > > > > ... "Congestion" is not only due to queuing, but can be caused by > > other conditions (e.g., changing radio coverage as a mobile device > > moves about). > > Though mobility is far from the only "strange" case, it's a good > example of the variety of cases we need to cover. > > For strict re-ecn, it's almost true-by-definition that "congestion" > is whatever ECN marks as "congestion." > > However, that does not mean we can look at one ECN spec and draw > conclusions about what that means in a "roaming" case. Any spec we > write must "just work" if underlying ECN implementations evolve. > > "Changing radio coverage" might actually occur before a queue for > the first radio path fills. And the new path may be well-established > before anyone _could_ tell whether the queue for the first path will > ever clear sufficiently to deliver its packets over the first path. > > Most of these issues are out-of-scope for ConEx. There _will_ be > non-congestion losses, and there will be cases we'd call "congestion" > that never get ECN-marked. And ConEx may well end up with something > quite different from ECN defining what will be marked as congestion. > > Also, wireless mobility cases point out that we can't know how > much hysteresis is in the feedback loop. The ConEx intent is that > senders estimate congestion along the path a packet may take _when_ > it travels that path (which by definition must be _after_ the > estimate is made). > > Though re-ecn has laid out an algorithm for such estimates, I > don't believe ConEx intends to rubber-stamp that algorithm. To me, > what particular algorithm a sender uses is out-of-scope for ConEx. > If, for example, a sender knows the receiver is roaming, there > might be an economic case for estimating more congestion than was > seen during the last RTT. (There are a number of other that the > probability of a roaming handover might be inferred.) > > -- > John Leslie > _______________________________________________ > re-ECN mailing list > re-ECN@ietf.org > https://www.ietf.org/mailman/listinfo/re-ecn > -- Regards, Bo Zhou China Mobile --00504502e17bc1e2870482a449e2 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
Hi John,
=A0
From your point, the re-ECN only do which can=A0implement "re-ECN= " mark in the transmission path. I am not sure this can bring the End-= user the real congestion information during transmission path.
For example, fixed network implement Ethernet based VPN for its backha= ul transmission or others L2 transmission technologies, which cannot=A0mark= "re-ECN"=A0in my mind. But from real network case, more fixed ne= twork congestion is happened in the backhaul.
Another example is mobile network, only in GI interface the IP packet = can be found. before that, the traffic will go through air-interface, mobil= e-backhaul and GTP tunnel, all these parts cannot do "re-ECN" mar= k as well. But all these part of missing-"re-ECN" path are major = congestion point in mobile network.
=A0
Regards,
=A0
Bo Zhou

On Fri, Mar 26, 2010 at 1:59 AM, John Leslie <john@jlc.net> wrote:
Mcdysan, David E <dave.mcdysan@verizon.com> wrote: >
> ... "Congestion" is not only due to queuing, but can= be caused by
> other conditions (e.g., changing radio coverage as a = mobile device
> moves about).

=A0 Though mobility is far from = the only "strange" case, it's a good
example of the variety of cases we need to cover.

=A0 For strict re-= ecn, it's almost true-by-definition that "congestion"
is w= hatever ECN marks as "congestion."

=A0 However, that does = not mean we can look at one ECN spec and draw
conclusions about what that means in a "roaming" case. Any spec w= e
write must "just work" if underlying ECN implementations evo= lve.

=A0 "Changing radio coverage" might actually occur be= fore a queue for
the first radio path fills. And the new path may be well-established
bef= ore anyone _could_ tell whether the queue for the first path will
ever c= lear sufficiently to deliver its packets over the first path.

=A0 Mo= st of these issues are out-of-scope for ConEx. There _will_ be
non-congestion losses, and there will be cases we'd call "congesti= on"
that never get ECN-marked. And ConEx may well end up with somet= hing
quite different from ECN defining what will be marked as congestion= .

=A0 Also, wireless mobility cases point out that we can't know how<= br>much hysteresis is in the feedback loop. The ConEx intent is that
sen= ders estimate congestion along the path a packet may take _when_
it trav= els that path (which by definition must be _after_ the
estimate is made).

=A0 Though re-ecn has laid out an algorithm for s= uch estimates, I
don't believe ConEx intends to rubber-stamp that al= gorithm. To me,
what particular algorithm a sender uses is out-of-scope = for ConEx.
If, for example, a sender knows the receiver is roaming, there
might be = an economic case for estimating more congestion than was
seen during the= last RTT. (There are a number of other that the
probability of a roamin= g handover might be inferred.)

--
John Leslie <john@jlc.net>
____________________________________________= ___
re-ECN mailing list
re-ECN@iet= f.org
= https://www.ietf.org/mailman/listinfo/re-ecn



--
Regards,

Bo Zhou
China Mobile=
--00504502e17bc1e2870482a449e2-- From john@jlc.net Thu Mar 25 11:56:45 2010 Return-Path: X-Original-To: re-ecn@core3.amsl.com Delivered-To: re-ecn@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 1C3F03A6A4D for ; Thu, 25 Mar 2010 11:56:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.262 X-Spam-Level: X-Spam-Status: No, score=-4.262 tagged_above=-999 required=5 tests=[AWL=1.207, BAYES_00=-2.599, DNS_FROM_OPENWHOIS=1.13, 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 a7b+jqPU68xe for ; Thu, 25 Mar 2010 11:56:44 -0700 (PDT) Received: from mailhost.jlc.net (mailhost.jlc.net [199.201.159.9]) by core3.amsl.com (Postfix) with ESMTP id 3CFF33A6964 for ; Thu, 25 Mar 2010 11:56:44 -0700 (PDT) Received: by mailhost.jlc.net (Postfix, from userid 104) id 1942133C78; Thu, 25 Mar 2010 14:57:07 -0400 (EDT) Date: Thu, 25 Mar 2010 14:57:07 -0400 From: John Leslie To: bo zhou Message-ID: <20100325185707.GC43441@verdi> References: <548FC4B9D57A4043AAFFE888A39429031D01FA59BC@ESESSCMS0356.eemea.ericsson.se> <793F49BA1FC821409F99F10862A0E4DB06454596@FHDP1LUMXCV14.us.one.verizon.com> <20100325175917.GB43441@verdi> <36a593231003251133y2347e6d1ncc7e56c1bef55f36@mail.gmail.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <36a593231003251133y2347e6d1ncc7e56c1bef55f36@mail.gmail.com> User-Agent: Mutt/1.4.1i Cc: re-ecn@ietf.org Subject: Re: [re-ECN] mobile device "congestion" X-BeenThere: re-ecn@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: re-inserted explicit congestion notification List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 25 Mar 2010 18:56:45 -0000 bo zhou wrote: > > From your point, the re-ECN only do which can implement "re-ECN" mark > in the transmission path. I am not sure this can bring the End-user the > real congestion information during transmission path. If you mean that ECN markings are not sufficient information, I tend to agree. However, it may be more important to have a clear definition of what ConEx marking _means_ than to have it accurately measure any particular definition of "congestion". > For example, fixed network implement Ethernet based VPN for its > backhaul transmission or others L2 transmission technologies, which > cannot mark "re-ECN" in my mind. VPN can be thought of as a tunnel, where "congestion" should be marked at tunnel ingress. Clearly, the tunnel ingress could ECN-flag according to a reasonable interpretation of ECN marking. > But from real network case, more fixed network congestion is happened > in the backhaul. IMHO, it's more important to approximate subpath congestion than to mark the congestion at any particular point. > Another example is mobile network, only in GI interface the IP packet > can be found. before that, the traffic will go through air-interface, > mobile-backhaul and GTP tunnel, all these parts cannot do "re-ECN" mark > as well. But all these part of missing-"re-ECN" path are major > congestion point in mobile network. IMHO, ConEx should only specify marking and visibility within IP packets, not when traffic is carried in some other networking proocol. This implies that elsewhere we must either estimate congestion outside of IP forwarding nodes, or settle for only packet loss on congestion. To cover one particular case, if IP packets sent by a mobile user must first travel over a non-IP path, ConEx IMHO cannot handle how to estimate packet loss before the first IP router, and we'll have to settle for loss signals. :^( -- John Leslie From karagian@cs.utwente.nl Thu Mar 25 13:45:55 2010 Return-Path: X-Original-To: re-ecn@core3.amsl.com Delivered-To: re-ecn@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id B87D33A69D9 for ; Thu, 25 Mar 2010 13:45:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 2.502 X-Spam-Level: ** X-Spam-Status: No, score=2.502 tagged_above=-999 required=5 tests=[AWL=0.387, BAYES_05=-1.11, DNS_FROM_OPENWHOIS=1.13, HELO_EQ_NL=0.55, HOST_EQ_NL=1.545] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 95skk9m4ESF4 for ; Thu, 25 Mar 2010 13:45:54 -0700 (PDT) Received: from denhaag.ewi.utwente.nl (denhaag.ewi.utwente.nl [130.89.10.11]) by core3.amsl.com (Postfix) with ESMTP id 859263A693C for ; Thu, 25 Mar 2010 13:45:54 -0700 (PDT) Received: from webmail.cs.utwente.nl (janus.ewi.utwente.nl [130.89.10.26]) by denhaag.ewi.utwente.nl (8.13.6/8.13.6) with SMTP id o2PKk4Fn020725; Thu, 25 Mar 2010 21:46:04 +0100 (MET) Received: from 130.129.30.6 (auth. user karagian@imap1.ewi.utwente.nl) by webmail.cs.utwente.nl with HTTP; Thu, 25 Mar 2010 20:46:06 +0000 To: "John Leslie" Date: Thu, 25 Mar 2010 20:46:05 +0000 X-Mailer: IlohaMail/0.8.13 (On: webmail.cs.utwente.nl) Message-ID: In-Reply-To: <20100325154706.GA39172@verdi> From: "Georgios Karagiannis" Bounce-To: "Georgios Karagiannis" Errors-To: "Georgios Karagiannis" MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable X-Scanned-By: MIMEDefang 2.52 on 130.89.10.11 X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-3.0rc3 (denhaag.ewi.utwente.nl [130.89.10.11]); Thu, 25 Mar 2010 21:46:13 +0100 (MET) Cc: "re-ecn@ietf.org" Subject: Re: [re-ECN] Comments regarding Conex charter X-BeenThere: re-ecn@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: re-inserted explicit congestion notification List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 25 Mar 2010 20:45:55 -0000 Hi John Thanks for the reply! Please see in line! On 3/25/2010, "John Leslie" wrote: >Georgios Karagiannis wrote: >> >> I agree with the argumentation given in the different available Conex >> drafts that such work is needed and that it is useful to start a Working >> group in the area oc Congestion exposure. > > :^) > >> However the current charter is not clear to me. > > Then we should fix it! > >> From this description is not clear to me whether the working group will >> specify: >> >> o) How the network will detect congestion? > > Likely not... (personally, I'm not sure we could reach an agreement >what we mean by "congestion"...) Georgios: Yes but I assume that this would be the first step before start doing the work in Conex, or? > >> o) How the network informs the source about this congestion? > > I believe we're intending that we only treat how to inform the >_recipient_ and leave up to a transport protocol to inform the sender. Georgios: but work item 3 of the Charter is about: "Transport-related best practices and specifications for A. the timely transport of congestion information from the destination to the sender" Will the WG work on extensions of a transport protocol or will the WG specify requirements for the transport protocol. > >> o) How the network will use the information provided by the source >> regarding the level of congestion? > > This is a major area of work for the proposed WG. I don't believe >we want to limit usage at chartering time. > > The intent is clear that any network router can know rest-of-path >expected congestion, and determine somehow whether congestion-so-far >exceeds the "expected congestion". Exactly what it might do in such >a case, IMHO, we do not intend to specify. > > My personal view is that there might be formal or informal >settlements -- leading to cost justification for infrastructure >upgrades. But I do not believe that is a charter issue. Georgios: So the WG will not work on any mitigation or reduction of the congestion! > >> It is not clear to me whether you want to say that the >> ?network by using the information provided by the senders could >> predict and mitigate or reduce possible congestion situation that >> are occurring or could occur in the immediate future.? > > My view is that settlements are a good path to justify upgrades; >and that conversely, "deadbeat" network peers that refuse to pay >settlements deserve a lower priority for their traffic -- perhaps >_lower_ priority than traffic without any ConEx marking. > > YMMV, of course... Georgios: So in your opinion the Conex WG will not work on mitigating or reducing congestion n the network. > >> Moreover, regarding the protocol solutions, in the given work items >> I could find only find the following information: >> >> >> I do not see any work items on how the timely transport of congestion >> information from the destination to the sender will be used. > > IMHO, any such specification would be premature: I expect various >mechanisms to be tried. Georgios: But are you expecting that this work will be done within the Conex WG? I do not see this as an Work item. > >> In my opinion two more work items could be identified, see below: >> >> o) provide a solution on how the sender re-echoes the feedback >> information into the network, and how the network uses this >> re-echoed information. > > I think that specification of how to specify expected congestion >when an IP packet originates is the limit of our work. How a sender >might calculate that number seems out-of-scope. Georgios: But if the sender receives feedback and re-echoes it, then the sender would need to know what to re-echo or? > >> o) provide a solution on how the network could predict and mitigate >> or reduce possible congestion situation that are occurring or >> could occur in the immediate future by using the information >> provided by the senders > > I would be happy to participate in such work; but I'm not sure >whether it is a necessary part of ConEx work. IMHO, it would be a >bad thing to even _suggest_ that there should be only one way... Georgios: So mitigating or reducing network congestion is out of scope. Best regards, Georgios > >-- >John Leslie From john@jlc.net Thu Mar 25 14:21:15 2010 Return-Path: X-Original-To: re-ecn@core3.amsl.com Delivered-To: re-ecn@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 7EC6B3A659A for ; Thu, 25 Mar 2010 14:21:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.503 X-Spam-Level: X-Spam-Status: No, score=-4.503 tagged_above=-999 required=5 tests=[AWL=0.966, BAYES_00=-2.599, DNS_FROM_OPENWHOIS=1.13, 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 b4iUAj5UIY0E for ; Thu, 25 Mar 2010 14:21:09 -0700 (PDT) Received: from mailhost.jlc.net (mailhost.jlc.net [199.201.159.9]) by core3.amsl.com (Postfix) with ESMTP id 5F9BB3A6BCF for ; Thu, 25 Mar 2010 14:21:04 -0700 (PDT) Received: by mailhost.jlc.net (Postfix, from userid 104) id 5ECA833C6D; Thu, 25 Mar 2010 17:21:27 -0400 (EDT) Date: Thu, 25 Mar 2010 17:21:27 -0400 From: John Leslie To: Georgios Karagiannis Message-ID: <20100325212127.GA59072@verdi> References: <20100325154706.GA39172@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: re-ecn@ietf.org Subject: Re: [re-ECN] Comments regarding Conex charter X-BeenThere: re-ecn@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: re-inserted explicit congestion notification List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 25 Mar 2010 21:21:15 -0000 Georgios Karagiannis wrote: > >>> From this description is not clear to me whether the working group will >>> specify: >>> >>> o) How the network will detect congestion? >> >> Likely not... (personally, I'm not sure we could reach an agreement >> what we mean by "congestion"...) > > Georgios: Yes but I assume that this would be the first step before start > doing the work in Conex, or? My guess is that we would punt that question. If we agreed on a definition, I think it would have to be by reference to some existing document. My recommendation would be to leave that question open, and design ConEx so it could work with many different definitions of congestion. > > Will the WG work on extensions of a transport protocol or will the WG > specify requirements for the transport protocol. I really couldn't say (though I think a charter ought to at least hint one way or the other). For myself, I'd prefer to do as little as possible, and nothing at all about standards-track extensions to any transport protocol. >> My personal view is that there might be formal or informal >> settlements -- leading to cost justification for infrastructure >> upgrades. But I do not believe that is a charter issue. > > Georgios: So the WG will not work on any mitigation or reduction of the > congestion! Individual WG members almost certainly would work on such schemes. But I don't think a ConEx WG should seem to promise any mitigation -- rather we should limit ourselves to how a ConEx protocol might be used in mitigation efforts. >>> I do not see any work items on how the timely transport of congestion >>> information from the destination to the sender will be used. >> >> IMHO, any such specification would be premature: I expect various >> mechanisms to be tried. > > Georgios: But are you expecting that this work will be done within the > Conex WG? I do not see this as an Work item. I wouldn't know how to specify such a charter work item. >> I think that specification of how to specify expected congestion >> when an IP packet originates is the limit of our work. How a sender >> might calculate that number seems out-of-scope. > > Georgios: But if the sender receives feedback and re-echoes it, then > the sender would need to know what to re-echo or? IMHO, ConEx should only specify the meaning of ConEx signals, not how to calculate expected congestion. Any algorithm we might specify would inevitably include a loop delay which could lead to oscillation. (We might even have to specify damping functions to avoid oscillation.) > Georgios: So mitigating or reducing network congestion is out of scope. IMHO, we're building a _tool_ which would be useful in mitigating congestion, not defining a _process_ for doing so. -- John Leslie From rbriscoe@jungle.bt.co.uk Fri Mar 26 07:52:59 2010 Return-Path: X-Original-To: re-ecn@core3.amsl.com Delivered-To: re-ecn@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 904063A6A28 for ; Fri, 26 Mar 2010 07:52:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 2.342 X-Spam-Level: ** X-Spam-Status: No, score=2.342 tagged_above=-999 required=5 tests=[AWL=-0.729, BAYES_50=0.001, DNS_FROM_OPENWHOIS=1.13, DNS_FROM_RFC_BOGUSMX=1.482, HTML_MESSAGE=0.001, MIME_HTML_ONLY=1.457, 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 2rO8i6OES9OX for ; Fri, 26 Mar 2010 07:52:48 -0700 (PDT) Received: from smtp1.smtp.bt.com (smtp1.smtp.bt.com [217.32.164.137]) by core3.amsl.com (Postfix) with ESMTP id A74AA3A680F for ; Fri, 26 Mar 2010 07:52:47 -0700 (PDT) Received: from i2kc08-ukbr.domain1.systemhost.net ([193.113.197.71]) by smtp1.smtp.bt.com with Microsoft SMTPSVC(6.0.3790.3959); Fri, 26 Mar 2010 14:53:09 +0000 Received: from cbibipnt08.iuser.iroot.adidom.com ([147.149.100.81]) by i2kc08-ukbr.domain1.systemhost.net with Microsoft SMTPSVC(6.0.3790.3959); Fri, 26 Mar 2010 14:53:09 +0000 Received: From bagheera.jungle.bt.co.uk ([132.146.168.158]) by cbibipnt08.iuser.iroot.adidom.com (WebShield SMTP v4.5 MR1a P0803.399); id 1269615187829; Fri, 26 Mar 2010 14:53:07 +0000 Received: from MUT.jungle.bt.co.uk ([10.142.66.128]) by bagheera.jungle.bt.co.uk (8.13.5/8.12.8) with ESMTP id o2QEr2NT006750; Fri, 26 Mar 2010 14:53:03 GMT Message-Id: <201003261453.o2QEr2NT006750@bagheera.jungle.bt.co.uk> X-Mailer: QUALCOMM Windows Eudora Version 7.1.0.9 Date: Fri, 26 Mar 2010 14:53:03 +0000 To: bo zhou From: Bob Briscoe In-Reply-To: <36a593231003251133y2347e6d1ncc7e56c1bef55f36@mail.gmail.co m> References: <548FC4B9D57A4043AAFFE888A39429031D01FA59BC@ESESSCMS0356.eemea.ericsson.se> <793F49BA1FC821409F99F10862A0E4DB06454596@FHDP1LUMXCV14.us.one.verizon.com> <20100325175917.GB43441@verdi> <36a593231003251133y2347e6d1ncc7e56c1bef55f36@mail.gmail.com> Mime-Version: 1.0 Content-Type: text/html; charset="us-ascii" X-Scanned-By: MIMEDefang 2.56 on 132.146.168.158 X-OriginalArrivalTime: 26 Mar 2010 14:53:09.0418 (UTC) FILETIME=[0CE940A0:01CACCF4] Cc: re-ecn@ietf.org Subject: Re: [re-ECN] mobile device "congestion" X-BeenThere: re-ecn@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: re-inserted explicit congestion notification List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 26 Mar 2010 14:52:59 -0000 Bo, John,

I think the 5 points below cover all the concerns in your 2 mails.

There are three types of in-band signal:
* Congestion so far:
  a) explicit congestion notification (ECN)
  b) implicit congestion notification (drop)
* Whole path congestion:
  c) Re-inserted explicit congestion notification (RE)

1) Whenever any segment of the network is congested it tells the receiver, either by ECN or drop.

2) The source tells the network using RE how much drop *or* ECN is being seen by the e2e transport (excepting any drop it can be nearly certain is not due to congestion).

3) The network gives the e2e transport an incentive to warn of *potential* upcoming congestion (e.g. when rapidly increasing its rate). If the transport gets this wrong it risks its traffic being briefly punished for cheating. This makes the source care about the risk to everyone else's service, because it bears the cost of the risk that its expectation of congestion is wrong.

4a) A network that wants to check the integrity of the sender's re-ECN markings has the incentive to ensure it notifies congestion using ECN rather than drop wherever possible, to make verification much easier.

4b) ECN is not currently defined for many lower layer technologies (RFC3168 listed the main ones that will have to be done). Often networks are designed so that one node (often IP-aware) manages congestion for the subnet it sends traffic into, to avoid congestion on the non-IP links.

Nonetheless, if such links get congested they will have to drop, but the operator has an incentive to get ECN standardised for these cases. These standards will propagate ECN up from the lower layer to IP at the next IP node (as RFC5129 does for MPLS).

5) The ConEx w-g is chartering to add the RE part to IP (initially v6).

Standards for ECN part already exist in IP & MPLS.

ConEx is not asking to be chartered to add an ECN-like function to other lower layer technologies, but ConEx will at least work with drop even though it is harder to verify. And the ConEx effort will encourage such standardisation in other bodies (point 4a).



Bob

At 18:33 25/03/2010, bo zhou wrote:
Hi John,
 
From your point, the re-ECN only do which can implement "re-ECN" mark in the transmission path. I am not sure this can bring the End-user the real congestion information during transmission path.
For example, fixed network implement Ethernet based VPN for its backhaul transmission or others L2 transmission technologies, which cannot mark "re-ECN" in my mind. But from real network case, more fixed network congestion is happened in the backhaul.
Another example is mobile network, only in GI interface the IP packet can be found. before that, the traffic will go through air-interface, mobile-backhaul and GTP tunnel, all these parts cannot do "re-ECN" mark as well. But all these part of missing-"re-ECN" path are major congestion point in mobile network.
 
Regards,
 
Bo Zhou

On Fri, Mar 26, 2010 at 1:59 AM, John Leslie <john@jlc.net> wrote:
Mcdysan, David E <dave.mcdysan@verizon.com > wrote:
>
> ... "Congestion" is not only due to queuing, but can be caused by
> other conditions (e.g., changing radio coverage as a mobile device
> moves about).

  Though mobility is far from the only "strange" case, it's a good
example of the variety of cases we need to cover.

  For strict re-ecn, it's almost true-by-definition that "congestion"
is whatever ECN marks as "congestion."

  However, that does not mean we can look at one ECN spec and draw
conclusions about what that means in a "roaming" case. Any spec we
write must "just work" if underlying ECN implementations evolve.

  "Changing radio coverage" might actually occur before a queue for
the first radio path fills. And the new path may be well-established
before anyone _could_ tell whether the queue for the first path will
ever clear sufficiently to deliver its packets over the first path.

  Most of these issues are out-of-scope for ConEx. There _will_ be
non-congestion losses, and there will be cases we'd call "congestion"
that never get ECN-marked. And ConEx may well end up with something
quite different from ECN defining what will be marked as congestion.

  Also, wireless mobility cases point out that we can't know how
much hysteresis is in the feedback loop. The ConEx intent is that
senders estimate congestion along the path a packet may take _when_
it travels that path (which by definition must be _after_ the
estimate is made).

  Though re-ecn has laid out an algorithm for such estimates, I
don't believe ConEx intends to rubber-stamp that algorithm. To me,
what particular algorithm a sender uses is out-of-scope for ConEx.
If, for example, a sender knows the receiver is roaming, there
might be an economic case for estimating more congestion than was
seen during the last RTT. (There are a number of other that the
probability of a roaming handover might be inferred.)

--
John Leslie <john@jlc.net>
_______________________________________________
re-ECN mailing list
re-ECN@ietf.org
https://www.ietf.org/mailman/listinfo/re-ecn




--
Regards,

Bo Zhou
China Mobile
_______________________________________________
re-ECN mailing list
re-ECN@ietf.org
https://www.ietf.org/mailman/listinfo/re-ecn

________________________________________________________________
Bob Briscoe,                                BT Innovate & Design From matt.mathis@gmail.com Sun Mar 28 15:56:37 2010 Return-Path: X-Original-To: re-ecn@core3.amsl.com Delivered-To: re-ecn@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 26F1B3A68C2 for ; Sun, 28 Mar 2010 15:56:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.131 X-Spam-Level: * X-Spam-Status: No, score=1.131 tagged_above=-999 required=5 tests=[BAYES_50=0.001, DNS_FROM_OPENWHOIS=1.13] 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 PxOuK1jAMP1h for ; Sun, 28 Mar 2010 15:56:35 -0700 (PDT) Received: from mail-vw0-f44.google.com (mail-vw0-f44.google.com [209.85.212.44]) by core3.amsl.com (Postfix) with ESMTP id C0BED3A6801 for ; Sun, 28 Mar 2010 15:56:35 -0700 (PDT) Received: by vws12 with SMTP id 12so2830382vws.31 for ; Sun, 28 Mar 2010 15:56:59 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:in-reply-to:references :date:received:message-id:subject:from:to:cc:content-type :content-transfer-encoding; bh=HpvV253ioZKHW1Wa1V6Dchhh6atO81IHQiHixu+SV0k=; b=iJhSM9O1GWd0GNRmWHIPzk0PYskfuGBPVi3bNYp2BSAqoAdT3EPxFvYFbi3bcwOWsE J3gCLi4TFX353aYcIZtsnVw3n+vBtdZJXGlSGoQ53x/a4IkYx1EbuN9IVu+VCQ+dIVbX lm0G2uFsIarQGoEnKDx81YwDmabKPQTLc4t+Y= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; b=xGGfZLZjv6rTFlhVGS+yHG/SjTskCkNi5VC5yk5vDU7siWx3KAbqiowfD9GMSoWJcF ICCcAMrJeQkYARdzf6qpkw8KmkDqbseFh697TBW+Rp2k7t6wq1FcCRImjOsmOU9PY+XR tSaajgYcu1hNaKnizniJ1z27htImRt6BqPe2A= MIME-Version: 1.0 Received: by 10.220.162.194 with HTTP; Sun, 28 Mar 2010 15:56:59 -0700 (PDT) In-Reply-To: <20100325212127.GA59072@verdi> References: <20100325154706.GA39172@verdi> <20100325212127.GA59072@verdi> Date: Sun, 28 Mar 2010 18:56:59 -0400 Received: by 10.220.62.201 with SMTP id y9mr2612237vch.99.1269817019759; Sun, 28 Mar 2010 15:56:59 -0700 (PDT) Message-ID: From: Matt Mathis To: John Leslie Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: re-ecn@ietf.org Subject: Re: [re-ECN] Comments regarding Conex charter X-BeenThere: re-ecn@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: re-inserted explicit congestion notification List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 28 Mar 2010 22:56:37 -0000 So from this thread I realize that the ConEx charter probably needs one more sentence. Something like "ConEx will not change the semantics of either loss or ECN based congestion indications, nor will it change sender transport behaviors in response to congestion signals." 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. On Thu, Mar 25, 2010 at 5:21 PM, John Leslie wrote: > Georgios Karagiannis wrote: >> >>>> From this description is not clear to me whether the working group wil= l >>>> specify: >>>> >>>> o) How the network will detect congestion? >>> >>> Likely not... (personally, I'm not sure we could reach an agreement >>> what we mean by "congestion"...) >> >> Georgios: Yes but I assume that this would be the first step before star= t >> doing the work in Conex, or? > > =A0 My guess is that we would punt that question. If we agreed on a > definition, I think it would have to be by reference to some existing > document. > > =A0 My recommendation would be to leave that question open, and design > ConEx so it could work with many different definitions of congestion. > > >> >> Will the WG work on extensions of a transport protocol or will the WG >> specify requirements for the transport protocol. > > =A0 I really couldn't say (though I think a charter ought to at least > hint one way or the other). > > =A0 For myself, I'd prefer to do as little as possible, and nothing at > all about standards-track extensions to any transport protocol. > >>> My personal view is that there might be formal or informal >>> settlements -- leading to cost justification for infrastructure >>> upgrades. But I do not believe that is a charter issue. >> >> Georgios: So the WG will not work on any mitigation or reduction of the >> congestion! > > =A0 Individual WG members almost certainly would work on such schemes. > But I don't think a ConEx WG should seem to promise any mitigation -- > rather we should limit ourselves to how a ConEx protocol might be used > in mitigation efforts. > >>>> I do not see any work items on how the timely transport of congestion >>>> information from the destination to the sender will be used. >>> >>> IMHO, any such specification would be premature: I expect various >>> mechanisms to be tried. >> >> Georgios: But are you expecting that this work will be done within the >> Conex WG? I do not see this as an Work item. > > =A0 I wouldn't know how to specify such a charter work item. > >>> I think that specification of how to specify expected congestion >>> when an IP packet originates is the limit of our work. How a sender >>> might calculate that number seems out-of-scope. >> >> Georgios: But if the sender receives feedback and re-echoes it, then >> the sender would need to know what to re-echo or? > > =A0 IMHO, ConEx should only specify the meaning of ConEx signals, not > how to calculate expected congestion. Any algorithm we might specify > would inevitably include a loop delay which could lead to oscillation. > (We might even have to specify damping functions to avoid oscillation.) > >> Georgios: So mitigating or reducing network congestion is out of scope. > > =A0 IMHO, we're building a _tool_ which would be useful in mitigating > congestion, not defining a _process_ for doing so. > > -- > John Leslie > _______________________________________________ > re-ECN mailing list > re-ECN@ietf.org > https://www.ietf.org/mailman/listinfo/re-ecn > From matt.mathis@gmail.com Sun Mar 28 17:38:56 2010 Return-Path: X-Original-To: re-ecn@core3.amsl.com Delivered-To: re-ecn@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id B1AA03A6902 for ; Sun, 28 Mar 2010 17:38:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.131 X-Spam-Level: * X-Spam-Status: No, score=1.131 tagged_above=-999 required=5 tests=[BAYES_50=0.001, DNS_FROM_OPENWHOIS=1.13] 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 Ps7uYiMIBt9Q for ; Sun, 28 Mar 2010 17:38:55 -0700 (PDT) Received: from mail-vw0-f44.google.com (mail-vw0-f44.google.com [209.85.212.44]) by core3.amsl.com (Postfix) with ESMTP id AF4353A68CB for ; Sun, 28 Mar 2010 17:38:53 -0700 (PDT) Received: by vws12 with SMTP id 12so2854356vws.31 for ; Sun, 28 Mar 2010 17:39:17 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:date:received:message-id :subject:from:to:cc:content-type; bh=qU8nHWDzvR3olngN0M/jXTaoTkM4vRp/InVYWJNqYW4=; b=fVg995bUaDubWQcqRnMo+DJgtXK8h89JS/0owD8uAfC+jmzDd3Q6dfA+t8EYct2d9S dI5hxJ92kV3m1bgC8G0nHYSIcuRcRKAnRVcHwdc/dMYS2F2pLAnEoIgklI0j1ZOH3Izl GH3RutEkYAZgSTAQFqrfkAQ/r/xRv7CBjFOes= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:date:message-id:subject:from:to:cc:content-type; b=IHWzc8MEruotTaQdwlTsdGuOiO9W265eDMO1709N6gPA/P0zS6EKPdg5mxPLXu1fdV vQqhOL4VrNY+1WRVqB5jhZKRTARU8dt2FMMSqV5ENcw6xUaGIOFIm9dae/v7BXL/+pIl dAjj27ENysX+eBRu4AhS+53Z7Oj1EuPTukJrg= MIME-Version: 1.0 Received: by 10.220.94.81 with HTTP; Sun, 28 Mar 2010 17:39:16 -0700 (PDT) Date: Sun, 28 Mar 2010 20:39:16 -0400 Received: by 10.220.121.233 with SMTP id i41mr2615920vcr.163.1269823156865; Sun, 28 Mar 2010 17:39:16 -0700 (PDT) Message-ID: From: Matt Mathis To: "re-ecn@ietf.org list" Content-Type: text/plain; charset=ISO-8859-1 Subject: [re-ECN] Abstract specification of ConEx X-BeenThere: re-ecn@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: re-inserted explicit congestion notification List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 29 Mar 2010 00:38:56 -0000 While Bob and I were working on our ICCRG presentation I generated a slide that described an abstract (coding independent) representation of ConEx. This slide did not make it into the final presentation, but I thought I would describe it here, with one enhancement that came up during the week. Congestion indications (ECN marks) propagate from the network to the transport receiver. To avoid ambiguity these must be three state marking: Not supported, not marked, and congestion detected (ECN). For shorthand ECN marked is referred to as "RED" or "debit" marks. The transport ACKs carry this information and loss information (e.g. TCP SACKS) from the receiver to the sender. The details are not specified in the abstract model, but full marking information must be preserved (The sender has to be able to construct cumulative counts of ECN marked and not marked. The "Not supported" indication MUST be all or none). The sender is required to adjust its window size or data rate according to existing congestion control standards. 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) X-Original-To: re-ecn@core3.amsl.com Delivered-To: re-ecn@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id B6CBA3A67A6 for ; Mon, 29 Mar 2010 00:06:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.856 X-Spam-Level: * X-Spam-Status: No, score=1.856 tagged_above=-999 required=5 tests=[AWL=0.243, BAYES_50=0.001, DNS_FROM_OPENWHOIS=1.13, 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 htFljL6tZdho for ; Mon, 29 Mar 2010 00:06:46 -0700 (PDT) Received: from smtp4.smtp.bt.com (smtp4.smtp.bt.com [217.32.164.151]) by core3.amsl.com (Postfix) with ESMTP id 615723A67A3 for ; Mon, 29 Mar 2010 00:06:46 -0700 (PDT) Received: from i2kc08-ukbr.domain1.systemhost.net ([193.113.197.71]) by smtp4.smtp.bt.com with Microsoft SMTPSVC(6.0.3790.3959); Mon, 29 Mar 2010 08:07:12 +0100 Received: from cbibipnt08.iuser.iroot.adidom.com ([147.149.100.81]) by i2kc08-ukbr.domain1.systemhost.net with Microsoft SMTPSVC(6.0.3790.3959); Mon, 29 Mar 2010 08:07:12 +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 1269846431245; Mon, 29 Mar 2010 08:07:11 +0100 Received: from MUT.jungle.bt.co.uk ([10.73.61.169]) by bagheera.jungle.bt.co.uk (8.13.5/8.12.8) with ESMTP id o2T777cP032534; Mon, 29 Mar 2010 08:07:08 +0100 Message-Id: <201003290707.o2T777cP032534@bagheera.jungle.bt.co.uk> X-Mailer: QUALCOMM Windows Eudora Version 7.1.0.9 Date: Mon, 29 Mar 2010 08:06:56 +0100 To: Matt Mathis From: Bob Briscoe In-Reply-To: References: 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: 29 Mar 2010 07:07:12.0280 (UTC) FILETIME=[7465C980:01CACF0E] Cc: "re-ecn@ietf.org list" Subject: Re: [re-ECN] Abstract specification of ConEx X-BeenThere: re-ecn@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: re-inserted explicit congestion notification List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 29 Mar 2010 07:06:53 -0000 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)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 From rbriscoe@jungle.bt.co.uk Mon Mar 29 01:34:58 2010 Return-Path: X-Original-To: re-ecn@core3.amsl.com Delivered-To: re-ecn@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 5BC483A69F7 for ; Mon, 29 Mar 2010 01:34:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.795 X-Spam-Level: * X-Spam-Status: No, score=1.795 tagged_above=-999 required=5 tests=[AWL=0.182, BAYES_50=0.001, DNS_FROM_OPENWHOIS=1.13, 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 EBVwxlGnctMW for ; Mon, 29 Mar 2010 01:34:51 -0700 (PDT) Received: from smtp3.smtp.bt.com (smtp3.smtp.bt.com [217.32.164.138]) by core3.amsl.com (Postfix) with ESMTP id C9DC23A6A11 for ; Mon, 29 Mar 2010 01:30:57 -0700 (PDT) Received: from i2kc08-ukbr.domain1.systemhost.net ([193.113.197.71]) by smtp3.smtp.bt.com with Microsoft SMTPSVC(6.0.3790.3959); Mon, 29 Mar 2010 09:31:24 +0100 Received: from cbibipnt08.iuser.iroot.adidom.com ([147.149.100.81]) by i2kc08-ukbr.domain1.systemhost.net with Microsoft SMTPSVC(6.0.3790.3959); Mon, 29 Mar 2010 09:31:19 +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 1269851476332; Mon, 29 Mar 2010 09:31:16 +0100 Received: from MUT.jungle.bt.co.uk ([10.73.61.110]) by bagheera.jungle.bt.co.uk (8.13.5/8.12.8) with ESMTP id o2T8VBXK001476; Mon, 29 Mar 2010 09:31:12 +0100 Message-Id: <201003290831.o2T8VBXK001476@bagheera.jungle.bt.co.uk> X-Mailer: QUALCOMM Windows Eudora Version 7.1.0.9 Date: Mon, 29 Mar 2010 09:28:44 +0100 To: Matt Mathis From: Bob Briscoe In-Reply-To: References: <20100325154706.GA39172@verdi> <20100325212127.GA59072@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: 29 Mar 2010 08:31:19.0514 (UTC) FILETIME=[34C893A0:01CACF1A] Cc: re-ecn@ietf.org Subject: Re: [re-ECN] Comments regarding Conex charter X-BeenThere: re-ecn@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: re-inserted explicit congestion notification List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 29 Mar 2010 08:34:58 -0000 Matt, At 23:56 28/03/2010, Matt Mathis wrote: >So from this thread I realize that the ConEx charter probably needs >one more sentence. Something like "ConEx will not change the >semantics of either loss or ECN based congestion indications, nor will >it change sender transport behaviors in response to congestion >signals." Good idea. t twice: s/change/specify changes to/ ConEx will subtly change the semantics of congestion indications: it will switch on their significance and enforceability. Also, in an evolutionary sense, I hope ConEx does intend to change sender transport behaviours, but not directly; only indirectly by creating incentives ;) 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 From ingemar.s.johansson@ericsson.com Mon Mar 29 05:36:04 2010 Return-Path: X-Original-To: re-ecn@core3.amsl.com Delivered-To: re-ecn@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id E5F263A6A4C for ; Mon, 29 Mar 2010 05:36:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.881 X-Spam-Level: X-Spam-Status: No, score=0.881 tagged_above=-999 required=5 tests=[AWL=-0.250, BAYES_50=0.001, DNS_FROM_OPENWHOIS=1.13] 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 EMVvvp3+JntK for ; Mon, 29 Mar 2010 05:36:03 -0700 (PDT) Received: from mailgw9.se.ericsson.net (mailgw9.se.ericsson.net [193.180.251.57]) by core3.amsl.com (Postfix) with ESMTP id B5B243A6A4A for ; Mon, 29 Mar 2010 05:36:02 -0700 (PDT) X-AuditID: c1b4fb39-b7b85ae000005cbc-8d-4bb09ecc2701 Received: from esessmw0237.eemea.ericsson.se (Unknown_Domain [153.88.253.125]) by mailgw9.se.ericsson.net (Symantec Brightmail Gateway) with SMTP id 67.0F.23740.CCE90BB4; Mon, 29 Mar 2010 14:36:28 +0200 (CEST) Received: from ESESSCMS0356.eemea.ericsson.se ([169.254.2.100]) by esessmw0237.eemea.ericsson.se ([153.88.115.90]) with mapi; Mon, 29 Mar 2010 14:36:28 +0200 From: Ingemar Johansson S To: "re-ecn@ietf.org" Date: Mon, 29 Mar 2010 14:36:27 +0200 Thread-Topic: [re-ECN] Abstract specification of ConEx Thread-Index: AcrPD0J/4bnJysQmRaqq108m5CoH8wAKtBfQ Message-ID: <548FC4B9D57A4043AAFFE888A39429031D01FD83E1@ESESSCMS0356.eemea.ericsson.se> References: In-Reply-To: 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: "matt.mathis@gmail.com" Subject: [re-ECN] Abstract specification of ConEx X-BeenThere: re-ecn@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: re-inserted explicit congestion notification List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 29 Mar 2010 12:36:05 -0000 Hi In general I believe that here lies some of the stuff that makes ConEx diff= icult to comprehend and lack of proper graphichs to explain it does not mak= e it simpler.=20 If I understand things correctly the GREEN marks (or pre-credits) are only = needed in order to satisfy an "incentive dropper" (is it the correct term?)= so that flows are not falsely detected as cheating. The pre-credits are no= t really needed for the congestion-volume policing or ?. I guess you have turned this whole thing inside-out several times and there= fore understand it better than I do, but anyway I wonder why the pre-credit= s needed from the first place.=20 I understand that without the pre-credits the flow will constantly be in de= bt as it is up too one RTT short of credit marks. But cannot the "incentive= dropper" be made tolerant to this offset. After all cheating will manifest= it self as a constantly increasing debt that should be fairly easy to dist= inguish from the non-cheating case. Or is it fear of "gaming the system" th= at is the driver behind this ? Regards Ingemar > ---------------------------------------------------------------------- >=20 > Message: 1 > Date: Mon, 29 Mar 2010 08:06:56 +0100 > From: Bob Briscoe > Subject: Re: [re-ECN] Abstract specification of ConEx > To: Matt Mathis > Cc: "re-ecn@ietf.org list" > Message-ID: <201003290707.o2T777cP032534@bagheera.jungle.bt.co.uk> > Content-Type: text/plain; charset=3D"us-ascii"; format=3Dflowed >=20 > Matt, >=20 > 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=20 > seen at the=20 > >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=20 > >retransmissions. > >GREEN - Pre-credits to used to assure that even though the=20 > BLACK marks=20 > >are delayed by one RTT count(RED)=20 > For an unconstrained abstract encoding, I see this=20 > differently (as I tried to describe in my earlier posting on=20 > this subject): >=20 > The ECN field already shows whether it supports drop=20 > (Not-ECT) or ECN (the other three codepoints). So, if an=20 > orthoginal re-feedback field supports the following four codepoints: > - re-feedback not supported > - re-feedback unmarked > - re-feedback marked > - re-feedback pre-credit >=20 > Then, combined with Not-ECT in the ECN field, these can=20 > re-echo losses. > Or, combined with the other ECN codepoints, they can be used=20 > to re-echo ECN. >=20 >=20 > >Depending on the deployment scenario and other coding=20 > constraints the=20 > >sender marking might be three separate ternary values=20 > (unsupported, not=20 > >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=20 > >situations where transport might carry both loss and ECN=20 > information on=20 > >the same ACK. > > > >The point of the abstract specification is to permit us to=20 > list some of=20 > >the algorithms that ConEx might support, such that when it=20 > comes time=20 > >to choose a particular encoding, it is easy to understand=20 > what features=20 > >we might forfeit when using it. > > > >For example, if a flow is observed to violate=20 > >count(RED) identified as > >cheating. If I have to encode all of the sender marks into=20 > 2 bits (4 > >code points) then would be better not to conflate BLACK_Loss with=20 > >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=20 > >something better.... >=20 > I tried in my first posting of this thread. > Did you see it and think it was not useful? Or did you miss it? >=20 >=20 >=20 > Bob >=20 >=20 > >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=20 > >force to apply it to others. >=20 > ________________________________________________________________ > Bob Briscoe, BT Innovate & Design=20 >=20 >=20 >=20 > ------------------------------ >=20 > _______________________________________________ > re-ECN mailing list > re-ECN@ietf.org > https://www.ietf.org/mailman/listinfo/re-ecn >=20 >=20 > End of re-ECN Digest, Vol 13, Issue 87 > ************************************** > = From philip.eardley@bt.com Mon Mar 29 09:38:43 2010 Return-Path: X-Original-To: re-ecn@core3.amsl.com Delivered-To: re-ecn@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 6B52A3A6ACA for ; Mon, 29 Mar 2010 09:38:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.463 X-Spam-Level: X-Spam-Status: No, score=0.463 tagged_above=-999 required=5 tests=[AWL=0.332, BAYES_50=0.001, DNS_FROM_OPENWHOIS=1.13, 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 4zey4HTE+zGa for ; Mon, 29 Mar 2010 09:38:42 -0700 (PDT) Received: from smtp1.smtp.bt.com (smtp1.smtp.bt.com [217.32.164.137]) by core3.amsl.com (Postfix) with ESMTP id AEAB93A6A8B for ; Mon, 29 Mar 2010 09:38:41 -0700 (PDT) Received: from E03MVB1-UKBR.domain1.systemhost.net ([193.113.197.110]) by smtp1.smtp.bt.com with Microsoft SMTPSVC(6.0.3790.3959); Mon, 29 Mar 2010 17:39:09 +0100 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Date: Mon, 29 Mar 2010 17:39:08 +0100 Message-ID: <4A916DBC72536E419A0BD955EDECEDEC05DF8CFD@E03MVB1-UKBR.domain1.systemhost.net> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [re-ECN] Abstract specification of ConEx Thread-Index: AcrPD0J/4bnJysQmRaqq108m5CoH8wAKtBfQAAjkNIM= References: <548FC4B9D57A4043AAFFE888A39429031D01FD83E1@ESESSCMS0356.eemea.ericsson.se> From: To: , X-OriginalArrivalTime: 29 Mar 2010 16:39:09.0139 (UTC) FILETIME=[5AD6EA30:01CACF5E] Cc: matt.mathis@gmail.com Subject: Re: [re-ECN] Abstract specification of ConEx X-BeenThere: re-ecn@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: re-inserted explicit congestion notification List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 29 Mar 2010 16:38:43 -0000 i think you have summarised the issue correctly. but the issue is that a = cheater can keep creating new identities for itself. then it always gets = within the tolerance of the "incenitve dropper" ie its debt doesnt = "constantly increase" becuase it looks like a new user. =20 so if you dont have the green marks (pre-credits) then you have to - decide that identity splitting isn't a threat you will worry about - deal with the threat though some other mechanism best wishes phil ________________________________ From: re-ecn-bounces@ietf.org on behalf of Ingemar Johansson S Sent: Mon 29/03/2010 13:36 To: re-ecn@ietf.org Cc: matt.mathis@gmail.com Subject: [re-ECN] Abstract specification of ConEx Hi In general I believe that here lies some of the stuff that makes ConEx = difficult to comprehend and lack of proper graphichs to explain it does = not make it simpler. If I understand things correctly the GREEN marks (or pre-credits) are = only needed in order to satisfy an "incentive dropper" (is it the = correct term?) so that flows are not falsely detected as cheating. The = pre-credits are not really needed for the congestion-volume policing or = ?. I guess you have turned this whole thing inside-out several times and = therefore understand it better than I do, but anyway I wonder why the = pre-credits needed from the first place. I understand that without the pre-credits the flow will constantly be in = debt as it is up too one RTT short of credit marks. But cannot the = "incentive dropper" be made tolerant to this offset. After all cheating = will manifest it self as a constantly increasing debt that should be = fairly easy to distinguish from the non-cheating case. Or is it fear of = "gaming the system" that is the driver behind this ? Regards Ingemar > ---------------------------------------------------------------------- > > Message: 1 > Date: Mon, 29 Mar 2010 08:06:56 +0100 > From: Bob Briscoe > Subject: Re: [re-ECN] Abstract specification of ConEx > To: Matt Mathis > Cc: "re-ecn@ietf.org list" > Message-ID: <201003290707.o2T777cP032534@bagheera.jungle.bt.co.uk> > Content-Type: text/plain; charset=3D"us-ascii"; format=3Dflowed > > 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) identified as > >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 > > > > ------------------------------ > > _______________________________________________ > re-ECN mailing list > re-ECN@ietf.org > https://www.ietf.org/mailman/listinfo/re-ecn > > > End of re-ECN Digest, Vol 13, Issue 87 > ************************************** > _______________________________________________ re-ECN mailing list re-ECN@ietf.org https://www.ietf.org/mailman/listinfo/re-ecn From rbriscoe@jungle.bt.co.uk Mon Mar 29 10:54:30 2010 Return-Path: X-Original-To: re-ecn@core3.amsl.com Delivered-To: re-ecn@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 0CEBC3A6B18 for ; Mon, 29 Mar 2010 10:54:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.759 X-Spam-Level: * X-Spam-Status: No, score=1.759 tagged_above=-999 required=5 tests=[AWL=0.146, BAYES_50=0.001, DNS_FROM_OPENWHOIS=1.13, 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 HYA7ne9S9jDN for ; Mon, 29 Mar 2010 10:54:23 -0700 (PDT) Received: from smtp4.smtp.bt.com (smtp4.smtp.bt.com [217.32.164.151]) by core3.amsl.com (Postfix) with ESMTP id B13193A6B36 for ; Mon, 29 Mar 2010 10:54:19 -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); Mon, 29 Mar 2010 18:54:47 +0100 Received: from cbibipnt05.iuser.iroot.adidom.com ([147.149.196.177]) by i2kc06-ukbr.domain1.systemhost.net with Microsoft SMTPSVC(6.0.3790.3959); Mon, 29 Mar 2010 18:54: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 1269885285437; Mon, 29 Mar 2010 18:54:45 +0100 Received: from MUT.jungle.bt.co.uk ([10.73.62.233]) by bagheera.jungle.bt.co.uk (8.13.5/8.12.8) with ESMTP id o2THse2i016466; Mon, 29 Mar 2010 18:54:41 +0100 Message-Id: <201003291754.o2THse2i016466@bagheera.jungle.bt.co.uk> X-Mailer: QUALCOMM Windows Eudora Version 7.1.0.9 Date: Mon, 29 Mar 2010 18:54:33 +0100 To: Ingemar Johansson S From: Bob Briscoe In-Reply-To: <548FC4B9D57A4043AAFFE888A39429031D01FD83E1@ESESSCMS0356.ee mea.ericsson.se> References: <548FC4B9D57A4043AAFFE888A39429031D01FD83E1@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: 29 Mar 2010 17:54:46.0750 (UTC) FILETIME=[EB7767E0:01CACF68] Cc: "matt.mathis@gmail.com" , "re-ecn@ietf.org" Subject: Re: [re-ECN] Abstract specification of ConEx X-BeenThere: re-ecn@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: re-inserted explicit congestion notification List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 29 Mar 2010 17:54:30 -0000 Ingemar, At 13:36 29/03/2010, Ingemar Johansson S wrote: >Hi > >In general I believe that here lies some of the stuff that makes >ConEx difficult to comprehend and lack of proper graphichs to >explain it does not make it simpler. > >If I understand things correctly the GREEN marks (or pre-credits) >are only needed in order to satisfy an "incentive dropper" (is it >the correct term?) so that flows are not falsely detected as >cheating. The pre-credits are not really needed for the >congestion-volume policing or ?. > >I guess you have turned this whole thing inside-out several times >and therefore understand it better than I do, but anyway I wonder >why the pre-credits needed from the first place. Two parts to this question: - is pre-credit needed? - could pre-credit be the same codepoint as post-credit? >I understand that without the pre-credits the flow will constantly >be in debt as it is up too one RTT short of credit marks. But cannot >the "incentive dropper" be made tolerant to this offset. After all >cheating will manifest it self as a constantly increasing debt that >should be fairly easy to distinguish from the non-cheating case. Or >is it fear of "gaming the system" that is the driver behind this ? You're exactly hitting the nub of the problem: the network layer is about stateless packets. Given policing has to work across multiple networks, it cannot depend on a network holding some sort of reputation per source address (let alone port numbers too). If the network were to allow for an RTT delay, flows could just continue until they experienced congestion then start a new whitewashed flow ID rather than balance the debit marks of the congestion with credit marks. So instead, I took the approach of using the source address (and optionally port no) purely as a meaningless label that associates a set of packets. The network holds the balance between credit and debit as state. But it only stores state about a set of packets when pre-credit has been sent. Any packets without any matching state in the network (because they haven't sent credit), but that claim to support ConEx, all get treated as one bulk set of misbehaving packets. Requiring pre-credit also has the nice property that it shifts the risk of hurting others onto transports, making them care about things like overshoot at flow start. This arrangement has the important property that network state doesn't tie a flow to a fixed path (fate sharing). If a flow re-routes so it no longer goes through the same anti-cheating device, after 1RTT black or green packets will just recreate state in the new box, and the old one will timeout. IOW, it uses automatic in-band soft-state. I thought it would be best if state were not guaranteed to be held longer than a min idle period (1 sec say), after which it can timeout. If the same ID re-appears later it is taken to imply an unrelated set of packets (even if it is actually the same flow) and must supply renewed pre-credit. This accords with the transport's information about the path going stale if it is idle. It also protects against memory exhaustion attacks. HTH Bob >Regards >Ingemar > > > ---------------------------------------------------------------------- > > > > Message: 1 > > Date: Mon, 29 Mar 2010 08:06:56 +0100 > > From: Bob Briscoe > > Subject: Re: [re-ECN] Abstract specification of ConEx > > To: Matt Mathis > > Cc: "re-ecn@ietf.org list" > > Message-ID: <201003290707.o2T777cP032534@bagheera.jungle.bt.co.uk> > > Content-Type: text/plain; charset="us-ascii"; format=flowed > > > > 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) > identified as > > >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 > > > > > > > > ------------------------------ > > > > _______________________________________________ > > re-ECN mailing list > > re-ECN@ietf.org > > https://www.ietf.org/mailman/listinfo/re-ecn > > > > > > End of re-ECN Digest, Vol 13, Issue 87 > > ************************************** > > ________________________________________________________________ Bob Briscoe, BT Innovate & Design From philip.eardley@bt.com Tue Mar 30 03:40:11 2010 Return-Path: X-Original-To: re-ecn@core3.amsl.com Delivered-To: re-ecn@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 129BB3A688F for ; Tue, 30 Mar 2010 03:40:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.028 X-Spam-Level: X-Spam-Status: No, score=-0.028 tagged_above=-999 required=5 tests=[AWL=-0.160, BAYES_50=0.001, DNS_FROM_OPENWHOIS=1.13, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 1E85zp0g7LVh for ; Tue, 30 Mar 2010 03:40:09 -0700 (PDT) Received: from smtp4.smtp.bt.com (smtp4.smtp.bt.com [217.32.164.151]) by core3.amsl.com (Postfix) with ESMTP id BC2933A67B1 for ; Tue, 30 Mar 2010 03:40:02 -0700 (PDT) Received: from E03MVB1-UKBR.domain1.systemhost.net ([193.113.197.110]) by smtp4.smtp.bt.com with Microsoft SMTPSVC(6.0.3790.3959); Tue, 30 Mar 2010 11:40:30 +0100 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01CACFF5.6AFDE7D5" Date: Tue, 30 Mar 2010 11:40:30 +0100 Message-ID: <4A916DBC72536E419A0BD955EDECEDEC06363F37@E03MVB1-UKBR.domain1.systemhost.net> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: New draft Conex charter - for rapid comments please Thread-Index: AcrP9WpVs8Py8kXCTM603MXv5kYQMA== From: To: X-OriginalArrivalTime: 30 Mar 2010 10:40:30.0792 (UTC) FILETIME=[6B517C80:01CACFF5] Subject: [re-ECN] New draft Conex charter - for rapid comments please X-BeenThere: re-ecn@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: re-inserted explicit congestion notification List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 30 Mar 2010 10:40:11 -0000 This is a multi-part message in MIME format. ------_=_NextPart_001_01CACFF5.6AFDE7D5 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Just to let those of you who weren't in Anaheim about progress.=20 We had two good meetings, there are extensive jabber notes (offiicial = meeting notes to follow) http://www.ietf.org/jabber/logs/conex/2010-03-24.txt http://www.ietf.org/jabber/logs/conex/2010-03-25.txt We discussed how to change the Charter to meet the issues raised. The = following were proposed and received good support: * Experimental track (no Standards track docs) * for the use cases work, concentrate on one use case (where the end = hosts & the destination network are conex-enabled, but not the other = networks) * do IPv6 header encoding * suggest a work item in tsvwg (probably) about assigning "bit 48" as = Experimental in the IPv4 header=20 Here's a new draft Charter implementing these changes. If we can = complete by Thursday lunchtime, then we should get it into the next IESG = call. Thanks Phil & Leslie --- Congestion Exposure (CONEX) WG The purpose of the CONEX working group is to develop a mechanism by = which senders inform the network about the congestion their packets = encounter. Today, the network signals congestion by ECN marking or = dropping packets, the receiver passes this information back to the = sender in transport layer acknowledgements, where the sender makes an = adjustment to its window size or data rate as appropriate. The = mechanism to be developed under CONEX will enable the sender to also = relay the congestion information back into the IP layer such that the = total level of congestion is visible to all IP devices along the path.=20 The primary goal of the CONEX WG is to develop experimental = specifications to achieve the above. To help explore how to squeeze the = necessary information into a very limited numbers of header bits, the WG = will also develop an abstract specification for the congestion exposure = mechanism, independent of transport and protocol version. Primary work items are: * An Informational document with an abstract specification for the = congestion exposure mechanism * Experimental Specification of IPv6 packet structure that = encapsulates CONEX information (header bits, interpretation). * Experimental Specification for 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 which can be applied as a key element of congestion = management solutions in a wide variety of use cases. However, the WG = will initially focus solely on one use case, where the end hosts and the = network of the destination end host are CONEX-enabled but the other = networks are not. CONEX information can assist the network operator's = traffic management and incentivise LEDBAT-like applications. Experiments = on the use case are encouraged and the WG will solicit input about their = process and findings. The output of the WG includes Informational = document(s) for the use case covering: * Assumptions it makes * Deployment considerations * Security Threats * Advice on mitigating threats (detailed work on a mechanism to = mitigate the threats is out of the initial scope) * Description of results from experiments on the use case In establishing this working group, much interest was expressed in = pursuing an IPv4 specification. A new work item proposed for TSVWG would = define how 'bit 48' of the IPv4 header can be used for Experiments. At = the appropriate time, the CONEX WG will consider rechartering to include = a work item to specify the IPv4 packet structure to encapsulate CONEX = information.=20 Milestones Jul 2010 Internet-draft Informational document with an abstract = specification for the congestion exposure mechanism Jul 2010 Internet-draft use case Sep 2010 Internet-draft specification of IPv6 packet structure. Sep 2010 Internet-draft specification for modification to TCP Mar 2011 Informational RFC abstract specification of the congestion = exposure mechanism Mar 2011 Informational RFC use case Sep 2011 Experimental RFC specification of IPv6 packet structure Sep 2011 Experimental RFC specification for modification to TCP ------_=_NextPart_001_01CACFF5.6AFDE7D5 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable New draft Conex charter - for rapid comments please

Just to let those of you who weren't in = Anaheim about progress.

We had two good meetings, there are = extensive jabber notes (offiicial meeting notes to follow)
http://www.ietf.org/jabber/logs/conex/2010-03-24.txt
http://www.ietf.org/jabber/logs/conex/2010-03-25.txt

We discussed how to change the Charter = to meet the issues raised. The following were proposed and received good = support:

* Experimental track (no Standards = track docs)
* for the use cases work, concentrate = on one use case (where the end hosts & the destination network are = conex-enabled, but not the other networks)

* do IPv6 header encoding
* suggest a work item in tsvwg = (probably) about assigning "bit 48" as Experimental in the = IPv4 header

Here's a new draft Charter implementing = these changes. If we can complete by Thursday lunchtime, then we should = get it into the next IESG call.

Thanks
Phil & Leslie
---
Congestion Exposure (CONEX) WG


The purpose of the CONEX working group = is to develop a mechanism by which senders inform the network about the = congestion their packets encounter. Today, the network signals = congestion by ECN marking or dropping packets, the receiver passes this = information back to the sender in transport layer acknowledgements, = where the sender makes an adjustment to its window size or data rate as = appropriate.  The mechanism to be developed under CONEX will enable = the sender to also relay the congestion information back into the IP = layer such that the total level of congestion is visible to all IP = devices along the path.

The primary goal of the CONEX WG is to = develop experimental specifications to achieve the above. To help = explore how to squeeze the necessary information into a very limited = numbers of header bits, the WG will also develop an abstract = specification for the congestion exposure mechanism, independent of = transport and protocol version.

Primary work items are:

*       = An Informational document with an abstract specification for the = congestion exposure mechanism
* =A0 =A0 =A0 Experimental = Specification of IPv6 packet structure that encapsulates CONEX = information (header bits, interpretation).

* =A0 =A0 =A0 Experimental = Specification for 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 which can be applied as a key = element of congestion management solutions in a wide variety of use = cases. However, the WG will initially focus solely on one use case, = where the end hosts and the network of the destination end host are = CONEX-enabled but the other networks are not. CONEX information can = assist the network operator's traffic management and incentivise = LEDBAT-like applications. Experiments on the use case are encouraged and = the WG will solicit input about their process and findings. The output = of the WG includes Informational document(s) for the use case = covering:

* =A0 =A0 =A0 Assumptions it = makes
* =A0 =A0 =A0 Deployment = considerations
* =A0 =A0 =A0 Security Threats
* =A0 =A0 =A0 Advice on mitigating = threats (detailed work on a mechanism to mitigate the threats is out of = the initial scope)
* =A0 =A0 =A0 Description of results = from experiments on the use case

In establishing this working group, = much interest was expressed in pursuing an IPv4 specification. A new = work item proposed for TSVWG would define how 'bit 48' of the IPv4 = header can be used for Experiments. At the appropriate time, the CONEX = WG will consider rechartering to include a work item to specify the IPv4 = packet structure to encapsulate CONEX information.

Milestones

Jul 2010 Internet-draft Informational = document with an abstract specification for the congestion exposure = mechanism

Jul 2010 Internet-draft use case

Sep 2010 Internet-draft specification = of IPv6 packet structure.

Sep 2010 Internet-draft specification = for modification to TCP

Mar 2011 Informational RFC abstract = specification of the congestion exposure mechanism

Mar 2011 Informational RFC use = case

Sep 2011 Experimental RFC specification = of IPv6 packet structure

Sep 2011 Experimental RFC specification = for modification to TCP

------_=_NextPart_001_01CACFF5.6AFDE7D5-- From ingemar.s.johansson@ericsson.com Tue Mar 30 04:40:22 2010 Return-Path: X-Original-To: re-ecn@core3.amsl.com Delivered-To: re-ecn@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id F376D3A688F for ; Tue, 30 Mar 2010 04:40:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.469 X-Spam-Level: X-Spam-Status: No, score=-1.469 tagged_above=-999 required=5 tests=[AWL=1.400, BAYES_50=0.001, DNS_FROM_OPENWHOIS=1.13, 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 zhK-NBHsjNhW for ; Tue, 30 Mar 2010 04:40:20 -0700 (PDT) Received: from mailgw10.se.ericsson.net (mailgw10.se.ericsson.net [193.180.251.61]) by core3.amsl.com (Postfix) with ESMTP id 28DC23A6953 for ; Tue, 30 Mar 2010 04:40:15 -0700 (PDT) X-AuditID: c1b4fb3d-b7bf6ae000005bec-1c-4bb1e33bdf25 Received: from esessmw0256.eemea.ericsson.se (Unknown_Domain [153.88.253.125]) by mailgw10.se.ericsson.net (Symantec Brightmail Gateway) with SMTP id 01.B8.23532.B33E1BB4; Tue, 30 Mar 2010 13:40:44 +0200 (CEST) Received: from ESESSCMS0356.eemea.ericsson.se ([169.254.2.100]) by esessmw0256.eemea.ericsson.se ([10.2.3.125]) with mapi; Tue, 30 Mar 2010 13:40:43 +0200 From: Ingemar Johansson S To: Bob Briscoe , "philip.eardley@bt.com" Date: Tue, 30 Mar 2010 13:40:41 +0200 Thread-Topic: [re-ECN] Abstract specification of ConEx Thread-Index: AcrPaOx8TAxjbT1gT32K6kg9R1yFOQAlGJSw Message-ID: <548FC4B9D57A4043AAFFE888A39429031D02006575@ESESSCMS0356.eemea.ericsson.se> References: <548FC4B9D57A4043AAFFE888A39429031D01FD83E1@ESESSCMS0356.eemea.ericsson.se> <201003291754.o2THse2i016466@bagheera.jungle.bt.co.uk> In-Reply-To: <201003291754.o2THse2i016466@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: "re-ecn@ietf.org" Subject: Re: [re-ECN] Abstract specification of ConEx X-BeenThere: re-ecn@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: re-inserted explicit congestion notification List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 30 Mar 2010 11:40:22 -0000 Thanks Bob and Phil for the explanation.=20 Can't say that I get all the details around the pre-credits but if this WG = flies I am confident that I will get to understand this piece as well. /Ingemar > -----Original Message----- > From: Bob Briscoe [mailto:rbriscoe@jungle.bt.co.uk]=20 > Sent: den 29 mars 2010 19:55 > To: Ingemar Johansson S > Cc: re-ecn@ietf.org; matt.mathis@gmail.com > Subject: Re: [re-ECN] Abstract specification of ConEx >=20 > Ingemar, >=20 > At 13:36 29/03/2010, Ingemar Johansson S wrote: > >Hi > > > >In general I believe that here lies some of the stuff that=20 > makes ConEx=20 > >difficult to comprehend and lack of proper graphichs to=20 > explain it does=20 > >not make it simpler. > > > >If I understand things correctly the GREEN marks (or=20 > pre-credits) are=20 > >only needed in order to satisfy an "incentive dropper" (is it the=20 > >correct term?) so that flows are not falsely detected as=20 > cheating. The=20 > >pre-credits are not really needed for the congestion-volume=20 > policing or=20 > >?. > > > >I guess you have turned this whole thing inside-out several=20 > times and=20 > >therefore understand it better than I do, but anyway I=20 > wonder why the=20 > >pre-credits needed from the first place. >=20 > Two parts to this question: > - is pre-credit needed? > - could pre-credit be the same codepoint as post-credit? >=20 > >I understand that without the pre-credits the flow will=20 > constantly be=20 > >in debt as it is up too one RTT short of credit marks. But=20 > cannot the=20 > >"incentive dropper" be made tolerant to this offset. After=20 > all cheating=20 > >will manifest it self as a constantly increasing debt that should be=20 > >fairly easy to distinguish from the non-cheating case. Or is=20 > it fear of=20 > >"gaming the system" that is the driver behind this ? >=20 > You're exactly hitting the nub of the problem: the network=20 > layer is about stateless packets. Given policing has to work=20 > across multiple networks, it cannot depend on a network=20 > holding some sort of reputation per source address (let alone=20 > port numbers too). >=20 > If the network were to allow for an RTT delay, flows could=20 > just continue until they experienced congestion then start a=20 > new whitewashed flow ID rather than balance the debit marks=20 > of the congestion with credit marks. >=20 > So instead, I took the approach of using the source address=20 > (and optionally port no) purely as a meaningless label that=20 > associates a set of packets. The network holds the balance=20 > between credit and debit as state. But it only stores state=20 > about a set of packets when pre-credit has been sent. Any=20 > packets without any matching state in the network (because=20 > they haven't sent credit), but that claim to support ConEx,=20 > all get treated as one bulk set of misbehaving packets. >=20 > Requiring pre-credit also has the nice property that it=20 > shifts the risk of hurting others onto transports, making=20 > them care about things like overshoot at flow start. >=20 > This arrangement has the important property that network=20 > state doesn't tie a flow to a fixed path (fate sharing). If a=20 > flow re-routes so it no longer goes through the same=20 > anti-cheating device, after 1RTT black or green packets will=20 > just recreate state in the new box, and the old one will=20 > timeout. IOW, it uses automatic in-band soft-state. >=20 > I thought it would be best if state were not guaranteed to be=20 > held longer than a min idle period (1 sec say), after which=20 > it can timeout. If the same ID re-appears later it is taken=20 > to imply an unrelated set of packets (even if it is actually=20 > the same flow) and must supply renewed pre-credit. This=20 > accords with the transport's information about the path going=20 > stale if it is idle. It also protects against memory=20 > exhaustion attacks. >=20 > HTH >=20 >=20 >=20 > Bob >=20 >=20 > >Regards > >Ingemar > > > > >=20 > -------------------------------------------------------------------- > > > -- > > > > > > Message: 1 > > > Date: Mon, 29 Mar 2010 08:06:56 +0100 > > > From: Bob Briscoe > > > Subject: Re: [re-ECN] Abstract specification of ConEx > > > To: Matt Mathis > > > Cc: "re-ecn@ietf.org list" > > > Message-ID: <201003290707.o2T777cP032534@bagheera.jungle.bt.co.uk> > > > Content-Type: text/plain; charset=3D"us-ascii"; format=3Dflowed > > > > > > Matt, > > > > > > At 01:39 29/03/2010, Matt Mathis wrote: > > > >If it supports > > > >ConEx, the sender needs to be able to send three=20 > 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=20 > losses signaled. > > > >For reliable protocols should be in exact agreement with=20 > > > >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=20 > differently (as I=20 > > > 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=20 > orthoginal=20 > > > 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=20 > > > losses. > > > Or, combined with the other ECN codepoints, they can be used to=20 > > > 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=20 > reasonable to > > > >assume one 5 valued signal, but this representation can=20 > not model=20 > > > >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=20 > > > >count(RED) > > identified as > > > >cheating. If I have to encode all of the sender marks into > > > 2 bits (4 > > > >code points) then would be better not to conflate=20 > BLACK_Loss with=20 > > > >either BLACK_ECN or GREEN, because doing so will either weaken or > > > >break the cheating test. It looks as though it might=20 > be ok to use a > > > >single code point for GREEN and BLACK_ECN marks. > > > > > > > >My notation is not particularly good. Perhaps somebody=20 > can suggest=20 > > > >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=20 > Truth" and use=20 > > > >force to apply it to others. > > > > > > ________________________________________________________________ > > > Bob Briscoe, BT Innovate & Design > > > > > > > > > > > > ------------------------------ > > > > > > _______________________________________________ > > > re-ECN mailing list > > > re-ECN@ietf.org > > > https://www.ietf.org/mailman/listinfo/re-ecn > > > > > > > > > End of re-ECN Digest, Vol 13, Issue 87 > > > ************************************** > > > >=20 > ________________________________________________________________ > Bob Briscoe, BT Innovate & Design=20 >=20 > = From ingemar.s.johansson@ericsson.com Tue Mar 30 04:56:59 2010 Return-Path: X-Original-To: re-ecn@core3.amsl.com Delivered-To: re-ecn@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 037AD3A697A for ; Tue, 30 Mar 2010 04:56:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.925 X-Spam-Level: X-Spam-Status: No, score=-0.925 tagged_above=-999 required=5 tests=[AWL=0.544, BAYES_00=-2.599, DNS_FROM_OPENWHOIS=1.13] 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 Rf0bOq0r3+wg for ; Tue, 30 Mar 2010 04:56:57 -0700 (PDT) Received: from mailgw9.se.ericsson.net (mailgw9.se.ericsson.net [193.180.251.57]) by core3.amsl.com (Postfix) with ESMTP id 0A0993A677C for ; Tue, 30 Mar 2010 04:56:56 -0700 (PDT) X-AuditID: c1b4fb39-b7b85ae000005cbc-0e-4bb1e724f739 Received: from esessmw0184.eemea.ericsson.se (Unknown_Domain [153.88.253.125]) by mailgw9.se.ericsson.net (Symantec Brightmail Gateway) with SMTP id 33.0C.23740.427E1BB4; Tue, 30 Mar 2010 13:57:25 +0200 (CEST) Received: from ESESSCMS0356.eemea.ericsson.se ([169.254.2.100]) by esessmw0184.eemea.ericsson.se ([153.88.115.81]) with mapi; Tue, 30 Mar 2010 13:57:24 +0200 From: Ingemar Johansson S To: "re-ecn@ietf.org" Date: Tue, 30 Mar 2010 13:57:23 +0200 Thread-Topic: [re-ECN] New draft Conex charter - for rapid comments please Thread-Index: AcrP9XdC72lh9C65Qcqi+ufIT9zrQgABzrDg Message-ID: <548FC4B9D57A4043AAFFE888A39429031D0200659F@ESESSCMS0356.eemea.ericsson.se> References: In-Reply-To: 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== Subject: Re: [re-ECN] New draft Conex charter - for rapid comments please X-BeenThere: re-ecn@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: re-inserted explicit congestion notification List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 30 Mar 2010 11:56:59 -0000 Hi I have one question. Based on my recently gained understanding about "emoti= onal feelings" :-) around bit48 in IPv4 I can understand why you propose to= make use of this bit experimental.=20 However when it comes to IPv6 I am not really convinced why this need to be= experimental. As I understand it the ConEx info will be encoded in an IPv6= extension that is encoded in such a way that a node can safely ignore it a= nd just let it pass through if it does not understand it or does not care.= =20 My problem with the word "Experimental" is that it is just.. experimental a= nd I have a hard time to understand if e.g 3GPP is interested at all to sup= port something that is experimental.=20 What is the risk of making the IPv6 header extension standards track ? Regards /Ingemar > ---------------------------------------------------------------------- >=20 > Message: 1 > Date: Tue, 30 Mar 2010 11:40:30 +0100 > From: > Subject: [re-ECN] New draft Conex charter - for rapid comments please > To: > Message-ID: > =09 > <4A916DBC72536E419A0BD955EDECEDEC06363F37@E03MVB1-UKBR.domain1 > .systemhost.net> > =09 > Content-Type: text/plain; charset=3D"iso-8859-1" >=20 > Just to let those of you who weren't in Anaheim about progress.=20 >=20 > We had two good meetings, there are extensive jabber notes=20 > (offiicial meeting notes to follow)=20 > http://www.ietf.org/jabber/logs/conex/2010-03-24.txt > http://www.ietf.org/jabber/logs/conex/2010-03-25.txt >=20 > We discussed how to change the Charter to meet the issues=20 > raised. The following were proposed and received good support: > * Experimental track (no Standards track docs) > * for the use cases work, concentrate on one use case (where=20 > the end hosts & the destination network are conex-enabled,=20 > but not the other networks) > * do IPv6 header encoding > * suggest a work item in tsvwg (probably) about assigning=20 > "bit 48" as Experimental in the IPv4 header=20 >=20 > Here's a new draft Charter implementing these changes. If we=20 > can complete by Thursday lunchtime, then we should get it=20 > into the next IESG call. >=20 > Thanks > Phil & Leslie > --- > Congestion Exposure (CONEX) WG >=20 >=20 > The purpose of the CONEX working group is to develop a=20 > mechanism by which senders inform the network about the=20 > congestion their packets encounter. Today, the network=20 > signals congestion by ECN marking or dropping packets, the=20 > receiver passes this information back to the sender in=20 > transport layer acknowledgements, where the sender makes an=20 > adjustment to its window size or data rate as appropriate. =20 > The mechanism to be developed under CONEX will enable the=20 > sender to also relay the congestion information back into the=20 > IP layer such that the total level of congestion is visible=20 > to all IP devices along the path.=20 >=20 > The primary goal of the CONEX WG is to develop experimental=20 > specifications to achieve the above. To help explore how to=20 > squeeze the necessary information into a very limited numbers=20 > of header bits, the WG will also develop an abstract=20 > specification for the congestion exposure mechanism,=20 > independent of transport and protocol version. >=20 > Primary work items are: >=20 > * An Informational document with an abstract=20 > specification for the congestion exposure mechanism > * Experimental Specification of IPv6 packet structure=20 > that encapsulates CONEX information (header bits, interpretation). > * Experimental Specification for modification to TCP,=20 > for the timely transport of congestion information from the=20 > destination to the sender >=20 > It is believed that the CONEX mechanism will be useful as a=20 > generative technology which can be applied as a key element=20 > of congestion management solutions in a wide variety of use=20 > cases. However, the WG will initially focus solely on one use=20 > case, where the end hosts and the network of the destination=20 > end host are CONEX-enabled but the other networks are not.=20 > CONEX information can assist the network operator's traffic=20 > management and incentivise LEDBAT-like applications.=20 > Experiments on the use case are encouraged and the WG will=20 > solicit input about their process and findings. The output of=20 > the WG includes Informational document(s) for the use case covering: >=20 > * Assumptions it makes > * Deployment considerations > * Security Threats > * Advice on mitigating threats (detailed work on a=20 > mechanism to mitigate the threats is out of the initial scope) > * Description of results from experiments on the use case >=20 > In establishing this working group, much interest was=20 > expressed in pursuing an IPv4 specification. A new work item=20 > proposed for TSVWG would define how 'bit 48' of the IPv4=20 > header can be used for Experiments. At the appropriate time,=20 > the CONEX WG will consider rechartering to include a work=20 > item to specify the IPv4 packet structure to encapsulate=20 > CONEX information.=20 >=20 > Milestones >=20 > Jul 2010 Internet-draft Informational document with an=20 > abstract specification for the congestion exposure mechanism >=20 > Jul 2010 Internet-draft use case >=20 > Sep 2010 Internet-draft specification of IPv6 packet structure. >=20 > Sep 2010 Internet-draft specification for modification to TCP >=20 > Mar 2011 Informational RFC abstract specification of the=20 > congestion exposure mechanism >=20 > Mar 2011 Informational RFC use case >=20 > Sep 2011 Experimental RFC specification of IPv6 packet structure >=20 > Sep 2011 Experimental RFC specification for modification to TCP >=20 > -------------- next part -------------- > An HTML attachment was scrubbed... > URL:=20 > 330/e093c8a6/attachment.htm> >=20 > ------------------------------ >=20 > _______________________________________________ > re-ECN mailing list > re-ECN@ietf.org > https://www.ietf.org/mailman/listinfo/re-ecn >=20 >=20 > End of re-ECN Digest, Vol 13, Issue 92 > ************************************** > = From dave.mcdysan@verizon.com Tue Mar 30 05:04:38 2010 Return-Path: X-Original-To: re-ecn@core3.amsl.com Delivered-To: re-ecn@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id D38D53A6806 for ; Tue, 30 Mar 2010 05:04:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.756 X-Spam-Level: X-Spam-Status: No, score=-0.756 tagged_above=-999 required=5 tests=[AWL=-0.146, BAYES_20=-0.74, DNS_FROM_OPENWHOIS=1.13, 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 3QxoWPVxVYOS for ; Tue, 30 Mar 2010 05:04:34 -0700 (PDT) Received: from tpamail4.verizon.com (tpamail4.verizon.com [192.76.82.161]) by core3.amsl.com (Postfix) with ESMTP id CC7313A6896 for ; Tue, 30 Mar 2010 05:04:23 -0700 (PDT) Received: from tpaintrmemf3.verizon.com (tpaintrmemf3.verizon.com [138.83.67.58]) by tpamail4.verizon.com (8.13.6/8.13.3) with ESMTP id o2UC2odA003774; Tue, 30 Mar 2010 08:03:07 -0400 (EDT) X-AuditID: 8a53433a-b7b49ae000004a57-85-4bb1e8e14a29 Received: from smtptpa3.verizon.com ( [138.83.71.176]) by tpaintrmemf3.verizon.com (EMF) with SMTP id 05.E4.19031.1E8E1BB4; Tue, 30 Mar 2010 08:04:49 -0400 (EDT) Received: from FHDP1CCMXCG01.us.one.verizon.com ([166.68.240.33]) by smtptpa3.verizon.com (8.13.3/8.13.3) with ESMTP id o2UC4j2l029261; Tue, 30 Mar 2010 08:04:49 -0400 (EDT) Received: from FHDP1LUMXCV14.us.one.verizon.com ([166.68.125.35]) by FHDP1CCMXCG01.us.one.verizon.com with Microsoft SMTPSVC(6.0.3790.3959); Tue, 30 Mar 2010 08:04:45 -0400 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: quoted-printable Date: Tue, 30 Mar 2010 08:04:03 -0400 Message-ID: <793F49BA1FC821409F99F10862A0E4DB0658A79C@FHDP1LUMXCV14.us.one.verizon.com> In-Reply-To: <4A916DBC72536E419A0BD955EDECEDEC06363F37@E03MVB1-UKBR.domain1.systemhost.net> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [re-ECN] New draft Conex charter - for rapid comments please Thread-Index: AcrP9WpVs8Py8kXCTM603MXv5kYQMAACh23w References: <4A916DBC72536E419A0BD955EDECEDEC06363F37@E03MVB1-UKBR.domain1.systemhost.net> From: "Mcdysan, David E" To: , X-OriginalArrivalTime: 30 Mar 2010 12:04:45.0400 (UTC) FILETIME=[30197580:01CAD001] X-Brightmail-Tracker: AAAAAA== Subject: Re: [re-ECN] New draft Conex charter - for rapid comments please X-BeenThere: re-ecn@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: re-inserted explicit congestion notification List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 30 Mar 2010 12:04:38 -0000 Phil, =20 A few comments in line below prefixed by DM. =20 Thanks, Dave ________________________________ From: re-ecn-bounces@ietf.org [mailto:re-ecn-bounces@ietf.org] On Behalf Of philip.eardley@bt.com Sent: Tuesday, March 30, 2010 6:41 AM To: re-ecn@ietf.org Subject: [re-ECN] New draft Conex charter - for rapid comments please =09 =09 Just to let those of you who weren't in Anaheim about progress.=20 We had two good meetings, there are extensive jabber notes (offiicial meeting notes to follow)=20 http://www.ietf.org/jabber/logs/conex/2010-03-24.txt=20 http://www.ietf.org/jabber/logs/conex/2010-03-25.txt=20 We discussed how to change the Charter to meet the issues raised. The following were proposed and received good support: * Experimental track (no Standards track docs)=20 * for the use cases work, concentrate on one use case (where the end hosts & the destination network are conex-enabled, but not the other networks) * do IPv6 header encoding=20 * suggest a work item in tsvwg (probably) about assigning "bit 48" as Experimental in the IPv4 header=20 Here's a new draft Charter implementing these changes. If we can complete by Thursday lunchtime, then we should get it into the next IESG call. Thanks=20 Phil & Leslie=20 ---=20 Congestion Exposure (CONEX) WG=20 The purpose of the CONEX working group is to develop a mechanism by which senders inform=20 some=20 the network about the congestion their packets encounter. Today, ^^^^^ networks signal DM: Not every implementation supports ECN marking in the network, nor does every operator enable it in implementations that do. Slight rewording proposed to not give the impression that network elements (e.g., routers) setting ECN is already widely done today. congestion by ECN marking or dropping packets, the receiver passes this information back to the sender in transport layer acknowledgements, where the sender makes an adjustment to its window size or data rate as appropriate. The mechanism to be developed under CONEX will enable the sender to also relay the congestion information back into the IP layer such that the total level of congestion is visible to all IP devices along the path.=20 DM: IPv6 may provide additional bits or methods to signal congestion as an alternative to and/or as a complement to ECN.=20 The primary goal of the CONEX WG is to develop experimental specifications to achieve the above. To help explore how to squeeze the necessary information into a very limited numbers of header bits,=20 DM: This limitation seems to apply to only IPv4. Can the charter separate this case for IPv4 fromt that of IPv6. Recall Adrian's comments at the mike. the WG will also develop an abstract specification for the congestion exposure mechanism, independent of transport and protocol version. Primary work items are:=20 * An Informational document with an abstract specification for the congestion exposure mechanism=20 DM: suggesting adding "unconstrained by the number of available bits in the IP header" * Experimental Specification of IPv6 packet structure that encapsulates CONEX information (header bits, interpretation). * Experimental Specification for 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 which can be applied as a key element of congestion management solutions in a wide variety of use cases. However, the WG will initially focus solely on one use case, where the end hosts and the network of the destination end host are CONEX-enabled but the other networks are not. CONEX information can assist the network operator's traffic management and incentivise LEDBAT-like applications. DM: This is an extremely important point -- working only with TCP (e.g., ECN) is not enough, the use cases must include protocols that are a client of the TCP. Not clear from this wording whether this will be part of the use case, and I would like for it to be part of the use case.=20 Experiments on the use case are encouraged and the WG will solicit input about their process and findings. The output of the WG includes Informational document(s) for the use case covering: * Assumptions it makes=20 * Deployment considerations=20 * Security Threats=20 * Advice on mitigating threats (detailed work on a mechanism to mitigate the threats is out of the initial scope)=20 * Description of results from experiments on the use case=20 In establishing this working group, much interest was expressed in pursuing an IPv4 specification. A new work item proposed for TSVWG would define how 'bit 48' of the IPv4 header can be used for Experiments. At the appropriate time, the CONEX WG will consider rechartering to include a work item to specify the IPv4 packet structure to encapsulate CONEX information.=20 Milestones=20 Jul 2010 Internet-draft Informational document with an abstract specification for the congestion exposure mechanism=20 Jul 2010 Internet-draft use case=20 Sep 2010 Internet-draft specification of IPv6 packet structure.=20 Sep 2010 Internet-draft specification for modification to TCP=20 Mar 2011 Informational RFC abstract specification of the congestion exposure mechanism=20 Mar 2011 Informational RFC use case=20 Sep 2011 Experimental RFC specification of IPv6 packet structure Sep 2011 Experimental RFC specification for modification to TCP=20 From philip.eardley@bt.com Tue Mar 30 08:12:42 2010 Return-Path: X-Original-To: re-ecn@core3.amsl.com Delivered-To: re-ecn@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id CD71D3A6BF8 for ; Tue, 30 Mar 2010 08:12:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.268 X-Spam-Level: X-Spam-Status: No, score=-0.268 tagged_above=-999 required=5 tests=[AWL=0.112, BAYES_05=-1.11, DNS_FROM_OPENWHOIS=1.13, J_CHICKENPOX_72=0.6, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id XEYQgH8oLANW for ; Tue, 30 Mar 2010 08:12:40 -0700 (PDT) Received: from smtp4.smtp.bt.com (smtp4.smtp.bt.com [217.32.164.151]) by core3.amsl.com (Postfix) with ESMTP id 90BF23A6BF4 for ; Tue, 30 Mar 2010 08:12:35 -0700 (PDT) Received: from E03MVB1-UKBR.domain1.systemhost.net ([193.113.197.110]) by smtp4.smtp.bt.com with Microsoft SMTPSVC(6.0.3790.3959); Tue, 30 Mar 2010 16:13:04 +0100 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Tue, 30 Mar 2010 16:13:03 +0100 Message-ID: <4A916DBC72536E419A0BD955EDECEDEC06363F3E@E03MVB1-UKBR.domain1.systemhost.net> In-Reply-To: <548FC4B9D57A4043AAFFE888A39429031D0200659F@ESESSCMS0356.eemea.ericsson.se> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [re-ECN] New draft Conex charter - for rapid comments please Thread-Index: AcrP9XdC72lh9C65Qcqi+ufIT9zrQgABzrDgAAd7M5A= From: To: , X-OriginalArrivalTime: 30 Mar 2010 15:13:04.0498 (UTC) FILETIME=[7EE2FD20:01CAD01B] Subject: Re: [re-ECN] New draft Conex charter - for rapid comments please X-BeenThere: re-ecn@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: re-inserted explicit congestion notification List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 30 Mar 2010 15:12:42 -0000 > -----Original Message----- > From: Ingemar Johansson S [mailto:ingemar.s.johansson@ericsson.com]=20 > Sent: 30 March 2010 12:57 > To: re-ecn@ietf.org > Cc: Eardley,PL,Philip,DEE1 R > Subject: RE: [re-ECN] New draft Conex charter - for rapid=20 > comments please >=20 >=20 > Hi >=20 > I have one question. Based on my recently gained=20 > understanding about "emotional feelings" :-) around bit48 in=20 > IPv4 I can understand why you propose to make use of this bit=20 > experimental.=20 >=20 > However when it comes to IPv6 I am not really convinced why=20 > this need to be experimental. As I understand it the ConEx=20 > info will be encoded in an IPv6 extension that is encoded in=20 > such a way that a node can safely ignore it and just let it=20 > pass through if it does not understand it or does not care.=20 > My problem with the word "Experimental" is that it is just..=20 > experimental and I have a hard time to understand if e.g 3GPP=20 > is interested at all to support something that is experimental.=20 > What is the risk of making the IPv6 header extension standards track ? I have sympathy with your viewpoint - but the IESG have given us guidance that it should be Experimental. There is no harda nf fast guidance on what's experimental and what's standards track. Safety is one thing I've heard to distinguish them (as you say) - another is "do we believe this is baked enough for the IETF to recommend it for widespread deployment?". On the positive side, the transition from Experimental to standards track is a well-accepted path.=20 >=20 > Regards > /Ingemar > >=20 > ---------------------------------------------------------------------- > >=20 > > Message: 1 > > Date: Tue, 30 Mar 2010 11:40:30 +0100 > > From: > > Subject: [re-ECN] New draft Conex charter - for rapid=20 > comments please > > To: > > Message-ID: > > =09 > > <4A916DBC72536E419A0BD955EDECEDEC06363F37@E03MVB1-UKBR.domain1 > > .systemhost.net> > > =09 > > Content-Type: text/plain; charset=3D"iso-8859-1" > >=20 > > Just to let those of you who weren't in Anaheim about progress. > >=20 > > We had two good meetings, there are extensive jabber notes > > (offiicial meeting notes to follow)=20 > > http://www.ietf.org/jabber/logs/conex/2010-03-24.txt > > http://www.ietf.org/jabber/logs/conex/2010-03-25.txt > >=20 > > We discussed how to change the Charter to meet the issues > > raised. The following were proposed and received good support: > > * Experimental track (no Standards track docs) > > * for the use cases work, concentrate on one use case (where=20 > > the end hosts & the destination network are conex-enabled,=20 > > but not the other networks) > > * do IPv6 header encoding > > * suggest a work item in tsvwg (probably) about assigning=20 > > "bit 48" as Experimental in the IPv4 header=20 > >=20 > > Here's a new draft Charter implementing these changes. If we > > can complete by Thursday lunchtime, then we should get it=20 > > into the next IESG call. > >=20 > > Thanks > > Phil & Leslie > > --- > > Congestion Exposure (CONEX) WG > >=20 > >=20 > > The purpose of the CONEX working group is to develop a > > mechanism by which senders inform the network about the=20 > > congestion their packets encounter. Today, the network=20 > > signals congestion by ECN marking or dropping packets, the=20 > > receiver passes this information back to the sender in=20 > > transport layer acknowledgements, where the sender makes an=20 > > adjustment to its window size or data rate as appropriate. =20 > > The mechanism to be developed under CONEX will enable the=20 > > sender to also relay the congestion information back into the=20 > > IP layer such that the total level of congestion is visible=20 > > to all IP devices along the path.=20 > >=20 > > The primary goal of the CONEX WG is to develop experimental > > specifications to achieve the above. To help explore how to=20 > > squeeze the necessary information into a very limited numbers=20 > > of header bits, the WG will also develop an abstract=20 > > specification for the congestion exposure mechanism,=20 > > independent of transport and protocol version. > >=20 > > Primary work items are: > >=20 > > * An Informational document with an abstract=20 > > specification for the congestion exposure mechanism > > * Experimental Specification of IPv6 packet structure=20 > > that encapsulates CONEX information (header bits, interpretation). > > * Experimental Specification for modification to TCP,=20 > > 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 which can be applied as a key element=20 > > of congestion management solutions in a wide variety of use=20 > > cases. However, the WG will initially focus solely on one use=20 > > case, where the end hosts and the network of the destination=20 > > end host are CONEX-enabled but the other networks are not.=20 > > CONEX information can assist the network operator's traffic=20 > > management and incentivise LEDBAT-like applications.=20 > > Experiments on the use case are encouraged and the WG will=20 > > solicit input about their process and findings. The output of=20 > > the WG includes Informational document(s) for the use case covering: > >=20 > > * Assumptions it makes > > * Deployment considerations > > * Security Threats > > * Advice on mitigating threats (detailed work on a=20 > > mechanism to mitigate the threats is out of the initial scope) > > * Description of results from experiments on the use case > >=20 > > In establishing this working group, much interest was > > expressed in pursuing an IPv4 specification. A new work item=20 > > proposed for TSVWG would define how 'bit 48' of the IPv4=20 > > header can be used for Experiments. At the appropriate time,=20 > > the CONEX WG will consider rechartering to include a work=20 > > item to specify the IPv4 packet structure to encapsulate=20 > > CONEX information.=20 > >=20 > > Milestones > >=20 > > Jul 2010 Internet-draft Informational document with an > > abstract specification for the congestion exposure mechanism > >=20 > > Jul 2010 Internet-draft use case > >=20 > > Sep 2010 Internet-draft specification of IPv6 packet structure. > >=20 > > Sep 2010 Internet-draft specification for modification to TCP > >=20 > > Mar 2011 Informational RFC abstract specification of the > > congestion exposure mechanism > >=20 > > Mar 2011 Informational RFC use case > >=20 > > Sep 2011 Experimental RFC specification of IPv6 packet structure > >=20 > > Sep 2011 Experimental RFC specification for modification to TCP > >=20 > > -------------- next part -------------- > > An HTML attachment was scrubbed... > > URL: > > > 330/e093c8a6/attachment.htm> > >=20 > > ------------------------------ > >=20 > > _______________________________________________ > > re-ECN mailing list > > re-ECN@ietf.org > > https://www.ietf.org/mailman/listinfo/re-ecn > >=20 > >=20 > > End of re-ECN Digest, Vol 13, Issue 92 > > ************************************** > >=20 >=20 From philip.eardley@bt.com Tue Mar 30 08:26:35 2010 Return-Path: X-Original-To: re-ecn@core3.amsl.com Delivered-To: re-ecn@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id DF5403A68C7 for ; Tue, 30 Mar 2010 08:26:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.023 X-Spam-Level: X-Spam-Status: No, score=-1.023 tagged_above=-999 required=5 tests=[AWL=0.846, BAYES_00=-2.599, DNS_FROM_OPENWHOIS=1.13, J_CHICKENPOX_72=0.6, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id UtKqlU1peYbW for ; Tue, 30 Mar 2010 08:26:34 -0700 (PDT) Received: from smtp1.smtp.bt.com (smtp1.smtp.bt.com [217.32.164.137]) by core3.amsl.com (Postfix) with ESMTP id 681383A66B4 for ; Tue, 30 Mar 2010 08:26:34 -0700 (PDT) Received: from E03MVB1-UKBR.domain1.systemhost.net ([193.113.197.110]) by smtp1.smtp.bt.com with Microsoft SMTPSVC(6.0.3790.3959); Tue, 30 Mar 2010 16:27:02 +0100 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Tue, 30 Mar 2010 16:27:02 +0100 Message-ID: <4A916DBC72536E419A0BD955EDECEDEC06363F3F@E03MVB1-UKBR.domain1.systemhost.net> In-Reply-To: <793F49BA1FC821409F99F10862A0E4DB0658A79C@FHDP1LUMXCV14.us.one.verizon.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [re-ECN] New draft Conex charter - for rapid comments please Thread-Index: AcrP9WpVs8Py8kXCTM603MXv5kYQMAACh23wAAb71hA= From: To: , X-OriginalArrivalTime: 30 Mar 2010 15:27:02.0870 (UTC) FILETIME=[72986760:01CAD01D] Subject: Re: [re-ECN] New draft Conex charter - for rapid comments please X-BeenThere: re-ecn@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: re-inserted explicit congestion notification List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 30 Mar 2010 15:26:36 -0000 Thanks In-line phil > -----Original Message----- > From: Mcdysan, David E [mailto:dave.mcdysan@verizon.com]=20 > Sent: 30 March 2010 13:04 > To: Eardley,PL,Philip,DEE1 R; re-ecn@ietf.org > Subject: RE: [re-ECN] New draft Conex charter - for rapid=20 > comments please >=20 >=20 > Phil, > =20 > A few comments in line below prefixed by DM. > =20 > Thanks, >=20 > Dave >=20 >=20 > ________________________________ >=20 > From: re-ecn-bounces@ietf.org=20 > [mailto:re-ecn-bounces@ietf.org] On Behalf Of philip.eardley@bt.com > Sent: Tuesday, March 30, 2010 6:41 AM > To: re-ecn@ietf.org > Subject: [re-ECN] New draft Conex charter - for rapid=20 > comments please > =09 > =09 >=20 > Just to let those of you who weren't in Anaheim about progress.=20 >=20 > We had two good meetings, there are extensive jabber=20 > notes (offiicial meeting notes to follow)=20 > http://www.ietf.org/jabber/logs/conex/2010-03-24.txt=20 > http://www.ietf.org/jabber/logs/conex/2010-03-25.txt=20 >=20 > We discussed how to change the Charter to meet the=20 > issues raised. The following were proposed and received good support: >=20 > * Experimental track (no Standards track docs)=20 > * for the use cases work, concentrate on one use case=20 > (where the end hosts & the destination network are=20 > conex-enabled, but not the other > networks) >=20 > * do IPv6 header encoding=20 > * suggest a work item in tsvwg (probably) about=20 > assigning "bit 48" as Experimental in the IPv4 header=20 >=20 > Here's a new draft Charter implementing these changes.=20 > If we can complete by Thursday lunchtime, then we should get=20 > it into the next IESG call. >=20 > Thanks=20 > Phil & Leslie=20 > ---=20 > Congestion Exposure (CONEX) WG=20 >=20 >=20 > The purpose of the CONEX working group is to develop a=20 > mechanism by which senders inform=20 > some=20 > the network about the congestion their packets encounter.=20 > Today, ^^^^^ networks signal >=20 > DM: Not every implementation supports ECN marking in the=20 > network, nor does every operator enable it in implementations=20 > that do. Slight rewording proposed to not give the impression=20 > that network elements (e.g., routers) setting ECN is already=20 > widely done today. Phil: adding ^^^some - might suggest that only some networks drop pkts!? Perhaps: "Today networks ^^may signal congestion by ECN marking or dropping packets >=20 > congestion by ECN marking or dropping packets, the receiver=20 > passes this information back to the sender in transport layer=20 > acknowledgements, where the sender makes an adjustment to its=20 > window size or data rate as appropriate. The mechanism to be=20 > developed under CONEX will enable the sender to also relay=20 > the congestion information back into the IP layer such that=20 > the total level of congestion is visible to all IP devices=20 > along the path.=20 >=20 > DM: IPv6 may provide additional bits or methods to signal=20 > congestion as an alternative to and/or as a complement to ECN.=20 Phil: sorry, is this a comment or suggested extra text? (I don't think it's needed] >=20 > The primary goal of the CONEX WG is to develop=20 > experimental specifications to achieve the above. To help=20 > explore how to squeeze the necessary information into a very=20 > limited numbers of header bits,=20 >=20 > DM: This limitation seems to apply to only IPv4. Can the=20 > charter separate this case for IPv4 fromt that of IPv6.=20 > Recall Adrian's comments at the mike. Phil: was trying to say something very brief to justify the abstract spec. but see your point. Perhaps it's easiest simply to delete the phrase and start at "The WG will ..." >=20 > the WG will also develop an abstract specification for the=20 > congestion exposure mechanism, independent of transport and=20 > protocol version. >=20 > Primary work items are:=20 >=20 > * An Informational document with an abstract specification > for the congestion exposure mechanism=20 > DM: suggesting adding "unconstrained by the number of=20 > available bits in the IP header" Phil: I like this addition [will add "for example unconstrained..." >=20 > * Experimental Specification of IPv6 packet structure that > encapsulates CONEX information (header bits, interpretation). >=20 > * Experimental Specification for modification to TCP, for > the timely transport of congestion information from the=20 > destination to the sender >=20 > It is believed that the CONEX mechanism will be useful=20 > as a generative technology which can be applied as a key=20 > element of congestion management solutions in a wide variety=20 > of use cases. However, the WG will initially focus solely on=20 > one use case, where the end hosts and the network of the=20 > destination end host are CONEX-enabled but the other networks=20 > are not. CONEX information can assist the network operator's=20 > traffic management and incentivise LEDBAT-like applications. >=20 > DM: This is an extremely important point -- working only with=20 > TCP (e.g., > ECN) is not enough, the use cases must include protocols that=20 > are a client of the TCP. Not clear from this wording whether=20 > this will be part of the use case, and I would like for it to=20 > be part of the use case.=20 Phil: ok, I see the problem is that the list of bullets for the use case needs to include: * Advice on how to use the CONEX mechanism as an an element of a congestion management solution >=20 > Experiments on the use case are encouraged and the WG will=20 > solicit input about their process and findings. The output of=20 > the WG includes Informational document(s) for the use case covering: >=20 > * Assumptions it makes=20 > * Deployment considerations=20 > * Security Threats=20 > * Advice on mitigating threats (detailed work on a > mechanism to mitigate the threats is out of the initial scope)=20 > * Description of results from experiments on the use case=20 >=20 > In establishing this working group, much interest was=20 > expressed in pursuing an IPv4 specification. A new work item=20 > proposed for TSVWG would define how 'bit 48' of the IPv4=20 > header can be used for Experiments. At the appropriate time,=20 > the CONEX WG will consider rechartering to include a work=20 > item to specify the IPv4 packet structure to encapsulate=20 > CONEX information.=20 >=20 > Milestones=20 >=20 > Jul 2010 Internet-draft Informational document with an=20 > abstract specification for the congestion exposure mechanism=20 >=20 > Jul 2010 Internet-draft use case=20 >=20 > Sep 2010 Internet-draft specification of IPv6 packet structure.=20 >=20 > Sep 2010 Internet-draft specification for modification to TCP=20 >=20 > Mar 2011 Informational RFC abstract specification of=20 > the congestion exposure mechanism=20 >=20 > Mar 2011 Informational RFC use case=20 >=20 > Sep 2011 Experimental RFC specification of IPv6 packet structure >=20 >=20 > Sep 2011 Experimental RFC specification for modification to TCP=20 >=20 >=20 From carlberg@g11.org.uk Tue Mar 30 08:28:10 2010 Return-Path: X-Original-To: re-ecn@core3.amsl.com Delivered-To: re-ecn@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 077C83A6A85 for ; Tue, 30 Mar 2010 08:28:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.096 X-Spam-Level: X-Spam-Status: No, score=0.096 tagged_above=-999 required=5 tests=[AWL=-0.295, BAYES_20=-0.74, DNS_FROM_OPENWHOIS=1.13, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 1XiI17p9ezhL for ; Tue, 30 Mar 2010 08:28:08 -0700 (PDT) Received: from portland.eukhost.com (portland.eukhost.com [92.48.97.5]) by core3.amsl.com (Postfix) with ESMTP id 924103A6A6E for ; Tue, 30 Mar 2010 08:28:08 -0700 (PDT) Received: from c-76-111-69-4.hsd1.va.comcast.net ([76.111.69.4]:53703 helo=[192.168.0.20]) by portland.eukhost.com with esmtpa (Exim 4.69) (envelope-from ) id 1NwdMo-0006dx-AU; Tue, 30 Mar 2010 15:28:34 +0000 Mime-Version: 1.0 (Apple Message framework v1077) Content-Type: multipart/alternative; boundary=Apple-Mail-22--402060730 From: ken carlberg In-Reply-To: <4A916DBC72536E419A0BD955EDECEDEC06363F37@E03MVB1-UKBR.domain1.systemhost.net> Date: Tue, 30 Mar 2010 11:28:35 -0400 Message-Id: <39D98271-942E-40DB-A451-93D344F0F148@g11.org.uk> References: <4A916DBC72536E419A0BD955EDECEDEC06363F37@E03MVB1-UKBR.domain1.systemhost.net> To: X-Mailer: Apple Mail (2.1077) X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - portland.eukhost.com X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - g11.org.uk Cc: re-ecn@ietf.org Subject: Re: [re-ECN] New draft Conex charter - for rapid comments please X-BeenThere: re-ecn@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: re-inserted explicit congestion notification List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 30 Mar 2010 15:28:10 -0000 --Apple-Mail-22--402060730 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii On Mar 30, 2010, at 6:40 AM, = wrote: > We discussed how to change the Charter to meet the issues raised. The = following were proposed and received good support: >=20 > * Experimental track (no Standards track docs)=20 > * for the use cases work, concentrate on one use case (where the end = hosts & the destination network are conex-enabled, but not the other = networks) >=20 > * do IPv6 header encoding=20 > * suggest a work item in tsvwg (probably) about assigning "bit 48" as = Experimental in the IPv4 header >=20 > Here's a new draft Charter implementing these changes. If we can = complete by Thursday lunchtime, then we should get it into the next IESG = call. >=20 I thought that Lars had presented a reasonable alternative with respect = to the IPv4 and/or IPv6 encodings that suggested starting out with IPv6 = and then soon revisiting the work with IPv4 -- kind of a staggered = design effort. While there were some folks who understandably expressed concern about = assigning the last available bit in IPv4, it would seem that the status = of experimental versus standards track makes this assignment quite = tentative. In addition, one thing not mentioned in the meeting was that = there is always the process of changing a document to historic, which = would allow the IETF to reclaim that last bit, if necessary. Of course, if IPv4 is soon to be replaced by IPv6 anyway, then the = potential need for that last bit in IPv4 should really diminish quite = fast. Besides, the rate at which documents get through the IETF these = days means that we do have some time before any CONEX draft becomes an = RFC :-)=20 -ken --Apple-Mail-22--402060730 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=us-ascii philip.eardley@bt.com> = <philip.eardley@bt.com>= wrote:

We discussed how to change the Charter to meet the issues = raised. The following were proposed and received good = support:

* Experimental = track (no Standards track docs) 
* for the use cases work, concentrate on one use case = (where the end hosts & the destination network are conex-enabled, = but not the other networks)

*= do IPv6 header encoding 
* suggest a work item in tsvwg (probably) about assigning = "bit 48" as Experimental in the IPv4 header

Here's a new draft Charter implementing these changes. If = we can complete by Thursday lunchtime, then we should get it into the = next IESG call.

I thought that Lars = had presented a reasonable alternative with respect to the IPv4 and/or = IPv6 encodings that suggested starting out with IPv6 and then soon = revisiting the work with IPv4 -- kind of a staggered design = effort.

While there were some folks who = understandably expressed concern about assigning the last available bit = in IPv4, it would seem that the status of experimental versus standards = track makes this assignment quite tentative.  In addition, one = thing not mentioned in the meeting was that there is always the process = of changing a document to historic, which would allow the IETF to = reclaim that last bit, if necessary.

Of course, = if IPv4 is soon to be replaced by IPv6 anyway, then the potential need = for that last bit in IPv4 should really diminish quite fast. =  Besides, the rate at which documents get through the IETF these = days means that we do have some time before any CONEX draft becomes an = RFC = :-) 

-ken

= --Apple-Mail-22--402060730-- From philip.eardley@bt.com Tue Mar 30 08:34:36 2010 Return-Path: X-Original-To: re-ecn@core3.amsl.com Delivered-To: re-ecn@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 1DEA53A68C7 for ; Tue, 30 Mar 2010 08:34:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.287 X-Spam-Level: X-Spam-Status: No, score=0.287 tagged_above=-999 required=5 tests=[AWL=-0.604, BAYES_20=-0.74, DNS_FROM_OPENWHOIS=1.13, HTML_MESSAGE=0.001, MIME_ASCII0=1.5, 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 42lSTD36-Arh for ; Tue, 30 Mar 2010 08:34:35 -0700 (PDT) Received: from smtp1.smtp.bt.com (smtp1.smtp.bt.com [217.32.164.137]) by core3.amsl.com (Postfix) with ESMTP id BE6F73A67BD for ; Tue, 30 Mar 2010 08:34:34 -0700 (PDT) Received: from E03MVB1-UKBR.domain1.systemhost.net ([193.113.197.110]) by smtp1.smtp.bt.com with Microsoft SMTPSVC(6.0.3790.3959); Tue, 30 Mar 2010 16:35:04 +0100 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01CAD01E.91067E01" Date: Tue, 30 Mar 2010 16:35:03 +0100 Message-ID: <4A916DBC72536E419A0BD955EDECEDEC06363F40@E03MVB1-UKBR.domain1.systemhost.net> In-Reply-To: <39D98271-942E-40DB-A451-93D344F0F148@g11.org.uk> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [re-ECN] New draft Conex charter - for rapid comments please Thread-Index: AcrQHawdiVxOu8QjRJioDD55UE0nMQAAE2Og From: To: X-OriginalArrivalTime: 30 Mar 2010 15:35:04.0020 (UTC) FILETIME=[91621140:01CAD01E] Cc: re-ecn@ietf.org Subject: Re: [re-ECN] New draft Conex charter - for rapid comments please X-BeenThere: re-ecn@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: re-inserted explicit congestion notification List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 30 Mar 2010 15:34:36 -0000 This is a multi-part message in MIME format. ------_=_NextPart_001_01CAD01E.91067E01 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable =09 I thought that Lars had presented a reasonable alternative with respect to the IPv4 and/or IPv6 encodings that suggested starting out with IPv6 and then soon revisiting the work with IPv4 -- kind of a staggered design effort.=20 =20 [phil] i think this staggering meant: initially charter for v6 - later charter for v4 (eg when there's progress on re-assigning bit48 from Reserved to Experimental]=20 While there were some folks who understandably expressed concern about assigning the last available bit in IPv4, it would seem that the status of experimental versus standards track makes this assignment quite tentative. In addition, one thing not mentioned in the meeting was that there is always the process of changing a document to historic, which would allow the IETF to reclaim that last bit, if necessary. Of course, if IPv4 is soon to be replaced by IPv6 anyway, then the potential need for that last bit in IPv4 should really diminish quite fast. Besides, the rate at which documents get through the IETF these days means that we do have some time before any CONEX draft becomes an RFC :-) =20 =20 -ken ------_=_NextPart_001_01CAD01E.91067E01 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Message
I thought that Lars had presented a reasonable alternative with = respect to=20 the IPv4 and/or IPv6 encodings that suggested starting out with IPv6 and = then=20 soon revisiting the work with IPv4 -- kind of a staggered design = effort. 
 
[phil]=20 i think this staggering meant: initially charter for v6 - later = charter for=20 v4 (eg when there's progress on re-assigning bit48 from Reserved to = Experimental] 

While there were some folks who understandably expressed concern = about=20 assigning the last available bit in IPv4, it would seem that the = status of=20 experimental versus standards track makes this assignment quite = tentative.=20  In addition, one thing not mentioned in the meeting was that = there is=20 always the process of changing a document to historic, which would = allow the=20 IETF to reclaim that last bit, if necessary.

Of course, if IPv4 is soon to be replaced by IPv6 anyway, then = the=20 potential need for that last bit in IPv4 should really diminish quite = fast.=20  Besides, the rate at which documents get through the IETF these = days=20 means that we do have some time before any CONEX draft becomes an RFC=20 :-)  
 

-ken

=00 ------_=_NextPart_001_01CAD01E.91067E01-- From mirja.kuehlewind@ikr.uni-stuttgart.de Tue Mar 30 09:17:10 2010 Return-Path: X-Original-To: re-ecn@core3.amsl.com Delivered-To: re-ecn@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 2E7CF3A6A7B for ; Tue, 30 Mar 2010 09:17:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.706 X-Spam-Level: * X-Spam-Status: No, score=1.706 tagged_above=-999 required=5 tests=[AWL=-0.075, BAYES_50=0.001, DNS_FROM_OPENWHOIS=1.13, HELO_EQ_DE=0.35, MIME_8BIT_HEADER=0.3] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id plAn1rXdv9rG for ; Tue, 30 Mar 2010 09:17:08 -0700 (PDT) Received: from mailsrv.ikr.uni-stuttgart.de (mailsrv.ikr.uni-stuttgart.de [129.69.170.2]) by core3.amsl.com (Postfix) with ESMTP id EBB113A6AB6 for ; Tue, 30 Mar 2010 09:16:55 -0700 (PDT) Received: from netsrv1.ikr.uni-stuttgart.de (netsrv1-c [10.11.12.12]) by mailsrv.ikr.uni-stuttgart.de (Postfix) with ESMTP id E176D43A12 for ; Tue, 30 Mar 2010 18:17:23 +0200 (CEST) Received: from vpn-1-cl08 (vpn-1-cl08 [10.88.11.18]) by netsrv1.ikr.uni-stuttgart.de (Postfix) with ESMTP id 92A74BC07E for ; Tue, 30 Mar 2010 18:17:23 +0200 (CEST) From: Mirja =?iso-8859-1?q?K=FChlewind?= To: re-ecn@ietf.org Date: Tue, 30 Mar 2010 18:17:18 +0200 User-Agent: KMail/1.9.10 (enterprise35 0.20090731.1005176) References: <4A916DBC72536E419A0BD955EDECEDEC06363F3F@E03MVB1-UKBR.domain1.systemhost.net> In-Reply-To: <4A916DBC72536E419A0BD955EDECEDEC06363F3F@E03MVB1-UKBR.domain1.systemhost.net> X-KMail-QuotePrefix: > MIME-Version: 1.0 Content-Type: Text/Plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-Id: <201003301817.18286.mkuehle@ikr.uni-stuttgart.de> Subject: Re: [re-ECN] New draft Conex charter - for rapid comments please X-BeenThere: re-ecn@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: re-inserted explicit congestion notification List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 30 Mar 2010 16:17:10 -0000 Hi, this sentence was not really clear to me at the first moment: > CONEX information can assist the network operator's > traffic management and incentivise LEDBAT-like applications. I suggest a working like: CONEX information supports a network operator's traffic management which is sensitive to congestion (and not to data volume or rate) and thereby creates an advantage for using LEDBAT-like congestion control. BR, Mirja From leslie@thinkingcat.com Tue Mar 30 09:48:12 2010 Return-Path: X-Original-To: re-ecn@core3.amsl.com Delivered-To: re-ecn@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 8ACB53A6AB6 for ; Tue, 30 Mar 2010 09:48:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.545 X-Spam-Level: * X-Spam-Status: No, score=1.545 tagged_above=-999 required=5 tests=[BAYES_40=-0.185, DNS_FROM_OPENWHOIS=1.13, J_CHICKENPOX_72=0.6] 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 TViy4mlfGoGD for ; Tue, 30 Mar 2010 09:48:11 -0700 (PDT) Received: from zeke.ecotroph.net (zeke.ecotroph.net [70.164.19.155]) by core3.amsl.com (Postfix) with ESMTP id DB0653A6AAD for ; Tue, 30 Mar 2010 09:48:10 -0700 (PDT) Received: from isocpwgkapfer01.isoc.local ([::ffff:209.183.196.229]) (AUTH: PLAIN leslie, SSL: TLSv1/SSLv3,256bits,AES256-SHA) by zeke.ecotroph.net with esmtp; Tue, 30 Mar 2010 12:48:37 -0400 id 015ACA03.4BB22B65.000022F3 Message-ID: <4BB22B5C.70101@thinkingcat.com> Date: Tue, 30 Mar 2010 12:48:28 -0400 From: Leslie Daigle User-Agent: Thunderbird 2.0.0.23 (Macintosh/20090812) MIME-Version: 1.0 To: ingemar.s.johansson@ericsson.com References: <4A916DBC72536E419A0BD955EDECEDEC06363F3E@E03MVB1-UKBR.domain1.systemhost.net> In-Reply-To: <4A916DBC72536E419A0BD955EDECEDEC06363F3E@E03MVB1-UKBR.domain1.systemhost.net> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: re-ecn@ietf.org Subject: Re: [re-ECN] New draft Conex charter - for rapid comments please X-BeenThere: re-ecn@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: re-inserted explicit congestion notification List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 30 Mar 2010 16:48:12 -0000 I'd like to expand a little on Phil's point. The IESG guidance was based on expressed concerns over predicting the eventual success (and uptake) of CONEX. Two options: 1/ Go for experimental, do experiments, demonstrate uptake and viability. It's easy enough to move documents to standards track if it's warranted. 2/ Go for standards -- prove, now, that this is a recommended and desired direction for the Internet. It seems "2/" is giving the IESG heartburn, and I think it's fair to say that it's easier to prove the viability of the approach when there is some form of open specification and results from broad-based experimental deployments. In that light -- I think "1/" makes a lot of sense. Leslie. philip.eardley@bt.com wrote: > >> -----Original Message----- >> From: Ingemar Johansson S [mailto:ingemar.s.johansson@ericsson.com] >> Sent: 30 March 2010 12:57 >> To: re-ecn@ietf.org >> Cc: Eardley,PL,Philip,DEE1 R >> Subject: RE: [re-ECN] New draft Conex charter - for rapid >> comments please >> >> >> Hi >> >> I have one question. Based on my recently gained >> understanding about "emotional feelings" :-) around bit48 in >> IPv4 I can understand why you propose to make use of this bit >> experimental. >> >> However when it comes to IPv6 I am not really convinced why >> this need to be experimental. As I understand it the ConEx >> info will be encoded in an IPv6 extension that is encoded in >> such a way that a node can safely ignore it and just let it >> pass through if it does not understand it or does not care. >> My problem with the word "Experimental" is that it is just.. >> experimental and I have a hard time to understand if e.g 3GPP >> is interested at all to support something that is experimental. >> What is the risk of making the IPv6 header extension standards track ? > > I have sympathy with your viewpoint - but the IESG have given us > guidance that it should be Experimental. There is no harda nf fast > guidance on what's experimental and what's standards track. Safety is > one thing I've heard to distinguish them (as you say) - another is "do > we believe this is baked enough for the IETF to recommend it for > widespread deployment?". > On the positive side, the transition from Experimental to standards > track is a well-accepted path. > >> Regards >> /Ingemar >> ---------------------------------------------------------------------- >>> Message: 1 >>> Date: Tue, 30 Mar 2010 11:40:30 +0100 >>> From: >>> Subject: [re-ECN] New draft Conex charter - for rapid >> comments please >>> To: >>> Message-ID: >>> >>> <4A916DBC72536E419A0BD955EDECEDEC06363F37@E03MVB1-UKBR.domain1 >>> .systemhost.net> >>> >>> Content-Type: text/plain; charset="iso-8859-1" >>> >>> Just to let those of you who weren't in Anaheim about progress. >>> >>> We had two good meetings, there are extensive jabber notes >>> (offiicial meeting notes to follow) >>> http://www.ietf.org/jabber/logs/conex/2010-03-24.txt >>> http://www.ietf.org/jabber/logs/conex/2010-03-25.txt >>> >>> We discussed how to change the Charter to meet the issues >>> raised. The following were proposed and received good support: >>> * Experimental track (no Standards track docs) >>> * for the use cases work, concentrate on one use case (where >>> the end hosts & the destination network are conex-enabled, >>> but not the other networks) >>> * do IPv6 header encoding >>> * suggest a work item in tsvwg (probably) about assigning >>> "bit 48" as Experimental in the IPv4 header >>> >>> Here's a new draft Charter implementing these changes. If we >>> can complete by Thursday lunchtime, then we should get it >>> into the next IESG call. >>> >>> Thanks >>> Phil & Leslie >>> --- >>> Congestion Exposure (CONEX) WG >>> >>> >>> The purpose of the CONEX working group is to develop a >>> mechanism by which senders inform the network about the >>> congestion their packets encounter. Today, the network >>> signals congestion by ECN marking or dropping packets, the >>> receiver passes this information back to the sender in >>> transport layer acknowledgements, where the sender makes an >>> adjustment to its window size or data rate as appropriate. >>> The mechanism to be developed under CONEX will enable the >>> sender to also relay the congestion information back into the >>> IP layer such that the total level of congestion is visible >>> to all IP devices along the path. >>> >>> The primary goal of the CONEX WG is to develop experimental >>> specifications to achieve the above. To help explore how to >>> squeeze the necessary information into a very limited numbers >>> of header bits, the WG will also develop an abstract >>> specification for the congestion exposure mechanism, >>> independent of transport and protocol version. >>> >>> Primary work items are: >>> >>> * An Informational document with an abstract >>> specification for the congestion exposure mechanism >>> * Experimental Specification of IPv6 packet structure >>> that encapsulates CONEX information (header bits, interpretation). >>> * Experimental Specification for 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 which can be applied as a key element >>> of congestion management solutions in a wide variety of use >>> cases. However, the WG will initially focus solely on one use >>> case, where the end hosts and the network of the destination >>> end host are CONEX-enabled but the other networks are not. >>> CONEX information can assist the network operator's traffic >>> management and incentivise LEDBAT-like applications. >>> Experiments on the use case are encouraged and the WG will >>> solicit input about their process and findings. The output of >>> the WG includes Informational document(s) for the use case covering: >>> >>> * Assumptions it makes >>> * Deployment considerations >>> * Security Threats >>> * Advice on mitigating threats (detailed work on a >>> mechanism to mitigate the threats is out of the initial scope) >>> * Description of results from experiments on the use case >>> >>> In establishing this working group, much interest was >>> expressed in pursuing an IPv4 specification. A new work item >>> proposed for TSVWG would define how 'bit 48' of the IPv4 >>> header can be used for Experiments. At the appropriate time, >>> the CONEX WG will consider rechartering to include a work >>> item to specify the IPv4 packet structure to encapsulate >>> CONEX information. >>> >>> Milestones >>> >>> Jul 2010 Internet-draft Informational document with an >>> abstract specification for the congestion exposure mechanism >>> >>> Jul 2010 Internet-draft use case >>> >>> Sep 2010 Internet-draft specification of IPv6 packet structure. >>> >>> Sep 2010 Internet-draft specification for modification to TCP >>> >>> Mar 2011 Informational RFC abstract specification of the >>> congestion exposure mechanism >>> >>> Mar 2011 Informational RFC use case >>> >>> Sep 2011 Experimental RFC specification of IPv6 packet structure >>> >>> Sep 2011 Experimental RFC specification for modification to TCP >>> >>> -------------- next part -------------- >>> An HTML attachment was scrubbed... >>> URL: >>> >> 330/e093c8a6/attachment.htm> >>> >>> ------------------------------ >>> >>> _______________________________________________ >>> re-ECN mailing list >>> re-ECN@ietf.org >>> https://www.ietf.org/mailman/listinfo/re-ecn >>> >>> >>> End of re-ECN Digest, Vol 13, Issue 92 >>> ************************************** >>> > _______________________________________________ > re-ECN mailing list > re-ECN@ietf.org > https://www.ietf.org/mailman/listinfo/re-ecn -- ------------------------------------------------------------------- "Reality: Yours to discover." -- ThinkingCat Leslie Daigle leslie@thinkingcat.com ------------------------------------------------------------------- From leslie@thinkingcat.com Tue Mar 30 10:10:55 2010 Return-Path: X-Original-To: re-ecn@core3.amsl.com Delivered-To: re-ecn@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id A551B3A67A5 for ; Tue, 30 Mar 2010 10:10:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.338 X-Spam-Level: * X-Spam-Status: No, score=1.338 tagged_above=-999 required=5 tests=[AWL=0.207, BAYES_50=0.001, DNS_FROM_OPENWHOIS=1.13] 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 xL9jAz0-hfng for ; Tue, 30 Mar 2010 10:10:54 -0700 (PDT) Received: from zeke.ecotroph.net (zeke.ecotroph.net [70.164.19.155]) by core3.amsl.com (Postfix) with ESMTP id 45CE93A6781 for ; Tue, 30 Mar 2010 10:10:54 -0700 (PDT) Received: from isocpwgkapfer01.isoc.local ([::ffff:209.183.196.229]) (AUTH: PLAIN leslie, SSL: TLSv1/SSLv3,256bits,AES256-SHA) by zeke.ecotroph.net with esmtp; Tue, 30 Mar 2010 13:11:22 -0400 id 015ACA03.4BB230BA.000029C8 Message-ID: <4BB230B1.1010806@thinkingcat.com> Date: Tue, 30 Mar 2010 13:11:13 -0400 From: Leslie Daigle User-Agent: Thunderbird 2.0.0.23 (Macintosh/20090812) MIME-Version: 1.0 To: "re-ecn@ietf.org" , Philip Eardley Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: [re-ECN] DRAFT minutes for CONEX IETF 77 Session 1 X-BeenThere: re-ecn@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: re-inserted explicit congestion notification List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 30 Mar 2010 17:10:55 -0000 Hi, Thanks to John Leslie & Matt Zekauskus for taking notes, and to Ted Hardie for being our jabber scribe for the session. Please find below an amalgamated set of draft notes for the minutes. Comments and corrections by Wed Apr 7, if you would be so kind! Thanks, Leslie. CONEX BoF, Session 1 March 24, 2010 15h10-16h10 Chairs: Leslie Daigle & Philip Eardley Jabber Scribe: Ted Hardie Note takers: John Leslie, Matt Zekauskas Leslie reviews what's been happening: BarBoF Stockholm, GIIC workshop, BoF in Hiroshima; two key questions there: "is conex a problem" YES; "is there IETF work here" YES. Followed up with draft charter, which provoked IESG comments; hence this BoF: why Congestion Exposure, response to IESG comments; need clarity, charter outline; looking for clarity in charter text; agenda for tomorrow will be posted after today. Want to clarify: there are 3 pieces: (1) generative technology, (2) deployable uses, (3) one implementation, re-ECN, (basis for believing this is worth pursuing); hard to keep these three separate; want to focus on first today. From the slides: congestion exposure is "A mechanism by which IP datagrams can signal the total rest-of-path congestion that they are expecting along the entire path they are traversing." Three presentations Presentation: Mat Ford, Some data from ISOC panel in IETF76 Briefing paper published yesterday Access networks getting faster; pressure from broadband, etc. Data of Japanese market, over four years Internet Observatory: private peering bringing content "closer" Pinch Points: CPE (typically no AQM), aggregation routers, interconnects Impact of individual subscribers increases; additional capacity may not be cost-effective; tools limited Questions? Hannes Tschofenig: also MIT project to run similar analysis, should be available in a few months David McDyson: is it in-charter to look at incentives to balance? Presentation: Richard Woundy, ISP perspective Three areas of concerns: customers & activities, external third parties, our own network; impact on customers is key -- customers calling -- do we know why there's congestion? Regulators are asking us what effect on customers & how do customers learn of issues Fixing congestion tends to require truck-runs -- may be delayed by weather, etc. Demand may double by the time you fix problem We want low-volume traffic not disturbed by high-volume uses; we want customers to be able to prioritize their uses Potential Use Cases: input to congestion mgmt; discovery/diagnosis of issues; possible DDoS mitigation; incent LEDBAT-like applications; congestion can occur in many places; customers report trouble on social-neworking sites and blogs (example where diagnosis was particularly difficult "Why don't you get back to me when you have something deployed" -- understandable Two "ecosystems": implementation ecosystem, network-deployment ecosystem -- engineering issues, not research issues Phil: use cases later, but use cases not in scope yet Hannes: valuable insight from Rich's presentation of Comcast's experiences, wish other providers would give similar info; what can be done today with existing tools; interesting properties, e.g. protocol-agnostic Presentation: Alissa Cooper -- Traffic Management tools & techniques Reasons why providers do traffic management Easier to deploy, cheaper than expanding, build-out schedules, fine-grained control Throwing capacity at it: straightforward, meets demand; but expensive, can't solve congestion on other networks, spreads cost to those who don't need more capacity Approaches: volume, rate, applications; what metric to take action, what action to take Volume caps, volume penalties; but impact too restrictive in times of low traffic, insufficient in times of very high volume Rate-limit, simple to implement; but too-much/too-little restriction Application-based: sensitive to use characteristics; but cat & mouse, public-policy issues Combinations... Benefits of Congestion Exposure Incentivizes reduced-congestion protocols like LEDBAT; Exposes congestion end-to-end, across network borders; transparency at every network node (good for capacity planning); enables Internet-wide solutions David McDysan: seems more access-network applications; focus on use-cases including access networks and transit networks, wireless access networks, collect/distill to prioritize requirements Leslie: good point. Is everyone clear on what problem is and the scope of impact.? silence... Leslie: Everyone seems to be clear on the scope, based on the "silence is agreement" model. Phil projects slide with Framework of charter Leslie: Now on to the Charter text discussion. Not all will get discussed today, but the meeting tomorrow will pick up where we leave off today -- please be sure to come back tomorrow as well. Phil: slide "the generative technologies" -- the major work item (in v4 and v6); how to carry congestion information Manesh ?? (microsoft): seems to be wired-network specific, need more input from wireless operators Phil: that wasn't on slide Matt Mathias: worth doing the exercise of some "test marketing" -- take this paragraph to people that haven't read it before, watch them read it ask if know what means. It would help to ask such folks to explain what they think it says Leslie: to a large degree this session's primary purpose is to clarify this text so it reflects what we agree are the tractable work items for a WG. Hannes: would be good to involve cellular operators in this discussion; problems & resolutions are different. Ingemar Johansson: Plan to submit a document on wireless aspects Lars: a little disappointed, one reason why approved second bof was because we had strong consensus, but IESG issues. Would have liked to see more people wearing dots to understand if issues resolved or not. Hoped to clarify the issues, would have been best to hear issues today and come back tomorrow for answers; I wonder if this has helped at all Adrian Farrell (IESG member): didn't find this helpful for issues which came up; difficult to grok, "given my previous experience this is my expectation of what congestion I may see in the future". Once had parsed that, he was able to understand where the group was going, but he is still not convinced that there is demand for it. He is cautious about burning cycles on items that might not get traction. Leslie: Happy to address the detailed comments once the core question of whether this IETF or IRTF work; she had hoped that the presentations today would address that. Andrew McLaughlin: I don't understand how we're going to deploy this among service providers. Appreciation expressed for Adrian stepping up to the microphone -- others voiced private concerns, Adrian helped by voicing publically. Lars: good place to stop; you can corner Adrian before tomorrow. David Harrington: I had some concerns about how this is to be used between providers, specifically the incentive to cheat -- ------------------------------------------------------------------- "Reality: Yours to discover." -- ThinkingCat Leslie Daigle leslie@thinkingcat.com ------------------------------------------------------------------- From dave.mcdysan@verizon.com Tue Mar 30 10:11:07 2010 Return-Path: X-Original-To: re-ecn@core3.amsl.com Delivered-To: re-ecn@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id B6ACE3A6A26 for ; Tue, 30 Mar 2010 10:11:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.372 X-Spam-Level: X-Spam-Status: No, score=-1.372 tagged_above=-999 required=5 tests=[AWL=0.497, BAYES_00=-2.599, DNS_FROM_OPENWHOIS=1.13, J_CHICKENPOX_72=0.6, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id SyWGExcBKsS7 for ; Tue, 30 Mar 2010 10:11:06 -0700 (PDT) Received: from sacmail4.verizon.com (sacmail4.verizon.com [192.76.84.42]) by core3.amsl.com (Postfix) with ESMTP id 1C6163A6896 for ; Tue, 30 Mar 2010 10:11:06 -0700 (PDT) Received: from irvintrmemf1.verizon.com (irvintrmemf1.verizon.com [138.83.34.101]) by sacmail4.verizon.com (8.13.7+Sun/8.13.3) with ESMTP id o2UHB9BR015435; Tue, 30 Mar 2010 13:11:20 -0400 (EDT) X-AuditID: 8a532265-b7bd3ae00000481d-4d-4bb230b8ba9a Received: from smtptpa3.verizon.com ( [138.83.71.176]) by irvintrmemf1.verizon.com (Symantec Brightmail Gateway) with SMTP id D4.ED.18461.8B032BB4; Tue, 30 Mar 2010 12:11:20 -0500 (CDT) Received: from FHDP1CCMXCG02.us.one.verizon.com ([166.68.240.34]) by smtptpa3.verizon.com (8.13.3/8.13.3) with ESMTP id o2UHBHLA018409; Tue, 30 Mar 2010 13:11:20 -0400 (EDT) Received: from FHDP1LUMXCV14.us.one.verizon.com ([166.68.125.35]) by FHDP1CCMXCG02.us.one.verizon.com with Microsoft SMTPSVC(6.0.3790.3959); Tue, 30 Mar 2010 13:11:19 -0400 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: quoted-printable Date: Tue, 30 Mar 2010 13:10:22 -0400 Message-ID: <793F49BA1FC821409F99F10862A0E4DB0658A944@FHDP1LUMXCV14.us.one.verizon.com> In-Reply-To: <4A916DBC72536E419A0BD955EDECEDEC06363F3F@E03MVB1-UKBR.domain1.systemhost.net> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [re-ECN] New draft Conex charter - for rapid comments please Thread-Index: AcrP9WpVs8Py8kXCTM603MXv5kYQMAACh23wAAb71hAAA/yUEA== References: <793F49BA1FC821409F99F10862A0E4DB0658A79C@FHDP1LUMXCV14.us.one.verizon.com> <4A916DBC72536E419A0BD955EDECEDEC06363F3F@E03MVB1-UKBR.domain1.systemhost.net> From: "Mcdysan, David E" To: , X-OriginalArrivalTime: 30 Mar 2010 17:11:19.0495 (UTC) FILETIME=[03D59D70:01CAD02C] X-Brightmail-Tracker: AAAAAA== Subject: Re: [re-ECN] New draft Conex charter - for rapid comments please X-BeenThere: re-ecn@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: re-inserted explicit congestion notification List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 30 Mar 2010 17:11:07 -0000 Hi Phil, A few responses in line below, attempting to finalize my inputs. Thanks, Dave=20 > -----Original Message----- > From: philip.eardley@bt.com [mailto:philip.eardley@bt.com]=20 > Sent: Tuesday, March 30, 2010 11:27 AM > To: Mcdysan, David E; re-ecn@ietf.org > Subject: RE: [re-ECN] New draft Conex charter - for rapid=20 > comments please >=20 > Thanks > In-line > phil >=20 > > -----Original Message----- > > From: Mcdysan, David E [mailto:dave.mcdysan@verizon.com] > > Sent: 30 March 2010 13:04 > > To: Eardley,PL,Philip,DEE1 R; re-ecn@ietf.org > > Subject: RE: [re-ECN] New draft Conex charter - for rapid comments=20 > > please > >=20 > >=20 > > Phil, > > =20 > > A few comments in line below prefixed by DM. > > =20 > > Thanks, > >=20 > > Dave > >=20 > >=20 > > ________________________________ > >=20 > > From: re-ecn-bounces@ietf.org > > [mailto:re-ecn-bounces@ietf.org] On Behalf Of philip.eardley@bt.com > > Sent: Tuesday, March 30, 2010 6:41 AM > > To: re-ecn@ietf.org > > Subject: [re-ECN] New draft Conex charter - for rapid=20 > comments please > > =09 > > =09 > >=20 > > Just to let those of you who weren't in Anaheim about progress.=20 > >=20 > > We had two good meetings, there are extensive jabber=20 > > notes (offiicial meeting notes to follow)=20 > > http://www.ietf.org/jabber/logs/conex/2010-03-24.txt=20 > > http://www.ietf.org/jabber/logs/conex/2010-03-25.txt=20 > >=20 > > We discussed how to change the Charter to meet the=20 > > issues raised. The following were proposed and received=20 > good support: > >=20 > > * Experimental track (no Standards track docs)=20 > > * for the use cases work, concentrate on one use case=20 > > (where the end hosts & the destination network are=20 > > conex-enabled, but not the other > > networks) > >=20 > > * do IPv6 header encoding=20 > > * suggest a work item in tsvwg (probably) about=20 > > assigning "bit 48" as Experimental in the IPv4 header=20 > >=20 > > Here's a new draft Charter implementing these changes.=20 > > If we can complete by Thursday lunchtime, then we should get=20 > > it into the next IESG call. > >=20 > > Thanks=20 > > Phil & Leslie=20 > > ---=20 > > Congestion Exposure (CONEX) WG=20 > >=20 > >=20 > > The purpose of the CONEX working group is to develop a=20 > > mechanism by which senders inform=20 > > =20 > some=20 > > the network about the congestion their packets encounter.=20 > > Today, ^^^^^ networks signal > >=20 > > DM: Not every implementation supports ECN marking in the=20 > > network, nor does every operator enable it in implementations=20 > > that do. Slight rewording proposed to not give the impression=20 > > that network elements (e.g., routers) setting ECN is already=20 > > widely done today. >=20 > Phil: adding ^^^some - might suggest that only some networks=20 > drop pkts!? > Perhaps: "Today networks ^^may signal congestion by ECN marking or > dropping packets DM: Inserting "may" works for me. >=20 > >=20 > > congestion by ECN marking or dropping packets, the receiver=20 > > passes this information back to the sender in transport layer=20 > > acknowledgements, where the sender makes an adjustment to its=20 > > window size or data rate as appropriate. The mechanism to be=20 > > developed under CONEX will enable the sender to also relay=20 > > the congestion information back into the IP layer such that=20 > > the total level of congestion is visible to all IP devices=20 > > along the path.=20 > >=20 > > DM: IPv6 may provide additional bits or methods to signal=20 > > congestion as an alternative to and/or as a complement to ECN.=20 >=20 > Phil: sorry, is this a comment or suggested extra text? (I don't think > it's needed] >=20 > >=20 > > The primary goal of the CONEX WG is to develop=20 > > experimental specifications to achieve the above. To help=20 > > explore how to squeeze the necessary information into a very=20 > > limited numbers of header bits,=20 > >=20 > > DM: This limitation seems to apply to only IPv4. Can the=20 > > charter separate this case for IPv4 fromt that of IPv6.=20 > > Recall Adrian's comments at the mike. >=20 > Phil: was trying to say something very brief to justify the abstract > spec. but see your point. > Perhaps it's easiest simply to delete the phrase and start at "The WG > will ..." DM: Deleting the phrase "To help explore how to squeeze the necessary information into a very limited numbers of header bits," addresses my point. >=20 > >=20 > > the WG will also develop an abstract specification for the=20 > > congestion exposure mechanism, independent of transport and=20 > > protocol version. > >=20 > > Primary work items are:=20 > >=20 > > * An Informational document with an abstract specification > > for the congestion exposure mechanism=20 > > DM: suggesting adding "unconstrained by the number of=20 > > available bits in the IP header" >=20 > Phil: I like this addition [will add "for example unconstrained..." DM: I think more people expressed support for IPv6.=20 >=20 > >=20 > > * Experimental Specification of IPv6 packet structure that > > encapsulates CONEX information (header bits, interpretation). > >=20 > > * Experimental Specification for modification to TCP, for > > the timely transport of congestion information from the=20 > > destination to the sender > >=20 > > It is believed that the CONEX mechanism will be useful=20 > > as a generative technology which can be applied as a key=20 > > element of congestion management solutions in a wide variety=20 > > of use cases. However, the WG will initially focus solely on=20 > > one use case, where the end hosts and the network of the=20 > > destination end host are CONEX-enabled but the other networks=20 > > are not. CONEX information can assist the network operator's=20 > > traffic management and incentivise LEDBAT-like applications. > >=20 > > DM: This is an extremely important point -- working only with=20 > > TCP (e.g., > > ECN) is not enough, the use cases must include protocols that=20 > > are a client of the TCP. Not clear from this wording whether=20 > > this will be part of the use case, and I would like for it to=20 > > be part of the use case.=20 >=20 > Phil: ok, I see the problem is that the list of bullets for=20 > the use case > needs to include: > * Advice on how to use the CONEX mechanism as an an element of a > congestion management solution DM: Possibly add a reference to the LEDBAT sentence as an example here for clarity? >=20 > >=20 > > Experiments on the use case are encouraged and the WG will=20 > > solicit input about their process and findings. The output of=20 > > the WG includes Informational document(s) for the use case covering: > >=20 > > * Assumptions it makes=20 > > * Deployment considerations=20 > > * Security Threats=20 > > * Advice on mitigating threats (detailed work on a > > mechanism to mitigate the threats is out of the initial scope)=20 > > * Description of results from experiments on the use case=20 > >=20 > > In establishing this working group, much interest was=20 > > expressed in pursuing an IPv4 specification. A new work item=20 > > proposed for TSVWG would define how 'bit 48' of the IPv4=20 > > header can be used for Experiments. At the appropriate time,=20 > > the CONEX WG will consider rechartering to include a work=20 > > item to specify the IPv4 packet structure to encapsulate=20 > > CONEX information.=20 > >=20 > > Milestones=20 > >=20 > > Jul 2010 Internet-draft Informational document with an=20 > > abstract specification for the congestion exposure mechanism=20 > >=20 > > Jul 2010 Internet-draft use case=20 > >=20 > > Sep 2010 Internet-draft specification of IPv6 packet structure.=20 > >=20 > > Sep 2010 Internet-draft specification for modification to TCP=20 > >=20 > > Mar 2011 Informational RFC abstract specification of=20 > > the congestion exposure mechanism=20 > >=20 > > Mar 2011 Informational RFC use case=20 > >=20 > > Sep 2011 Experimental RFC specification of IPv6 packet structure > >=20 > >=20 > > Sep 2011 Experimental RFC specification for modification to TCP=20 > >=20 > >=20 >=20 From leslie@thinkingcat.com Tue Mar 30 10:12:52 2010 Return-Path: X-Original-To: re-ecn@core3.amsl.com Delivered-To: re-ecn@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 7A7C73A67A5 for ; Tue, 30 Mar 2010 10:12:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.234 X-Spam-Level: * X-Spam-Status: No, score=1.234 tagged_above=-999 required=5 tests=[AWL=0.104, BAYES_50=0.001, DNS_FROM_OPENWHOIS=1.13] 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 x4qceqZ7f8Pk for ; Tue, 30 Mar 2010 10:12:51 -0700 (PDT) Received: from zeke.ecotroph.net (zeke.ecotroph.net [70.164.19.155]) by core3.amsl.com (Postfix) with ESMTP id 35ED93A684C for ; Tue, 30 Mar 2010 10:12:50 -0700 (PDT) Received: from isocpwgkapfer01.isoc.local ([::ffff:209.183.196.229]) (AUTH: PLAIN leslie, SSL: TLSv1/SSLv3,256bits,AES256-SHA) by zeke.ecotroph.net with esmtp; Tue, 30 Mar 2010 13:13:18 -0400 id 015ACA03.4BB2312E.00002A90 Message-ID: <4BB23126.6070803@thinkingcat.com> Date: Tue, 30 Mar 2010 13:13:10 -0400 From: Leslie Daigle User-Agent: Thunderbird 2.0.0.23 (Macintosh/20090812) MIME-Version: 1.0 To: "re-ecn@ietf.org" , Philip Eardley Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: [re-ECN] DRAFT minutes for CONEX IETF 77 Session 2 X-BeenThere: re-ecn@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: re-inserted explicit congestion notification List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 30 Mar 2010 17:12:52 -0000 Hi, Thanks to Mat Ford for the draft minutes attached (and, thanks again to our jabber scribe for the session, Ted Hardie). Comments on these by Wed Apr 7, if you would be so kind! Thanks, Leslie. THURSDAY, March 25, 2010 1510-1610 Afternoon Session II California B TSV conex Congestion Exposure BOF Chairs: Phil Eardley, Leslie Daigle Phil Eardley (PE) presents slides: http://www.ietf.org/proceedings/10mar/slides/conex-4.pdf Gorry Fairhurst (GF) - You're talking about experimental modifications to IPv4 headers yes? PE - Yes. GF - Re-writing Proposed Standards and obsoleting them or updating them or what? Does the experimentation invalidate anything which is currently in PS or does it just use reserved bits? PE - I believe it does not GF - Does it invalidate anything which is currently experimental? Bob Briscoe (BB) - If we're talking about re-ECN, you would have to update RFC791 to say that the last bit is no longer reserved but experimental. And then you'd have to write an Experimental RFC to use it. That process was used for ECN. The only other thing is ECN-nonce which is Experimental currently. We would have to work out a way to set that aside while we do this experiment. GF - That was nicely worded. Dave McDysan (DM) - In IPv6 we would have more degrees of freedom, potentially more capabilities in IPv6 using more bits. Ingemar Johansson (IJ) - This work should be standards-track. PE - We've already had strong feedback that work items should be Experimental rather than Standards Track. Leslie Daigle (LD) - It's not a broken path to start with Experimental and then move to Standards Track if experiment is successful. There is consensus that the desired outcome is a standard. Georgios Karagiannis (GK) - There are only two major work items - are others to follow? PE - Yes, see later slides. GK - When these bits are signalled across the network, the network has to do something with them - where is behaviour of the network specified? PE - See later slides. David Black (DB) - ECN was experimental for a time before it went to standards track. Matt Mathis (MM) - There is another strategy here - talk about an abstract implementation and how functional units might work, and then map to a coding which forces you to give up some of the functions. LD - We'll touch on that later in this talk. IJ - Concept of conex is good. If it had been proposed 20 years ago would resistance have been higher or lower? PE - We could discuss that over beer later. Tim Shepard (TS) - I'm a fan of this technology, but my hope is that 20 years from now it might be extensively deployed. I doubt we're going to see this inside of 10 years. But it's important to do the work now - if we don't it won't be here inside of 20 years. LD - We're trying to unlatch requirement that says we have all the final answers and rather say lets get the work started - going for EXP acknowledges that we don't have all the right answers. DM - I and others in my company have concerns about retrofitting this to IPv4 - should really be focussing this on IPv6. PE - So you're happy with delivery, it's just about the process of getting there? DM - Supports MM comment, there is another deliverable (abstract design) and the order is generic requirements and then that drives how you do the encodings. Andrew McLachlan (AM) - If we're still counting congestion in 20 years then we've done something seriously wrong. Bandwidth is getting cheaper and cheaper and if we're still using congestion to measure congestion we've made a huge mistake somewhere along the line. LD - Not agreeing with that point we need to move on and not argue it because if we argue it we'll be done with today's session. PE continues with presentation PE - Are people OK with this narrowed Charter? MM - If this makes it easier to get past the IESG, then we should do it - we can always change the charter later. PE - Are there any ADs in the room? LD - The only question should be 'is this well-framed work for the IETF'? John Leslie (JL) - I have no problem in principal with narrowing the charter, but I don't understand why this narrowing would make anyone happier, nor does it look like a good way to define a generative technology. LD - Instead of trying to map out the entire path, this is what we do know today. This is the work that needs to get done in order to get the work started, and the use cases are the biggest unknowns, so moving them out seems like a non-lossy way to proceed. Ross Callon (RC) - Former AD - personal opinion having heard other ADs discuss this is: this is interesting research that we don't think is going to get deployed in the Internet - unless we hear from a lot of service providers that they want to deploy. If narrowing the scope of the charter makes it clearer how we'll get this deployed then that is a good thing. BB - Supports going for experimental status. It is very difficult for people to imagine what they might do with this until it exists. An experimental protocol that allows you to build a testbed and start using it allows people to understand what it is for. We're trying to prevent what happened with NATs happening with DPI (i.e. nothing is specified and we end up with a mess). Rolf Winter (RW) - We have heard from operators that this is an important direction and they need a standardised solution. If we don't work on this now then we don't get to complain in 10 years when DPI is pervasive and breaking the network. Jason Livingood (JL2) - Bob's last point was a good one - similar to NATs, if there's not something standardised in this space then you will see a lot of proprietary DPI devices deployed and that is a risk. JL - I really don't even understand how you're proposing to narrow the charter. LD - We are here to review the proposal to reduce the scope. JL - I have no objection to a reduced charter. RW - The narrowed scope addresses the problems raised, and leaves the core that we want to work on. Once we have made this initial piece work, there are probably additional things that will follow. Ken Carlberg (KC) - Will IESG express their concerns publicly? Could they please be encouraged to do so? LD - Yes, shadowboxing the IESG isn't fun. DM - Will the charter be revised as MM proposed? IPv6 deployment could be enhanced if we focus there. LD - Is your concern that we not focus exclusively on IPv4? DM - Yes MM - Coding for IPv4 is harder, so abstract design followed by coding work could help. MM - Re future-historic tense - better sense: 'to allow all the elements along the path to get information about congestion all along the path' Chris Morrow (CM) - We could do better with existing tools. I'm not sure I see a need for this. LD - Were you in the room yesterday? CM - No LD - Check out the materials and minutes - the problem statement was extensively addressed. CM - OK. Adrian Farrell (AF) - I've caught every second word - had to be in another room. Experimental proposal gels with how I feel. I'm a little nervous about the use of the very last bit in IPv4, maybe we could cut it in half :) . An option might be to work on this in IPv6 first - if it flies there I might feel better about allocating the last IPv4 bit. PE reviews proposed narrowing of use cases. AF - was there any discussion about what the level of demand for this is? LD presents Bob's analysis of support gleaned from the mailing list. Stewart Bryant (SB) - Glad to see moving this to an Experiment, encourages focussing on IPv6 - glad to see narrowed scope so that it can work with MPLS, nervous about interaction with white cloud in the diagram. Can white cloud inject information that causes mis-allocation of funds? Ted Hardie (TH) - clarifying question - are you asking that the charter do something to address this, or are you asking whether re-ecn addresses this? How re-ecn deals with this now is not relevant. SB - Charter should clearly address the security risks. BB - on the v4 vs. v6 topic - a number of people have thought long and hard about using up the last bit of the IPv4 header - difficulty is that sensible trials with real users and real applications need real traffic (don't mean to be rude about IPv6, but we won't get that there). IPv4 code can be restricted in time and space. AM - As a provider, why would I want to express that my network is congested? The use case should take that into account. TS - Would your question apply to ECN? AM - I'm not well-versed in the protocol. MM - If you don't mark then remote senders will hit your network harder because you're effectively giving them permission to use a higher data rate, this signalling is how we tell senders to slow down. AM - the use case needs to express this. TS - It would be a burden if the experiment had to be conducted on a v6 only network. It needs to be considered whether that burden needs to be put on this work. LD - We need to balance need to have a runnable experiment versus concerns about burning the last bit in the IPv4 header. DM - IPv6 networks as they're being deployed are smaller in scope, more experimental, more likely to experience congestion. If an experiment there can show a benefit versus IPv4 network that's a more experimental environment for operational traffic for operations folks at Verizon. Mat Ford (MF) - It's hard to understand why people have difficulty with the idea of re-classifying the last bit in the IPv4 header to allow experimental use, when it is debatable whether IPv4 has a long life-time ahead of it. LD - Perhaps another way of expressing that is to ask, do we reasonably project that in whatever lifetime IPv4 has there will be cause for a standards-based use of that last bit? Lars Eggert (LE) - One proposal would be to initially limit experimentation under the initial conex charter to IPv6. We need to investigate how experimentation in IPv4 could proceed and be limited as necessary - make this a work item for conex. If that proves positive reconsider the limitation and potentially re-charter at that point. LD - Certainly don't want to gate chartering conex on this point. LE - It's clear that it should be possible to get useful data from IPv6 experiments. Mark Handley (MH) - We need to define how we know whether the experiment has succeeded or failed. The bit has to be redefined as experimental for anyone to make any use of it for anything, otherwise it's just a useless bit. LD - Thanks all for your input. Revised charter will appear on the list in due course. ENDS -- ------------------------------------------------------------------- "Reality: Yours to discover." -- ThinkingCat Leslie Daigle leslie@thinkingcat.com ------------------------------------------------------------------- From karagian@cs.utwente.nl Tue Mar 30 14:16:35 2010 Return-Path: X-Original-To: re-ecn@core3.amsl.com Delivered-To: re-ecn@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 0A7BD3A6A02 for ; Tue, 30 Mar 2010 14:16:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 3.831 X-Spam-Level: *** X-Spam-Status: No, score=3.831 tagged_above=-999 required=5 tests=[AWL=-0.791, BAYES_50=0.001, DNS_FROM_OPENWHOIS=1.13, HELO_EQ_NL=0.55, HOST_EQ_NL=1.545, MIME_QP_LONG_LINE=1.396] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 7Ty1Zc5dDo2X for ; Tue, 30 Mar 2010 14:16:34 -0700 (PDT) Received: from denhaag.ewi.utwente.nl (denhaag.ewi.utwente.nl [130.89.10.11]) by core3.amsl.com (Postfix) with ESMTP id D19553A6987 for ; Tue, 30 Mar 2010 14:16:33 -0700 (PDT) Received: from webmail.cs.utwente.nl (janus.ewi.utwente.nl [130.89.10.26]) by denhaag.ewi.utwente.nl (8.13.6/8.13.6) with SMTP id o2ULGoVC013870; Tue, 30 Mar 2010 23:16:50 +0200 (MEST) Received: from 84.82.109.231 (auth. user karagian@imap1.ewi.utwente.nl) by webmail.cs.utwente.nl with HTTP; Tue, 30 Mar 2010 21:16:51 +0000 To: "philip.eardley@bt.com" , "re-ecn@ietf.org" Date: Tue, 30 Mar 2010 21:16:51 +0000 X-Mailer: IlohaMail/0.8.13 (On: webmail.cs.utwente.nl) Message-ID: In-Reply-To: <4A916DBC72536E419A0BD955EDECEDEC06363F37@E03MVB1-UKBR.domain1.systemhost.net> From: "Georgios Karagiannis" Bounce-To: "Georgios Karagiannis" Errors-To: "Georgios Karagiannis" MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable X-Scanned-By: MIMEDefang 2.52 on 130.89.10.11 X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-3.0rc3 (denhaag.ewi.utwente.nl [130.89.10.11]); Tue, 30 Mar 2010 23:17:01 +0200 (MEST) Subject: Re: [re-ECN] New draft Conex charter - for rapid comments please X-BeenThere: re-ecn@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: re-inserted explicit congestion notification List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 30 Mar 2010 21:16:35 -0000 Hi Phil The new charter looks much better, it is clear and it satisfies the conclusions of the CONEX BOF meeting that we have had in Anaheim! Best regards, Georgios On 3/30/2010, "philip.eardley@bt.com" wrote: >Just to let those of you who weren't in Anaheim about progress.=20 > >We had two good meetings, there are extensive jabber notes (offiicial meetin= g notes to follow) >http://www.ietf.org/jabber/logs/conex/2010-03-24.txt >http://www.ietf.org/jabber/logs/conex/2010-03-25.txt > >We discussed how to change the Charter to meet the issues raised. The follow= ing were proposed and received good support: >* Experimental track (no Standards track docs) >* for the use cases work, concentrate on one use case (where the end hosts &= the destination network are conex-enabled, but not the other networks) >* do IPv6 header encoding >* suggest a work item in tsvwg (probably) about assigning "bit 48" as Experi= mental in the IPv4 header=20 > >Here's a new draft Charter implementing these changes. If we can complete by= Thursday lunchtime, then we should get it into the next IESG call. > >Thanks >Phil & Leslie >--- >Congestion Exposure (CONEX) WG > > >The purpose of the CONEX working group is to develop a mechanism by which se= nders inform the network about the congestion their packets encounter. Today,= the network signals congestion by ECN marking or dropping packets, the recei= ver passes this information back to the sender in transport layer acknowledge= ments, where the sender makes an adjustment to its window size or data rate a= s appropriate. The mechanism to be developed under CONEX will enable the sen= der to also relay the congestion information back into the IP layer such that= the total level of congestion is visible to all IP devices along the path.= =20 > >The primary goal of the CONEX WG is to develop experimental specifications t= o achieve the above. To help explore how to squeeze the necessary information= into a very limited numbers of header bits, the WG will also develop an abst= ract specification for the congestion exposure mechanism, independent of tran= sport and protocol version. > >Primary work items are: > >* An Informational document with an abstract specification for the con= gestion exposure mechanism >* Experimental Specification of IPv6 packet structure that encapsulate= s CONEX information (header bits, interpretation). >* Experimental Specification for modification to TCP, for the timely t= ransport of congestion information from the destination to the sender > >It is believed that the CONEX mechanism will be useful as a generative techn= ology which can be applied as a key element of congestion management solution= s in a wide variety of use cases. However, the WG will initially focus solely= on one use case, where the end hosts and the network of the destination end = host are CONEX-enabled but the other networks are not. CONEX information can = assist the network operator's traffic management and incentivise LEDBAT-like = applications. Experiments on the use case are encouraged and the WG will soli= cit input about their process and findings. The output of the WG includes Inf= ormational document(s) for the use case covering: > >* Assumptions it makes >* Deployment considerations >* Security Threats >* Advice on mitigating threats (detailed work on a mechanism to mitiga= te the threats is out of the initial scope) >* Description of results from experiments on the use case > >In establishing this working group, much interest was expressed in pursuing = an IPv4 specification. A new work item proposed for TSVWG would define how 'b= it 48' of the IPv4 header can be used for Experiments. At the appropriate tim= e, the CONEX WG will consider rechartering to include a work item to specify = the IPv4 packet structure to encapsulate CONEX information.=20 > >Milestones > >Jul 2010 Internet-draft Informational document with an abstract specificatio= n for the congestion exposure mechanism > >Jul 2010 Internet-draft use case > >Sep 2010 Internet-draft specification of IPv6 packet structure. > >Sep 2010 Internet-draft specification for modification to TCP > >Mar 2011 Informational RFC abstract specification of the congestion exposure= mechanism > >Mar 2011 Informational RFC use case > >Sep 2011 Experimental RFC specification of IPv6 packet structure > >Sep 2011 Experimental RFC specification for modification to TCP > From matt.mathis@gmail.com Tue Mar 30 20:54:40 2010 Return-Path: X-Original-To: re-ecn@core3.amsl.com Delivered-To: re-ecn@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id C4A1D3A67A2 for ; Tue, 30 Mar 2010 20:54:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.131 X-Spam-Level: * X-Spam-Status: No, score=1.131 tagged_above=-999 required=5 tests=[BAYES_50=0.001, DNS_FROM_OPENWHOIS=1.13] 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 o4Nh+-Dg3DnJ for ; Tue, 30 Mar 2010 20:54:39 -0700 (PDT) Received: from mail-vw0-f44.google.com (mail-vw0-f44.google.com [209.85.212.44]) by core3.amsl.com (Postfix) with ESMTP id F312A3A6782 for ; Tue, 30 Mar 2010 20:54:38 -0700 (PDT) Received: by vws9 with SMTP id 9so1233082vws.31 for ; Tue, 30 Mar 2010 20:55:05 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:in-reply-to:references :date:received:message-id:subject:from:to:cc:content-type :content-transfer-encoding; bh=CH19sQRuJ4r5my55Kl+c0NXkGHaj3MiPyoilXVyiBbA=; b=EpTZN039GrElou/RyfrHja9sXcytjwAEn6mOP56maQG8D7eGLnQVrP1uuqdq+yktyi a6IfpBKWGLtsccVc9VZgluK1fUFQ4hB/AJiqk10EIVezqZDUI9UhkCRTxn1aiZKv275W oizSW8RFyIa4itUB/XklpXodEzOhBOzHY9PMU= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; b=GntCEHlONivzxRoMHJ0Zv2pWL93gghbwGWUd2WLKxlqax2ZnvNPLesI0JbSM+1HC1F mLuUng8txF3OCVMg6jnpIgtLNnYK/8jKMwTWfmHmZfZxaMFGk4RvUaFwoYjVHgA3T9+5 T+n7cH8ehzdx3Q4kmR3suOswragY224CCi9AE= MIME-Version: 1.0 Received: by 10.220.94.81 with HTTP; Tue, 30 Mar 2010 20:55:05 -0700 (PDT) In-Reply-To: <201003290707.o2T777cP032534@bagheera.jungle.bt.co.uk> References: <201003290707.o2T777cP032534@bagheera.jungle.bt.co.uk> Date: Tue, 30 Mar 2010 23:55:05 -0400 Received: by 10.220.125.93 with SMTP id x29mr4436691vcr.125.1270007705413; Tue, 30 Mar 2010 20:55:05 -0700 (PDT) Message-ID: From: Matt Mathis To: Bob Briscoe Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: "re-ecn@ietf.org list" Subject: Re: [re-ECN] Abstract specification of ConEx X-BeenThere: re-ecn@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: re-inserted explicit congestion notification List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 31 Mar 2010 03:54:40 -0000 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 wro= te: > 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 trie= d > to describe in my earlier posting on this subject): > > The ECN field already shows whether it supports drop (Not-ECT) or ECN (th= e > 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 E= CN. > > >> 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. =A0 =A0Note 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. =A0 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. =A0 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. =A0Perhaps 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 =A0 =A0 =A0http://staff.psc.edu/mathis >> Work:412.268.3319 =A0 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, =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 = =A0BT Innovate & Design > From ingemar.s.johansson@ericsson.com Wed Mar 31 00:19:07 2010 Return-Path: X-Original-To: re-ecn@core3.amsl.com Delivered-To: re-ecn@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 2CDF43A6A36 for ; Wed, 31 Mar 2010 00:19:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.976 X-Spam-Level: X-Spam-Status: No, score=-1.976 tagged_above=-999 required=5 tests=[AWL=1.034, BAYES_20=-0.74, DNS_FROM_OPENWHOIS=1.13, J_CHICKENPOX_72=0.6, 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 BYuc9cDGwgIB for ; Wed, 31 Mar 2010 00:19:04 -0700 (PDT) Received: from mailgw10.se.ericsson.net (mailgw10.se.ericsson.net [193.180.251.61]) by core3.amsl.com (Postfix) with ESMTP id 04CBD3A6A4B for ; Wed, 31 Mar 2010 00:18:24 -0700 (PDT) X-AuditID: c1b4fb3d-b7bf6ae000005bec-8f-4bb2f75e0c75 Received: from esessmw0237.eemea.ericsson.se (Unknown_Domain [153.88.253.125]) by mailgw10.se.ericsson.net (Symantec Brightmail Gateway) with SMTP id 80.B6.23532.E57F2BB4; Wed, 31 Mar 2010 09:18:54 +0200 (CEST) Received: from ESESSCMS0356.eemea.ericsson.se ([169.254.2.100]) by esessmw0237.eemea.ericsson.se ([153.88.115.90]) with mapi; Wed, 31 Mar 2010 09:18:53 +0200 From: Ingemar Johansson S To: Leslie Daigle Date: Wed, 31 Mar 2010 09:18:52 +0200 Thread-Topic: [re-ECN] New draft Conex charter - for rapid comments please Thread-Index: AcrQKNuJWhWXMrswQ6eyDWzmjJ2z5QAdmaUQ Message-ID: <548FC4B9D57A4043AAFFE888A39429031D02006AAA@ESESSCMS0356.eemea.ericsson.se> References: <4A916DBC72536E419A0BD955EDECEDEC06363F3E@E03MVB1-UKBR.domain1.systemhost.net> <4BB22B5C.70101@thinkingcat.com> In-Reply-To: <4BB22B5C.70101@thinkingcat.com> 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="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-Brightmail-Tracker: AAAAAA== Cc: "re-ecn@ietf.org" Subject: Re: [re-ECN] New draft Conex charter - for rapid comments please X-BeenThere: re-ecn@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: re-inserted explicit congestion notification List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 31 Mar 2010 07:19:07 -0000 T0sNCg0KSSBzdGlsbCBoYXZlIG15IGNvbmNlcm5zIG9uIHRoZSBleHBlcmltZW50YWwgcGF0aCBh cyBzaG9ydGVyIGxlYWQtdGltZXMgaW4gdGhlIGluZHVzdHJ5IG1heSBjcmVhdGUgYSBjYXRjaC0y MiBzaXR1YXRpb24sIGl0IHdpbGwgbm90IGJlIHBvc3NpYmxlIHRvIHRlc3QgdGhpcyBvbiBhIGxh cmdlciBzY2FsZSBhcyBpbXBsZW1lbnRvcnMgYXJlIG5vdCBpbnRlcmVzdGVkIGluIGl0IGp1c3Qg YmVjYXVzZSBpdCBpcyAiRXhwZXJpbWVudGFsIi4gRG9pbmcgSFcvc29mdHdhcmUgaXMgcXVpdGUg ZXhwZW5zaXZlIHRvZGF5IGFuZCB0aGVyZSBhcmUgYSBsb3Qgb2YgZmFuY3kgZmVhdHVyZXMgdGhh dCB3YWl0IHRvIGdldCBpbXBsZW1lbnRlZC4gVGhlIHdvcmQgIkV4cGVyaW1lbnRhbCIgZG9lcyBJ TUhPIG5vdCBlbmNvdXJhZ2UgdGhlIGluZHVzdHJ5IHRvIGFsbG9jYXRlIHBlb3BsZSB0byBpbXBs ZW1lbnQgdGhpcy4NCg0KSSBiZWxpZXZlIHRoYXQgdGhlIHRpbmtpbmcgYXJvdW5kIHRoZSByZS1m ZWVkYmFjayAod2hpY2ggaXMgdG8gYmUgZW5jb2RlZCBpbiB0aGUgSVB2NiBoZWFkZXIpIGhhcyBj b21lIHF1aXRlIGZhciwgaXQgbWF5IGJlIHRoZSBjYXNlIHRoYXQgc29tZSB5ZXQgdW5rbm93biB0 cnV0aHMgd2lsbCBlbWVyZ2UgdGhhdCBtYXkgcmVzdWx0IGluIGEgbmVlZCB0byB1cGRhdGUgdGhl IHJlLWZlZWRiYWNrIGJ1dCB0aGVuIHRoZXJlIGFyZSBhIGxvdCBvZiBmcmVlIGJpdHMgaW4gYSBJ UHY2IGV4dGVuc2lvbiBoZWFkZXIgYW5kIGludGVsbGlnZW50IGVuY29kaW5nIGNhbiBtYWtlIGl0 IHBvc3NpYmxlIHRvIGNyZWF0ZSBiYWNrd2FyZHMgY29tcGF0aWJsZSB1cGRhdGVzLiANCg0KQXMg cmVnYXJkcyB0byBJRVNHcyBjb25jZXJucywgd2lsbCBpdCBiZSB1c2VkIGJ5IG9wZXJhdG9ycz8u IEkgc2VlIGFscmVhZHkgdG9kYXkgdGhhdCB0aGVyZSBhcmUgYSByZXByZXNlbnRhdGl2ZXMgb2Yg YSBmZXcgb3BlcmF0b3JzIHdobyBzaG93cyBpbnRlcmVzdCBpbiB0aGlzIG9uIHRoZSBsaXN0IChh bmQgZHVyaW5nIHRoZSBCb0Ygc2Vzc2lvbnMpLiBJZiBpdCBmYWlscyA/LCB0aGVuIGl0IGlzIG5v dCB0aGUgZmlyc3QgdGltZSBhIGNvbmNlcHQgaGFzIGZhaWxlZCBhbmQgdGhlbiB3ZSBhcmUgc3R1 Y2sgd2l0aCBhbiB1bnVzZWQgSVB2NiBoZWFkZXIgZXh0ZW5zaW9uLCBpcyB0aGlzIGEgYmlnIHBy b2JsZW0gPw0KDQpNeSA14oKsDQovSW5nZW1hcg0KDQo+IC0tLS0tT3JpZ2luYWwgTWVzc2FnZS0t LS0tDQo+IEZyb206IExlc2xpZSBEYWlnbGUgW21haWx0bzpsZXNsaWVAdGhpbmtpbmdjYXQuY29t XSANCj4gU2VudDogZGVuIDMwIG1hcnMgMjAxMCAxODo0OA0KPiBUbzogSW5nZW1hciBKb2hhbnNz b24gUw0KPiBDYzogcGhpbGlwLmVhcmRsZXlAYnQuY29tOyByZS1lY25AaWV0Zi5vcmcNCj4gU3Vi amVjdDogUmU6IFtyZS1FQ05dIE5ldyBkcmFmdCBDb25leCBjaGFydGVyIC0gZm9yIHJhcGlkIA0K PiBjb21tZW50cyBwbGVhc2UNCj4gDQo+IA0KPiBJJ2QgbGlrZSB0byBleHBhbmQgYSBsaXR0bGUg b24gUGhpbCdzIHBvaW50LiAgVGhlIElFU0cgDQo+IGd1aWRhbmNlIHdhcyBiYXNlZCBvbiBleHBy ZXNzZWQgY29uY2VybnMgb3ZlciBwcmVkaWN0aW5nIHRoZSANCj4gZXZlbnR1YWwgc3VjY2VzcyAo YW5kDQo+IHVwdGFrZSkgb2YgQ09ORVguDQo+IA0KPiBUd28gb3B0aW9uczoNCj4gDQo+IDEvIEdv IGZvciBleHBlcmltZW50YWwsIGRvIGV4cGVyaW1lbnRzLCBkZW1vbnN0cmF0ZSB1cHRha2UgDQo+ IGFuZCB2aWFiaWxpdHkuICBJdCdzIGVhc3kgZW5vdWdoIHRvIG1vdmUgZG9jdW1lbnRzIHRvIA0K PiBzdGFuZGFyZHMgdHJhY2sgaWYgaXQncyB3YXJyYW50ZWQuDQo+IA0KPiAyLyBHbyBmb3Igc3Rh bmRhcmRzIC0tIHByb3ZlLCBub3csIHRoYXQgdGhpcyBpcyBhIHJlY29tbWVuZGVkIA0KPiBhbmQg ZGVzaXJlZCBkaXJlY3Rpb24gZm9yIHRoZSBJbnRlcm5ldC4NCj4gDQo+IA0KPiBJdCBzZWVtcyAi Mi8iIGlzIGdpdmluZyB0aGUgSUVTRyBoZWFydGJ1cm4sIGFuZCBJIHRoaW5rIGl0J3MgDQo+IGZh aXIgdG8gc2F5IA0KPiB0aGF0IGl0J3MgZWFzaWVyIHRvIHByb3ZlIHRoZSB2aWFiaWxpdHkgb2Yg dGhlIGFwcHJvYWNoIHdoZW4gdGhlcmUgaXMgDQo+IHNvbWUgZm9ybSBvZiBvcGVuIHNwZWNpZmlj YXRpb24gYW5kIHJlc3VsdHMgZnJvbSBicm9hZC1iYXNlZCANCj4gZXhwZXJpbWVudGFsIGRlcGxv eW1lbnRzLg0KPiANCj4gSW4gdGhhdCBsaWdodCAtLSBJIHRoaW5rICIxLyIgbWFrZXMgYSBsb3Qg b2Ygc2Vuc2UuDQo+IA0KPiBMZXNsaWUuDQo+IA0KPiANCj4gcGhpbGlwLmVhcmRsZXlAYnQuY29t IHdyb3RlOg0KPiA+IA0KPiA+PiAtLS0tLU9yaWdpbmFsIE1lc3NhZ2UtLS0tLQ0KPiA+PiBGcm9t OiBJbmdlbWFyIEpvaGFuc3NvbiBTIA0KPiBbbWFpbHRvOmluZ2VtYXIucy5qb2hhbnNzb25AZXJp Y3Nzb24uY29tXSANCj4gPj4gU2VudDogMzAgTWFyY2ggMjAxMCAxMjo1Nw0KPiA+PiBUbzogcmUt ZWNuQGlldGYub3JnDQo+ID4+IENjOiBFYXJkbGV5LFBMLFBoaWxpcCxERUUxIFINCj4gPj4gU3Vi amVjdDogUkU6IFtyZS1FQ05dIE5ldyBkcmFmdCBDb25leCBjaGFydGVyIC0gZm9yIHJhcGlkIA0K PiA+PiBjb21tZW50cyBwbGVhc2UNCj4gPj4NCj4gPj4NCj4gPj4gSGkNCj4gPj4NCj4gPj4gSSBo YXZlIG9uZSBxdWVzdGlvbi4gQmFzZWQgb24gbXkgcmVjZW50bHkgZ2FpbmVkIA0KPiA+PiB1bmRl cnN0YW5kaW5nIGFib3V0ICJlbW90aW9uYWwgZmVlbGluZ3MiIDotKSBhcm91bmQgYml0NDggaW4g DQo+ID4+IElQdjQgSSBjYW4gdW5kZXJzdGFuZCB3aHkgeW91IHByb3Bvc2UgdG8gbWFrZSB1c2Ug b2YgdGhpcyBiaXQgDQo+ID4+IGV4cGVyaW1lbnRhbC4gDQo+ID4+DQo+ID4+IEhvd2V2ZXIgd2hl biBpdCBjb21lcyB0byBJUHY2IEkgYW0gbm90IHJlYWxseSBjb252aW5jZWQgd2h5IA0KPiA+PiB0 aGlzIG5lZWQgdG8gYmUgZXhwZXJpbWVudGFsLiBBcyBJIHVuZGVyc3RhbmQgaXQgdGhlIENvbkV4 IA0KPiA+PiBpbmZvIHdpbGwgYmUgZW5jb2RlZCBpbiBhbiBJUHY2IGV4dGVuc2lvbiB0aGF0IGlz IGVuY29kZWQgaW4gDQo+ID4+IHN1Y2ggYSB3YXkgdGhhdCBhIG5vZGUgY2FuIHNhZmVseSBpZ25v cmUgaXQgYW5kIGp1c3QgbGV0IGl0IA0KPiA+PiBwYXNzIHRocm91Z2ggaWYgaXQgZG9lcyBub3Qg dW5kZXJzdGFuZCBpdCBvciBkb2VzIG5vdCBjYXJlLiANCj4gPj4gTXkgcHJvYmxlbSB3aXRoIHRo ZSB3b3JkICJFeHBlcmltZW50YWwiIGlzIHRoYXQgaXQgaXMganVzdC4uIA0KPiA+PiBleHBlcmlt ZW50YWwgYW5kIEkgaGF2ZSBhIGhhcmQgdGltZSB0byB1bmRlcnN0YW5kIGlmIGUuZyAzR1BQIA0K PiA+PiBpcyBpbnRlcmVzdGVkIGF0IGFsbCB0byBzdXBwb3J0IHNvbWV0aGluZyB0aGF0IGlzIGV4 cGVyaW1lbnRhbC4gDQo+ID4+IFdoYXQgaXMgdGhlIHJpc2sgb2YgbWFraW5nIHRoZSBJUHY2IGhl YWRlciBleHRlbnNpb24gDQo+IHN0YW5kYXJkcyB0cmFjayA/DQo+ID4gDQo+ID4gSSBoYXZlIHN5 bXBhdGh5IHdpdGggeW91ciB2aWV3cG9pbnQgLSBidXQgdGhlIElFU0cgaGF2ZSBnaXZlbiB1cw0K PiA+IGd1aWRhbmNlIHRoYXQgaXQgc2hvdWxkIGJlIEV4cGVyaW1lbnRhbC4gVGhlcmUgaXMgbm8g aGFyZGEgbmYgZmFzdA0KPiA+IGd1aWRhbmNlIG9uIHdoYXQncyBleHBlcmltZW50YWwgYW5kIHdo YXQncyBzdGFuZGFyZHMgdHJhY2suIA0KPiBTYWZldHkgaXMNCj4gPiBvbmUgdGhpbmcgSSd2ZSBo ZWFyZCB0byBkaXN0aW5ndWlzaCB0aGVtIChhcyB5b3Ugc2F5KSAtIA0KPiBhbm90aGVyIGlzICJk bw0KPiA+IHdlIGJlbGlldmUgdGhpcyBpcyBiYWtlZCBlbm91Z2ggZm9yIHRoZSBJRVRGIHRvIHJl Y29tbWVuZCBpdCBmb3INCj4gPiB3aWRlc3ByZWFkIGRlcGxveW1lbnQ/Ii4NCj4gPiBPbiB0aGUg cG9zaXRpdmUgc2lkZSwgdGhlIHRyYW5zaXRpb24gZnJvbSBFeHBlcmltZW50YWwgdG8gc3RhbmRh cmRzDQo+ID4gdHJhY2sgaXMgYSB3ZWxsLWFjY2VwdGVkIHBhdGguIA0KPiA+IA0KPiA+PiBSZWdh cmRzDQo+ID4+IC9JbmdlbWFyDQo+ID4+IA0KPiAtLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tDQo+ID4+PiBNZXNzYWdl OiAxDQo+ID4+PiBEYXRlOiBUdWUsIDMwIE1hciAyMDEwIDExOjQwOjMwICswMTAwDQo+ID4+PiBG cm9tOiA8cGhpbGlwLmVhcmRsZXlAYnQuY29tPg0KPiA+Pj4gU3ViamVjdDogW3JlLUVDTl0gTmV3 IGRyYWZ0IENvbmV4IGNoYXJ0ZXIgLSBmb3IgcmFwaWQgDQo+ID4+IGNvbW1lbnRzIHBsZWFzZQ0K PiA+Pj4gVG86IDxyZS1lY25AaWV0Zi5vcmc+DQo+ID4+PiBNZXNzYWdlLUlEOg0KPiA+Pj4gCQ0K PiA+Pj4gPDRBOTE2REJDNzI1MzZFNDE5QTBCRDk1NUVERUNFREVDMDYzNjNGMzdARTAzTVZCMS1V S0JSLmRvbWFpbjENCj4gPj4+IC5zeXN0ZW1ob3N0Lm5ldD4NCj4gPj4+IAkNCj4gPj4+IENvbnRl bnQtVHlwZTogdGV4dC9wbGFpbjsgY2hhcnNldD0iaXNvLTg4NTktMSINCj4gPj4+DQo+ID4+PiBK dXN0IHRvIGxldCB0aG9zZSBvZiB5b3Ugd2hvIHdlcmVuJ3QgaW4gQW5haGVpbSBhYm91dCBwcm9n cmVzcy4NCj4gPj4+DQo+ID4+PiBXZSBoYWQgdHdvIGdvb2QgbWVldGluZ3MsIHRoZXJlIGFyZSBl eHRlbnNpdmUgamFiYmVyIG5vdGVzDQo+ID4+PiAob2ZmaWljaWFsIG1lZXRpbmcgbm90ZXMgdG8g Zm9sbG93KSANCj4gPj4+IGh0dHA6Ly93d3cuaWV0Zi5vcmcvamFiYmVyL2xvZ3MvY29uZXgvMjAx MC0wMy0yNC50eHQNCj4gPj4+IGh0dHA6Ly93d3cuaWV0Zi5vcmcvamFiYmVyL2xvZ3MvY29uZXgv MjAxMC0wMy0yNS50eHQNCj4gPj4+DQo+ID4+PiBXZSBkaXNjdXNzZWQgaG93IHRvIGNoYW5nZSB0 aGUgQ2hhcnRlciB0byBtZWV0IHRoZSBpc3N1ZXMNCj4gPj4+IHJhaXNlZC4gVGhlIGZvbGxvd2lu ZyB3ZXJlIHByb3Bvc2VkIGFuZCByZWNlaXZlZCBnb29kIHN1cHBvcnQ6DQo+ID4+PiAqIEV4cGVy aW1lbnRhbCB0cmFjayAobm8gU3RhbmRhcmRzIHRyYWNrIGRvY3MpDQo+ID4+PiAqIGZvciB0aGUg dXNlIGNhc2VzIHdvcmssIGNvbmNlbnRyYXRlIG9uIG9uZSB1c2UgY2FzZSAod2hlcmUgDQo+ID4+ PiB0aGUgZW5kIGhvc3RzICYgdGhlIGRlc3RpbmF0aW9uIG5ldHdvcmsgYXJlIGNvbmV4LWVuYWJs ZWQsIA0KPiA+Pj4gYnV0IG5vdCB0aGUgb3RoZXIgbmV0d29ya3MpDQo+ID4+PiAqIGRvIElQdjYg aGVhZGVyIGVuY29kaW5nDQo+ID4+PiAqIHN1Z2dlc3QgYSB3b3JrIGl0ZW0gaW4gdHN2d2cgKHBy b2JhYmx5KSBhYm91dCBhc3NpZ25pbmcgDQo+ID4+PiAiYml0IDQ4IiBhcyBFeHBlcmltZW50YWwg aW4gdGhlIElQdjQgaGVhZGVyIA0KPiA+Pj4NCj4gPj4+IEhlcmUncyBhIG5ldyBkcmFmdCBDaGFy dGVyIGltcGxlbWVudGluZyB0aGVzZSBjaGFuZ2VzLiBJZiB3ZQ0KPiA+Pj4gY2FuIGNvbXBsZXRl IGJ5IFRodXJzZGF5IGx1bmNodGltZSwgdGhlbiB3ZSBzaG91bGQgZ2V0IGl0IA0KPiA+Pj4gaW50 byB0aGUgbmV4dCBJRVNHIGNhbGwuDQo+ID4+Pg0KPiA+Pj4gVGhhbmtzDQo+ID4+PiBQaGlsICYg TGVzbGllDQo+ID4+PiAtLS0NCj4gPj4+IENvbmdlc3Rpb24gRXhwb3N1cmUgKENPTkVYKSBXRw0K PiA+Pj4NCj4gPj4+DQo+ID4+PiBUaGUgcHVycG9zZSBvZiB0aGUgQ09ORVggd29ya2luZyBncm91 cCBpcyB0byBkZXZlbG9wIGENCj4gPj4+IG1lY2hhbmlzbSBieSB3aGljaCBzZW5kZXJzIGluZm9y bSB0aGUgbmV0d29yayBhYm91dCB0aGUgDQo+ID4+PiBjb25nZXN0aW9uIHRoZWlyIHBhY2tldHMg ZW5jb3VudGVyLiBUb2RheSwgdGhlIG5ldHdvcmsgDQo+ID4+PiBzaWduYWxzIGNvbmdlc3Rpb24g YnkgRUNOIG1hcmtpbmcgb3IgZHJvcHBpbmcgcGFja2V0cywgdGhlIA0KPiA+Pj4gcmVjZWl2ZXIg cGFzc2VzIHRoaXMgaW5mb3JtYXRpb24gYmFjayB0byB0aGUgc2VuZGVyIGluIA0KPiA+Pj4gdHJh bnNwb3J0IGxheWVyIGFja25vd2xlZGdlbWVudHMsIHdoZXJlIHRoZSBzZW5kZXIgbWFrZXMgYW4g DQo+ID4+PiBhZGp1c3RtZW50IHRvIGl0cyB3aW5kb3cgc2l6ZSBvciBkYXRhIHJhdGUgYXMgYXBw cm9wcmlhdGUuICANCj4gPj4+IFRoZSBtZWNoYW5pc20gdG8gYmUgZGV2ZWxvcGVkIHVuZGVyIENP TkVYIHdpbGwgZW5hYmxlIHRoZSANCj4gPj4+IHNlbmRlciB0byBhbHNvIHJlbGF5IHRoZSBjb25n ZXN0aW9uIGluZm9ybWF0aW9uIGJhY2sgaW50byB0aGUgDQo+ID4+PiBJUCBsYXllciBzdWNoIHRo YXQgdGhlIHRvdGFsIGxldmVsIG9mIGNvbmdlc3Rpb24gaXMgdmlzaWJsZSANCj4gPj4+IHRvIGFs bCBJUCBkZXZpY2VzIGFsb25nIHRoZSBwYXRoLiANCj4gPj4+DQo+ID4+PiBUaGUgcHJpbWFyeSBn b2FsIG9mIHRoZSBDT05FWCBXRyBpcyB0byBkZXZlbG9wIGV4cGVyaW1lbnRhbA0KPiA+Pj4gc3Bl Y2lmaWNhdGlvbnMgdG8gYWNoaWV2ZSB0aGUgYWJvdmUuIFRvIGhlbHAgZXhwbG9yZSBob3cgdG8g DQo+ID4+PiBzcXVlZXplIHRoZSBuZWNlc3NhcnkgaW5mb3JtYXRpb24gaW50byBhIHZlcnkgbGlt aXRlZCBudW1iZXJzIA0KPiA+Pj4gb2YgaGVhZGVyIGJpdHMsIHRoZSBXRyB3aWxsIGFsc28gZGV2 ZWxvcCBhbiBhYnN0cmFjdCANCj4gPj4+IHNwZWNpZmljYXRpb24gZm9yIHRoZSBjb25nZXN0aW9u IGV4cG9zdXJlIG1lY2hhbmlzbSwgDQo+ID4+PiBpbmRlcGVuZGVudCBvZiB0cmFuc3BvcnQgYW5k IHByb3RvY29sIHZlcnNpb24uDQo+ID4+Pg0KPiA+Pj4gUHJpbWFyeSB3b3JrIGl0ZW1zIGFyZToN Cj4gPj4+DQo+ID4+PiAqICAgICAgIEFuIEluZm9ybWF0aW9uYWwgZG9jdW1lbnQgd2l0aCBhbiBh YnN0cmFjdCANCj4gPj4+IHNwZWNpZmljYXRpb24gZm9yIHRoZSBjb25nZXN0aW9uIGV4cG9zdXJl IG1lY2hhbmlzbQ0KPiA+Pj4gKiAgICAgICBFeHBlcmltZW50YWwgU3BlY2lmaWNhdGlvbiBvZiBJ UHY2IHBhY2tldCBzdHJ1Y3R1cmUgDQo+ID4+PiB0aGF0IGVuY2Fwc3VsYXRlcyBDT05FWCBpbmZv cm1hdGlvbiAoaGVhZGVyIGJpdHMsIGludGVycHJldGF0aW9uKS4NCj4gPj4+ICogICAgICAgRXhw ZXJpbWVudGFsIFNwZWNpZmljYXRpb24gZm9yIG1vZGlmaWNhdGlvbiB0byBUQ1AsIA0KPiA+Pj4g Zm9yIHRoZSB0aW1lbHkgdHJhbnNwb3J0IG9mIGNvbmdlc3Rpb24gaW5mb3JtYXRpb24gZnJvbSB0 aGUNCj4gPj4+IGRlc3RpbmF0aW9uIHRvIHRoZSBzZW5kZXINCj4gPj4+DQo+ID4+PiBJdCBpcyBi ZWxpZXZlZCB0aGF0IHRoZSBDT05FWCBtZWNoYW5pc20gd2lsbCBiZSB1c2VmdWwgYXMgYQ0KPiA+ Pj4gZ2VuZXJhdGl2ZSB0ZWNobm9sb2d5IHdoaWNoIGNhbiBiZSBhcHBsaWVkIGFzIGEga2V5IGVs ZW1lbnQgDQo+ID4+PiBvZiBjb25nZXN0aW9uIG1hbmFnZW1lbnQgc29sdXRpb25zIGluIGEgd2lk ZSB2YXJpZXR5IG9mIHVzZSANCj4gPj4+IGNhc2VzLiBIb3dldmVyLCB0aGUgV0cgd2lsbCBpbml0 aWFsbHkgZm9jdXMgc29sZWx5IG9uIG9uZSB1c2UgDQo+ID4+PiBjYXNlLCB3aGVyZSB0aGUgZW5k IGhvc3RzIGFuZCB0aGUgbmV0d29yayBvZiB0aGUgZGVzdGluYXRpb24gDQo+ID4+PiBlbmQgaG9z dCBhcmUgQ09ORVgtZW5hYmxlZCBidXQgdGhlIG90aGVyIG5ldHdvcmtzIGFyZSBub3QuIA0KPiA+ Pj4gQ09ORVggaW5mb3JtYXRpb24gY2FuIGFzc2lzdCB0aGUgbmV0d29yayBvcGVyYXRvcidzIHRy YWZmaWMgDQo+ID4+PiBtYW5hZ2VtZW50IGFuZCBpbmNlbnRpdmlzZSBMRURCQVQtbGlrZSBhcHBs aWNhdGlvbnMuIA0KPiA+Pj4gRXhwZXJpbWVudHMgb24gdGhlIHVzZSBjYXNlIGFyZSBlbmNvdXJh Z2VkIGFuZCB0aGUgV0cgd2lsbCANCj4gPj4+IHNvbGljaXQgaW5wdXQgYWJvdXQgdGhlaXIgcHJv Y2VzcyBhbmQgZmluZGluZ3MuIFRoZSBvdXRwdXQgb2YgDQo+ID4+PiB0aGUgV0cgaW5jbHVkZXMg SW5mb3JtYXRpb25hbCBkb2N1bWVudChzKSBmb3IgdGhlIHVzZSANCj4gY2FzZSBjb3ZlcmluZzoN Cj4gPj4+DQo+ID4+PiAqICAgICAgIEFzc3VtcHRpb25zIGl0IG1ha2VzDQo+ID4+PiAqICAgICAg IERlcGxveW1lbnQgY29uc2lkZXJhdGlvbnMNCj4gPj4+ICogICAgICAgU2VjdXJpdHkgVGhyZWF0 cw0KPiA+Pj4gKiAgICAgICBBZHZpY2Ugb24gbWl0aWdhdGluZyB0aHJlYXRzIChkZXRhaWxlZCB3 b3JrIG9uIGEgDQo+ID4+PiBtZWNoYW5pc20gdG8gbWl0aWdhdGUgdGhlIHRocmVhdHMgaXMgb3V0 IG9mIHRoZSBpbml0aWFsIHNjb3BlKQ0KPiA+Pj4gKiAgICAgICBEZXNjcmlwdGlvbiBvZiByZXN1 bHRzIGZyb20gZXhwZXJpbWVudHMgb24gdGhlIHVzZSBjYXNlDQo+ID4+Pg0KPiA+Pj4gSW4gZXN0 YWJsaXNoaW5nIHRoaXMgd29ya2luZyBncm91cCwgbXVjaCBpbnRlcmVzdCB3YXMNCj4gPj4+IGV4 cHJlc3NlZCBpbiBwdXJzdWluZyBhbiBJUHY0IHNwZWNpZmljYXRpb24uIEEgbmV3IHdvcmsgaXRl bSANCj4gPj4+IHByb3Bvc2VkIGZvciBUU1ZXRyB3b3VsZCBkZWZpbmUgaG93ICdiaXQgNDgnIG9m IHRoZSBJUHY0IA0KPiA+Pj4gaGVhZGVyIGNhbiBiZSB1c2VkIGZvciBFeHBlcmltZW50cy4gQXQg dGhlIGFwcHJvcHJpYXRlIHRpbWUsIA0KPiA+Pj4gdGhlIENPTkVYIFdHIHdpbGwgY29uc2lkZXIg cmVjaGFydGVyaW5nIHRvIGluY2x1ZGUgYSB3b3JrIA0KPiA+Pj4gaXRlbSB0byBzcGVjaWZ5IHRo ZSBJUHY0IHBhY2tldCBzdHJ1Y3R1cmUgdG8gZW5jYXBzdWxhdGUgDQo+ID4+PiBDT05FWCBpbmZv cm1hdGlvbi4gDQo+ID4+Pg0KPiA+Pj4gTWlsZXN0b25lcw0KPiA+Pj4NCj4gPj4+IEp1bCAyMDEw IEludGVybmV0LWRyYWZ0IEluZm9ybWF0aW9uYWwgZG9jdW1lbnQgd2l0aCBhbg0KPiA+Pj4gYWJz dHJhY3Qgc3BlY2lmaWNhdGlvbiBmb3IgdGhlIGNvbmdlc3Rpb24gZXhwb3N1cmUgbWVjaGFuaXNt DQo+ID4+Pg0KPiA+Pj4gSnVsIDIwMTAgSW50ZXJuZXQtZHJhZnQgdXNlIGNhc2UNCj4gPj4+DQo+ ID4+PiBTZXAgMjAxMCBJbnRlcm5ldC1kcmFmdCBzcGVjaWZpY2F0aW9uIG9mIElQdjYgcGFja2V0 IHN0cnVjdHVyZS4NCj4gPj4+DQo+ID4+PiBTZXAgMjAxMCBJbnRlcm5ldC1kcmFmdCBzcGVjaWZp Y2F0aW9uIGZvciBtb2RpZmljYXRpb24gdG8gVENQDQo+ID4+Pg0KPiA+Pj4gTWFyIDIwMTEgSW5m b3JtYXRpb25hbCBSRkMgYWJzdHJhY3Qgc3BlY2lmaWNhdGlvbiBvZiB0aGUNCj4gPj4+IGNvbmdl c3Rpb24gZXhwb3N1cmUgbWVjaGFuaXNtDQo+ID4+Pg0KPiA+Pj4gTWFyIDIwMTEgSW5mb3JtYXRp b25hbCBSRkMgdXNlIGNhc2UNCj4gPj4+DQo+ID4+PiBTZXAgMjAxMSBFeHBlcmltZW50YWwgUkZD IHNwZWNpZmljYXRpb24gb2YgSVB2NiBwYWNrZXQgc3RydWN0dXJlDQo+ID4+Pg0KPiA+Pj4gU2Vw IDIwMTEgRXhwZXJpbWVudGFsIFJGQyBzcGVjaWZpY2F0aW9uIGZvciBtb2RpZmljYXRpb24gdG8g VENQDQo+ID4+Pg0KPiA+Pj4gLS0tLS0tLS0tLS0tLS0gbmV4dCBwYXJ0IC0tLS0tLS0tLS0tLS0t DQo+ID4+PiBBbiBIVE1MIGF0dGFjaG1lbnQgd2FzIHNjcnViYmVkLi4uDQo+ID4+PiBVUkw6DQo+ ID4+PiA8aHR0cDovL3d3dy5pZXRmLm9yZy9tYWlsLWFyY2hpdmUvd2ViL3JlLWVjbi9hdHRhY2ht ZW50cy8yMDEwMA0KPiA+Pj4gMzMwL2UwOTNjOGE2L2F0dGFjaG1lbnQuaHRtPg0KPiA+Pj4NCj4g Pj4+IC0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLQ0KPiA+Pj4NCj4gPj4+IF9fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fDQo+ID4+PiByZS1FQ04gbWFp bGluZyBsaXN0DQo+ID4+PiByZS1FQ05AaWV0Zi5vcmcNCj4gPj4+IGh0dHBzOi8vd3d3LmlldGYu b3JnL21haWxtYW4vbGlzdGluZm8vcmUtZWNuDQo+ID4+Pg0KPiA+Pj4NCj4gPj4+IEVuZCBvZiBy ZS1FQ04gRGlnZXN0LCBWb2wgMTMsIElzc3VlIDkyDQo+ID4+PiAqKioqKioqKioqKioqKioqKioq KioqKioqKioqKioqKioqKioqKg0KPiA+Pj4NCj4gPiBfX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fXw0KPiA+IHJlLUVDTiBtYWlsaW5nIGxpc3QNCj4gPiByZS1F Q05AaWV0Zi5vcmcNCj4gPiBodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL3Jl LWVjbg0KPiANCj4gLS0gDQo+IA0KPiAtLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tDQo+ICJSZWFsaXR5Og0KPiAgICAgICBZ b3VycyB0byBkaXNjb3Zlci4iDQo+ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIC0t IFRoaW5raW5nQ2F0DQo+IExlc2xpZSBEYWlnbGUNCj4gbGVzbGllQHRoaW5raW5nY2F0LmNvbQ0K PiAtLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tDQo+IA== From ingemar.s.johansson@ericsson.com Wed Mar 31 02:40:00 2010 Return-Path: X-Original-To: re-ecn@core3.amsl.com Delivered-To: re-ecn@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 602623A6841 for ; Wed, 31 Mar 2010 02:40:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.603 X-Spam-Level: X-Spam-Status: No, score=-1.603 tagged_above=-999 required=5 tests=[AWL=-0.134, BAYES_00=-2.599, DNS_FROM_OPENWHOIS=1.13] 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 fau0QD4e4R8R for ; Wed, 31 Mar 2010 02:39:59 -0700 (PDT) Received: from mailgw9.se.ericsson.net (mailgw9.se.ericsson.net [193.180.251.57]) by core3.amsl.com (Postfix) with ESMTP id 8A9493A6870 for ; Wed, 31 Mar 2010 02:39:58 -0700 (PDT) X-AuditID: c1b4fb39-b7b85ae000005cbc-bb-4bb3188baa5a Received: from esessmw0247.eemea.ericsson.se (Unknown_Domain [153.88.253.125]) by mailgw9.se.ericsson.net (Symantec Brightmail Gateway) with SMTP id BB.CD.23740.B8813BB4; Wed, 31 Mar 2010 11:40:27 +0200 (CEST) Received: from ESESSCMS0356.eemea.ericsson.se ([169.254.2.100]) by esessmw0247.eemea.ericsson.se ([10.2.3.116]) with mapi; Wed, 31 Mar 2010 11:40:27 +0200 From: Ingemar Johansson S To: "re-ecn@ietf.org" Date: Wed, 31 Mar 2010 11:40:26 +0200 Thread-Topic: re-ECN Digest, Vol 13, Issue 106 Thread-Index: AcrQhflhdOWndTLeT8Oq87JlA31K3QALzDjA Message-ID: <548FC4B9D57A4043AAFFE888A39429031D02006C9D@ESESSCMS0356.eemea.ericsson.se> References: In-Reply-To: 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: "matt.mathis@gmail.com" Subject: Re: [re-ECN] re-ECN Digest, Vol 13, Issue 106 X-BeenThere: re-ecn@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: re-inserted explicit congestion notification List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 31 Mar 2010 09:40:00 -0000 Hi I believe I agree with Matt. There is a an educational angle to this. I fin= d the red/black/green things somewhat difficult to grasp. For this reason I= believe that it is Ok to "waste codepoints" in the abstract specification,= it will (I believe) make it easier for others to follow the discussion. Co= mpressing the codepoints for the real protocol spec is the next step IMHO. /Ingemar =20 >=20 > Message: 1 > Date: Tue, 30 Mar 2010 23:55:05 -0400 > From: Matt Mathis > Subject: Re: [re-ECN] Abstract specification of ConEx > To: Bob Briscoe > Cc: "re-ecn@ietf.org list" > Message-ID: > > Content-Type: text/plain; charset=3DISO-8859-1 >=20 > 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=20 > rate and most robust when you are close to the sender. >=20 > Furthermore these are orthogonal signals in the transport=20 > ACKs: a single TCP ACK might carry both SACK blocks=20 > indicating losses and ECT marks. Choosing four code points=20 > rather than three independent bits obscures a lot of=20 > information and the concurrency in other parts of the system. >=20 > In order to make sure that the abstract model isn't coloring=20 > our thinking, we really want to preserve all of this=20 > information in the model even though we think it is clear=20 > which credit marks we want to > conflate. That means the abstract model will not be the same as the > IPv6 encoding.... >=20 > Thanks, > --MM-- >=20 >=20 > On Mon, Mar 29, 2010 at 3:06 AM, Bob Briscoe=20 > 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=20 > marks seen at=20 > >> 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=20 > >> retransmissions. > >> GREEN - Pre-credits to used to assure that even though the BLACK=20 > >> marks are delayed by one RTT=20 > count(RED) > > > For an unconstrained abstract encoding, I see this=20 > differently (as I=20 > > tried to describe in my earlier posting on this subject): > > > > The ECN field already shows whether it supports drop=20 > (Not-ECT) or ECN=20 > > (the other three codepoints). So, if an orthoginal=20 > re-feedback field=20 > > 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=20 > re-echo losses. > > Or, combined with the other ECN codepoints, they can be=20 > used to re-echo ECN. > > > > > >> Depending on the deployment scenario and other coding=20 > constraints the=20 > >> sender marking might be three separate ternary values=20 > (unsupported,=20 > >> not marked or marked) or one supported indication plus 3 binary=20 > >> values. ? ?Note that as a practical matter it might be=20 > reasonable to=20 > >> assume one 5 valued signal, but this representation can not model=20 > >> situations where transport might carry both loss and ECN=20 > information=20 > >> on the same ACK. > >> > >> The point of the abstract specification is to permit us to=20 > list some=20 > >> of the algorithms that ConEx might support, such that when=20 > it comes=20 > >> time to choose a particular encoding, it is easy to=20 > understand what=20 > >> features we might forfeit when using it. > >> > >> For example, if a flow is observed to violate=20 > >> count(RED) identified=20 > >> as cheating. ? If I have to encode all of the sender marks into 2=20 > >> bits (4 code points) then would be better not to conflate=20 > BLACK_Loss=20 > >> with either BLACK_ECN or GREEN, because doing so will=20 > either weaken=20 > >> or break the cheating test. ? It looks as though it might be ok to=20 > >> use a single code point for GREEN and BLACK_ECN marks. > >> > >> My notation is not particularly good. ?Perhaps somebody=20 > can suggest=20 > >> 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=20 > >> force to apply it to others. > > > > ________________________________________________________________ > > Bob Briscoe, ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ?BT Innovate & Design > > >=20 >=20 > ------------------------------ >=20 > _______________________________________________ > re-ECN mailing list > re-ECN@ietf.org > https://www.ietf.org/mailman/listinfo/re-ecn >=20 >=20 > End of re-ECN Digest, Vol 13, Issue 106 > *************************************** > = From acooper@cdt.org Wed Mar 31 09:52:40 2010 Return-Path: X-Original-To: re-ecn@core3.amsl.com Delivered-To: re-ecn@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id E9CDB3A6B91 for ; Wed, 31 Mar 2010 09:52:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.788 X-Spam-Level: X-Spam-Status: No, score=-0.788 tagged_above=-999 required=5 tests=[AWL=0.681, BAYES_00=-2.599, DNS_FROM_OPENWHOIS=1.13] 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 LlOHQMS3G4yK for ; Wed, 31 Mar 2010 09:52:39 -0700 (PDT) Received: from mail.maclaboratory.net (mail.maclaboratory.net [209.190.215.232]) by core3.amsl.com (Postfix) with ESMTP id 5096C3A6A44 for ; Wed, 31 Mar 2010 09:43:29 -0700 (PDT) Received: from [10.0.1.112] ([207.188.255.130]) (authenticated user acooper@cdt.org) by mail.maclaboratory.net (using TLSv1/SSLv3 with cipher AES128-SHA (128 bits)) for re-ecn@ietf.org; Wed, 31 Mar 2010 12:43:52 -0400 Message-Id: <405D8C01-DD5E-4616-B073-5217680E01B3@cdt.org> From: Alissa Cooper To: re-ecn@ietf.org In-Reply-To: <4A916DBC72536E419A0BD955EDECEDEC06363F37@E03MVB1-UKBR.domain1.systemhost.net> Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v936) Date: Wed, 31 Mar 2010 12:43:51 -0400 References: <4A916DBC72536E419A0BD955EDECEDEC06363F37@E03MVB1-UKBR.domain1.systemhost.net> X-Mailer: Apple Mail (2.936) Subject: Re: [re-ECN] New draft Conex charter - for rapid comments please X-BeenThere: re-ecn@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: re-inserted explicit congestion notification List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 31 Mar 2010 16:52:41 -0000 Two comments inline... On Mar 30, 2010, at 6:40 AM, wrote: > > --- > Congestion Exposure (CONEX) WG > > > The purpose of the CONEX working group is to develop a mechanism by > which senders inform the network about the congestion their packets > encounter. Today, the network signals congestion by ECN marking or > dropping packets, the receiver passes this information back to the > sender in transport layer acknowledgements, where the sender makes > an adjustment to its window size or data rate as appropriate. > [AC] s/the receiver passes/and the receiver passes/ > The mechanism to be developed under CONEX will enable the sender to > also relay the congestion information back into the IP layer such > that the total level of congestion is visible to all IP devices > along the path. > > The primary goal of the CONEX WG is to develop experimental > specifications to achieve the above. To help explore how to squeeze > the necessary information into a very limited numbers of header > bits, the WG will also develop an abstract specification for the > congestion exposure mechanism, independent of transport and protocol > version. > > Primary work items are: > > * An Informational document with an abstract specification for > the congestion exposure mechanism > * Experimental Specification of IPv6 packet structure that > encapsulates CONEX information (header bits, interpretation). > > * Experimental Specification for 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 which can be applied as a key element of > congestion management solutions in a wide variety of use cases. > However, the WG will initially focus solely on one use case, where > the end hosts and the network of the destination end host are CONEX- > enabled but the other networks are not. CONEX information can assist > the network operator's traffic management and incentivise LEDBAT- > like applications. Experiments on the use case are encouraged and > the WG will solicit input about their process and findings. The > output of the WG includes Informational document(s) for the use case > covering: > > * Assumptions it makes > * Deployment considerations > * Security Threats > * Advice on mitigating threats (detailed work on a mechanism > to mitigate the threats is out of the initial scope) > * Description of results from experiments on the use case > > In establishing this working group, much interest was expressed in > pursuing an IPv4 specification. A new work item proposed for TSVWG > would define how 'bit 48' of the IPv4 header can be used for > Experiments. > [AC] It's unclear what this means -- has the work item already been proposed? Will it definitely be proposed? Or does the CONEX group just really hope it gets proposed so we can get on with standardizing something in the IPv4 header? > At the appropriate time, the CONEX WG will consider rechartering to > include a work item to specify the IPv4 packet structure to > encapsulate CONEX information. > > Milestones > > Jul 2010 Internet-draft Informational document with an abstract > specification for the congestion exposure mechanism > > Jul 2010 Internet-draft use case > > Sep 2010 Internet-draft specification of IPv6 packet structure. > > Sep 2010 Internet-draft specification for modification to TCP > > Mar 2011 Informational RFC abstract specification of the congestion > exposure mechanism > > Mar 2011 Informational RFC use case > > Sep 2011 Experimental RFC specification of IPv6 packet structure > > Sep 2011 Experimental RFC specification for modification to TCP > > _______________________________________________ > re-ECN mailing list > re-ECN@ietf.org > https://www.ietf.org/mailman/listinfo/re-ecn From philip.eardley@bt.com Wed Mar 31 10:04:27 2010 Return-Path: X-Original-To: re-ecn@core3.amsl.com Delivered-To: re-ecn@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id B818D3A6A33 for ; Wed, 31 Mar 2010 10:04:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.047 X-Spam-Level: X-Spam-Status: No, score=-1.047 tagged_above=-999 required=5 tests=[AWL=0.822, BAYES_00=-2.599, DNS_FROM_OPENWHOIS=1.13, J_CHICKENPOX_72=0.6, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id BCmZwUy-xq1N for ; Wed, 31 Mar 2010 10:04:26 -0700 (PDT) Received: from smtp2.smtp.bt.com (smtp2.smtp.bt.com [217.32.164.150]) by core3.amsl.com (Postfix) with ESMTP id 0B4043A6C79 for ; Wed, 31 Mar 2010 09:53:20 -0700 (PDT) Received: from E03MVB1-UKBR.domain1.systemhost.net ([193.113.197.110]) by smtp2.smtp.bt.com with Microsoft SMTPSVC(6.0.3790.3959); Wed, 31 Mar 2010 17:53:51 +0100 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Wed, 31 Mar 2010 17:53:50 +0100 Message-ID: <4A916DBC72536E419A0BD955EDECEDEC06363F50@E03MVB1-UKBR.domain1.systemhost.net> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [re-ECN] New draft Conex charter - for rapid comments please Thread-Index: AcrQ8Dgd9yNl2zI7QOar80GV/SOmAgAAMOWAAABnJVA= From: To: X-OriginalArrivalTime: 31 Mar 2010 16:53:51.0414 (UTC) FILETIME=[BD8AE560:01CAD0F2] Subject: [re-ECN] FW: New draft Conex charter - for rapid comments please X-BeenThere: re-ecn@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: re-inserted explicit congestion notification List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 31 Mar 2010 17:04:27 -0000 Cc list, which got dropped by mistake phil -----Original Message----- From: Eardley,PL,Philip,DEE1 R=20 Sent: 31 March 2010 17:45 To: 'Alissa Cooper' Subject: RE: [re-ECN] New draft Conex charter - for rapid comments please > > > > In establishing this working group, much interest was expressed in=20 > > pursuing an IPv4 specification. A new work item proposed for TSVWG > > would define how 'bit 48' of the IPv4 header can be used for =20 > > Experiments. > > > [AC] It's unclear what this means -- has the work item already been > proposed? Will it definitely be proposed? Or does the CONEX=20 > group just =20 > really hope it gets proposed so we can get on with standardizing =20 > something in the IPv4 header? >=20 At the moment, the last is nearest How about this - The WG hopes that other IETF work (to be proposed for TSVWG) will define how 'bit 48' of the IPv4 header can be used for Experiments. Thanks phil=20 ---- -----Original Message----- From: Alissa Cooper [mailto:acooper@cdt.org]=20 Sent: 31 March 2010 17:36 To: Eardley,PL,Philip,DEE1 R Subject: Re: [re-ECN] New draft Conex charter - for rapid comments please Two comments inline... On Mar 30, 2010, at 6:40 AM, wrote: > > --- > Congestion Exposure (CONEX) WG > > > The purpose of the CONEX working group is to develop a mechanism by > which senders inform the network about the congestion their packets =20 > encounter. Today, the network signals congestion by ECN marking or =20 > dropping packets, the receiver passes this information back to the =20 > sender in transport layer acknowledgements, where the sender makes =20 > an adjustment to its window size or data rate as appropriate. > [AC] s/the receiver passes/and the receiver passes/ > The mechanism to be developed under CONEX will enable the sender to > also relay the congestion information back into the IP layer such =20 > that the total level of congestion is visible to all IP devices =20 > along the path. > > The primary goal of the CONEX WG is to develop experimental > specifications to achieve the above. To help explore how to squeeze =20 > the necessary information into a very limited numbers of header =20 > bits, the WG will also develop an abstract specification for the =20 > congestion exposure mechanism, independent of transport and protocol =20 > version. > > Primary work items are: > > * An Informational document with an abstract specification for =20 > the congestion exposure mechanism > * Experimental Specification of IPv6 packet structure that =20 > encapsulates CONEX information (header bits, interpretation). > > * Experimental Specification for modification to TCP, for the =20 > 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 which can be applied as a key element of =20 > congestion management solutions in a wide variety of use cases. =20 > However, the WG will initially focus solely on one use case, where =20 > the end hosts and the network of the destination end host are CONEX-=20 > enabled but the other networks are not. CONEX information can assist =20 > the network operator's traffic management and incentivise LEDBAT-=20 > like applications. Experiments on the use case are encouraged and =20 > the WG will solicit input about their process and findings. The =20 > output of the WG includes Informational document(s) for the use case =20 > covering: > > * Assumptions it makes > * Deployment considerations > * Security Threats > * Advice on mitigating threats (detailed work on a mechanism =20 > to mitigate the threats is out of the initial scope) > * Description of results from experiments on the use case > > In establishing this working group, much interest was expressed in > pursuing an IPv4 specification. A new work item proposed for TSVWG =20 > would define how 'bit 48' of the IPv4 header can be used for =20 > Experiments. > [AC] It's unclear what this means -- has the work item already been =20 proposed? Will it definitely be proposed? Or does the CONEX group just =20 really hope it gets proposed so we can get on with standardizing =20 something in the IPv4 header? > At the appropriate time, the CONEX WG will consider rechartering to > include a work item to specify the IPv4 packet structure to =20 > encapsulate CONEX information. > > Milestones > > Jul 2010 Internet-draft Informational document with an abstract > specification for the congestion exposure mechanism > > Jul 2010 Internet-draft use case > > Sep 2010 Internet-draft specification of IPv6 packet structure. > > Sep 2010 Internet-draft specification for modification to TCP > > Mar 2011 Informational RFC abstract specification of the congestion > exposure mechanism > > Mar 2011 Informational RFC use case > > Sep 2011 Experimental RFC specification of IPv6 packet structure > > Sep 2011 Experimental RFC specification for modification to TCP > > _______________________________________________ > re-ECN mailing list > re-ECN@ietf.org > https://www.ietf.org/mailman/listinfo/re-ecn From carlberg@g11.org.uk Wed Mar 31 10:20:36 2010 Return-Path: X-Original-To: re-ecn@core3.amsl.com Delivered-To: re-ecn@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 385833A6A5B for ; Wed, 31 Mar 2010 10:20:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.792 X-Spam-Level: X-Spam-Status: No, score=-0.792 tagged_above=-999 required=5 tests=[AWL=0.677, BAYES_00=-2.599, DNS_FROM_OPENWHOIS=1.13] 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 yrswRmcEvAUX for ; Wed, 31 Mar 2010 10:20:35 -0700 (PDT) Received: from portland.eukhost.com (portland.eukhost.com [92.48.97.5]) by core3.amsl.com (Postfix) with ESMTP id E5B283A6AE1 for ; Wed, 31 Mar 2010 10:12:56 -0700 (PDT) Received: from c-76-111-69-4.hsd1.va.comcast.net ([76.111.69.4]:62111 helo=[192.168.0.20]) by portland.eukhost.com with esmtpa (Exim 4.69) (envelope-from ) id 1Nx1To-0000F2-KL; Wed, 31 Mar 2010 17:13:24 +0000 Mime-Version: 1.0 (Apple Message framework v1077) Content-Type: text/plain; charset=us-ascii From: ken carlberg In-Reply-To: <4A916DBC72536E419A0BD955EDECEDEC06363F50@E03MVB1-UKBR.domain1.systemhost.net> Date: Wed, 31 Mar 2010 13:13:25 -0400 Content-Transfer-Encoding: quoted-printable Message-Id: References: <4A916DBC72536E419A0BD955EDECEDEC06363F50@E03MVB1-UKBR.domain1.systemhost.net> To: X-Mailer: Apple Mail (2.1077) X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - portland.eukhost.com X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - g11.org.uk Cc: re-ecn@ietf.org Subject: Re: [re-ECN] FW: New draft Conex charter - for rapid comments please X-BeenThere: re-ecn@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: re-inserted explicit congestion notification List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 31 Mar 2010 17:20:36 -0000 On Mar 31, 2010, at 12:53 PM, wrote: >> [AC] It's unclear what this means -- has the work item already been >> proposed? Will it definitely be proposed? Or does the CONEX=20 >> group just =20 >> really hope it gets proposed so we can get on with standardizing =20 >> something in the IPv4 header? >>=20 > At the moment, the last is nearest >=20 > How about this - > The WG hopes that other IETF work (to be proposed for TSVWG) will = define > how 'bit 48' of the IPv4 header can be used for Experiments. or words to the effect of "...the WG intends to revisit the issue with = IPv4..." However its articulated, I think its important to place a hook in the = charter that convey's the interest of the WG to applying the effort to = IPv4, if at all possible, and even if just under the context of = initially an experimental effort. -ken From philip.eardley@bt.com Wed Mar 31 10:29:17 2010 Return-Path: X-Original-To: re-ecn@core3.amsl.com Delivered-To: re-ecn@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 5D4293A6B56 for ; Wed, 31 Mar 2010 10:29:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.805 X-Spam-Level: X-Spam-Status: No, score=-0.805 tagged_above=-999 required=5 tests=[AWL=0.464, BAYES_00=-2.599, DNS_FROM_OPENWHOIS=1.13, J_CHICKENPOX_21=0.6, J_CHICKENPOX_72=0.6, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id bEY-CZfTzVeI for ; Wed, 31 Mar 2010 10:29:16 -0700 (PDT) Received: from smtp1.smtp.bt.com (smtp1.smtp.bt.com [217.32.164.137]) by core3.amsl.com (Postfix) with ESMTP id 28E523A6B60 for ; Wed, 31 Mar 2010 10:25:35 -0700 (PDT) Received: from E03MVB1-UKBR.domain1.systemhost.net ([193.113.197.110]) by smtp1.smtp.bt.com with Microsoft SMTPSVC(6.0.3790.3959); Wed, 31 Mar 2010 18:26:05 +0100 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Wed, 31 Mar 2010 18:26:04 +0100 Message-ID: <4A916DBC72536E419A0BD955EDECEDEC06363F54@E03MVB1-UKBR.domain1.systemhost.net> In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [re-ECN] FW: New draft Conex charter - for rapid comments please Thread-Index: AcrQ9Xxo0kd6p96VShytEep0golkzAAAKGuQ From: To: X-OriginalArrivalTime: 31 Mar 2010 17:26:05.0049 (UTC) FILETIME=[3E142E90:01CAD0F7] Cc: re-ecn@ietf.org Subject: Re: [re-ECN] FW: New draft Conex charter - for rapid comments please X-BeenThere: re-ecn@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: re-inserted explicit congestion notification List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 31 Mar 2010 17:29:17 -0000 Here's the complete paragraph at the moment < In establishing this working group, much interest was expressed in pursuing an IPv4 specification. The WG hopes that other IETF work (to be proposed for TSVWG) will define how 'bit 48' of the IPv4 header can be used for Experiments. At the appropriate time, the CONEX WG will consider rechartering to include a work item to specify the IPv4 packet structure to encapsulate CONEX information.=20 > - I think this conveys that the wg is very interested in v4. not sure how to spell it out better. The problem with saying something like "the WG intends to revisit the issue with IPv4" is that it seems to say the charter includes v4. somehow we need to say that although v4 is out of scope at the moment, we believe it's important work that we will want to do, once it's a bit clearer how to do this - like the bit48 stuff has got further - and once we'r re-chartered to do it. Open to suggestions [eg a complete new para] as jet lag is starting to zap my word generator. Thanks phil >=20 > -----Original Message----- > From: ken carlberg [mailto:carlberg@g11.org.uk]=20 > Sent: 31 March 2010 18:13 > To: Eardley,PL,Philip,DEE1 R > Cc: re-ecn@ietf.org > Subject: Re: [re-ECN] FW: New draft Conex charter - for rapid=20 > comments please >=20 >=20 >=20 > On Mar 31, 2010, at 12:53 PM, wrote: >=20 > >> [AC] It's unclear what this means -- has the work item=20 > already been=20 > >> proposed? Will it definitely be proposed? Or does the CONEX group=20 > >> just > >> really hope it gets proposed so we can get on with standardizing =20 > >> something in the IPv4 header? > >>=20 > > At the moment, the last is nearest > >=20 > > How about this - > > The WG hopes that other IETF work (to be proposed for TSVWG) will=20 > > define how 'bit 48' of the IPv4 header can be used for Experiments. >=20 > or words to the effect of "...the WG intends to revisit the=20 > issue with IPv4..." >=20 > However its articulated, I think its important to place a=20 > hook in the charter that convey's the interest of the WG to=20 > applying the effort to IPv4, if at all possible, and even if=20 > just under the context of initially an experimental effort. >=20 > -ken >=20 >=20 From philip.eardley@bt.com Wed Mar 31 10:35:24 2010 Return-Path: X-Original-To: re-ecn@core3.amsl.com Delivered-To: re-ecn@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 9DF593A69D4 for ; Wed, 31 Mar 2010 10:35:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.507 X-Spam-Level: X-Spam-Status: No, score=-0.507 tagged_above=-999 required=5 tests=[AWL=0.103, BAYES_20=-0.74, DNS_FROM_OPENWHOIS=1.13, 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 LwBwkQJSlEat for ; Wed, 31 Mar 2010 10:35:23 -0700 (PDT) Received: from smtp1.smtp.bt.com (smtp1.smtp.bt.com [217.32.164.137]) by core3.amsl.com (Postfix) with ESMTP id C6F3E3A69BE for ; Wed, 31 Mar 2010 10:35:17 -0700 (PDT) Received: from E03MVB1-UKBR.domain1.systemhost.net ([193.113.197.110]) by smtp1.smtp.bt.com with Microsoft SMTPSVC(6.0.3790.3959); Wed, 31 Mar 2010 18:35:48 +0100 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Date: Wed, 31 Mar 2010 18:35:48 +0100 Message-ID: <4A916DBC72536E419A0BD955EDECEDEC06363F55@E03MVB1-UKBR.domain1.systemhost.net> In-Reply-To: <201003301817.18286.mkuehle@ikr.uni-stuttgart.de> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [re-ECN] New draft Conex charter - for rapid comments please Thread-Index: AcrQJIv4kysA4WpPQfuh74CxfHNVrQA0r/LQ From: To: , X-OriginalArrivalTime: 31 Mar 2010 17:35:48.0685 (UTC) FILETIME=[99F3F7D0:01CAD0F8] Subject: Re: [re-ECN] New draft Conex charter - for rapid comments please X-BeenThere: re-ecn@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: re-inserted explicit congestion notification List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 31 Mar 2010 17:35:24 -0000 Hi Mirja, - I think adding in something like 'helps it be sensitive to congestion' = is a bit redundant [the fact it's conex information should tell the = reader this] - adding '(not data volume or rate)' might be provocative. Some people = would see conex info as additional - used alongside volume & rate - adding 'thereby' seems good to help connect between the 2 halves of = the sentence. - I don't mind whether 'creates an advantage for using' or = 'incentivises' [the latter is shorter but not a word, at least it's not = in Chambers] - I think it's better to say 'LEDBAT-like applications' than = 'LEDBAT-like congestion control' [someone who doesn't know what ledbat = is might wonder whether 'congestion control' means by end systems or by = something else] Thanks phil=20 > -----Original Message----- > From: re-ecn-bounces@ietf.org=20 > [mailto:re-ecn-bounces@ietf.org] On Behalf Of Mirja K=FChlewind > Sent: 30 March 2010 17:17 > To: re-ecn@ietf.org > Subject: Re: [re-ECN] New draft Conex charter - for rapid=20 > comments please >=20 >=20 > Hi, >=20 > this sentence was not really clear to me at the first moment: >=20 > > CONEX information can assist the network operator's > > traffic management and incentivise LEDBAT-like applications. >=20 > I suggest a working like: CONEX information supports a=20 > network operator's=20 > traffic management which is sensitive to congestion (and not=20 > to data volume=20 > or rate) and thereby creates an advantage for using=20 > LEDBAT-like congestion=20 > control. >=20 > BR, > Mirja >=20 > _______________________________________________ > re-ECN mailing list > re-ECN@ietf.org > https://www.ietf.org/mailman/listinfo/re-ecn >=20 From acooper@cdt.org Wed Mar 31 11:59:08 2010 Return-Path: X-Original-To: re-ecn@core3.amsl.com Delivered-To: re-ecn@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 0C8A63A68E5 for ; Wed, 31 Mar 2010 11:59:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.269 X-Spam-Level: X-Spam-Status: No, score=-0.269 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, DNS_FROM_OPENWHOIS=1.13, J_CHICKENPOX_21=0.6, J_CHICKENPOX_72=0.6] 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 ME7Wu6kDeVjA for ; Wed, 31 Mar 2010 11:59:07 -0700 (PDT) Received: from mail.maclaboratory.net (mail.maclaboratory.net [209.190.215.232]) by core3.amsl.com (Postfix) with ESMTP id D33C03A6A57 for ; Wed, 31 Mar 2010 11:59:06 -0700 (PDT) Received: from [192.168.1.103] ([76.21.209.191]) (authenticated user acooper@cdt.org) by mail.maclaboratory.net (using TLSv1/SSLv3 with cipher AES128-SHA (128 bits)); Wed, 31 Mar 2010 14:59:28 -0400 Message-Id: From: Alissa Cooper To: In-Reply-To: <4A916DBC72536E419A0BD955EDECEDEC06363F54@E03MVB1-UKBR.domain1.systemhost.net> Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v936) Date: Wed, 31 Mar 2010 14:59:26 -0400 References: <4A916DBC72536E419A0BD955EDECEDEC06363F54@E03MVB1-UKBR.domain1.systemhost.net> X-Mailer: Apple Mail (2.936) Cc: re-ecn@ietf.org Subject: Re: [re-ECN] FW: New draft Conex charter - for rapid comments please X-BeenThere: re-ecn@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: re-inserted explicit congestion notification List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 31 Mar 2010 18:59:08 -0000 On Mar 31, 2010, at 1:26 PM, wrote: > Here's the complete paragraph at the moment > > < > In establishing this working group, much interest was expressed in > pursuing an IPv4 specification. The WG hopes that other IETF work > (to be > proposed for TSVWG) will define how 'bit 48' of the IPv4 header can be > used for Experiments. At the appropriate time, the CONEX WG will > consider rechartering to include a work item to specify the IPv4 > packet > structure to encapsulate CONEX information. I think this paragraph does the job. Alissa >> > > - I think this conveys that the wg is very interested in v4. not sure > how to spell it out better. The problem with saying something like > "the > WG intends to revisit the issue with IPv4" is that it seems to say the > charter includes v4. somehow we need to say that although v4 is out of > scope at the moment, we believe it's important work that we will > want to > do, once it's a bit clearer how to do this - like the bit48 stuff has > got further - and once we'r re-chartered to do it. > > Open to suggestions [eg a complete new para] as jet lag is starting to > zap my word generator. > > Thanks > phil >> > >> -----Original Message----- >> From: ken carlberg [mailto:carlberg@g11.org.uk] >> Sent: 31 March 2010 18:13 >> To: Eardley,PL,Philip,DEE1 R >> Cc: re-ecn@ietf.org >> Subject: Re: [re-ECN] FW: New draft Conex charter - for rapid >> comments please >> >> >> >> On Mar 31, 2010, at 12:53 PM, wrote: >> >>>> [AC] It's unclear what this means -- has the work item >> already been >>>> proposed? Will it definitely be proposed? Or does the CONEX group >>>> just >>>> really hope it gets proposed so we can get on with standardizing >>>> something in the IPv4 header? >>>> >>> At the moment, the last is nearest >>> >>> How about this - >>> The WG hopes that other IETF work (to be proposed for TSVWG) will >>> define how 'bit 48' of the IPv4 header can be used for Experiments. >> >> or words to the effect of "...the WG intends to revisit the >> issue with IPv4..." >> >> However its articulated, I think its important to place a >> hook in the charter that convey's the interest of the WG to >> applying the effort to IPv4, if at all possible, and even if >> just under the context of initially an experimental effort. >> >> -ken >> >> > _______________________________________________ > re-ECN mailing list > re-ECN@ietf.org > https://www.ietf.org/mailman/listinfo/re-ecn > From rbriscoe@jungle.bt.co.uk Wed Mar 31 14:29:28 2010 Return-Path: X-Original-To: re-ecn@core3.amsl.com Delivered-To: re-ecn@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 8F7523A6AB7 for ; Wed, 31 Mar 2010 14:29:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.754 X-Spam-Level: * X-Spam-Status: No, score=1.754 tagged_above=-999 required=5 tests=[AWL=0.282, BAYES_20=-0.74, DNS_FROM_OPENWHOIS=1.13, DNS_FROM_RFC_BOGUSMX=1.482, J_CHICKENPOX_72=0.6, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id YkIKd1fUIIo1 for ; Wed, 31 Mar 2010 14:29:21 -0700 (PDT) Received: from smtp2.smtp.bt.com (smtp2.smtp.bt.com [217.32.164.150]) by core3.amsl.com (Postfix) with ESMTP id F03D13A6AD8 for ; Wed, 31 Mar 2010 14:29:10 -0700 (PDT) Received: from i2kc08-ukbr.domain1.systemhost.net ([193.113.197.71]) by smtp2.smtp.bt.com with Microsoft SMTPSVC(6.0.3790.3959); Wed, 31 Mar 2010 22:29:41 +0100 Received: from cbibipnt08.iuser.iroot.adidom.com ([147.149.100.81]) by i2kc08-ukbr.domain1.systemhost.net with Microsoft SMTPSVC(6.0.3790.3959); Wed, 31 Mar 2010 22:29:41 +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 1270070979656; Wed, 31 Mar 2010 22:29:39 +0100 Received: from MUT.jungle.bt.co.uk ([10.73.62.35]) by bagheera.jungle.bt.co.uk (8.13.5/8.12.8) with ESMTP id o2VLTZZn032466; Wed, 31 Mar 2010 22:29:36 +0100 Message-Id: <201003312129.o2VLTZZn032466@bagheera.jungle.bt.co.uk> X-Mailer: QUALCOMM Windows Eudora Version 7.1.0.9 Date: Wed, 31 Mar 2010 22:29:35 +0100 To: , Leslie Daigle From: Bob Briscoe In-Reply-To: <4A916DBC72536E419A0BD955EDECEDEC06363F50@E03MVB1-UKBR.doma in1.systemhost.net> References: <4A916DBC72536E419A0BD955EDECEDEC06363F50@E03MVB1-UKBR.domain1.systemhost.net> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-Scanned-By: MIMEDefang 2.56 on 132.146.168.158 X-OriginalArrivalTime: 31 Mar 2010 21:29:41.0313 (UTC) FILETIME=[460D1310:01CAD119] Cc: re-ecn@ietf.org Subject: Re: [re-ECN] FW: New draft Conex charter - for rapid comments please X-BeenThere: re-ecn@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: re-inserted explicit congestion notification List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 31 Mar 2010 21:29:28 -0000 Phil, Leslie, Thanks for all the ducking and diving you guys have had to do on this. Could you post what you now believe is the latest state of the charter text? I have just one nit: s/the WG will initially focus solely on one use case/ the WG will initially focus on one use case/ I suggest this, because I am concerned we otherwise preclude keeping in mind that ConEx should work in other use cases (which I'm sure was't the IESG intention). In particular, the proposed use-case precludes two networks using ConEx info at their mutual border. Given interconnect was identified as the main unique selling point of ConEx (see earlier thread by Rich Woundy, Alissa Cooper, Mat Ford etc), we don't want to completely preclude using ConEx at interconnect. To satisfy the IESG, we only have to promise not to make anything depend on MPLS. I don't think anyone on the IESG wanted us to preclude interconnection from ConEx scope. Bob At 17:53 31/03/2010, philip.eardley@bt.com wrote: >Cc list, which got dropped by mistake >phil > >-----Original Message----- >From: Eardley,PL,Philip,DEE1 R >Sent: 31 March 2010 17:45 >To: 'Alissa Cooper' >Subject: RE: [re-ECN] New draft Conex charter - for rapid comments >please > > > > --- > > Congestion Exposure (CONEX) WG > > > > > > The purpose of the CONEX working group is to develop a mechanism by > > which senders inform the network about the congestion their packets > > encounter. Today, the network signals congestion by ECN marking or > > dropping packets, the receiver passes this information back to the > > sender in transport layer acknowledgements, where the sender makes > > an adjustment to its window size or data rate as appropriate. > > > > The mechanism to be developed under CONEX will enable the sender to > > also relay the congestion information back into the IP layer such > > that the total level of congestion is visible to all IP devices > > along the path. > > > > The primary goal of the CONEX WG is to develop experimental > > specifications to achieve the above. To help explore how to squeeze > > the necessary information into a very limited numbers of header > > bits, the WG will also develop an abstract specification for the > > congestion exposure mechanism, independent of transport and protocol > > version. > > > > Primary work items are: > > > > * An Informational document with an abstract specification for > > the congestion exposure mechanism > > * Experimental Specification of IPv6 packet structure that > > encapsulates CONEX information (header bits, interpretation). > > > > * Experimental Specification for 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 which can be applied as a key element of > > congestion management solutions in a wide variety of use cases. > > However, the WG will initially focus solely on one use case, where > > the end hosts and the network of the destination end host are CONEX- > > enabled but the other networks are not. CONEX information can assist > > the network operator's traffic management and incentivise LEDBAT- > > like applications. Experiments on the use case are encouraged and > > the WG will solicit input about their process and findings. The > > output of the WG includes Informational document(s) for the use case > > covering: > > > > * Assumptions it makes > > * Deployment considerations > > * Security Threats > > * Advice on mitigating threats (detailed work on a mechanism > > to mitigate the threats is out of the initial scope) > > * Description of results from experiments on the use case > > > > In establishing this working group, much interest was expressed in > > pursuing an IPv4 specification. A new work item proposed for TSVWG > > would define how 'bit 48' of the IPv4 header can be used for > > Experiments. > > > > At the appropriate time, the CONEX WG will consider rechartering to > > include a work item to specify the IPv4 packet structure to > > encapsulate CONEX information. > > > > Milestones > > > > Jul 2010 Internet-draft Informational document with an abstract > > specification for the congestion exposure mechanism > > > > Jul 2010 Internet-draft use case > > > > Sep 2010 Internet-draft specification of IPv6 packet structure. > > > > Sep 2010 Internet-draft specification for modification to TCP > > > > Mar 2011 Informational RFC abstract specification of the congestion > > exposure mechanism > > > > Mar 2011 Informational RFC use case > > > > Sep 2011 Experimental RFC specification of IPv6 packet structure > > > > Sep 2011 Experimental RFC specification for modification to TCP > > > > _______________________________________________ > > re-ECN mailing list > > re-ECN@ietf.org > > https://www.ietf.org/mailman/listinfo/re-ecn > ________________________________________________________________ Bob Briscoe, BT Innovate & Design From lars.eggert@nokia.com Wed Mar 31 23:29:00 2010 Return-Path: X-Original-To: re-ecn@core3.amsl.com Delivered-To: re-ecn@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id CB4E83A6958 for ; Wed, 31 Mar 2010 23:29:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.234 X-Spam-Level: X-Spam-Status: No, score=-5.234 tagged_above=-999 required=5 tests=[AWL=0.235, BAYES_00=-2.599, DNS_FROM_OPENWHOIS=1.13, 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 WD2CRQpsLuIr for ; Wed, 31 Mar 2010 23:28:58 -0700 (PDT) Received: from mgw-mx03.nokia.com (smtp.nokia.com [192.100.122.230]) by core3.amsl.com (Postfix) with ESMTP id 3DBAB3A6885 for ; Wed, 31 Mar 2010 23:28:55 -0700 (PDT) Received: from esebh106.NOE.Nokia.com (esebh106.ntc.nokia.com [172.21.138.213]) by mgw-mx03.nokia.com (Switch-3.3.3/Switch-3.3.3) with ESMTP id o316THqV015600; Thu, 1 Apr 2010 09:29:22 +0300 Received: from esebh102.NOE.Nokia.com ([172.21.138.183]) by esebh106.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.3959); Thu, 1 Apr 2010 09:29:09 +0300 Received: from mgw-sa02.ext.nokia.com ([147.243.1.48]) by esebh102.NOE.Nokia.com over TLS secured channel with Microsoft SMTPSVC(6.0.3790.3959); Thu, 1 Apr 2010 09:29:09 +0300 Received: from mail.fit.nokia.com (esdhcp030222.research.nokia.com [172.21.30.222]) by mgw-sa02.ext.nokia.com (Switch-3.3.3/Switch-3.3.3) with ESMTP id o316T61L005445 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 1 Apr 2010 09:29:06 +0300 X-Virus-Status: Clean X-Virus-Scanned: clamav-milter 0.95.3 at fit.nokia.com Mime-Version: 1.0 (Apple Message framework v1078) Content-Type: multipart/signed; boundary=Apple-Mail-75--261636761; protocol="application/pkcs7-signature"; micalg=sha1 From: Lars Eggert In-Reply-To: <201003312129.o2VLTZZn032466@bagheera.jungle.bt.co.uk> Date: Thu, 1 Apr 2010 09:28:59 +0300 Message-Id: References: <4A916DBC72536E419A0BD955EDECEDEC06363F50@E03MVB1-UKBR.domain1.systemhost.net> <201003312129.o2VLTZZn032466@bagheera.jungle.bt.co.uk> To: Bob Briscoe X-Mailer: Apple Mail (2.1078) X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.2.3 (mail.fit.nokia.com [0.0.0.0]); Thu, 01 Apr 2010 09:28:59 +0300 (EEST) X-OriginalArrivalTime: 01 Apr 2010 06:29:09.0960 (UTC) FILETIME=[A344A480:01CAD164] X-Nokia-AV: Clean Cc: "re-ecn@ietf.org" Subject: Re: [re-ECN] FW: New draft Conex charter - for rapid comments please X-BeenThere: re-ecn@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: re-inserted explicit congestion notification List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 01 Apr 2010 06:29:01 -0000 --Apple-Mail-75--261636761 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii Hi, On 2010-4-1, at 0:29, Bob Briscoe wrote: > Could you post what you now believe is the latest state of the charter = text? this was directed at Phil, but since he sent me what he believed to be = the final text and I made some minor edits, I'll send you what I sent = him an hour ago.=20 Please let me know if this looks good to you. Lars Congestion Exposure (CONEX) WG=20 The purpose of the CONEX working group is to develop a mechanism by which senders inform the network about the congestion their packets encounter. 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, where the sender makes an adjustment to its window size or data rate, as appropriate. The mechanism to be developed by the CONEX WG will enable the sender to also relay the congestion information back into the IP layer, such that the total level of congestion is visible to all IP devices along the path. The primary goal of the CONEX WG is to develop experimental specifications to achieve the above. The WG will also develop an abstract, higher-level description of the congestion exposure mechanism.=20 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. =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. 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 solely on one use case, where the end hosts and the network that contains the destination end host are CONEX-enabled but other networks are not. CONEX information can assist the network operator's traffic management and, for example, incentivize LEDBAT-like applications. Experiments on such 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=20 * 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)=20 * Descriptions of results from experiments with the use case=20 During the chartering discussion of the CONEX WG, much interest was expressed in pursuing a CONEX specification for IPv4. Due to the complications of experimenting with 'bit 48', i.e., the last unassigned bit in the IPv4 header, this was decided to be out of scope for the initial charter. If the IETF comes to consensus on how 'bit 48' can be used for experiments, the CONEX WG may consider rechartering to work on an IPv4 packet structure to encapsulate CONEX information. Milestones=20 Mar 2011 Submit abstract specification for the congestion exposure mechanism to IESG as Informational Mar 2011 Submit use case description to IESG as Informational Sep 2011 Submit specification of IPv6 packet structure to IESG as Experimental Sep 2011 Submit specification for modification to TCP to IESG as Experimental --Apple-Mail-75--261636761 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 MQ8XDTEwMDQwMTA2Mjg1OVowIwYJKoZIhvcNAQkEMRYEFIzfnnFi9drAOQOcGK3XeHAxliaJMIGF BgkrBgEEAYI3EAQxeDB2MGIxCzAJBgNVBAYTAlpBMSUwIwYDVQQKExxUaGF3dGUgQ29uc3VsdGlu ZyAoUHR5KSBMdGQuMSwwKgYDVQQDEyNUaGF3dGUgUGVyc29uYWwgRnJlZW1haWwgSXNzdWluZyBD QQIQB2OTfqxcpudWfXlLT+pSnTCBhwYLKoZIhvcNAQkQAgsxeKB2MGIxCzAJBgNVBAYTAlpBMSUw IwYDVQQKExxUaGF3dGUgQ29uc3VsdGluZyAoUHR5KSBMdGQuMSwwKgYDVQQDEyNUaGF3dGUgUGVy c29uYWwgRnJlZW1haWwgSXNzdWluZyBDQQIQB2OTfqxcpudWfXlLT+pSnTANBgkqhkiG9w0BAQEF AASCAQAWUMEbH4LQ3Dr5oRS/aw2dVGE3I8iRoG+y/KvRgLGbH6h176Vi/rDY68n4vLGunQgC1SjN Qr4opT/boxGDZHy1wGxd2tuJFMAYfNH7WCLN6vb9TFLbntm89pxEDkNYJ/twEFKHhSfQSfvcypYB NG6NXehTgvNZG8YR8l4/NOifXOrU6L9eRpJgoJChsT4PEyqK8uajuqIXLJQj7PW27n+CzsAh0+Ee nR8awqGBfakGtKXhSZH+ruPIXv/qn1ZjKZtIj2m3rkC/qbLBTtLeKx023AHMxxYkZWR/5WpVPPSP +xeU9f9koa2wSrjpFb0Pcz3lPCsdFI+H6H2dsNIN3zzRAAAAAAAA --Apple-Mail-75--261636761--