From lars.eggert@nokia.com Thu Jun 3 04:51:39 2010 Return-Path: X-Original-To: ledbat@core3.amsl.com Delivered-To: ledbat@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 79E733A69CE for ; Thu, 3 Jun 2010 04:51:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.693 X-Spam-Level: X-Spam-Status: No, score=-4.693 tagged_above=-999 required=5 tests=[AWL=-0.694, BAYES_50=0.001, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id JAw74z0XxM9L for ; Thu, 3 Jun 2010 04:51:38 -0700 (PDT) Received: from mgw-mx03.nokia.com (smtp.nokia.com [192.100.122.230]) by core3.amsl.com (Postfix) with ESMTP id 69ACF3A676A for ; Thu, 3 Jun 2010 04:51:37 -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 o53BpDT2002654; Thu, 3 Jun 2010 14:51:21 +0300 Received: from vaebh104.NOE.Nokia.com ([10.160.244.30]) by esebh106.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.4675); Thu, 3 Jun 2010 14:51:06 +0300 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.4675); Thu, 3 Jun 2010 14:51:05 +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 o53Bp4gT017865 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 3 Jun 2010 14:51:04 +0300 From: Lars Eggert X-Virus-Status: Clean X-Virus-Scanned: clamav-milter 0.96.1 at fit.nokia.com Content-Type: multipart/signed; boundary=Apple-Mail-12-905910268; protocol="application/pkcs7-signature"; micalg=sha1 Date: Thu, 3 Jun 2010 14:50:53 +0300 Message-Id: <084FBD1A-13B2-4C0E-BC11-99A4D915B963@nokia.com> To: ledbat@ietf.org Mime-Version: 1.0 (Apple Message framework v1078) X-Mailer: Apple Mail (2.1078) X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.2.5 (mail.fit.nokia.com); Thu, 03 Jun 2010 14:50:54 +0300 (EEST) X-OriginalArrivalTime: 03 Jun 2010 11:51:05.0847 (UTC) FILETIME=[0C755870:01CB0313] X-Nokia-AV: Clean Cc: ledbat-chairs@tools.ietf.org, Rolf Winter Subject: [ledbat] chair change & current status X-BeenThere: ledbat@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Mailing list of the LEDBAT WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 03 Jun 2010 11:51:39 -0000 --Apple-Mail-12-905910268 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii Hi, Stas is stepping down as co-chair. Rolf Winter will replace him = effective immediately. I want to sincerely thank Stas for the significant effort it took to get = agreement to bring a previously proprietary congestion control algorithm = to the IETF, and for the time he has invested in getting the first few = versions of the specification written and progressed. I don't think we = would have been able to spin up this working group without him. I've discussed the current state of the LEDBAT work items with Murari, = Stas and Rolf, and here is my interpretation of where we are: draft-ietf-ledbat-congestion: A few remaining issues need to be worked = through and updated in the document. Requires some regular editing = cycles + a burst of WG activity. Murari and Rolf will discuss whether = they want to assign a co-editor that can drive this WG document to = conclusion. draft-ietf-ledbat-practices-recommendations: We need to step back and = have a discussion on the purpose and content of the document. The = document seems to have a tendency to incorporate new material with each = revision that is not really essential for its stated purpose (e.g., the = DSCP marking section in earlier revisions, now the HTTP sections). draft-ietf-ledbat-survey: Seems to be in reasonable shape, but is also = not the most important document for the WG to publish. Lars= --Apple-Mail-12-905910268 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 MQ8XDTEwMDYwMzExNTA1NFowIwYJKoZIhvcNAQkEMRYEFNvgpMTFXpNML0brh4mb/VNA+aVUMIGF BgkrBgEEAYI3EAQxeDB2MGIxCzAJBgNVBAYTAlpBMSUwIwYDVQQKExxUaGF3dGUgQ29uc3VsdGlu ZyAoUHR5KSBMdGQuMSwwKgYDVQQDEyNUaGF3dGUgUGVyc29uYWwgRnJlZW1haWwgSXNzdWluZyBD QQIQB2OTfqxcpudWfXlLT+pSnTCBhwYLKoZIhvcNAQkQAgsxeKB2MGIxCzAJBgNVBAYTAlpBMSUw IwYDVQQKExxUaGF3dGUgQ29uc3VsdGluZyAoUHR5KSBMdGQuMSwwKgYDVQQDEyNUaGF3dGUgUGVy c29uYWwgRnJlZW1haWwgSXNzdWluZyBDQQIQB2OTfqxcpudWfXlLT+pSnTANBgkqhkiG9w0BAQEF AASCAQAaQC49Wx+ZJI4DcDhi0Z66391ZYM5n9Y6SfdLyvb0gf99ZnUEALFLWGQpKLV6caNbfrWQA mNJLj75BNrI+FNv33CHv3b7DRdbEVZkd5E7KFmZ1WzH9xcSJmRa26OOYxQtP1ruIb5LdwAtlVJYQ qAjb4gjcc1lGNJA7S6FOvEQzVL1YuTwbzcQULMDVM1a1sooST2KzQZ7D3h5i6MUJr0ltK3EmY3Pm i245S08yZ53q7fSP4MOdVxYYcdY/KTho8H/GaM1sE2FXw0jEKmSf8BRr36wwZQ0dDFvmvuPNBtId HC0pd+94kwrF1sYzdhAirE2v31QgkLpgH1fTAEVoN51uAAAAAAAA --Apple-Mail-12-905910268-- From Rolf.Winter@neclab.eu Fri Jun 4 04:57:20 2010 Return-Path: X-Original-To: ledbat@core3.amsl.com Delivered-To: ledbat@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id E78423A692E for ; Fri, 4 Jun 2010 04:57:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.001 X-Spam-Level: X-Spam-Status: No, score=0.001 tagged_above=-999 required=5 tests=[BAYES_50=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id piCImgWWIWJo for ; Fri, 4 Jun 2010 04:57:20 -0700 (PDT) Received: from smtp0.neclab.eu (smtp0.neclab.eu [195.37.70.41]) by core3.amsl.com (Postfix) with ESMTP id D0AA43A6979 for ; Fri, 4 Jun 2010 04:57:19 -0700 (PDT) Received: from localhost (localhost.localdomain [127.0.0.1]) by smtp0.neclab.eu (Postfix) with ESMTP id 23EEE2C000C0A; Fri, 4 Jun 2010 13:57:06 +0200 (CEST) X-Virus-Scanned: Amavisd on Debian GNU/Linux (atlas2.office) Received: from smtp0.neclab.eu ([127.0.0.1]) by localhost (atlas2.office [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Ws6o-Hw1E1Oo; Fri, 4 Jun 2010 13:57:06 +0200 (CEST) Received: from VENUS.office (mx2.office [192.168.24.15]) by smtp0.neclab.eu (Postfix) with ESMTP id 0436B2C000C0C; Fri, 4 Jun 2010 13:56:56 +0200 (CEST) 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, 4 Jun 2010 13:56:55 +0200 Message-ID: <547F018265F92642B577B986577D671C014B9694@VENUS.office> In-Reply-To: <084FBD1A-13B2-4C0E-BC11-99A4D915B963@nokia.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: chair change & current status Thread-Index: AcsDExw+XO6zpHZhRLGZgIDVXf6xVQAra/qw References: <084FBD1A-13B2-4C0E-BC11-99A4D915B963@nokia.com> From: "Rolf Winter" To: Cc: ledbat-chairs@tools.ietf.org Subject: Re: [ledbat] chair change & current status X-BeenThere: ledbat@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Mailing list of the LEDBAT WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 04 Jun 2010 11:57:21 -0000 Hi WG, First of all, I'd also like to thank Stas for his effort bringing LEDBAT = to life. I also pretty much agree with Lars' summary of the situation = but I would like to hear from the WG how they see the status of the = documents.=20 Regarding the congestion control draft, I think it is pretty cooked and = it would be a good thing if we can progress it to the next stage fairly = soon. If you believe there are outstanding issues please raise them on = this list. Especially if you have implementation experience that you = would like to share, please speak up. Rolf NEC Europe Limited | Registered Office: NEC House, 1 Victoria Road, = London W3 6BL | Registered in England 2832014=20 -----Original Message----- From: Lars Eggert [mailto:lars.eggert@nokia.com]=20 Sent: Donnerstag, 3. Juni 2010 13:51 To: ledbat@ietf.org Cc: Rolf Winter; ledbat-chairs@tools.ietf.org Subject: chair change & current status Hi, Stas is stepping down as co-chair. Rolf Winter will replace him = effective immediately. I want to sincerely thank Stas for the significant effort it took to get = agreement to bring a previously proprietary congestion control algorithm = to the IETF, and for the time he has invested in getting the first few = versions of the specification written and progressed. I don't think we = would have been able to spin up this working group without him. I've discussed the current state of the LEDBAT work items with Murari, = Stas and Rolf, and here is my interpretation of where we are: draft-ietf-ledbat-congestion: A few remaining issues need to be worked = through and updated in the document. Requires some regular editing = cycles + a burst of WG activity. Murari and Rolf will discuss whether = they want to assign a co-editor that can drive this WG document to = conclusion. draft-ietf-ledbat-practices-recommendations: We need to step back and = have a discussion on the purpose and content of the document. The = document seems to have a tendency to incorporate new material with each = revision that is not really essential for its stated purpose (e.g., the = DSCP marking section in earlier revisions, now the HTTP sections). draft-ietf-ledbat-survey: Seems to be in reasonable shape, but is also = not the most important document for the WG to publish. Lars From Rolf.Winter@neclab.eu Fri Jun 4 04:59:14 2010 Return-Path: X-Original-To: ledbat@core3.amsl.com Delivered-To: ledbat@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 451403A6931 for ; Fri, 4 Jun 2010 04:59:14 -0700 (PDT) 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=[AWL=2.000, BAYES_50=0.001, GB_I_INVITATION=-2, GB_I_LETTER=-2] 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 43cCMlEMx5E5 for ; Fri, 4 Jun 2010 04:59:13 -0700 (PDT) Received: from smtp0.neclab.eu (smtp0.neclab.eu [195.37.70.41]) by core3.amsl.com (Postfix) with ESMTP id C9B9E3A67EA for ; Fri, 4 Jun 2010 04:59:12 -0700 (PDT) Received: from localhost (localhost.localdomain [127.0.0.1]) by smtp0.neclab.eu (Postfix) with ESMTP id 1AE192C000C0C for ; Fri, 4 Jun 2010 13:58:59 +0200 (CEST) X-Virus-Scanned: Amavisd on Debian GNU/Linux (atlas2.office) Received: from smtp0.neclab.eu ([127.0.0.1]) by localhost (atlas2.office [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id WNhMSi9hpAJC for ; Fri, 4 Jun 2010 13:58:59 +0200 (CEST) Received: from VENUS.office (mx2.office [192.168.24.15]) by smtp0.neclab.eu (Postfix) with ESMTP id F20AD2C000C0A for ; Fri, 4 Jun 2010 13:58:53 +0200 (CEST) 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, 4 Jun 2010 13:58:53 +0200 Message-ID: <547F018265F92642B577B986577D671C014B9695@VENUS.office> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: IETF 78 - Meeting and Sponsorship Information Thread-Index: AcsDVjNwb3ArQ4RwTrab0IvC3w7qfAAhuIGw From: "Rolf Winter" To: Subject: [ledbat] FW: IETF 78 - Meeting and Sponsorship Information X-BeenThere: ledbat@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Mailing list of the LEDBAT WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 04 Jun 2010 11:59:14 -0000 RllJLg0KDQpORUMgRXVyb3BlIExpbWl0ZWQgfCBSZWdpc3RlcmVkIE9mZmljZTogTkVDIEhvdXNl LCAxIFZpY3RvcmlhIFJvYWQsIExvbmRvbiBXMyA2QkwgfCBSZWdpc3RlcmVkIGluIEVuZ2xhbmQg MjgzMjAxNCANCg0KDQotLS0tLU9yaWdpbmFsIE1lc3NhZ2UtLS0tLQ0KRnJvbTogd2djaGFpcnMt Ym91bmNlc0BpZXRmLm9yZyBbbWFpbHRvOndnY2hhaXJzLWJvdW5jZXNAaWV0Zi5vcmddIE9uIEJl aGFsZiBPZiBJRVRGIFNlY3JldGFyaWF0DQpTZW50OiBEb25uZXJzdGFnLCAzLiBKdW5pIDIwMTAg MjE6NTINClRvOiBXb3JraW5nIEdyb3VwIENoYWlycw0KU3ViamVjdDogSUVURiA3OCAtIE1lZXRp bmcgYW5kIFNwb25zb3JzaGlwIEluZm9ybWF0aW9uIA0KDQpXb3JraW5nIEdyb3VwIENoYWlycywN Cg0KQ2FuIHlvdSBwbGVhc2UgZm9yd2FyZCB0aGlzIG1lc3NhZ2UgdG8geW91ciBpbmRpdmlkdWFs IHdvcmtpbmcgZ3JvdXANCmVtYWlscyBsaXN0cy4gIFdlIHdhbnQgdG8gZW5zdXJlIHRoYXQgYXMg bWFueSBwZW9wbGUgYXMgcG9zc2libGUgYXJlIGF3YXJlDQpvZiB0aGUgc3BvbnNvcnNoaXAgb3Bw b3J0dW5pdGllcyBhdmFpbGFibGUgYXQgSUVURiBtZWV0aW5ncy4NCg0KVGhhbmsgeW91Lg0KPT09 PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09DQo3OHRoIElFVEYgTWVldGlu ZyANCk1hYXN0cmljaHQsIE5ldGhlcmxhbmRzDQpKdWx5IDI1LTMwLCAyMDEwIA0KIA0KMS4gU3Bv bnNvcnNoaXAgT3Bwb3J0dW5pdGllcw0KMi4gUmVnaXN0cmF0aW9uIFR5cGVzDQozLiBWaXNhcyBh bmQgTGV0dGVycyBvZiBJbnZpdGF0aW9uDQo0LiBBY2NvbW1vZGF0aW9ucyAmIEJyZWFrZmFzdCBJ bmZvcm1hdGlvbg0KNS4gSUVURiA3OSAoQmVpamluZykgVmlzYSBJbmZvcm1hdGlvbg0KDQoxKSBT cG9uc29yc2hpcCBPcHBvcnR1bml0aWVzDQpUaGVyZSBhcmUgc3RpbGwgc3BvbnNvcnNoaXAgb3Bw b3J0dW5pdGllcyBhbmQgYmVuZWZpdHMgZm9yIGhpZ2ggcHJvZmlsZQ0KY29tcGFueS9vcmdhbml6 YXRpb25hbCBleHBvc3VyZSBhdCB0aGUgdXBjb21pbmcgSUVURiBtZWV0aW5nIGluDQpNYWFzdHJp Y2h0LCBOZXRoZXJsYW5kcyBmcm9tIEp1bHkgMjUtMzAsIDIwMTAuICBBbGwgc3BvbnNvcnNoaXAg ZmVlcyBnbw0KZGlyZWN0bHkgdG8gZnVuZCB0aGUgb3BlcmF0aW9ucyBvZiB0aGUgSUVURi4gIFNl ZSB0aGUgb3B0aW9ucyBhdDoNCmh0dHA6Ly93d3cuaWV0Zi5vcmcvbWVldGluZy83OC9pbmRleC5o dG1sIFNwb25zb3JzaGlwIE9wcG9ydHVuaXRpZXMNCnVuZGVyIEdlbmVyYWwuICBFYWNoIG9mIHRo ZSBzcG9uc29yc2hpcCBvcHRpb25zIHByb3ZpZGUgZXh0ZW5kZWQgYW5kDQpyZXBlYXQgZXhwb3N1 cmUgYXQgdGhpcyB3ZWVrbG9uZyBtZWV0aW5nLiAgIA0KDQpQbGVhc2UgY29udGFjdCBEcmV3IER2 b3JzaGFrLCBkdm9yc2hha0Bpc29jLm9yZywgd2l0aCBhbnkgcXVlc3Rpb25zDQphbmQvb3IgdG8g cmVzZXJ2ZSB5b3VyIG9yZ2FuaXphdGlvbnMgc3BvdC4gIFRoYW5rcyBpbiBhZHZhbmNlIGZvcg0K c3VwcG9ydGluZyB0aGUgY3JpdGljYWwgd29yayBvZiB0aGUgSUVURiENCg0KMikgUmVnaXN0ZXIg b25saW5lIGF0OiAgaHR0cDovL3d3dy5pZXRmLm9yZy9tZWV0aW5ncy83OC8NCg0KMykgTGV0dGVy cyBvZiBJbnZpdGF0aW9uIGFuZCBWaXNhcyANCkxldHRlcnMgb2YgSW52aXRhdGlvbg0KQWZ0ZXIg eW91IGNvbXBsZXRlIHRoZSBtZWV0aW5nIHJlZ2lzdHJhdGlvbiBwcm9jZXNzLCB5b3Ugd2lsbCBi ZSBnaXZlbiB0aGUNCm9wdGlvbiB0byByZXF1ZXN0IGEgbGV0dGVyIG9mIGludml0YXRpb24uIFlv dSBjYW4gcmVxdWVzdCB0aGUgTGV0dGVyIG9mDQpJbnZpdGF0aW9uIGFzIHNvb24gYXMgeW91IGZp bmlzaCByZWdpc3RyYXRpb24sIG9yIGF0IGEgbGF0ZXIgdGltZSBieQ0KZm9sbG93aW5nIHRoZSBs aW5rIHByb3ZpZGVkIGluIHRoZSBjb25maXJtYXRpb24gZW1haWwuDQoNClZpc2FzDQpQbGVhc2Ug Y2hlY2sgdGhlIE5ldGhlcmxhbmRzIE1pbmlzdHJ5IG9mIEZvcmVpZ24gQWZmYWlycyBzaXRlDQoo aHR0cDovL3d3dy5taW5idXphLm5sL2VuL1NlcnZpY2VzL0NvbnN1bGFyX1NlcnZpY2VzL1Zpc2Ep IGZvciBsaXN0IG9mDQpjb3VudHJpZXMgd2l0aCB2aXNhIGV4ZW1wdGlvbnMuDQoNCldlIHJlY29t bWVuZCB5b3UgZ2l2ZSB5b3Vyc2VsZiBhdCBsZWFzdCBvbmUgbW9udGggdG8gY29tcGxldGUgdGhl IHZpc2ENCnByb2Nlc3MuDQoNCjQpIEFjY29tbW9kYXRpb25zICYgQnJlYWtmYXN0IEluZm9ybWF0 aW9uDQpodHRwOi8vd3d3LmlldGYub3JnL21lZXRpbmcvNzgvaG90ZWwuaHRtbA0KDQo1KSBJZiB5 b3Ugd2FudCB0byBzdGFydCBwbGFubmluZyBmb3IgeW91ciB0cmlwIHRvIElFVEYgNzkgaW4gQmVp amluZywgd2UNCmhhdmUgdmlzYSBpbmZvcm1hdGlvbiBvbmxpbmUgaGVyZToNCmh0dHA6Ly93d3cu aWV0Zi5vcmcvbWVldGluZy83OS92aXNhLmh0bWwNCg0KT25seSA1MiBkYXlzIHVudGlsIElFVEYg NzghDQoNCg== From Rolf.Winter@neclab.eu Tue Jun 8 07:03:42 2010 Return-Path: X-Original-To: ledbat@core3.amsl.com Delivered-To: ledbat@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id B205F28C1BD for ; Tue, 8 Jun 2010 07:03:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.001 X-Spam-Level: X-Spam-Status: No, score=0.001 tagged_above=-999 required=5 tests=[AWL=-0.001, 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 rzLpnZBuM55Z for ; Tue, 8 Jun 2010 07:03:42 -0700 (PDT) Received: from smtp0.neclab.eu (smtp0.neclab.eu [195.37.70.41]) by core3.amsl.com (Postfix) with ESMTP id D25B728C1AF for ; Tue, 8 Jun 2010 07:03:41 -0700 (PDT) Received: from localhost (localhost.localdomain [127.0.0.1]) by smtp0.neclab.eu (Postfix) with ESMTP id C56A22C000C08 for ; Tue, 8 Jun 2010 16:03:42 +0200 (CEST) X-Virus-Scanned: Amavisd on Debian GNU/Linux (atlas2.office) Received: from smtp0.neclab.eu ([127.0.0.1]) by localhost (atlas2.office [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id mK-kz1HShW6D for ; Tue, 8 Jun 2010 16:03:42 +0200 (CEST) Received: from VENUS.office (mx2.office [192.168.24.15]) by smtp0.neclab.eu (Postfix) with ESMTP id AB3882C000C05 for ; Tue, 8 Jun 2010 16:03:37 +0200 (CEST) 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, 8 Jun 2010 16:03:37 +0200 Message-ID: <547F018265F92642B577B986577D671C014B9A15@VENUS.office> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Open issues, part 1 Thread-Index: AcsHE2PQewQv0uuySr+/Cf14F2gaSA== From: "Rolf Winter" To: Subject: [ledbat] Open issues, part 1 X-BeenThere: ledbat@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Mailing list of the LEDBAT WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 08 Jun 2010 14:03:43 -0000 Hi, Here is the first Email in a series of Emails (to keep Email threats = separate) which deal with open points in the congestion control draft. I = pulled those together from various sources such as meeting minutes. I = would like have a documented agreement on them. If there are other open = question please speak up. 1. Parameters There were comments on the parameterization of the congestion control = draft. The main concern was that they seem to come out of thin air. To = close this issue I'd like to ask the group whether they think the = parameters are sensible or not (e.g. 25ms delay target). It would be = good to hear from people such as, say, game developers what they have to = say about this target. A better description of why these were chosen is = surely something that should go into the text. Best, Rolf NEC Europe Limited | Registered Office: NEC House, 1 Victoria Road, = London W3 6BL | Registered in England 2832014=20 From Rolf.Winter@neclab.eu Tue Jun 8 07:05:52 2010 Return-Path: X-Original-To: ledbat@core3.amsl.com Delivered-To: ledbat@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 45D9328C1AC for ; Tue, 8 Jun 2010 07:05:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.999 X-Spam-Level: X-Spam-Status: No, score=-0.999 tagged_above=-999 required=5 tests=[AWL=1.000, BAYES_50=0.001, GB_I_INVITATION=-2] 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 b1uwLoK744xz for ; Tue, 8 Jun 2010 07:05:51 -0700 (PDT) Received: from smtp0.neclab.eu (smtp0.neclab.eu [195.37.70.41]) by core3.amsl.com (Postfix) with ESMTP id 5B69428C1AA for ; Tue, 8 Jun 2010 07:05:51 -0700 (PDT) Received: from localhost (localhost.localdomain [127.0.0.1]) by smtp0.neclab.eu (Postfix) with ESMTP id 581842C000C08 for ; Tue, 8 Jun 2010 16:05:52 +0200 (CEST) X-Virus-Scanned: Amavisd on Debian GNU/Linux (atlas2.office) Received: from smtp0.neclab.eu ([127.0.0.1]) by localhost (atlas2.office [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id cdiIiMiaqo5N for ; Tue, 8 Jun 2010 16:05:52 +0200 (CEST) Received: from VENUS.office (mx2.office [192.168.24.15]) by smtp0.neclab.eu (Postfix) with ESMTP id 3D8BB2C000C05 for ; Tue, 8 Jun 2010 16:05:47 +0200 (CEST) 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, 8 Jun 2010 16:05:46 +0200 Message-ID: <547F018265F92642B577B986577D671C014B9A18@VENUS.office> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: open issues, delay target MUST/SHOULD Thread-Index: AcsHE7EPwu5G5jJIT+mRdCF01fJqqg== From: "Rolf Winter" To: Subject: [ledbat] open issues, delay target MUST/SHOULD X-BeenThere: ledbat@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Mailing list of the LEDBAT WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 08 Jun 2010 14:05:52 -0000 Hi, Here's the second open issue: 2. MUST/SHOULD/SHALL on the delay target Should the delay target be MUST or SHOULD (or something else). There was = a discussion on whether the delay target should be required to be 25ms. = Stas argued it is needed for interoperability. But some people argued it = would be good if people were allowed to experiment with different = values. I personally think this should be fixed. My argument would be = that if people were allowed to fiddle with the 25 ms they will in order = to have their app to perform better. Imagine two p2p applications = running behind a common bottleneck (in your home network e.g.). The one = choosing a slightly higher target will win over the other. We did = experiments with this and found a few milliseconds to be sufficient. = This potentially is an open invitation to an arms race amongst app = developers I think. I'd like to hear more arguments for either one or = the other. Best, Rolf NEC Europe Limited | Registered Office: NEC House, 1 Victoria Road, = London W3 6BL | Registered in England 2832014=20 From Rolf.Winter@neclab.eu Tue Jun 8 07:08:05 2010 Return-Path: X-Original-To: ledbat@core3.amsl.com Delivered-To: ledbat@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id B498628C1E9 for ; Tue, 8 Jun 2010 07:08:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.333 X-Spam-Level: X-Spam-Status: No, score=-0.333 tagged_above=-999 required=5 tests=[AWL=-0.334, 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 1ICrqCkuOwxd for ; Tue, 8 Jun 2010 07:08:04 -0700 (PDT) Received: from smtp0.neclab.eu (smtp0.neclab.eu [195.37.70.41]) by core3.amsl.com (Postfix) with ESMTP id 8C21728C1E6 for ; Tue, 8 Jun 2010 07:08:04 -0700 (PDT) Received: from localhost (localhost.localdomain [127.0.0.1]) by smtp0.neclab.eu (Postfix) with ESMTP id 6CE0A2C000C0D for ; Tue, 8 Jun 2010 16:08:05 +0200 (CEST) X-Virus-Scanned: Amavisd on Debian GNU/Linux (atlas2.office) Received: from smtp0.neclab.eu ([127.0.0.1]) by localhost (atlas2.office [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id eSm55uHJDg+e for ; Tue, 8 Jun 2010 16:08:05 +0200 (CEST) Received: from VENUS.office (mx2.office [192.168.24.15]) by smtp0.neclab.eu (Postfix) with ESMTP id 4E5962C000C09 for ; Tue, 8 Jun 2010 16:08:00 +0200 (CEST) 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, 8 Jun 2010 16:07:59 +0200 Message-ID: <547F018265F92642B577B986577D671C014B9A19@VENUS.office> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: open issues, applicability statement Thread-Index: AcsHFABmMEHKK4SBRAyUv05eOptF9g== From: "Rolf Winter" To: Subject: [ledbat] open issues, applicability statement X-BeenThere: ledbat@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Mailing list of the LEDBAT WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 08 Jun 2010 14:08:05 -0000 Hi, third open issue: 3. Applicability I myself had a few comments on clarifications in the document during the = last meeting. There maybe are a few applicability statements we could = add to the draft. E.g. today there are still a lot of rural areas served = by DSL with really low uplink capacities. LEDBAT will not be able to = achieve the delay target here if full-sized segments are sent. A single = segment will violate the 25 ms. This could be added, with a comment that = adaptive segment sizing is not in scope of the document but is not = precluded by the document either.=20 Another hint could be given to home gateway manufactures which like to = classify P2P traffic into low priority class queues. Which is fine when = they run over TCP, but LEDBAT deals with the "problem" already so there = is no need to put it into a different queue. In fact we did some = measurements that show that in certain circumstances LEDBAT will not = fulfil its design goals in such a low priority queue anymore. But that = is home gateway implementation-specific. There were arguments against = this. Please discuss. Best, Rolf NEC Europe Limited | Registered Office: NEC House, 1 Victoria Road, = London W3 6BL | Registered in England 2832014=20 From Rolf.Winter@neclab.eu Tue Jun 8 07:10:00 2010 Return-Path: X-Original-To: ledbat@core3.amsl.com Delivered-To: ledbat@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 4DEDF28C1B2 for ; Tue, 8 Jun 2010 07:10:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.249 X-Spam-Level: X-Spam-Status: No, score=-0.249 tagged_above=-999 required=5 tests=[AWL=-0.250, 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 UTKDuVzKPYAJ for ; Tue, 8 Jun 2010 07:09:56 -0700 (PDT) Received: from smtp0.neclab.eu (smtp0.neclab.eu [195.37.70.41]) by core3.amsl.com (Postfix) with ESMTP id 710E228C1C7 for ; Tue, 8 Jun 2010 07:09:56 -0700 (PDT) Received: from localhost (localhost.localdomain [127.0.0.1]) by smtp0.neclab.eu (Postfix) with ESMTP id 6E3DA2C000C08 for ; Tue, 8 Jun 2010 16:09:57 +0200 (CEST) X-Virus-Scanned: Amavisd on Debian GNU/Linux (atlas2.office) Received: from smtp0.neclab.eu ([127.0.0.1]) by localhost (atlas2.office [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id AM4Eh-fVzR09 for ; Tue, 8 Jun 2010 16:09:57 +0200 (CEST) Received: from VENUS.office (mx2.office [192.168.24.15]) by smtp0.neclab.eu (Postfix) with ESMTP id 52E492C000C05 for ; Tue, 8 Jun 2010 16:09:52 +0200 (CEST) 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, 8 Jun 2010 16:09:51 +0200 Message-ID: <547F018265F92642B577B986577D671C014B9A1A@VENUS.office> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: open issues, ACK rate Thread-Index: AcsHFEMeWPWCdOFmTwSo+iLv1U/TGA== From: "Rolf Winter" To: Subject: [ledbat] open issues, ACK rate X-BeenThere: ledbat@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Mailing list of the LEDBAT WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 08 Jun 2010 14:10:00 -0000 Hi WG, my final comment for now. If you have more, please speak up: 4. ACK rate In the framing and wire format section, Stas promised to add a statement = that LEDBAT needs to send (and receive) ACKs frequently in order to work = properly. This is an open issue that needs to be solved. As this has not = happened yet, text to include from the WG is more than welcome. Details = on what frequently should mean in practice is open for discussion. Best, Rolf NEC Europe Limited | Registered Office: NEC House, 1 Victoria Road, = London W3 6BL | Registered in England 2832014=20 From muraris@microsoft.com Wed Jun 9 08:27:01 2010 Return-Path: X-Original-To: ledbat@core3.amsl.com Delivered-To: ledbat@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id A7A493A695D for ; Wed, 9 Jun 2010 08:27:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -7.998 X-Spam-Level: X-Spam-Status: No, score=-7.998 tagged_above=-999 required=5 tests=[BAYES_50=0.001, HTML_MESSAGE=0.001, 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 YKa1QTGqVT9D for ; Wed, 9 Jun 2010 08:26:56 -0700 (PDT) Received: from smtp.microsoft.com (smtp.microsoft.com [131.107.115.214]) by core3.amsl.com (Postfix) with ESMTP id 5548E3A6814 for ; Wed, 9 Jun 2010 08:26:56 -0700 (PDT) Received: from TK5EX14MLTC104.redmond.corp.microsoft.com (157.54.79.159) by TK5-EXGWY-E803.partners.extranet.microsoft.com (10.251.56.169) with Microsoft SMTP Server (TLS) id 8.2.176.0; Wed, 9 Jun 2010 08:26:58 -0700 Received: from tk5ex14mbxc106.redmond.corp.microsoft.com ([169.254.3.138]) by TK5EX14MLTC104.redmond.corp.microsoft.com ([157.54.79.159]) with mapi id 14.01.0160.007; Wed, 9 Jun 2010 08:26:57 -0700 From: Murari Sridharan To: "ledbat@ietf.org" Thread-Topic: LEDBAT Status and plan moving forward Thread-Index: AcsH6AOcGRfe5LK9Saun62y28KOcIg== Date: Wed, 9 Jun 2010 15:26:56 +0000 Message-ID: <902F4C8483487C40A366621E25F01D960605CBA9@tk5ex14mbxc106.redmond.corp.microsoft.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: Content-Type: multipart/alternative; boundary="_000_902F4C8483487C40A366621E25F01D960605CBA9tk5ex14mbxc106r_" MIME-Version: 1.0 Cc: "ledbat-chairs@tools.ietf.org" Subject: [ledbat] LEDBAT Status and plan moving forward X-BeenThere: ledbat@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Mailing list of the LEDBAT WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 09 Jun 2010 15:27:01 -0000 --_000_902F4C8483487C40A366621E25F01D960605CBA9tk5ex14mbxc106r_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable All: We set out with three goals for this WG with the most important one to put = out an experimental congestion algorithm for less-than-best-effort traffic. Oct 2009 - Submit 'Multiple Transport Connections in Applications Design' t= o the IESG for consideration as an Informational RFC Oct 2009 - Submit 'Low Extra Delay Background Transport (LEDBAT)' to the IE= SG for consideration as an Experimental RFC Feb 2010 - Submit 'A Survey of Lower-than-Best Effort Transport Protocols' = to the IESG for consideration as an Informational RFC The first draft draft-ietf-ledbat-practices-recommendations isn't convergin= g, Rolf and I are going to have a chat with the authors regarding this draf= t. We want to hear from the group if they think this document is useful in = its present form. We started out with all the right intentions here but thi= s is simply not converging. Unless there is strong interest in keeping draf= t-ietf-ledbat-practices-recommendations alive we should drop it as a WG doc= ument. draft draft-ietf-ledbat-congestion is in great shape and once a few remaini= ng issues are addressed I think we are ready to recommend this to IESG cons= ideration as an Experimental RFC. Either I or Jana will be working with Sta= s to make the remaining changes to the draft and address the open issues. The survey is in a good shape but as Lars pointed out isn't the most import= ant document to work on. This brings us to the plan for IETF78. Rolf and I had a chat this morning a= bout whether this WG should meet. We want the list to speak up. Our recomme= ndation is to make changes to the ledbat draft and complete the discussion = over email, forward the document to IESG and close the WG. Please speak up, as of now we do not plan to schedule a meeting at the next= IETF. Thanks Murari & Rolf. --_000_902F4C8483487C40A366621E25F01D960605CBA9tk5ex14mbxc106r_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

All:

 

We set out with three goals for this WG with the mos= t important one to put out an experimental congestion algorithm for less-th= an-best-effort traffic.

 

Oct 2009 - Submit '= Multiple Transport Connections in Applications Design' to the IESG for cons= ideration as an Informational RFC

Oct 2009 - Submit '= Low Extra Delay Background Transport (LEDBAT)' to the IESG for consideratio= n as an Experimental RFC

Feb 2010 - Submit '= A Survey of Lower-than-Best Effort Transport Protocols' to the IESG for con= sideration as an Informational RFC

 

The first draft draft-ietf-ledbat-practices-recommendations isn’t converging, Rol= f and I are going to have a chat with the authors regarding this draft. We = want to hear from the group if they think this document is useful in its present form. We started out with all the r= ight intentions here but this is simply not converging. Unless there is str= ong interest in keeping draft-ietf-ledbat-practices-recommendations alive w= e should drop it as a WG document.

 

draft draft-ietf-ledbat-congestion is in great shape= and once a few remaining issues are addressed I think we are ready to reco= mmend this to IESG consideration as an Experimental RFC. Either I or Jana w= ill be working with Stas to make the remaining changes to the draft and address the open issues.

 

The survey is in a good shape but as Lars pointed ou= t isn’t the most important document to work on.

 

This brings us to the plan for IETF78. Rolf and I ha= d a chat this morning about whether this WG should meet. We want the list t= o speak up. Our recommendation is to make changes to the ledbat draft and c= omplete the discussion over email, forward the document to IESG and close the WG.

 

Please speak up, as of now we do not plan to schedul= e a meeting at the next IETF.

 

Thanks

Murari & Rolf. =

 

--_000_902F4C8483487C40A366621E25F01D960605CBA9tk5ex14mbxc106r_-- From michawe@ifi.uio.no Wed Jun 9 08:41:50 2010 Return-Path: X-Original-To: ledbat@core3.amsl.com Delivered-To: ledbat@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 91DBB3A697F for ; Wed, 9 Jun 2010 08:41:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.999 X-Spam-Level: X-Spam-Status: No, score=-3.999 tagged_above=-999 required=5 tests=[BAYES_50=0.001, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Hh2kUUs4-QSL for ; Wed, 9 Jun 2010 08:41:49 -0700 (PDT) Received: from mail-out1.uio.no (mail-out1.uio.no [129.240.10.57]) by core3.amsl.com (Postfix) with ESMTP id 58B073A67F6 for ; Wed, 9 Jun 2010 08:41:49 -0700 (PDT) Received: from mail-mx3.uio.no ([129.240.10.44]) by mail-out1.uio.no with esmtp (Exim 4.69) (envelope-from ) id 1OMNPZ-0004GD-Ew; Wed, 09 Jun 2010 17:41:49 +0200 Received: from div-8021x-dhcp216.uio.no ([193.157.176.225]) by mail-mx3.uio.no with esmtpsa (TLSv1:AES128-SHA:128) user michawe (Exim 4.69) (envelope-from ) id 1OMNPY-0005Ic-VD; Wed, 09 Jun 2010 17:41:49 +0200 Message-Id: <7A652946-1400-4FB3-8872-FB2E546BCB7A@ifi.uio.no> From: Michael Welzl To: Murari Sridharan In-Reply-To: <902F4C8483487C40A366621E25F01D960605CBA9@tk5ex14mbxc106.redmond.corp.microsoft.com> Content-Type: text/plain; charset=WINDOWS-1252; format=flowed; delsp=yes Content-Transfer-Encoding: quoted-printable Mime-Version: 1.0 (Apple Message framework v936) Date: Wed, 9 Jun 2010 17:41:48 +0200 References: <902F4C8483487C40A366621E25F01D960605CBA9@tk5ex14mbxc106.redmond.corp.microsoft.com> X-Mailer: Apple Mail (2.936) X-UiO-Ratelimit-Test: rcpts/h 3 msgs/h 1 sum rcpts/h 4 sum msgs/h 2 total rcpts 859 max rcpts/h 24 ratelimit 0 X-UiO-Spam-info: not spam, SpamAssassin (score=-5.0, required=5.0, autolearn=disabled, T_RP_MATCHES_RCVD=-0.01, UIO_MAIL_IS_INTERNAL=-5, uiobl=NO, uiouri=NO) X-UiO-Scanned: 82ED18453D832DA9C6825E97FB8374B5E710668B X-UiO-SPAM-Test: remote_host: 193.157.176.225 spam_score: -49 maxlevel 80 minaction 2 bait 0 mail/h: 1 total 461 max/h 11 blacklist 0 greylist 0 ratelimit 0 Cc: "ledbat@ietf.org" , "ledbat-chairs@tools.ietf.org" Subject: Re: [ledbat] LEDBAT Status and plan moving forward X-BeenThere: ledbat@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Mailing list of the LEDBAT WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 09 Jun 2010 15:41:50 -0000 Hi, We're currently working on an update of the survey, which I would =20 present at the next meeting if there is one. I don't think it's necessary to meet =20 just for this draft. Cheers, Michael On Jun 9, 2010, at 5:26 PM, Murari Sridharan wrote: > All: > > We set out with three goals for this WG with the most important one =20= > to put out an experimental congestion algorithm for less-than-best-=20 > effort traffic. > > Oct 2009 - Submit 'Multiple Transport Connections in Applications =20 > Design' to the IESG for consideration as an Informational RFC > Oct 2009 - Submit 'Low Extra Delay Background Transport (LEDBAT)' to =20= > the IESG for consideration as an Experimental RFC > Feb 2010 - Submit 'A Survey of Lower-than-Best Effort Transport =20 > Protocols' to the IESG for consideration as an Informational RFC > > The first draft draft-ietf-ledbat-practices-recommendations isn=92t =20= > converging, Rolf and I are going to have a chat with the authors =20 > regarding this draft. We want to hear from the group if they think =20 > this document is useful in its present form. We started out with all =20= > the right intentions here but this is simply not converging. Unless =20= > there is strong interest in keeping draft-ietf-ledbat-practices-=20 > recommendations alive we should drop it as a WG document. > > draft draft-ietf-ledbat-congestion is in great shape and once a few =20= > remaining issues are addressed I think we are ready to recommend =20 > this to IESG consideration as an Experimental RFC. Either I or Jana =20= > will be working with Stas to make the remaining changes to the draft =20= > and address the open issues. > > The survey is in a good shape but as Lars pointed out isn=92t the most = =20 > important document to work on. > > This brings us to the plan for IETF78. Rolf and I had a chat this =20 > morning about whether this WG should meet. We want the list to speak =20= > up. Our recommendation is to make changes to the ledbat draft and =20 > complete the discussion over email, forward the document to IESG and =20= > close the WG. > > Please speak up, as of now we do not plan to schedule a meeting at =20 > the next IETF. > > Thanks > Murari & Rolf. > > _______________________________________________ > ledbat mailing list > ledbat@ietf.org > https://www.ietf.org/mailman/listinfo/ledbat From muraris@microsoft.com Wed Jun 9 08:54:05 2010 Return-Path: X-Original-To: ledbat@core3.amsl.com Delivered-To: ledbat@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 0F6D43A6971 for ; Wed, 9 Jun 2010 08:54:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -8.091 X-Spam-Level: X-Spam-Status: No, score=-8.091 tagged_above=-999 required=5 tests=[AWL=0.094, BAYES_40=-0.185, 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 2Yw5q5j2MgWj for ; Wed, 9 Jun 2010 08:54:04 -0700 (PDT) Received: from smtp.microsoft.com (mailb.microsoft.com [131.107.115.215]) by core3.amsl.com (Postfix) with ESMTP id DE19C3A6858 for ; Wed, 9 Jun 2010 08:54:03 -0700 (PDT) Received: from TK5EX14HUBC102.redmond.corp.microsoft.com (157.54.7.154) by TK5-EXGWY-E802.partners.extranet.microsoft.com (10.251.56.168) with Microsoft SMTP Server (TLS) id 8.2.176.0; Wed, 9 Jun 2010 08:54:05 -0700 Received: from tk5ex14mbxc106.redmond.corp.microsoft.com ([169.254.3.138]) by TK5EX14HUBC102.redmond.corp.microsoft.com ([157.54.7.154]) with mapi id 14.01.0160.007; Wed, 9 Jun 2010 08:54:05 -0700 From: Murari Sridharan To: Michael Welzl Thread-Topic: [ledbat] LEDBAT Status and plan moving forward Thread-Index: AcsH6AOcGRfe5LK9Saun62y28KOcIgAPO5AAAA5AkVA= Date: Wed, 9 Jun 2010 15:54:03 +0000 Message-ID: <902F4C8483487C40A366621E25F01D960605CEBA@tk5ex14mbxc106.redmond.corp.microsoft.com> References: <902F4C8483487C40A366621E25F01D960605CBA9@tk5ex14mbxc106.redmond.corp.microsoft.com> <7A652946-1400-4FB3-8872-FB2E546BCB7A@ifi.uio.no> In-Reply-To: <7A652946-1400-4FB3-8872-FB2E546BCB7A@ifi.uio.no> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "ledbat@ietf.org" , "ledbat-chairs@tools.ietf.org" Subject: Re: [ledbat] LEDBAT Status and plan moving forward X-BeenThere: ledbat@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Mailing list of the LEDBAT WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 09 Jun 2010 15:54:05 -0000 Great, thanks.=20 -----Original Message----- From: Michael Welzl [mailto:michawe@ifi.uio.no]=20 Sent: Wednesday, June 09, 2010 8:42 AM To: Murari Sridharan Cc: ledbat@ietf.org; ledbat-chairs@tools.ietf.org Subject: Re: [ledbat] LEDBAT Status and plan moving forward Hi, We're currently working on an update of the survey, which I would =20 present at the next meeting if there is one. I don't think it's necessary to meet =20 just for this draft. Cheers, Michael On Jun 9, 2010, at 5:26 PM, Murari Sridharan wrote: > All: > > We set out with three goals for this WG with the most important one =20 > to put out an experimental congestion algorithm for less-than-best-=20 > effort traffic. > > Oct 2009 - Submit 'Multiple Transport Connections in Applications =20 > Design' to the IESG for consideration as an Informational RFC > Oct 2009 - Submit 'Low Extra Delay Background Transport (LEDBAT)' to =20 > the IESG for consideration as an Experimental RFC > Feb 2010 - Submit 'A Survey of Lower-than-Best Effort Transport =20 > Protocols' to the IESG for consideration as an Informational RFC > > The first draft draft-ietf-ledbat-practices-recommendations isn't =20 > converging, Rolf and I are going to have a chat with the authors =20 > regarding this draft. We want to hear from the group if they think =20 > this document is useful in its present form. We started out with all =20 > the right intentions here but this is simply not converging. Unless =20 > there is strong interest in keeping draft-ietf-ledbat-practices-=20 > recommendations alive we should drop it as a WG document. > > draft draft-ietf-ledbat-congestion is in great shape and once a few =20 > remaining issues are addressed I think we are ready to recommend =20 > this to IESG consideration as an Experimental RFC. Either I or Jana =20 > will be working with Stas to make the remaining changes to the draft =20 > and address the open issues. > > The survey is in a good shape but as Lars pointed out isn't the most =20 > important document to work on. > > This brings us to the plan for IETF78. Rolf and I had a chat this =20 > morning about whether this WG should meet. We want the list to speak =20 > up. Our recommendation is to make changes to the ledbat draft and =20 > complete the discussion over email, forward the document to IESG and =20 > close the WG. > > Please speak up, as of now we do not plan to schedule a meeting at =20 > the next IETF. > > Thanks > Murari & Rolf. > > _______________________________________________ > ledbat mailing list > ledbat@ietf.org > https://www.ietf.org/mailman/listinfo/ledbat From touch@isi.edu Wed Jun 9 09:10:13 2010 Return-Path: X-Original-To: ledbat@core3.amsl.com Delivered-To: ledbat@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 5CA9128C112 for ; Wed, 9 Jun 2010 09:10:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.001 X-Spam-Level: X-Spam-Status: No, score=0.001 tagged_above=-999 required=5 tests=[BAYES_50=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id GoRoSGsEz4al for ; Wed, 9 Jun 2010 09:10:12 -0700 (PDT) Received: from nitro.isi.edu (nitro.isi.edu [128.9.208.207]) by core3.amsl.com (Postfix) with ESMTP id 21DA228C0F1 for ; Wed, 9 Jun 2010 09:10:12 -0700 (PDT) Received: from [75.214.16.128] (128.sub-75-214-16.myvzw.com [75.214.16.128]) (authenticated bits=0) by nitro.isi.edu (8.13.8/8.13.8) with ESMTP id o59G9Xvk028756 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Wed, 9 Jun 2010 09:09:44 -0700 (PDT) Message-ID: <4C0FBCBB.5040907@isi.edu> Date: Wed, 09 Jun 2010 09:09:31 -0700 From: Joe Touch User-Agent: Thunderbird 2.0.0.24 (Windows/20100228) MIME-Version: 1.0 To: Murari Sridharan References: <902F4C8483487C40A366621E25F01D960605CBA9@tk5ex14mbxc106.redmond.corp.microsoft.com> In-Reply-To: <902F4C8483487C40A366621E25F01D960605CBA9@tk5ex14mbxc106.redmond.corp.microsoft.com> X-Enigmail-Version: 0.96.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="------------enig563DA7FC70267EF92F0EA146" X-MailScanner-ID: o59G9Xvk028756 X-ISI-4-69-MailScanner: Found to be clean X-MailScanner-From: touch@isi.edu Cc: "ledbat@ietf.org" , "ledbat-chairs@tools.ietf.org" Subject: Re: [ledbat] LEDBAT Status and plan moving forward X-BeenThere: ledbat@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Mailing list of the LEDBAT WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 09 Jun 2010 16:10:13 -0000 This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --------------enig563DA7FC70267EF92F0EA146 Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable Hi, all, Murari Sridharan wrote: > All: >=20 > =20 >=20 > We set out with three goals for this WG with the most important one to > put out an experimental congestion algorithm for less-than-best-effort > traffic. >=20 =2E.. > The first draft draft-ietf-ledbat-practices-recommendations isn=92t > converging, Rolf and I are going to have a chat with the authors > regarding this draft. We want to hear from the group if they think this= > document is useful in its present form. We started out with all the > right intentions here but this is simply not converging. Unless there i= s > strong interest in keeping draft-ietf-ledbat-practices-recommendations > alive we should drop it as a WG document. I see this as one of the most important documents, since it helps those o= utside this community determine the bounds and utility of our solutions. As one of the co-authors of this doc, I'd be more than glad to contribute= further cycles on this. The past scheduling has been unfortunate (overlap= ping with MIF and BEHAVE, among others). > This brings us to the plan for IETF78. Rolf and I had a chat this > morning about whether this WG should meet. We want the list to speak up= =2E > Our recommendation is to make changes to the ledbat draft and complete > the discussion over email, forward the document to IESG and close the W= G. This might be an opportunity to discuss the potential impact and interact= ions between MIF, BEHAVE, MPTCP, and LEDBAT, IMO, as well as to address the co= ncerns with the practices/recommendations doc. Provided we can avoid overlaps ;-) Joe --------------enig563DA7FC70267EF92F0EA146 Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.9 (MingW32) iEYEARECAAYFAkwPvLwACgkQE5f5cImnZrtVTgCeOYBmADWEaUmhwldb8N2NRvN9 /mIAn0a55w78DyU9g8lfsOf65MelpyAN =CsA7 -----END PGP SIGNATURE----- --------------enig563DA7FC70267EF92F0EA146-- From muraris@microsoft.com Wed Jun 9 10:16:25 2010 Return-Path: X-Original-To: ledbat@core3.amsl.com Delivered-To: ledbat@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 193793A6999 for ; Wed, 9 Jun 2010 10:16:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -8.045 X-Spam-Level: X-Spam-Status: No, score=-8.045 tagged_above=-999 required=5 tests=[AWL=-0.046, BAYES_50=0.001, 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 JeWo0ANpLmTs for ; Wed, 9 Jun 2010 10:16:24 -0700 (PDT) Received: from smtp.microsoft.com (mail2.microsoft.com [131.107.115.215]) by core3.amsl.com (Postfix) with ESMTP id 37B5B3A6994 for ; Wed, 9 Jun 2010 10:16:24 -0700 (PDT) Received: from TK5EX14MLTC101.redmond.corp.microsoft.com (157.54.79.178) by TK5-EXGWY-E802.partners.extranet.microsoft.com (10.251.56.168) with Microsoft SMTP Server (TLS) id 8.2.176.0; Wed, 9 Jun 2010 10:16:25 -0700 Received: from tk5ex14mbxc106.redmond.corp.microsoft.com ([169.254.3.138]) by TK5EX14MLTC101.redmond.corp.microsoft.com ([157.54.79.178]) with mapi id 14.01.0160.007; Wed, 9 Jun 2010 10:16:24 -0700 From: Murari Sridharan To: Joe Touch Thread-Topic: [ledbat] LEDBAT Status and plan moving forward Thread-Index: AcsH6AOcGRfe5LK9Saun62y28KOcIgAQM1+AAAxwn/A= Date: Wed, 9 Jun 2010 17:16:25 +0000 Message-ID: <902F4C8483487C40A366621E25F01D960605D14C@tk5ex14mbxc106.redmond.corp.microsoft.com> References: <902F4C8483487C40A366621E25F01D960605CBA9@tk5ex14mbxc106.redmond.corp.microsoft.com> <4C0FBCBB.5040907@isi.edu> In-Reply-To: <4C0FBCBB.5040907@isi.edu> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "ledbat@ietf.org" , "ledbat-chairs@tools.ietf.org" Subject: Re: [ledbat] LEDBAT Status and plan moving forward X-BeenThere: ledbat@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Mailing list of the LEDBAT WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 09 Jun 2010 17:16:25 -0000 Joe if you can take the lead and spend cycles on that draft that would be g= reat and it gives me confidence that we may be able to salvage the document= . =20 Regarding scheduling the actual meeting I am going to wait to see how many = people express interest in meeting as a WG. I will include BEHAVE in the co= nflict list if we do schedule it. If there is not much interest a few of us= could still meet and get the documents in shape and send the updates to th= e list.=20 Thanks Murari=20 -----Original Message----- From: Joe Touch [mailto:touch@isi.edu]=20 Sent: Wednesday, June 09, 2010 9:10 AM To: Murari Sridharan Cc: ledbat@ietf.org; ledbat-chairs@tools.ietf.org Subject: Re: [ledbat] LEDBAT Status and plan moving forward Hi, all, Murari Sridharan wrote: > All: >=20 > =20 >=20 > We set out with three goals for this WG with the most important one to=20 > put out an experimental congestion algorithm for less-than-best-effort=20 > traffic. >=20 ... > The first draft draft-ietf-ledbat-practices-recommendations isn't=20 > converging, Rolf and I are going to have a chat with the authors=20 > regarding this draft. We want to hear from the group if they think=20 > this document is useful in its present form. We started out with all=20 > the right intentions here but this is simply not converging. Unless=20 > there is strong interest in keeping=20 > draft-ietf-ledbat-practices-recommendations > alive we should drop it as a WG document. I see this as one of the most important documents, since it helps those out= side this community determine the bounds and utility of our solutions. As one of the co-authors of this doc, I'd be more than glad to contribute f= urther cycles on this. The past scheduling has been unfortunate (overlappin= g with MIF and BEHAVE, among others). > This brings us to the plan for IETF78. Rolf and I had a chat this=20 > morning about whether this WG should meet. We want the list to speak up. > Our recommendation is to make changes to the ledbat draft and complete=20 > the discussion over email, forward the document to IESG and close the WG. This might be an opportunity to discuss the potential impact and interactio= ns between MIF, BEHAVE, MPTCP, and LEDBAT, IMO, as well as to address the c= oncerns with the practices/recommendations doc. Provided we can avoid overlaps ;-) Joe From touch@isi.edu Wed Jun 9 11:30:30 2010 Return-Path: X-Original-To: ledbat@core3.amsl.com Delivered-To: ledbat@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 7CA833A680D for ; Wed, 9 Jun 2010 11:30:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.949 X-Spam-Level: X-Spam-Status: No, score=-1.949 tagged_above=-999 required=5 tests=[AWL=0.650, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id S2jrE9SfKg0H for ; Wed, 9 Jun 2010 11:30:29 -0700 (PDT) Received: from nitro.isi.edu (nitro.isi.edu [128.9.208.207]) by core3.amsl.com (Postfix) with ESMTP id EB50C3A676A for ; Wed, 9 Jun 2010 11:30:28 -0700 (PDT) Received: from [75.214.122.201] (201.sub-75-214-122.myvzw.com [75.214.122.201]) (authenticated bits=0) by nitro.isi.edu (8.13.8/8.13.8) with ESMTP id o59ITjg3028065 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Wed, 9 Jun 2010 11:29:56 -0700 (PDT) Message-ID: <4C0FDD98.5030605@isi.edu> Date: Wed, 09 Jun 2010 11:29:44 -0700 From: Joe Touch User-Agent: Thunderbird 2.0.0.24 (Windows/20100228) MIME-Version: 1.0 To: Murari Sridharan References: <902F4C8483487C40A366621E25F01D960605CBA9@tk5ex14mbxc106.redmond.corp.microsoft.com> <4C0FBCBB.5040907@isi.edu> <902F4C8483487C40A366621E25F01D960605D14C@tk5ex14mbxc106.redmond.corp.microsoft.com> In-Reply-To: <902F4C8483487C40A366621E25F01D960605D14C@tk5ex14mbxc106.redmond.corp.microsoft.com> X-Enigmail-Version: 0.96.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="------------enigDE6A5E6B76F40EB0E71E57C0" X-MailScanner-ID: o59ITjg3028065 X-ISI-4-69-MailScanner: Found to be clean X-MailScanner-From: touch@isi.edu Cc: "ledbat@ietf.org" , "ledbat-chairs@tools.ietf.org" Subject: Re: [ledbat] LEDBAT Status and plan moving forward X-BeenThere: ledbat@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Mailing list of the LEDBAT WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 09 Jun 2010 18:30:30 -0000 This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --------------enigDE6A5E6B76F40EB0E71E57C0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Hi, Murari, Murari Sridharan wrote: > Joe if you can take the lead and spend cycles on that draft that would = be > great and it gives me confidence that we may be able to salvage the doc= ument. Will do. > Regarding scheduling the actual meeting I am going to wait to see how m= any > people express interest in meeting as a WG. I will include BEHAVE in th= e > conflict list if we do schedule it. If there is not much interest a few= of us > could still meet and get the documents in shape and send the updates to= the list. AOK - FWIW, my hard conflicts include: TCPM SOFTWIRE TSVWG INTAREA Others which we should also avoid overlap, IMO: BEHAVE MIF MPTCP TSVAREA Joe --------------enigDE6A5E6B76F40EB0E71E57C0 Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.9 (MingW32) iEYEARECAAYFAkwP3ZgACgkQE5f5cImnZruOUQCg7wra0btP5e1uY6rj+o0o0uMc ywgAoNV6Hl6mt6FydW8g8PTaUk1CJxIH =ym5t -----END PGP SIGNATURE----- --------------enigDE6A5E6B76F40EB0E71E57C0-- From jason_livingood@cable.comcast.com Thu Jun 10 05:49:17 2010 Return-Path: X-Original-To: ledbat@core3.amsl.com Delivered-To: ledbat@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 953213A6999 for ; Thu, 10 Jun 2010 05:49:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.865 X-Spam-Level: X-Spam-Status: No, score=0.865 tagged_above=-999 required=5 tests=[BAYES_50=0.001, HELO_MISMATCH_COM=0.553, HOST_MISMATCH_NET=0.311] 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 kXRFa7QR5UhL for ; Thu, 10 Jun 2010 05:49:16 -0700 (PDT) Received: from cable.comcast.com (copdcimo01.potomac.co.ndcwest.comcast.net [76.96.32.251]) by core3.amsl.com (Postfix) with ESMTP id B1C793A6811 for ; Thu, 10 Jun 2010 05:49:16 -0700 (PDT) Received: from ([147.191.124.12]) by copdcimo01.cable.comcast.com with ESMTP with TLS id 5503630.1291251; Thu, 10 Jun 2010 06:52:16 -0600 Received: from PAOAKEXCSMTP01.cable.comcast.com (10.52.116.30) by copdcexhub01.cable.comcast.com (147.191.124.12) with Microsoft SMTP Server id 14.0.694.0; Thu, 10 Jun 2010 06:49:16 -0600 Received: from PACDCEXCMB04.cable.comcast.com ([24.40.15.86]) by PAOAKEXCSMTP01.cable.comcast.com with Microsoft SMTPSVC(6.0.3790.4675); Thu, 10 Jun 2010 08:49:07 -0400 Received: from 10.21.150.109 ([10.21.150.109]) 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 ; Thu, 10 Jun 2010 12:49:06 +0000 User-Agent: Microsoft-Entourage/12.24.0.100205 Date: Thu, 10 Jun 2010 08:49:06 -0400 From: Jason Livingood To: Joe Touch , Murari Sridharan Message-ID: Thread-Topic: [ledbat] LEDBAT Status and plan moving forward Thread-Index: AcsIm0+uroCZwRq/y0ew6WFjslARyg== In-Reply-To: <4C0FBCBB.5040907@isi.edu> MIME-Version: 1.0 Content-Type: text/plain; charset="ISO-8859-1" Content-Transfer-Encoding: quoted-printable X-OriginalArrivalTime: 10 Jun 2010 12:49:07.0058 (UTC) FILETIME=[50503D20:01CB089B] Cc: "ledbat@ietf.org" , "ledbat-chairs@tools.ietf.org" Subject: Re: [ledbat] LEDBAT Status and plan moving forward X-BeenThere: ledbat@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Mailing list of the LEDBAT WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 10 Jun 2010 12:49:17 -0000 >> The first draft draft-ietf-ledbat-practices-recommendations isn=B9t >> converging, Rolf and I are going to have a chat with the authors >> regarding this draft. We want to hear from the group if they think this >> document is useful in its present form. We started out with all the >> right intentions here but this is simply not converging. Unless there is >> strong interest in keeping draft-ietf-ledbat-practices-recommendations >> alive we should drop it as a WG document. >=20 > I see this as one of the most important documents, since it helps those > outside > this community determine the bounds and utility of our solutions. >=20 > As one of the co-authors of this doc, I'd be more than glad to contribute > further cycles on this. The past scheduling has been unfortunate (overlap= ping > with MIF and BEHAVE, among others). I also think the document provides useful information. If the authors can keep working on it, that'd be great. Jason From jason_livingood@cable.comcast.com Thu Jun 10 05:52:26 2010 Return-Path: X-Original-To: ledbat@core3.amsl.com Delivered-To: ledbat@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 8D4A83A6830 for ; Thu, 10 Jun 2010 05:52:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.865 X-Spam-Level: X-Spam-Status: No, score=0.865 tagged_above=-999 required=5 tests=[BAYES_50=0.001, HELO_MISMATCH_COM=0.553, HOST_MISMATCH_NET=0.311] 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 Zicf6enD6as3 for ; Thu, 10 Jun 2010 05:52:20 -0700 (PDT) Received: from cable.comcast.com (copdcimo01.potomac.co.ndcwest.comcast.net [76.96.32.251]) by core3.amsl.com (Postfix) with ESMTP id 806243A6999 for ; Thu, 10 Jun 2010 05:52:20 -0700 (PDT) Received: from ([147.191.124.14]) by copdcimo01.cable.comcast.com with ESMTP with TLS id 5503630.1291549; Thu, 10 Jun 2010 06:55:18 -0600 Received: from PAOAKEXCSMTP02.cable.comcast.com (10.52.116.31) by COPDCEXHUB03.cable.comcast.com (147.191.124.14) with Microsoft SMTP Server id 14.0.694.0; Thu, 10 Jun 2010 06:52:19 -0600 Received: from PACDCEXCMB04.cable.comcast.com ([24.40.15.86]) by PAOAKEXCSMTP02.cable.comcast.com with Microsoft SMTPSVC(6.0.3790.4675); Thu, 10 Jun 2010 08:52:11 -0400 Received: from 10.21.150.109 ([10.21.150.109]) 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 ; Thu, 10 Jun 2010 12:52:10 +0000 User-Agent: Microsoft-Entourage/12.24.0.100205 Date: Thu, 10 Jun 2010 08:52:10 -0400 From: Jason Livingood To: Murari Sridharan , Joe Touch Message-ID: Thread-Topic: [ledbat] LEDBAT Status and plan moving forward Thread-Index: AcsH6AOcGRfe5LK9Saun62y28KOcIgAQM1+AAAxwn/AAEEpxXA== In-Reply-To: <902F4C8483487C40A366621E25F01D960605D14C@tk5ex14mbxc106.redmond.corp.microsoft.com> MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 10 Jun 2010 12:52:11.0472 (UTC) FILETIME=[BE3B9500:01CB089B] Cc: "ledbat@ietf.org" , "ledbat-chairs@tools.ietf.org" Subject: Re: [ledbat] LEDBAT Status and plan moving forward X-BeenThere: ledbat@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Mailing list of the LEDBAT WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 10 Jun 2010 12:52:26 -0000 > Regarding scheduling the actual meeting I am going to wait to see how many > people express interest in meeting as a WG. I will include BEHAVE in the > conflict list if we do schedule it. If there is not much interest a few of us > could still meet and get the documents in shape and send the updates to the > list. The first question you should ask is what you want to do with the time. If it is to ask for feedback on some open issues for which an author is unsure how to proceed, or we have a lot of new documents/content, then surely it is useful. But, on the other hand, if you mainly need to iterate documents and make real progress on drafts, then your time may be better served focusing on writing / editing (which may not be interesting to a room full of people). Jason From arvid@cs.umu.se Thu Jun 10 10:10:58 2010 Return-Path: X-Original-To: ledbat@core3.amsl.com Delivered-To: ledbat@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id D501D3A6A1D for ; Thu, 10 Jun 2010 10:10:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.351 X-Spam-Level: X-Spam-Status: No, score=0.351 tagged_above=-999 required=5 tests=[BAYES_50=0.001, HELO_EQ_SE=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 WDEgWyfhYfvj for ; Thu, 10 Jun 2010 10:10:57 -0700 (PDT) Received: from mail.acc.umu.se (mail.acc.umu.se [IPv6:2001:6b0:e:2018::156]) by core3.amsl.com (Postfix) with ESMTP id A8A843A6A2E for ; Thu, 10 Jun 2010 10:10:51 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by amavisd-new (Postfix) with ESMTP id 4ECF8819 for ; Thu, 10 Jun 2010 19:10:49 +0200 (MEST) X-Virus-Scanned: amavisd-new at acc.umu.se Received: from mao.acc.umu.se (mao.acc.umu.se [130.239.18.154]) by mail.acc.umu.se (Postfix) with ESMTP id E7DF4818 for ; Thu, 10 Jun 2010 19:10:47 +0200 (MEST) Received: by mao.acc.umu.se (Postfix, from userid 3027) id D5E2C1008C; Thu, 10 Jun 2010 19:10:47 +0200 (CEST) Received: from rtr-02.sfo.bittorrent.com (rtr-02.sfo.bittorrent.com [208.72.192.2]) by puss.acc.umu.se (IMP) with HTTP for ; Thu, 10 Jun 2010 19:10:47 +0200 Message-ID: <1276189847.4c111c97cb6bb@puss.acc.umu.se> Date: Thu, 10 Jun 2010 19:10:47 +0200 From: arvid@cs.umu.se To: ledbat@ietf.org MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit User-Agent: Internet Messaging Program (IMP) 3.2.2 Subject: [ledbat] clock drift compensation X-BeenThere: ledbat@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Mailing list of the LEDBAT WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 10 Jun 2010 17:10:59 -0000 At BitTorrent we have come up with a way to compensate for drift between the clocks of the endpoints in a uTP connection. The conflicting findings we made was that: 1. On some DSL connections, it may take up to 10 minutes for a single packet to get through without any queuing delay, when the connection is saturated. 2. Some computers have a clock drift of up to 15 ms per 10 minutes. This poses the problem of how frequent the base delay should be updated. If it is updated every 10 minutes, the clock drift will have a significant impact on the delay measurements. If it is updated more frequent than every 10 minutes, some connections may have it set artificially high, becuase no delay-free packet has gotten through. One important observation regarding clock drift is that it is only ever a problem for one of the endpoints. Whichever endpoint sees lower and lower delay measurements is not really affected negatively by the clock drift, since the base delay will be updated continuously by the lower delays. However, for the other end, which sees bigger and bigger delay measurements, it will be a real problem. For that endpoint, the percieved delay will grow and not be reset for at least 10 minutes (or whatever base delay update frequency is chosen). We compensate for the drift by taking advantage of the fact that each endpoint has all the same time measurement information as the other endpoint. Since the suggested protocol header (and the actual header in BitTorrent's uTP) includes both a timestamp and the time stamp difference from last received packet, we can keep track of the other end's base delay as well as our own. We essentially factored out the logic to compare each received delay sample with the base delay, and to progress a counter in the circular buffer which keeps the history of our lowest seen samples. We then apply the same logic to the other end's measurements. The assumption is that every packet we send with a delay measurement in it, will actually be received. This assumption seems fairly safe given that packet loss is not part of the steady state of LEDBAT connections. Now that both endpoints know the other's base delay, it can detect all instances of the other ends base delay decreasing. The other end's base delay decreasing indicates that there is a clock drift "in their favor", i.e. we'll see artificially high delays. We compensate for this by increasing our own base delay by the same amount as the other end's base delay is decreasing. From our experiments, this improved the quality of our delay measurements significantly. We think that this is a strong argument in favor of keeping both the timestamp and the time difference in the suggested header. The slides from our presentation at IPTPS 2010 are available here: http://www.usenix.org/event/iptps10/tech/slides/cohen.pdf The effect of this is especially favorable in our tests since it was a one-way data transfer, so the return path was delay-free, which meant that the clock drift was detected essentially continuously. -- Arvid Norberg From muraris@microsoft.com Fri Jun 11 07:40:03 2010 Return-Path: X-Original-To: ledbat@core3.amsl.com Delivered-To: ledbat@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id AAC313A6824 for ; Fri, 11 Jun 2010 07:40:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -8.03 X-Spam-Level: X-Spam-Status: No, score=-8.03 tagged_above=-999 required=5 tests=[AWL=-0.031, BAYES_50=0.001, 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 Sj4vF+ilb2Ev for ; Fri, 11 Jun 2010 07:40:02 -0700 (PDT) Received: from smtp.microsoft.com (mailc.microsoft.com [131.107.115.214]) by core3.amsl.com (Postfix) with ESMTP id B3FFE3A687C for ; Fri, 11 Jun 2010 07:40:01 -0700 (PDT) Received: from TK5EX14HUBC101.redmond.corp.microsoft.com (157.54.7.153) by TK5-EXGWY-E803.partners.extranet.microsoft.com (10.251.56.169) with Microsoft SMTP Server (TLS) id 8.2.176.0; Fri, 11 Jun 2010 07:40:04 -0700 Received: from tk5ex14mbxc106.redmond.corp.microsoft.com ([169.254.3.138]) by TK5EX14HUBC101.redmond.corp.microsoft.com ([157.54.7.153]) with mapi id 14.01.0160.007; Fri, 11 Jun 2010 07:40:03 -0700 From: Murari Sridharan To: "arvid@cs.umu.se" , "ledbat@ietf.org" Thread-Topic: [ledbat] clock drift compensation Thread-Index: AQHLCMAFZz2JG5JImkiKoqyDMDGFY5J81Q8g Date: Fri, 11 Jun 2010 14:40:02 +0000 Message-ID: <902F4C8483487C40A366621E25F01D960605FD5A@tk5ex14mbxc106.redmond.corp.microsoft.com> References: <1276189847.4c111c97cb6bb@puss.acc.umu.se> In-Reply-To: <1276189847.4c111c97cb6bb@puss.acc.umu.se> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: Re: [ledbat] clock drift compensation X-BeenThere: ledbat@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Mailing list of the LEDBAT WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 11 Jun 2010 14:40:03 -0000 I haven't read your paper and the framing itself is out of scope for the co= ngestion control document. However one thing that concerns me in your findi= ngs is that it may take up to 10 minutes to measure base delay. Can you exp= lain this better why is there such a bias? If this were true then the probl= em of intra-protocol fairness may be significant. So unless it's a fairly l= ong lived flow this bias will be significant and throughput for different f= lows may not converge. Right? Thanks Murari=20 -----Original Message----- From: ledbat-bounces@ietf.org [mailto:ledbat-bounces@ietf.org] On Behalf Of= arvid@cs.umu.se Sent: Thursday, June 10, 2010 10:11 AM To: ledbat@ietf.org Subject: [ledbat] clock drift compensation At BitTorrent we have come up with a way to compensate for drift between th= e clocks of the endpoints in a uTP connection. The conflicting findings we made was that: 1. On some DSL connections, it may take up to 10 minutes for a single packe= t to get through without any queuing delay, when the connection is saturated. 2. Some computers have a clock drift of up to 15 ms per 10 minutes. This poses the problem of how frequent the base delay should be updated. If= it is updated every 10 minutes, the clock drift will have a significant im= pact on the delay measurements. If it is updated more frequent than every 10 minutes, some connections may = have it set artificially high, becuase no delay-free packet has gotten thro= ugh. One important observation regarding clock drift is that it is only ever a p= roblem for one of the endpoints. Whichever endpoint sees lower and lower de= lay measurements is not really affected negatively by the clock drift, sinc= e the base delay will be updated continuously by the lower delays. However,= for the other end, which sees bigger and bigger delay measurements, it wil= l be a real problem. For that endpoint, the percieved delay will grow and n= ot be reset for at least 10 minutes (or whatever base delay update frequenc= y is chosen). We compensate for the drift by taking advantage of the fact that each endpo= int has all the same time measurement information as the other endpoint. Si= nce the suggested protocol header (and the actual header in BitTorrent's uT= P) includes both a timestamp and the time stamp difference from last receiv= ed packet, we can keep track of the other end's base delay as well as our o= wn. We essentially factored out the logic to compare each received delay sample= with the base delay, and to progress a counter in the circular buffer whic= h keeps the history of our lowest seen samples. We then apply the same logi= c to the other end's measurements. The assumption is that every packet we s= end with a delay measurement in it, will actually be received. This assumption seems fairly safe given that packet loss is not part of the= steady state of LEDBAT connections. Now that both endpoints know the other's base delay, it can detect all inst= ances of the other ends base delay decreasing. The other end's base delay d= ecreasing indicates that there is a clock drift "in their favor", i.e. we'l= l see artificially high delays. We compensate for this by increasing our ow= n base delay by the same amount as the other end's base delay is decreasing= . From our experiments, this improved the quality of our delay measurements= significantly. We think that this is a strong argument in favor of keeping both the timest= amp and the time difference in the suggested header. The slides from our presentation at IPTPS 2010 are available here: http://www.usenix.org/event/iptps10/tech/slides/cohen.pdf The effect of this is especially favorable in our tests since it was a one-= way data transfer, so the return path was delay-free, which meant that the = clock drift was detected essentially continuously. -- Arvid Norberg _______________________________________________ ledbat mailing list ledbat@ietf.org https://www.ietf.org/mailman/listinfo/ledbat From bhooma@apple.com Fri Jun 11 11:25:12 2010 Return-Path: X-Original-To: ledbat@core3.amsl.com Delivered-To: ledbat@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id E080F28C121 for ; Fri, 11 Jun 2010 11:25:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.998 X-Spam-Level: X-Spam-Status: No, score=-103.998 tagged_above=-999 required=5 tests=[BAYES_50=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id mlJoDkeHcZYm for ; Fri, 11 Jun 2010 11:25:11 -0700 (PDT) Received: from mail-out3.apple.com (mail-out3.apple.com [17.254.13.22]) by core3.amsl.com (Postfix) with ESMTP id B8C2F28C0FC for ; Fri, 11 Jun 2010 11:25:11 -0700 (PDT) Received: from relay15.apple.com (relay15.apple.com [17.128.113.54]) by mail-out3.apple.com (Postfix) with ESMTP id 75757976F145 for ; Fri, 11 Jun 2010 11:25:14 -0700 (PDT) X-AuditID: 11807136-b7c9dae000000fcd-0c-4c127f8af71f Received: from il0204a-dhcp50.apple.com (il0204a-dhcp50.apple.com [17.202.45.178]) (using TLS with cipher AES128-SHA (AES128-SHA/128 bits)) (Client did not present a certificate) by relay15.apple.com (Apple SCV relay) with SMTP id F9.74.04045.A8F721C4; Fri, 11 Jun 2010 11:25:14 -0700 (PDT) From: Padma Bhooma Mime-Version: 1.0 (Apple Message framework v1150) Content-Type: multipart/alternative; boundary=Apple-Mail-21--526713724 Date: Fri, 11 Jun 2010 11:25:13 -0700 In-Reply-To: To: ledbat@ietf.org References: Message-Id: X-Mailer: Apple Mail (2.1150) X-Brightmail-Tracker: AAAAAQAAAZE= Subject: [ledbat] other open issues X-BeenThere: ledbat@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Mailing list of the LEDBAT WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 11 Jun 2010 18:25:13 -0000 --Apple-Mail-21--526713724 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii Hi WG, We have been looking into LEDBAT as an alternate TCP congestion control = mechanism for background traffic. A couple of things that are not very = clear in the draft draft-ietf-ledbat-congestion are: 1. How will base history expire after some idle time? May there should = be a recommendation to throw away the history and re-learn delay on the = link. 2. The linear controller that LEDBAT uses suggests that the congestion = window should be increased proportional to the change in one-way delay. = This is very good for responding quickly to changes in delay. But this = can cause the window to increase at a faster rate than TCP would do with = its probing mechanism using additive-increase. Although the maximum = increase in window is capped to be less than Best-effort TCP, the rate = of increase can be more. Does this concern anyone?=20 Some of these decisions can be made implementation-specific. I think, it = will be good if there is some discussion about it. Thanks, Padma On Jun 8, 2010, at 12:00 PM, ledbat-request@ietf.org wrote: >=20 > Date: Tue, 8 Jun 2010 16:03:37 +0200 > From: "Rolf Winter" > Subject: [ledbat] Open issues, part 1 > To: > Message-ID: <547F018265F92642B577B986577D671C014B9A15@VENUS.office> > Content-Type: text/plain; charset=3D"us-ascii" >=20 > Hi, >=20 > Here is the first Email in a series of Emails (to keep Email threats = separate) which deal with open points in the congestion control draft. I = pulled those together from various sources such as meeting minutes. I = would like have a documented agreement on them. If there are other open = question please speak up. >=20 > 1. Parameters > There were comments on the parameterization of the congestion control = draft. The main concern was that they seem to come out of thin air. To = close this issue I'd like to ask the group whether they think the = parameters are sensible or not (e.g. 25ms delay target). It would be = good to hear from people such as, say, game developers what they have to = say about this target. A better description of why these were chosen is = surely something that should go into the text. >=20 > Best, >=20 > Rolf >=20 > NEC Europe Limited | Registered Office: NEC House, 1 Victoria Road, = London W3 6BL | Registered in England 2832014=20 --Apple-Mail-21--526713724 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=us-ascii Hi = WG,

We have been looking into LEDBAT as an = alternate TCP congestion control mechanism for background traffic. A = couple of things that are not very clear in the draft = draft-ietf-ledbat-congestion are:

1. = How will base history expire after some idle time? May there should = be a recommendation to throw away the history and re-learn delay on the = link.

2. = The linear controller that LEDBAT uses suggests that the congestion = window should be increased proportional to the change in one-way delay. = This is very good for responding quickly to changes in delay. But this = can cause the window to increase at a faster rate than TCP would do with = its probing mechanism using additive-increase. Although the maximum = increase in window is capped to be less than Best-effort TCP, the rate = of increase can be more. Does this concern anyone? 

Some of these decisions can be = made implementation-specific. I think, it will be good if there is some = discussion about it.

Padma


On Jun 8, 2010, at 12:00 PM, ledbat-request@ietf.org = wrote:

Date: Tue, 8 Jun = 2010 16:03:37 +0200
From: "Rolf Winter" <Rolf.Winter@neclab.eu>
Sub= ject: [ledbat] Open issues, part 1
To: <ledbat@ietf.org>
Message-ID: = <547F= 018265F92642B577B986577D671C014B9A15@VENUS.office>
Content-Type:= text/plain; = charset=3D"us-ascii"

Hi,

Here is the first Email in = a series of Emails (to keep Email threats separate) which deal with open = points in the congestion control draft. I pulled those together from = various sources such as meeting minutes. I would like have a documented = agreement on them. If there are other open question please speak = up.

1. Parameters
There were comments on the parameterization = of the congestion control draft. The main concern was that they seem to = come out of thin air. To close this issue I'd like to ask the group = whether they think the parameters are sensible or not (e.g. 25ms delay = target). It would be good to hear from people such as, say, game = developers what they have to say about this target. A better description = of why these were chosen is surely something that should go into the = text.

Best,

Rolf

NEC Europe Limited | = Registered Office: NEC House, 1 Victoria Road, London W3 6BL | = Registered in England 2832014


=
= --Apple-Mail-21--526713724-- From Rolf.Winter@neclab.eu Sat Jun 12 01:40:31 2010 Return-Path: X-Original-To: ledbat@core3.amsl.com Delivered-To: ledbat@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 0B8DD3A67A7 for ; Sat, 12 Jun 2010 01:40:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.545 X-Spam-Level: X-Spam-Status: No, score=-0.545 tagged_above=-999 required=5 tests=[AWL=-0.546, 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 1BwG08TUadKp for ; Sat, 12 Jun 2010 01:40:22 -0700 (PDT) Received: from smtp0.neclab.eu (smtp0.neclab.eu [195.37.70.41]) by core3.amsl.com (Postfix) with ESMTP id 095353A6847 for ; Sat, 12 Jun 2010 01:40:21 -0700 (PDT) Received: from localhost (localhost.localdomain [127.0.0.1]) by smtp0.neclab.eu (Postfix) with ESMTP id 991C42C000C05; Sat, 12 Jun 2010 10:40:23 +0200 (CEST) X-Virus-Scanned: Amavisd on Debian GNU/Linux (atlas2.office) Received: from smtp0.neclab.eu ([127.0.0.1]) by localhost (atlas2.office [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id zFAJKol8ID4J; Sat, 12 Jun 2010 10:40:23 +0200 (CEST) Received: from VENUS.office (mx1.office [192.168.24.3]) by smtp0.neclab.eu (Postfix) with ESMTP id 77B532C000355; Sat, 12 Jun 2010 10:40:08 +0200 (CEST) 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: Sat, 12 Jun 2010 10:40:07 +0200 Message-ID: <547F018265F92642B577B986577D671C014B9ED3@VENUS.office> In-Reply-To: <902F4C8483487C40A366621E25F01D960605FD5A@tk5ex14mbxc106.redmond.corp.microsoft.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [ledbat] clock drift compensation Thread-Index: AQHLCMAFZz2JG5JImkiKoqyDMDGFY5J81Q8ggAEs8BA= References: <1276189847.4c111c97cb6bb@puss.acc.umu.se> <902F4C8483487C40A366621E25F01D960605FD5A@tk5ex14mbxc106.redmond.corp.microsoft.com> From: "Rolf Winter" To: "Murari Sridharan" , , Subject: Re: [ledbat] clock drift compensation X-BeenThere: ledbat@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Mailing list of the LEDBAT WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 12 Jun 2010 08:40:33 -0000 Hi, Another interesting thing from the slides is that uTP still has 100ms as = a delay target. Are there plans to adjust that? In other words will uTP = be LEDBAT compliant? Best, Rolf NEC Europe Limited | Registered Office: NEC House, 1 Victoria Road, = London W3 6BL | Registered in England 2832014=20 -----Original Message----- From: ledbat-bounces@ietf.org [mailto:ledbat-bounces@ietf.org] On Behalf = Of Murari Sridharan Sent: Freitag, 11. Juni 2010 16:40 To: arvid@cs.umu.se; ledbat@ietf.org Subject: Re: [ledbat] clock drift compensation I haven't read your paper and the framing itself is out of scope for the = congestion control document. However one thing that concerns me in your = findings is that it may take up to 10 minutes to measure base delay. Can = you explain this better why is there such a bias? If this were true then = the problem of intra-protocol fairness may be significant. So unless = it's a fairly long lived flow this bias will be significant and = throughput for different flows may not converge. Right? Thanks Murari=20 -----Original Message----- From: ledbat-bounces@ietf.org [mailto:ledbat-bounces@ietf.org] On Behalf = Of arvid@cs.umu.se Sent: Thursday, June 10, 2010 10:11 AM To: ledbat@ietf.org Subject: [ledbat] clock drift compensation At BitTorrent we have come up with a way to compensate for drift between = the clocks of the endpoints in a uTP connection. The conflicting findings we made was that: 1. On some DSL connections, it may take up to 10 minutes for a single = packet to get through without any queuing delay, when the connection is saturated. 2. Some computers have a clock drift of up to 15 ms per 10 minutes. This poses the problem of how frequent the base delay should be updated. = If it is updated every 10 minutes, the clock drift will have a = significant impact on the delay measurements. If it is updated more frequent than every 10 minutes, some connections = may have it set artificially high, becuase no delay-free packet has = gotten through. One important observation regarding clock drift is that it is only ever = a problem for one of the endpoints. Whichever endpoint sees lower and = lower delay measurements is not really affected negatively by the clock = drift, since the base delay will be updated continuously by the lower = delays. However, for the other end, which sees bigger and bigger delay = measurements, it will be a real problem. For that endpoint, the = percieved delay will grow and not be reset for at least 10 minutes (or = whatever base delay update frequency is chosen). We compensate for the drift by taking advantage of the fact that each = endpoint has all the same time measurement information as the other = endpoint. Since the suggested protocol header (and the actual header in = BitTorrent's uTP) includes both a timestamp and the time stamp = difference from last received packet, we can keep track of the other = end's base delay as well as our own. We essentially factored out the logic to compare each received delay = sample with the base delay, and to progress a counter in the circular = buffer which keeps the history of our lowest seen samples. We then apply = the same logic to the other end's measurements. The assumption is that = every packet we send with a delay measurement in it, will actually be = received. This assumption seems fairly safe given that packet loss is not part of = the steady state of LEDBAT connections. Now that both endpoints know the other's base delay, it can detect all = instances of the other ends base delay decreasing. The other end's base = delay decreasing indicates that there is a clock drift "in their favor", = i.e. we'll see artificially high delays. We compensate for this by = increasing our own base delay by the same amount as the other end's base = delay is decreasing. From our experiments, this improved the quality of = our delay measurements significantly. We think that this is a strong argument in favor of keeping both the = timestamp and the time difference in the suggested header. The slides from our presentation at IPTPS 2010 are available here: http://www.usenix.org/event/iptps10/tech/slides/cohen.pdf The effect of this is especially favorable in our tests since it was a = one-way data transfer, so the return path was delay-free, which meant = that the clock drift was detected essentially continuously. -- Arvid Norberg _______________________________________________ ledbat mailing list ledbat@ietf.org https://www.ietf.org/mailman/listinfo/ledbat _______________________________________________ ledbat mailing list ledbat@ietf.org https://www.ietf.org/mailman/listinfo/ledbat From Rolf.Winter@neclab.eu Sat Jun 12 01:55:22 2010 Return-Path: X-Original-To: ledbat@core3.amsl.com Delivered-To: ledbat@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 26E3E3A6885 for ; Sat, 12 Jun 2010 01:55:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.195 X-Spam-Level: X-Spam-Status: No, score=-0.195 tagged_above=-999 required=5 tests=[AWL=-0.796, BAYES_50=0.001, J_CHICKENPOX_75=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 gAPnhyDWz5oG for ; Sat, 12 Jun 2010 01:55:21 -0700 (PDT) Received: from smtp0.neclab.eu (smtp0.neclab.eu [195.37.70.41]) by core3.amsl.com (Postfix) with ESMTP id E93373A6847 for ; Sat, 12 Jun 2010 01:55:20 -0700 (PDT) Received: from localhost (localhost.localdomain [127.0.0.1]) by smtp0.neclab.eu (Postfix) with ESMTP id 9EBC92C000C05; Sat, 12 Jun 2010 10:55:23 +0200 (CEST) X-Virus-Scanned: Amavisd on Debian GNU/Linux (atlas2.office) Received: from smtp0.neclab.eu ([127.0.0.1]) by localhost (atlas2.office [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id yX1We8OYdfdr; Sat, 12 Jun 2010 10:55:23 +0200 (CEST) Received: from VENUS.office (mx1.office [192.168.24.3]) by smtp0.neclab.eu (Postfix) with ESMTP id 819FE2C000355; Sat, 12 Jun 2010 10:55:13 +0200 (CEST) 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: Sat, 12 Jun 2010 10:55:12 +0200 Message-ID: <547F018265F92642B577B986577D671C014B9ED4@VENUS.office> In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [ledbat] other open issues Thread-Index: AcsJk3pbJCCcvhc8R5CB+4NnOjN9VwAdWeVQ References: From: "Rolf Winter" To: "Padma Bhooma" , Subject: Re: [ledbat] other open issues X-BeenThere: ledbat@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Mailing list of the LEDBAT WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 12 Jun 2010 08:55:22 -0000 Padma, thanks for the feedback. Regarding point 1. I guess changes in the base = delay are expected only when the route changes. As we talk about the = last n minutes of measurement, I assume the "old" measurement will just = disappear over time even in idle periods(after n minutes). What the = draft should describe therefore I think is how periods of idle time are = interpreted. So if the last entry in the base history is still removed = even in periods where no data is sent or received and idle periods are = simply not taken into account when calculating the base delay, we might = be fine. But as you said this should be explicitly stated. Best, Rolf NEC Europe Limited | Registered Office: NEC House, 1 Victoria Road, = London W3 6BL | Registered in England 2832014=20 -----Original Message----- From: ledbat-bounces@ietf.org [mailto:ledbat-bounces@ietf.org] On Behalf = Of Padma Bhooma Sent: Freitag, 11. Juni 2010 20:25 To: ledbat@ietf.org Subject: [ledbat] other open issues Hi WG, We have been looking into LEDBAT as an alternate TCP congestion control = mechanism for background traffic. A couple of things that are not very = clear in the draft draft-ietf-ledbat-congestion are: 1. How will base history expire after some idle time? May there should = be a recommendation to throw away the history and re-learn delay on the = link. 2. The linear controller that LEDBAT uses suggests that the congestion = window should be increased proportional to the change in one-way delay. = This is very good for responding quickly to changes in delay. But this = can cause the window to increase at a faster rate than TCP would do with = its probing mechanism using additive-increase. Although the maximum = increase in window is capped to be less than Best-effort TCP, the rate = of increase can be more. Does this concern anyone?=20 Some of these decisions can be made implementation-specific. I think, it = will be good if there is some discussion about it. Thanks, Padma On Jun 8, 2010, at 12:00 PM, ledbat-request@ietf.org wrote: =09 Date: Tue, 8 Jun 2010 16:03:37 +0200 From: "Rolf Winter" Subject: [ledbat] Open issues, part 1 To: Message-ID: <547F018265F92642B577B986577D671C014B9A15@VENUS.office> Content-Type: text/plain; charset=3D"us-ascii" =09 Hi, =09 Here is the first Email in a series of Emails (to keep Email threats = separate) which deal with open points in the congestion control draft. I = pulled those together from various sources such as meeting minutes. I = would like have a documented agreement on them. If there are other open = question please speak up. =09 1. Parameters There were comments on the parameterization of the congestion control = draft. The main concern was that they seem to come out of thin air. To = close this issue I'd like to ask the group whether they think the = parameters are sensible or not (e.g. 25ms delay target). It would be = good to hear from people such as, say, game developers what they have to = say about this target. A better description of why these were chosen is = surely something that should go into the text. =09 Best, =09 Rolf =09 NEC Europe Limited | Registered Office: NEC House, 1 Victoria Road, = London W3 6BL | Registered in England 2832014=20 =09 From bhooma@apple.com Mon Jun 14 16:40:03 2010 Return-Path: X-Original-To: ledbat@core3.amsl.com Delivered-To: ledbat@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 926BD3A6A05 for ; Mon, 14 Jun 2010 16:40:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.698 X-Spam-Level: X-Spam-Status: No, score=-103.698 tagged_above=-999 required=5 tests=[AWL=-0.300, BAYES_50=0.001, J_CHICKENPOX_75=0.6, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id g6Zyc4zCGS5e for ; Mon, 14 Jun 2010 16:40:02 -0700 (PDT) Received: from mail-out3.apple.com (mail-out3.apple.com [17.254.13.22]) by core3.amsl.com (Postfix) with ESMTP id 614183A6877 for ; Mon, 14 Jun 2010 16:40:02 -0700 (PDT) Received: from relay15.apple.com (relay15.apple.com [17.128.113.54]) by mail-out3.apple.com (Postfix) with ESMTP id 76C4B97E39C3; Mon, 14 Jun 2010 16:40:06 -0700 (PDT) X-AuditID: 11807136-b7c9dae000000fcd-fa-4c16bdd6139c Received: from il0204a-dhcp50.apple.com (il0204a-dhcp50.apple.com [17.202.45.178]) (using TLS with cipher AES128-SHA (AES128-SHA/128 bits)) (Client did not present a certificate) by relay15.apple.com (Apple SCV relay) with SMTP id B8.D1.04045.6DDB61C4; Mon, 14 Jun 2010 16:40:06 -0700 (PDT) Mime-Version: 1.0 (Apple Message framework v1150) Content-Type: text/plain; charset=us-ascii From: Padma Bhooma In-Reply-To: <547F018265F92642B577B986577D671C014B9ED4@VENUS.office> Date: Mon, 14 Jun 2010 16:38:49 -0700 Content-Transfer-Encoding: quoted-printable Message-Id: References: <547F018265F92642B577B986577D671C014B9ED4@VENUS.office> To: Rolf Winter X-Mailer: Apple Mail (2.1150) X-Brightmail-Tracker: AAAAAQAAAZE= Cc: ledbat@ietf.org Subject: Re: [ledbat] other open issues X-BeenThere: ledbat@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Mailing list of the LEDBAT WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 14 Jun 2010 23:40:03 -0000 Thanks Rolf for the reply. Changes in base delay can happen more = frequently in wireless environment. For instance, it can happen when a = host moves from 3G to edge. It can also happen if the host moves away = from its Wifi access point or if the quality of the channel deteriorates = for some reason. I guess, these can also be considered as changes in the = route. Padma On Jun 12, 2010, at 1:55 AM, Rolf Winter wrote: > Padma, >=20 > thanks for the feedback. Regarding point 1. I guess changes in the = base delay are expected only when the route changes. As we talk about = the last n minutes of measurement, I assume the "old" measurement will = just disappear over time even in idle periods(after n minutes). What the = draft should describe therefore I think is how periods of idle time are = interpreted. So if the last entry in the base history is still removed = even in periods where no data is sent or received and idle periods are = simply not taken into account when calculating the base delay, we might = be fine. But as you said this should be explicitly stated. >=20 > Best, >=20 > Rolf >=20 >=20 > NEC Europe Limited | Registered Office: NEC House, 1 Victoria Road, = London W3 6BL | Registered in England 2832014=20 >=20 >=20 > -----Original Message----- > From: ledbat-bounces@ietf.org [mailto:ledbat-bounces@ietf.org] On = Behalf Of Padma Bhooma > Sent: Freitag, 11. Juni 2010 20:25 > To: ledbat@ietf.org > Subject: [ledbat] other open issues >=20 > Hi WG, >=20 > We have been looking into LEDBAT as an alternate TCP congestion = control mechanism for background traffic. A couple of things that are = not very clear in the draft draft-ietf-ledbat-congestion are: >=20 > 1. How will base history expire after some idle time? May there should = be a recommendation to throw away the history and re-learn delay on the = link. >=20 > 2. The linear controller that LEDBAT uses suggests that the congestion = window should be increased proportional to the change in one-way delay. = This is very good for responding quickly to changes in delay. But this = can cause the window to increase at a faster rate than TCP would do with = its probing mechanism using additive-increase. Although the maximum = increase in window is capped to be less than Best-effort TCP, the rate = of increase can be more. Does this concern anyone?=20 >=20 > Some of these decisions can be made implementation-specific. I think, = it will be good if there is some discussion about it. >=20 > Thanks, > Padma >=20 >=20 > On Jun 8, 2010, at 12:00 PM, ledbat-request@ietf.org wrote: >=20 > =09 > Date: Tue, 8 Jun 2010 16:03:37 +0200 > From: "Rolf Winter" > Subject: [ledbat] Open issues, part 1 > To: > Message-ID: = <547F018265F92642B577B986577D671C014B9A15@VENUS.office> > Content-Type: text/plain; charset=3D"us-ascii" > =09 > Hi, > =09 > Here is the first Email in a series of Emails (to keep Email = threats separate) which deal with open points in the congestion control = draft. I pulled those together from various sources such as meeting = minutes. I would like have a documented agreement on them. If there are = other open question please speak up. > =09 > 1. Parameters > There were comments on the parameterization of the congestion = control draft. The main concern was that they seem to come out of thin = air. To close this issue I'd like to ask the group whether they think = the parameters are sensible or not (e.g. 25ms delay target). It would be = good to hear from people such as, say, game developers what they have to = say about this target. A better description of why these were chosen is = surely something that should go into the text. > =09 > Best, > =09 > Rolf > =09 > NEC Europe Limited | Registered Office: NEC House, 1 Victoria = Road, London W3 6BL | Registered in England 2832014=20 > =09 >=20 >=20 >=20 From bhooma@apple.com Mon Jun 14 16:40:12 2010 Return-Path: X-Original-To: ledbat@core3.amsl.com Delivered-To: ledbat@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id D419028C0F3 for ; Mon, 14 Jun 2010 16:40:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.698 X-Spam-Level: X-Spam-Status: No, score=-103.698 tagged_above=-999 required=5 tests=[AWL=-0.300, BAYES_50=0.001, J_CHICKENPOX_75=0.6, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id rZkH4mXhuOWi for ; Mon, 14 Jun 2010 16:40:12 -0700 (PDT) Received: from mail-out3.apple.com (mail-out3.apple.com [17.254.13.22]) by core3.amsl.com (Postfix) with ESMTP id 9F72828C0F2 for ; Mon, 14 Jun 2010 16:40:12 -0700 (PDT) Received: from relay15.apple.com (relay15.apple.com [17.128.113.54]) by mail-out3.apple.com (Postfix) with ESMTP id 0212B97E39E2; Mon, 14 Jun 2010 16:40:17 -0700 (PDT) X-AuditID: 11807136-b7c9dae000000fcd-32-4c16bde0ddf4 Received: from il0204a-dhcp50.apple.com (il0204a-dhcp50.apple.com [17.202.45.178]) (using TLS with cipher AES128-SHA (AES128-SHA/128 bits)) (Client did not present a certificate) by relay15.apple.com (Apple SCV relay) with SMTP id 22.E1.04045.0EDB61C4; Mon, 14 Jun 2010 16:40:16 -0700 (PDT) Mime-Version: 1.0 (Apple Message framework v1150) Content-Type: text/plain; charset=us-ascii From: Padma Bhooma In-Reply-To: <547F018265F92642B577B986577D671C014B9ED4@VENUS.office> Date: Mon, 14 Jun 2010 16:40:16 -0700 Content-Transfer-Encoding: quoted-printable Message-Id: <53715B7F-46FC-4402-8350-CED87E546AA2@apple.com> References: <547F018265F92642B577B986577D671C014B9ED4@VENUS.office> To: Rolf Winter X-Mailer: Apple Mail (2.1150) X-Brightmail-Tracker: AAAAAQAAAZE= Cc: ledbat@ietf.org Subject: Re: [ledbat] other open issues X-BeenThere: ledbat@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Mailing list of the LEDBAT WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 14 Jun 2010 23:40:12 -0000 Thanks Rolf for the reply. Changes in base delay can happen more = frequently in wireless environment. For instance, it can happen when a = host moves from 3G to edge. It can also happen if the host moves away = from its Wifi access point or if the quality of the channel deteriorates = for some reason. I guess, these can also be considered as changes in the = route. Padma On Jun 12, 2010, at 1:55 AM, Rolf Winter wrote: > Padma, >=20 > thanks for the feedback. Regarding point 1. I guess changes in the = base delay are expected only when the route changes. As we talk about = the last n minutes of measurement, I assume the "old" measurement will = just disappear over time even in idle periods(after n minutes). What the = draft should describe therefore I think is how periods of idle time are = interpreted. So if the last entry in the base history is still removed = even in periods where no data is sent or received and idle periods are = simply not taken into account when calculating the base delay, we might = be fine. But as you said this should be explicitly stated. >=20 > Best, >=20 > Rolf >=20 >=20 > NEC Europe Limited | Registered Office: NEC House, 1 Victoria Road, = London W3 6BL | Registered in England 2832014=20 >=20 >=20 > -----Original Message----- > From: ledbat-bounces@ietf.org [mailto:ledbat-bounces@ietf.org] On = Behalf Of Padma Bhooma > Sent: Freitag, 11. Juni 2010 20:25 > To: ledbat@ietf.org > Subject: [ledbat] other open issues >=20 > Hi WG, >=20 > We have been looking into LEDBAT as an alternate TCP congestion = control mechanism for background traffic. A couple of things that are = not very clear in the draft draft-ietf-ledbat-congestion are: >=20 > 1. How will base history expire after some idle time? May there should = be a recommendation to throw away the history and re-learn delay on the = link. >=20 > 2. The linear controller that LEDBAT uses suggests that the congestion = window should be increased proportional to the change in one-way delay. = This is very good for responding quickly to changes in delay. But this = can cause the window to increase at a faster rate than TCP would do with = its probing mechanism using additive-increase. Although the maximum = increase in window is capped to be less than Best-effort TCP, the rate = of increase can be more. Does this concern anyone?=20 >=20 > Some of these decisions can be made implementation-specific. I think, = it will be good if there is some discussion about it. >=20 > Thanks, > Padma >=20 >=20 > On Jun 8, 2010, at 12:00 PM, ledbat-request@ietf.org wrote: >=20 > =09 > Date: Tue, 8 Jun 2010 16:03:37 +0200 > From: "Rolf Winter" > Subject: [ledbat] Open issues, part 1 > To: > Message-ID: = <547F018265F92642B577B986577D671C014B9A15@VENUS.office> > Content-Type: text/plain; charset=3D"us-ascii" > =09 > Hi, > =09 > Here is the first Email in a series of Emails (to keep Email = threats separate) which deal with open points in the congestion control = draft. I pulled those together from various sources such as meeting = minutes. I would like have a documented agreement on them. If there are = other open question please speak up. > =09 > 1. Parameters > There were comments on the parameterization of the congestion = control draft. The main concern was that they seem to come out of thin = air. To close this issue I'd like to ask the group whether they think = the parameters are sensible or not (e.g. 25ms delay target). It would be = good to hear from people such as, say, game developers what they have to = say about this target. A better description of why these were chosen is = surely something that should go into the text. > =09 > Best, > =09 > Rolf > =09 > NEC Europe Limited | Registered Office: NEC House, 1 Victoria = Road, London W3 6BL | Registered in England 2832014=20 > =09 >=20 >=20 >=20 From muraris@microsoft.com Mon Jun 14 19:21:32 2010 Return-Path: X-Original-To: ledbat@core3.amsl.com Delivered-To: ledbat@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id D7AD73A66B4 for ; Mon, 14 Jun 2010 19:21:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -7.722 X-Spam-Level: X-Spam-Status: No, score=-7.722 tagged_above=-999 required=5 tests=[AWL=-0.323, BAYES_50=0.001, J_CHICKENPOX_75=0.6, 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 OatdM6UlIPKI for ; Mon, 14 Jun 2010 19:21:31 -0700 (PDT) Received: from smtp.microsoft.com (smtp.microsoft.com [131.107.115.215]) by core3.amsl.com (Postfix) with ESMTP id 588B33A67E7 for ; Mon, 14 Jun 2010 19:21:31 -0700 (PDT) Received: from TK5EX14MLTC101.redmond.corp.microsoft.com (157.54.79.178) by TK5-EXGWY-E802.partners.extranet.microsoft.com (10.251.56.168) with Microsoft SMTP Server (TLS) id 8.2.176.0; Mon, 14 Jun 2010 19:21:35 -0700 Received: from tk5ex14mbxc106.redmond.corp.microsoft.com ([169.254.3.138]) by TK5EX14MLTC101.redmond.corp.microsoft.com ([157.54.79.178]) with mapi id 14.01.0160.007; Mon, 14 Jun 2010 19:21:35 -0700 From: Murari Sridharan To: Padma Bhooma , Rolf Winter Thread-Topic: [ledbat] other open issues Thread-Index: AQHLCZODh+FJAm7W40iRLczr6P/PypJ+fCAAgAQbi4D//7eTwA== Date: Tue, 15 Jun 2010 02:21:35 +0000 Message-ID: <902F4C8483487C40A366621E25F01D960606451D@tk5ex14mbxc106.redmond.corp.microsoft.com> References: <547F018265F92642B577B986577D671C014B9ED4@VENUS.office> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "ledbat@ietf.org" Subject: Re: [ledbat] other open issues X-BeenThere: ledbat@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Mailing list of the LEDBAT WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 15 Jun 2010 02:21:33 -0000 Yes as those changes happen base delay will have to be re-measured and hist= ory purged. Purging the history is necessary as the buffering on these wire= less networks is quite different and so samples will be invalid across thes= e changes. I guess along with route flaps we should talk about interface or= nexthop changes which are seamless (without breaking connectivity) like on= mobile devices.=20 Thanks Murari=20 -----Original Message----- From: ledbat-bounces@ietf.org [mailto:ledbat-bounces@ietf.org] On Behalf Of= Padma Bhooma Sent: Monday, June 14, 2010 4:39 PM To: Rolf Winter Cc: ledbat@ietf.org Subject: Re: [ledbat] other open issues Thanks Rolf for the reply. Changes in base delay can happen more frequently= in wireless environment. For instance, it can happen when a host moves fro= m 3G to edge. It can also happen if the host moves away from its Wifi acces= s point or if the quality of the channel deteriorates for some reason. I gu= ess, these can also be considered as changes in the route. Padma On Jun 12, 2010, at 1:55 AM, Rolf Winter wrote: > Padma, >=20 > thanks for the feedback. Regarding point 1. I guess changes in the base d= elay are expected only when the route changes. As we talk about the last n = minutes of measurement, I assume the "old" measurement will just disappear = over time even in idle periods(after n minutes). What the draft should desc= ribe therefore I think is how periods of idle time are interpreted. So if t= he last entry in the base history is still removed even in periods where no= data is sent or received and idle periods are simply not taken into accoun= t when calculating the base delay, we might be fine. But as you said this s= hould be explicitly stated. >=20 > Best, >=20 > Rolf >=20 >=20 > NEC Europe Limited | Registered Office: NEC House, 1 Victoria Road, Londo= n W3 6BL | Registered in England 2832014=20 >=20 >=20 > -----Original Message----- > From: ledbat-bounces@ietf.org [mailto:ledbat-bounces@ietf.org] On Behalf = Of Padma Bhooma > Sent: Freitag, 11. Juni 2010 20:25 > To: ledbat@ietf.org > Subject: [ledbat] other open issues >=20 > Hi WG, >=20 > We have been looking into LEDBAT as an alternate TCP congestion control m= echanism for background traffic. A couple of things that are not very clear= in the draft draft-ietf-ledbat-congestion are: >=20 > 1. How will base history expire after some idle time? May there should be= a recommendation to throw away the history and re-learn delay on the link. >=20 > 2. The linear controller that LEDBAT uses suggests that the congestion wi= ndow should be increased proportional to the change in one-way delay. This = is very good for responding quickly to changes in delay. But this can cause= the window to increase at a faster rate than TCP would do with its probing= mechanism using additive-increase. Although the maximum increase in window= is capped to be less than Best-effort TCP, the rate of increase can be mor= e. Does this concern anyone?=20 >=20 > Some of these decisions can be made implementation-specific. I think, it = will be good if there is some discussion about it. >=20 > Thanks, > Padma >=20 >=20 > On Jun 8, 2010, at 12:00 PM, ledbat-request@ietf.org wrote: >=20 > =09 > Date: Tue, 8 Jun 2010 16:03:37 +0200 > From: "Rolf Winter" > Subject: [ledbat] Open issues, part 1 > To: > Message-ID: <547F018265F92642B577B986577D671C014B9A15@VENUS.office> > Content-Type: text/plain; charset=3D"us-ascii" > =09 > Hi, > =09 > Here is the first Email in a series of Emails (to keep Email threats sep= arate) which deal with open points in the congestion control draft. I pulle= d those together from various sources such as meeting minutes. I would like= have a documented agreement on them. If there are other open question plea= se speak up. > =09 > 1. Parameters > There were comments on the parameterization of the congestion control dr= aft. The main concern was that they seem to come out of thin air. To close = this issue I'd like to ask the group whether they think the parameters are = sensible or not (e.g. 25ms delay target). It would be good to hear from peo= ple such as, say, game developers what they have to say about this target. = A better description of why these were chosen is surely something that shou= ld go into the text. > =09 > Best, > =09 > Rolf > =09 > NEC Europe Limited | Registered Office: NEC House, 1 Victoria Road, Lond= on W3 6BL | Registered in England 2832014=20 > =09 >=20 >=20 >=20 _______________________________________________ ledbat mailing list ledbat@ietf.org https://www.ietf.org/mailman/listinfo/ledbat From Rolf.Winter@neclab.eu Tue Jun 15 01:31:29 2010 Return-Path: X-Original-To: ledbat@core3.amsl.com Delivered-To: ledbat@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id A1B9C3A6A3A for ; Tue, 15 Jun 2010 01:31:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.429 X-Spam-Level: X-Spam-Status: No, score=-1.429 tagged_above=-999 required=5 tests=[AWL=0.570, BAYES_00=-2.599, J_CHICKENPOX_75=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 h+P8xSDXte9R for ; Tue, 15 Jun 2010 01:31:22 -0700 (PDT) Received: from smtp0.neclab.eu (smtp0.neclab.eu [195.37.70.41]) by core3.amsl.com (Postfix) with ESMTP id A9EBC3A6A48 for ; Tue, 15 Jun 2010 01:31:18 -0700 (PDT) Received: from localhost (localhost.localdomain [127.0.0.1]) by smtp0.neclab.eu (Postfix) with ESMTP id 4D4212C000C05; Tue, 15 Jun 2010 10:31:21 +0200 (CEST) X-Virus-Scanned: Amavisd on Debian GNU/Linux (atlas2.office) Received: from smtp0.neclab.eu ([127.0.0.1]) by localhost (atlas2.office [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id e-yoXmyKxmrb; Tue, 15 Jun 2010 10:31:21 +0200 (CEST) Received: from VENUS.office (mx1.office [192.168.24.3]) by smtp0.neclab.eu (Postfix) with ESMTP id 2E6472C000355; Tue, 15 Jun 2010 10:31:06 +0200 (CEST) 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, 15 Jun 2010 10:31:05 +0200 Message-ID: <547F018265F92642B577B986577D671C014BA135@VENUS.office> In-Reply-To: <902F4C8483487C40A366621E25F01D960606451D@tk5ex14mbxc106.redmond.corp.microsoft.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [ledbat] other open issues Thread-Index: AQHLCZODh+FJAm7W40iRLczr6P/PypJ+fCAAgAQbi4D//7eTwIAAVNHA References: <547F018265F92642B577B986577D671C014B9ED4@VENUS.office> <902F4C8483487C40A366621E25F01D960606451D@tk5ex14mbxc106.redmond.corp.microsoft.com> From: "Rolf Winter" To: "Murari Sridharan" , "Padma Bhooma" Cc: ledbat@ietf.org Subject: Re: [ledbat] other open issues X-BeenThere: ledbat@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Mailing list of the LEDBAT WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 15 Jun 2010 08:31:29 -0000 Padma, This is a very good point. However, I think we are mixing two issues = now. One is that you have periods of idle time, the other one is that = routes/access can change over time. Both can happen at the same time but = let's first look at them individually. Assuming for now that there is = not route change but only idle time, I think the algorithm as described = now works OK. We could add some text to make things clearer, but = initializing a minute of measurements with 'infinity' might just do the = trick. Do you think this is a valid assumption? The other issue that you bring up is how fast a new base delay can be = correctly measured on route/access change. For the following I assume = that you will be able to get one packet through that will give you a = good estimate for the base delay fairly quickly. The only problem I see = then is when the base delay increases. If it decreases, the new lower = base delay estimate will result in a correct overall base delay value = that you use for congestion control. However if it increases, there are = 'old' lower values that you will use until they disappear from the = history. If you consider the last 10 minutes, then it might take 9.x = Minutes till you have the correct base delay. I agree that it would be = nice if we could avoid that. However, while idle time is easy to = recognize, a potentially seamless change in access technology is not = that easy. If possible, I would like to not mandate the protocol to make = use of lower layer triggers but an implementation is free to do so. We = could in any case add text to the document. An earlier Email from Arvid concerned me where he said that it might = take 10 minutes till a packet gets through without experiencing queuing = delay. This is another issue that has a similar effect and I would like = to hear more about the settings when this happens. Thanks for the valuable feedback Padma. Best, Rolf NEC Europe Limited | Registered Office: NEC House, 1 Victoria Road, = London W3 6BL | Registered in England 2832014=20 -----Original Message----- From: Murari Sridharan [mailto:muraris@microsoft.com]=20 Sent: Dienstag, 15. Juni 2010 04:22 To: Padma Bhooma; Rolf Winter Cc: ledbat@ietf.org Subject: RE: [ledbat] other open issues Yes as those changes happen base delay will have to be re-measured and = history purged. Purging the history is necessary as the buffering on = these wireless networks is quite different and so samples will be = invalid across these changes. I guess along with route flaps we should = talk about interface or nexthop changes which are seamless (without = breaking connectivity) like on mobile devices.=20 Thanks Murari=20 -----Original Message----- From: ledbat-bounces@ietf.org [mailto:ledbat-bounces@ietf.org] On Behalf = Of Padma Bhooma Sent: Monday, June 14, 2010 4:39 PM To: Rolf Winter Cc: ledbat@ietf.org Subject: Re: [ledbat] other open issues Thanks Rolf for the reply. Changes in base delay can happen more = frequently in wireless environment. For instance, it can happen when a = host moves from 3G to edge. It can also happen if the host moves away = from its Wifi access point or if the quality of the channel deteriorates = for some reason. I guess, these can also be considered as changes in the = route. Padma On Jun 12, 2010, at 1:55 AM, Rolf Winter wrote: > Padma, >=20 > thanks for the feedback. Regarding point 1. I guess changes in the = base delay are expected only when the route changes. As we talk about = the last n minutes of measurement, I assume the "old" measurement will = just disappear over time even in idle periods(after n minutes). What the = draft should describe therefore I think is how periods of idle time are = interpreted. So if the last entry in the base history is still removed = even in periods where no data is sent or received and idle periods are = simply not taken into account when calculating the base delay, we might = be fine. But as you said this should be explicitly stated. >=20 > Best, >=20 > Rolf >=20 >=20 > NEC Europe Limited | Registered Office: NEC House, 1 Victoria Road, = London W3 6BL | Registered in England 2832014=20 >=20 >=20 > -----Original Message----- > From: ledbat-bounces@ietf.org [mailto:ledbat-bounces@ietf.org] On = Behalf Of Padma Bhooma > Sent: Freitag, 11. Juni 2010 20:25 > To: ledbat@ietf.org > Subject: [ledbat] other open issues >=20 > Hi WG, >=20 > We have been looking into LEDBAT as an alternate TCP congestion = control mechanism for background traffic. A couple of things that are = not very clear in the draft draft-ietf-ledbat-congestion are: >=20 > 1. How will base history expire after some idle time? May there should = be a recommendation to throw away the history and re-learn delay on the = link. >=20 > 2. The linear controller that LEDBAT uses suggests that the congestion = window should be increased proportional to the change in one-way delay. = This is very good for responding quickly to changes in delay. But this = can cause the window to increase at a faster rate than TCP would do with = its probing mechanism using additive-increase. Although the maximum = increase in window is capped to be less than Best-effort TCP, the rate = of increase can be more. Does this concern anyone?=20 >=20 > Some of these decisions can be made implementation-specific. I think, = it will be good if there is some discussion about it. >=20 > Thanks, > Padma >=20 >=20 > On Jun 8, 2010, at 12:00 PM, ledbat-request@ietf.org wrote: >=20 > =09 > Date: Tue, 8 Jun 2010 16:03:37 +0200 > From: "Rolf Winter" > Subject: [ledbat] Open issues, part 1 > To: > Message-ID: <547F018265F92642B577B986577D671C014B9A15@VENUS.office> > Content-Type: text/plain; charset=3D"us-ascii" > =09 > Hi, > =09 > Here is the first Email in a series of Emails (to keep Email threats = separate) which deal with open points in the congestion control draft. I = pulled those together from various sources such as meeting minutes. I = would like have a documented agreement on them. If there are other open = question please speak up. > =09 > 1. Parameters > There were comments on the parameterization of the congestion control = draft. The main concern was that they seem to come out of thin air. To = close this issue I'd like to ask the group whether they think the = parameters are sensible or not (e.g. 25ms delay target). It would be = good to hear from people such as, say, game developers what they have to = say about this target. A better description of why these were chosen is = surely something that should go into the text. > =09 > Best, > =09 > Rolf > =09 > NEC Europe Limited | Registered Office: NEC House, 1 Victoria Road, = London W3 6BL | Registered in England 2832014=20 > =09 >=20 >=20 >=20 _______________________________________________ ledbat mailing list ledbat@ietf.org https://www.ietf.org/mailman/listinfo/ledbat From muraris@microsoft.com Tue Jun 15 07:28:56 2010 Return-Path: X-Original-To: ledbat@core3.amsl.com Delivered-To: ledbat@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id B62553A6988 for ; Tue, 15 Jun 2010 07:28:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -8.957 X-Spam-Level: X-Spam-Status: No, score=-8.957 tagged_above=-999 required=5 tests=[AWL=1.042, BAYES_00=-2.599, J_CHICKENPOX_75=0.6, 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 ANiFJMkVKUJE for ; Tue, 15 Jun 2010 07:28:51 -0700 (PDT) Received: from smtp.microsoft.com (smtp.microsoft.com [131.107.115.212]) by core3.amsl.com (Postfix) with ESMTP id 4C5CC3A691B for ; Tue, 15 Jun 2010 07:28:51 -0700 (PDT) Received: from TK5EX14HUBC101.redmond.corp.microsoft.com (157.54.7.153) by TK5-EXGWY-E801.partners.extranet.microsoft.com (10.251.56.50) with Microsoft SMTP Server (TLS) id 8.2.176.0; Tue, 15 Jun 2010 07:28:49 -0700 Received: from tk5ex14mbxc106.redmond.corp.microsoft.com ([169.254.3.138]) by TK5EX14HUBC101.redmond.corp.microsoft.com ([157.54.7.153]) with mapi id 14.01.0160.007; Tue, 15 Jun 2010 07:28:49 -0700 From: Murari Sridharan To: Rolf Winter , Padma Bhooma Thread-Topic: [ledbat] other open issues Thread-Index: AQHLCZODh+FJAm7W40iRLczr6P/PypJ+fCAAgAQbi4D//7eTwIAAVNHAgAB2Q8A= Date: Tue, 15 Jun 2010 14:28:47 +0000 Message-ID: <902F4C8483487C40A366621E25F01D96060648C5@tk5ex14mbxc106.redmond.corp.microsoft.com> References: <547F018265F92642B577B986577D671C014B9ED4@VENUS.office> <902F4C8483487C40A366621E25F01D960606451D@tk5ex14mbxc106.redmond.corp.microsoft.com> <547F018265F92642B577B986577D671C014BA135@VENUS.office> In-Reply-To: <547F018265F92642B577B986577D671C014BA135@VENUS.office> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "ledbat@ietf.org" Subject: Re: [ledbat] other open issues X-BeenThere: ledbat@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Mailing list of the LEDBAT WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 15 Jun 2010 14:28:56 -0000 Rolf, good points; I think some discussion around this is definitely useful= although the exact way in which somebody would discover such a (seamless) = change is clearly out-of-scope of our charter.=20 Thanks -----Original Message----- From: Rolf Winter [mailto:Rolf.Winter@neclab.eu]=20 Sent: Tuesday, June 15, 2010 1:31 AM To: Murari Sridharan; Padma Bhooma Cc: ledbat@ietf.org Subject: RE: [ledbat] other open issues Padma, This is a very good point. However, I think we are mixing two issues now. O= ne is that you have periods of idle time, the other one is that routes/acce= ss can change over time. Both can happen at the same time but let's first l= ook at them individually. Assuming for now that there is not route change b= ut only idle time, I think the algorithm as described now works OK. We coul= d add some text to make things clearer, but initializing a minute of measur= ements with 'infinity' might just do the trick. Do you think this is a vali= d assumption? The other issue that you bring up is how fast a new base delay can be corre= ctly measured on route/access change. For the following I assume that you w= ill be able to get one packet through that will give you a good estimate fo= r the base delay fairly quickly. The only problem I see then is when the ba= se delay increases. If it decreases, the new lower base delay estimate will= result in a correct overall base delay value that you use for congestion c= ontrol. However if it increases, there are 'old' lower values that you will= use until they disappear from the history. If you consider the last 10 min= utes, then it might take 9.x Minutes till you have the correct base delay. = I agree that it would be nice if we could avoid that. However, while idle t= ime is easy to recognize, a potentially seamless change in access technolog= y is not that easy. If possible, I would like to not mandate the protocol t= o make use of lower layer triggers but an implementation is free to do so. = We could in any case add text to the document. An earlier Email from Arvid concerned me where he said that it might take 1= 0 minutes till a packet gets through without experiencing queuing delay. Th= is is another issue that has a similar effect and I would like to hear more= about the settings when this happens. Thanks for the valuable feedback Padma. Best, Rolf NEC Europe Limited | Registered Office: NEC House, 1 Victoria Road, London = W3 6BL | Registered in England 2832014=20 -----Original Message----- From: Murari Sridharan [mailto:muraris@microsoft.com]=20 Sent: Dienstag, 15. Juni 2010 04:22 To: Padma Bhooma; Rolf Winter Cc: ledbat@ietf.org Subject: RE: [ledbat] other open issues Yes as those changes happen base delay will have to be re-measured and hist= ory purged. Purging the history is necessary as the buffering on these wire= less networks is quite different and so samples will be invalid across thes= e changes. I guess along with route flaps we should talk about interface or= nexthop changes which are seamless (without breaking connectivity) like on= mobile devices.=20 Thanks Murari=20 -----Original Message----- From: ledbat-bounces@ietf.org [mailto:ledbat-bounces@ietf.org] On Behalf Of= Padma Bhooma Sent: Monday, June 14, 2010 4:39 PM To: Rolf Winter Cc: ledbat@ietf.org Subject: Re: [ledbat] other open issues Thanks Rolf for the reply. Changes in base delay can happen more frequently= in wireless environment. For instance, it can happen when a host moves fro= m 3G to edge. It can also happen if the host moves away from its Wifi acces= s point or if the quality of the channel deteriorates for some reason. I gu= ess, these can also be considered as changes in the route. Padma On Jun 12, 2010, at 1:55 AM, Rolf Winter wrote: > Padma, >=20 > thanks for the feedback. Regarding point 1. I guess changes in the base d= elay are expected only when the route changes. As we talk about the last n = minutes of measurement, I assume the "old" measurement will just disappear = over time even in idle periods(after n minutes). What the draft should desc= ribe therefore I think is how periods of idle time are interpreted. So if t= he last entry in the base history is still removed even in periods where no= data is sent or received and idle periods are simply not taken into accoun= t when calculating the base delay, we might be fine. But as you said this s= hould be explicitly stated. >=20 > Best, >=20 > Rolf >=20 >=20 > NEC Europe Limited | Registered Office: NEC House, 1 Victoria Road, Londo= n W3 6BL | Registered in England 2832014=20 >=20 >=20 > -----Original Message----- > From: ledbat-bounces@ietf.org [mailto:ledbat-bounces@ietf.org] On Behalf = Of Padma Bhooma > Sent: Freitag, 11. Juni 2010 20:25 > To: ledbat@ietf.org > Subject: [ledbat] other open issues >=20 > Hi WG, >=20 > We have been looking into LEDBAT as an alternate TCP congestion control m= echanism for background traffic. A couple of things that are not very clear= in the draft draft-ietf-ledbat-congestion are: >=20 > 1. How will base history expire after some idle time? May there should be= a recommendation to throw away the history and re-learn delay on the link. >=20 > 2. The linear controller that LEDBAT uses suggests that the congestion wi= ndow should be increased proportional to the change in one-way delay. This = is very good for responding quickly to changes in delay. But this can cause= the window to increase at a faster rate than TCP would do with its probing= mechanism using additive-increase. Although the maximum increase in window= is capped to be less than Best-effort TCP, the rate of increase can be mor= e. Does this concern anyone?=20 >=20 > Some of these decisions can be made implementation-specific. I think, it = will be good if there is some discussion about it. >=20 > Thanks, > Padma >=20 >=20 > On Jun 8, 2010, at 12:00 PM, ledbat-request@ietf.org wrote: >=20 > =09 > Date: Tue, 8 Jun 2010 16:03:37 +0200 > From: "Rolf Winter" > Subject: [ledbat] Open issues, part 1 > To: > Message-ID: <547F018265F92642B577B986577D671C014B9A15@VENUS.office> > Content-Type: text/plain; charset=3D"us-ascii" > =09 > Hi, > =09 > Here is the first Email in a series of Emails (to keep Email threats sep= arate) which deal with open points in the congestion control draft. I pulle= d those together from various sources such as meeting minutes. I would like= have a documented agreement on them. If there are other open question plea= se speak up. > =09 > 1. Parameters > There were comments on the parameterization of the congestion control dr= aft. The main concern was that they seem to come out of thin air. To close = this issue I'd like to ask the group whether they think the parameters are = sensible or not (e.g. 25ms delay target). It would be good to hear from peo= ple such as, say, game developers what they have to say about this target. = A better description of why these were chosen is surely something that shou= ld go into the text. > =09 > Best, > =09 > Rolf > =09 > NEC Europe Limited | Registered Office: NEC House, 1 Victoria Road, Lond= on W3 6BL | Registered in England 2832014=20 > =09 >=20 >=20 >=20 _______________________________________________ ledbat mailing list ledbat@ietf.org https://www.ietf.org/mailman/listinfo/ledbat From dario.rossi@enst.fr Wed Jun 16 07:43:05 2010 Return-Path: X-Original-To: ledbat@core3.amsl.com Delivered-To: ledbat@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id D3ED53A6B38 for ; Wed, 16 Jun 2010 07:43:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.351 X-Spam-Level: X-Spam-Status: No, score=0.351 tagged_above=-999 required=5 tests=[BAYES_50=0.001, HELO_EQ_FR=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 grHb0JKW5N1C for ; Wed, 16 Jun 2010 07:43:04 -0700 (PDT) Received: from smtp2.enst.fr (revol2.enst.fr [137.194.2.14]) by core3.amsl.com (Postfix) with ESMTP id 678CB3A6B33 for ; Wed, 16 Jun 2010 07:43:04 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by smtp2.enst.fr (Postfix) with ESMTP id 19373B83F0 for ; Wed, 16 Jun 2010 16:38:05 +0200 (CEST) X-Virus-Scanned: amavisd-new at enst.fr Received: from [IPv6:::1] (ares.enst.fr [137.194.34.9]) by smtp2.enst.fr (Postfix) with ESMTP id D6C9CB83E2 for ; Wed, 16 Jun 2010 16:38:04 +0200 (CEST) Message-ID: <4C18E1CC.4050206@enst.fr> Date: Wed, 16 Jun 2010 16:38:04 +0200 From: Dario Rossi User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.9.1.9) Gecko/20100423 Thunderbird/3.0.4 MIME-Version: 1.0 To: "ledbat@ietf.org" References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit Subject: Re: [ledbat] LEDBAT Status and plan moving forward X-BeenThere: ledbat@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Mailing list of the LEDBAT WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 16 Jun 2010 14:43:05 -0000 Dear all, we have been doing some more work on LEDBAT (currently under submission), which I think it may be interesting to share on the WG list to stimulate the discussion: #1: investigation of LEDBAT latecomer issue and possible solutions http://arxiv.org/abs/1006.3018 #2: comparison of different "lower than best effort" protocols (i.e. LEDBAT, TCP-LP and TCP-NICE) http://arxiv.org/abs/1006.3017 for the above work we have been using a custom implementation of LEDBAT for the ns2 simulator (notice that our code can also work as Linux kernel module, so that testbed experiments can be done as well), available at: http://perso.telecom-paristech.fr/~valenti/pmwiki/pmwiki.php?n=Main.LEDBAT thus, note that #1 and #2 have not used the uTP library that BitTorrent released at the end of may: Blog: http://blog.bittorrent.com/2010/05/21/%C2%B5tp-open-source-implementation/ Code: http://github.com/bittorrent/libutp as of today, we are not sure if we can participate to the IETF78 meeting (but in the latter case we would be happy to give presentations of #1 and #2 if this is of interest for the WG) Best regards, D. On 06/10/2010 02:49 PM, Jason Livingood wrote: > >>> The first draft draft-ietf-ledbat-practices-recommendations isnšt >>> converging, Rolf and I are going to have a chat with the authors >>> regarding this draft. We want to hear from the group if they think this >>> document is useful in its present form. We started out with all the >>> right intentions here but this is simply not converging. Unless there is >>> strong interest in keeping draft-ietf-ledbat-practices-recommendations >>> alive we should drop it as a WG document. >>> >> I see this as one of the most important documents, since it helps those >> outside >> this community determine the bounds and utility of our solutions. >> >> As one of the co-authors of this doc, I'd be more than glad to contribute >> further cycles on this. The past scheduling has been unfortunate (overlapping >> with MIF and BEHAVE, among others). >> > I also think the document provides useful information. If the authors can > keep working on it, that'd be great. > > Jason > > _______________________________________________ > ledbat mailing list > ledbat@ietf.org > https://www.ietf.org/mailman/listinfo/ledbat > -- Dario Rossi Oo Associate Professor > TELECOM ParisTech ~ (formerly ENST) mail: dario.rossi@enst.fr phone: +33.1.4581.7563 fax: +33.1.4581.7158 web: http://www.enst.fr/~drossi From bhooma@apple.com Wed Jun 16 09:03:14 2010 Return-Path: X-Original-To: ledbat@core3.amsl.com Delivered-To: ledbat@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 64E253A68BF for ; Wed, 16 Jun 2010 09:03:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.549 X-Spam-Level: X-Spam-Status: No, score=-103.549 tagged_above=-999 required=5 tests=[AWL=-0.150, BAYES_50=0.001, J_CHICKENPOX_75=0.6, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 46iEy0irwo3f for ; Wed, 16 Jun 2010 09:03:12 -0700 (PDT) Received: from mail-out4.apple.com (mail-out4.apple.com [17.254.13.23]) by core3.amsl.com (Postfix) with ESMTP id 32DB03A688D for ; Wed, 16 Jun 2010 09:03:12 -0700 (PDT) Received: from relay16.apple.com (relay16.apple.com [17.128.113.55]) by mail-out4.apple.com (Postfix) with ESMTP id 188ED9EDBDE9; Wed, 16 Jun 2010 09:03:17 -0700 (PDT) X-AuditID: 11807137-b7b43ae000004f8e-b6-4c18f5c4471a Received: from il0204a-dhcp50.apple.com (il0204a-dhcp50.apple.com [17.202.45.178]) (using TLS with cipher AES128-SHA (AES128-SHA/128 bits)) (Client did not present a certificate) by relay16.apple.com (Apple SCV relay) with SMTP id 95.BC.20366.5C5F81C4; Wed, 16 Jun 2010 09:03:17 -0700 (PDT) Mime-Version: 1.0 (Apple Message framework v1150) Content-Type: text/plain; charset=us-ascii From: Padma Bhooma In-Reply-To: <902F4C8483487C40A366621E25F01D96060648C5@tk5ex14mbxc106.redmond.corp.microsoft.com> Date: Wed, 16 Jun 2010 09:03:18 -0700 Content-Transfer-Encoding: quoted-printable Message-Id: References: <547F018265F92642B577B986577D671C014B9ED4@VENUS.office> <902F4C8483487C40A366621E25F01D960606451D@tk5ex14mbxc106.redmond.corp.microsoft.com> <547F018265F92642B577B986577D671C014BA135@VENUS.office> <902F4C8483487C40A366621E25F01D96060648C5@tk5ex14mbxc106.redmond.corp.microsoft.com> To: Murari Sridharan X-Mailer: Apple Mail (2.1150) X-Brightmail-Tracker: AAAAAQAAAZE= Cc: "ledbat@ietf.org" , Rolf Winter Subject: Re: [ledbat] other open issues X-BeenThere: ledbat@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Mailing list of the LEDBAT WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 16 Jun 2010 16:03:14 -0000 I am not suggesting that LEDBAT should use any hints about link layer = changes. I agree that it is out-of-scope for LEDBAT. The only reason = given for expiring base delay history was route changes. I was = suggesting that base delay can change more frequently in wireless = environments. The way LEDBAT expires the base delay every minute is a good way to = adjust to these changes. It is true that the current text says that base = delay should be stored for last n minutes. According to the current = algorithm, base delay should be updated during packet processing or = acknowledgement processing. So if there are no packets during some idle = period, base delay can become stale. I am asking if there needs to be = some text about expiring base delay during idle period. It looks like = there is some agreement on that. Thanks, Padma On Jun 15, 2010, at 7:28 AM, Murari Sridharan wrote: > Rolf, good points; I think some discussion around this is definitely = useful although the exact way in which somebody would discover such a = (seamless) change is clearly out-of-scope of our charter.=20 >=20 > Thanks >=20 > -----Original Message----- > From: Rolf Winter [mailto:Rolf.Winter@neclab.eu]=20 > Sent: Tuesday, June 15, 2010 1:31 AM > To: Murari Sridharan; Padma Bhooma > Cc: ledbat@ietf.org > Subject: RE: [ledbat] other open issues >=20 > Padma, >=20 > This is a very good point. However, I think we are mixing two issues = now. One is that you have periods of idle time, the other one is that = routes/access can change over time. Both can happen at the same time but = let's first look at them individually. Assuming for now that there is = not route change but only idle time, I think the algorithm as described = now works OK. We could add some text to make things clearer, but = initializing a minute of measurements with 'infinity' might just do the = trick. Do you think this is a valid assumption? >=20 > The other issue that you bring up is how fast a new base delay can be = correctly measured on route/access change. For the following I assume = that you will be able to get one packet through that will give you a = good estimate for the base delay fairly quickly. The only problem I see = then is when the base delay increases. If it decreases, the new lower = base delay estimate will result in a correct overall base delay value = that you use for congestion control. However if it increases, there are = 'old' lower values that you will use until they disappear from the = history. If you consider the last 10 minutes, then it might take 9.x = Minutes till you have the correct base delay. I agree that it would be = nice if we could avoid that. However, while idle time is easy to = recognize, a potentially seamless change in access technology is not = that easy. If possible, I would like to not mandate the protocol to make = use of lower layer triggers but an implementation is free to do so. We = could in any case add text to the document. >=20 > An earlier Email from Arvid concerned me where he said that it might = take 10 minutes till a packet gets through without experiencing queuing = delay. This is another issue that has a similar effect and I would like = to hear more about the settings when this happens. >=20 > Thanks for the valuable feedback Padma. >=20 > Best, >=20 > Rolf >=20 >=20 > NEC Europe Limited | Registered Office: NEC House, 1 Victoria Road, = London W3 6BL | Registered in England 2832014=20 >=20 > -----Original Message----- > From: Murari Sridharan [mailto:muraris@microsoft.com]=20 > Sent: Dienstag, 15. Juni 2010 04:22 > To: Padma Bhooma; Rolf Winter > Cc: ledbat@ietf.org > Subject: RE: [ledbat] other open issues >=20 > Yes as those changes happen base delay will have to be re-measured and = history purged. Purging the history is necessary as the buffering on = these wireless networks is quite different and so samples will be = invalid across these changes. I guess along with route flaps we should = talk about interface or nexthop changes which are seamless (without = breaking connectivity) like on mobile devices.=20 >=20 > Thanks > Murari=20 >=20 > -----Original Message----- > From: ledbat-bounces@ietf.org [mailto:ledbat-bounces@ietf.org] On = Behalf Of Padma Bhooma > Sent: Monday, June 14, 2010 4:39 PM > To: Rolf Winter > Cc: ledbat@ietf.org > Subject: Re: [ledbat] other open issues >=20 > Thanks Rolf for the reply. Changes in base delay can happen more = frequently in wireless environment. For instance, it can happen when a = host moves from 3G to edge. It can also happen if the host moves away = from its Wifi access point or if the quality of the channel deteriorates = for some reason. I guess, these can also be considered as changes in the = route. >=20 > Padma >=20 > On Jun 12, 2010, at 1:55 AM, Rolf Winter wrote: >=20 >> Padma, >>=20 >> thanks for the feedback. Regarding point 1. I guess changes in the = base delay are expected only when the route changes. As we talk about = the last n minutes of measurement, I assume the "old" measurement will = just disappear over time even in idle periods(after n minutes). What the = draft should describe therefore I think is how periods of idle time are = interpreted. So if the last entry in the base history is still removed = even in periods where no data is sent or received and idle periods are = simply not taken into account when calculating the base delay, we might = be fine. But as you said this should be explicitly stated. >>=20 >> Best, >>=20 >> Rolf >>=20 >>=20 >> NEC Europe Limited | Registered Office: NEC House, 1 Victoria Road, = London W3 6BL | Registered in England 2832014=20 >>=20 >>=20 >> -----Original Message----- >> From: ledbat-bounces@ietf.org [mailto:ledbat-bounces@ietf.org] On = Behalf Of Padma Bhooma >> Sent: Freitag, 11. Juni 2010 20:25 >> To: ledbat@ietf.org >> Subject: [ledbat] other open issues >>=20 >> Hi WG, >>=20 >> We have been looking into LEDBAT as an alternate TCP congestion = control mechanism for background traffic. A couple of things that are = not very clear in the draft draft-ietf-ledbat-congestion are: >>=20 >> 1. How will base history expire after some idle time? May there = should be a recommendation to throw away the history and re-learn delay = on the link. >>=20 >> 2. The linear controller that LEDBAT uses suggests that the = congestion window should be increased proportional to the change in = one-way delay. This is very good for responding quickly to changes in = delay. But this can cause the window to increase at a faster rate than = TCP would do with its probing mechanism using additive-increase. = Although the maximum increase in window is capped to be less than = Best-effort TCP, the rate of increase can be more. Does this concern = anyone?=20 >>=20 >> Some of these decisions can be made implementation-specific. I think, = it will be good if there is some discussion about it. >>=20 >> Thanks, >> Padma >>=20 >>=20 >> On Jun 8, 2010, at 12:00 PM, ledbat-request@ietf.org wrote: >>=20 >> =09 >> Date: Tue, 8 Jun 2010 16:03:37 +0200 >> From: "Rolf Winter" >> Subject: [ledbat] Open issues, part 1 >> To: >> Message-ID: = <547F018265F92642B577B986577D671C014B9A15@VENUS.office> >> Content-Type: text/plain; charset=3D"us-ascii" >> =09 >> Hi, >> =09 >> Here is the first Email in a series of Emails (to keep Email = threats separate) which deal with open points in the congestion control = draft. I pulled those together from various sources such as meeting = minutes. I would like have a documented agreement on them. If there are = other open question please speak up. >> =09 >> 1. Parameters >> There were comments on the parameterization of the congestion = control draft. The main concern was that they seem to come out of thin = air. To close this issue I'd like to ask the group whether they think = the parameters are sensible or not (e.g. 25ms delay target). It would be = good to hear from people such as, say, game developers what they have to = say about this target. A better description of why these were chosen is = surely something that should go into the text. >> =09 >> Best, >> =09 >> Rolf >> =09 >> NEC Europe Limited | Registered Office: NEC House, 1 Victoria = Road, London W3 6BL | Registered in England 2832014=20 >> =09 >>=20 >>=20 >>=20 >=20 > _______________________________________________ > ledbat mailing list > ledbat@ietf.org > https://www.ietf.org/mailman/listinfo/ledbat >=20 >=20 From muraris@microsoft.com Wed Jun 16 09:07:35 2010 Return-Path: X-Original-To: ledbat@core3.amsl.com Delivered-To: ledbat@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 4C94C28C0CF for ; Wed, 16 Jun 2010 09:07:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -9.131 X-Spam-Level: X-Spam-Status: No, score=-9.131 tagged_above=-999 required=5 tests=[AWL=0.868, BAYES_00=-2.599, J_CHICKENPOX_75=0.6, 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 ZWgmDFSlBJ6F for ; Wed, 16 Jun 2010 09:07:34 -0700 (PDT) Received: from smtp.microsoft.com (mailb.microsoft.com [131.107.115.215]) by core3.amsl.com (Postfix) with ESMTP id DEBAD3A67B8 for ; Wed, 16 Jun 2010 09:07:33 -0700 (PDT) Received: from TK5EX14CASC132.redmond.corp.microsoft.com (157.54.52.17) by TK5-EXGWY-E802.partners.extranet.microsoft.com (10.251.56.168) with Microsoft SMTP Server (TLS) id 8.2.176.0; Wed, 16 Jun 2010 09:07:38 -0700 Received: from tk5ex14mbxc106.redmond.corp.microsoft.com ([169.254.3.138]) by TK5EX14CASC132.redmond.corp.microsoft.com ([157.54.52.17]) with mapi id 14.01.0160.007; Wed, 16 Jun 2010 09:07:39 -0700 From: Murari Sridharan To: Padma Bhooma Thread-Topic: [ledbat] other open issues Thread-Index: AQHLCZODh+FJAm7W40iRLczr6P/PypJ+fCAAgAQbi4D//7eTwIAAVNHAgAB2Q8CAAiK+AP//i10Q Date: Wed, 16 Jun 2010 16:07:37 +0000 Message-ID: <902F4C8483487C40A366621E25F01D9606065C22@tk5ex14mbxc106.redmond.corp.microsoft.com> References: <547F018265F92642B577B986577D671C014B9ED4@VENUS.office> <902F4C8483487C40A366621E25F01D960606451D@tk5ex14mbxc106.redmond.corp.microsoft.com> <547F018265F92642B577B986577D671C014BA135@VENUS.office> <902F4C8483487C40A366621E25F01D96060648C5@tk5ex14mbxc106.redmond.corp.microsoft.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "ledbat@ietf.org" , Rolf Winter Subject: Re: [ledbat] other open issues X-BeenThere: ledbat@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Mailing list of the LEDBAT WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 16 Jun 2010 16:07:35 -0000 Yes and additional text to capture this discussion will be added to the doc= ument.=20 Thanks for reviewing and providing comments. Murari=20 -----Original Message----- From: Padma Bhooma [mailto:bhooma@apple.com]=20 Sent: Wednesday, June 16, 2010 9:03 AM To: Murari Sridharan Cc: Rolf Winter; ledbat@ietf.org Subject: Re: [ledbat] other open issues I am not suggesting that LEDBAT should use any hints about link layer chang= es. I agree that it is out-of-scope for LEDBAT. The only reason given for e= xpiring base delay history was route changes. I was suggesting that base de= lay can change more frequently in wireless environments. The way LEDBAT expires the base delay every minute is a good way to adjust = to these changes. It is true that the current text says that base delay sho= uld be stored for last n minutes. According to the current algorithm, base = delay should be updated during packet processing or acknowledgement process= ing. So if there are no packets during some idle period, base delay can bec= ome stale. I am asking if there needs to be some text about expiring base d= elay during idle period. It looks like there is some agreement on that. Thanks, Padma On Jun 15, 2010, at 7:28 AM, Murari Sridharan wrote: > Rolf, good points; I think some discussion around this is definitely usef= ul although the exact way in which somebody would discover such a (seamless= ) change is clearly out-of-scope of our charter.=20 >=20 > Thanks >=20 > -----Original Message----- > From: Rolf Winter [mailto:Rolf.Winter@neclab.eu]=20 > Sent: Tuesday, June 15, 2010 1:31 AM > To: Murari Sridharan; Padma Bhooma > Cc: ledbat@ietf.org > Subject: RE: [ledbat] other open issues >=20 > Padma, >=20 > This is a very good point. However, I think we are mixing two issues now.= One is that you have periods of idle time, the other one is that routes/ac= cess can change over time. Both can happen at the same time but let's first= look at them individually. Assuming for now that there is not route change= but only idle time, I think the algorithm as described now works OK. We co= uld add some text to make things clearer, but initializing a minute of meas= urements with 'infinity' might just do the trick. Do you think this is a va= lid assumption? >=20 > The other issue that you bring up is how fast a new base delay can be cor= rectly measured on route/access change. For the following I assume that you= will be able to get one packet through that will give you a good estimate = for the base delay fairly quickly. The only problem I see then is when the = base delay increases. If it decreases, the new lower base delay estimate wi= ll result in a correct overall base delay value that you use for congestion= control. However if it increases, there are 'old' lower values that you wi= ll use until they disappear from the history. If you consider the last 10 m= inutes, then it might take 9.x Minutes till you have the correct base delay= . I agree that it would be nice if we could avoid that. However, while idle= time is easy to recognize, a potentially seamless change in access technol= ogy is not that easy. If possible, I would like to not mandate the protocol= to make use of lower layer triggers but an implementation is free to do so= . We could in any case add text to the document. >=20 > An earlier Email from Arvid concerned me where he said that it might take= 10 minutes till a packet gets through without experiencing queuing delay. = This is another issue that has a similar effect and I would like to hear mo= re about the settings when this happens. >=20 > Thanks for the valuable feedback Padma. >=20 > Best, >=20 > Rolf >=20 >=20 > NEC Europe Limited | Registered Office: NEC House, 1 Victoria Road, Londo= n W3 6BL | Registered in England 2832014=20 >=20 > -----Original Message----- > From: Murari Sridharan [mailto:muraris@microsoft.com]=20 > Sent: Dienstag, 15. Juni 2010 04:22 > To: Padma Bhooma; Rolf Winter > Cc: ledbat@ietf.org > Subject: RE: [ledbat] other open issues >=20 > Yes as those changes happen base delay will have to be re-measured and hi= story purged. Purging the history is necessary as the buffering on these wi= reless networks is quite different and so samples will be invalid across th= ese changes. I guess along with route flaps we should talk about interface = or nexthop changes which are seamless (without breaking connectivity) like = on mobile devices.=20 >=20 > Thanks > Murari=20 >=20 > -----Original Message----- > From: ledbat-bounces@ietf.org [mailto:ledbat-bounces@ietf.org] On Behalf = Of Padma Bhooma > Sent: Monday, June 14, 2010 4:39 PM > To: Rolf Winter > Cc: ledbat@ietf.org > Subject: Re: [ledbat] other open issues >=20 > Thanks Rolf for the reply. Changes in base delay can happen more frequent= ly in wireless environment. For instance, it can happen when a host moves f= rom 3G to edge. It can also happen if the host moves away from its Wifi acc= ess point or if the quality of the channel deteriorates for some reason. I = guess, these can also be considered as changes in the route. >=20 > Padma >=20 > On Jun 12, 2010, at 1:55 AM, Rolf Winter wrote: >=20 >> Padma, >>=20 >> thanks for the feedback. Regarding point 1. I guess changes in the base = delay are expected only when the route changes. As we talk about the last n= minutes of measurement, I assume the "old" measurement will just disappear= over time even in idle periods(after n minutes). What the draft should des= cribe therefore I think is how periods of idle time are interpreted. So if = the last entry in the base history is still removed even in periods where n= o data is sent or received and idle periods are simply not taken into accou= nt when calculating the base delay, we might be fine. But as you said this = should be explicitly stated. >>=20 >> Best, >>=20 >> Rolf >>=20 >>=20 >> NEC Europe Limited | Registered Office: NEC House, 1 Victoria Road, Lond= on W3 6BL | Registered in England 2832014=20 >>=20 >>=20 >> -----Original Message----- >> From: ledbat-bounces@ietf.org [mailto:ledbat-bounces@ietf.org] On Behalf= Of Padma Bhooma >> Sent: Freitag, 11. Juni 2010 20:25 >> To: ledbat@ietf.org >> Subject: [ledbat] other open issues >>=20 >> Hi WG, >>=20 >> We have been looking into LEDBAT as an alternate TCP congestion control = mechanism for background traffic. A couple of things that are not very clea= r in the draft draft-ietf-ledbat-congestion are: >>=20 >> 1. How will base history expire after some idle time? May there should b= e a recommendation to throw away the history and re-learn delay on the link= . >>=20 >> 2. The linear controller that LEDBAT uses suggests that the congestion w= indow should be increased proportional to the change in one-way delay. This= is very good for responding quickly to changes in delay. But this can caus= e the window to increase at a faster rate than TCP would do with its probin= g mechanism using additive-increase. Although the maximum increase in windo= w is capped to be less than Best-effort TCP, the rate of increase can be mo= re. Does this concern anyone?=20 >>=20 >> Some of these decisions can be made implementation-specific. I think, it= will be good if there is some discussion about it. >>=20 >> Thanks, >> Padma >>=20 >>=20 >> On Jun 8, 2010, at 12:00 PM, ledbat-request@ietf.org wrote: >>=20 >> =09 >> Date: Tue, 8 Jun 2010 16:03:37 +0200 >> From: "Rolf Winter" >> Subject: [ledbat] Open issues, part 1 >> To: >> Message-ID: <547F018265F92642B577B986577D671C014B9A15@VENUS.office> >> Content-Type: text/plain; charset=3D"us-ascii" >> =09 >> Hi, >> =09 >> Here is the first Email in a series of Emails (to keep Email threats se= parate) which deal with open points in the congestion control draft. I pull= ed those together from various sources such as meeting minutes. I would lik= e have a documented agreement on them. If there are other open question ple= ase speak up. >> =09 >> 1. Parameters >> There were comments on the parameterization of the congestion control d= raft. The main concern was that they seem to come out of thin air. To close= this issue I'd like to ask the group whether they think the parameters are= sensible or not (e.g. 25ms delay target). It would be good to hear from pe= ople such as, say, game developers what they have to say about this target.= A better description of why these were chosen is surely something that sho= uld go into the text. >> =09 >> Best, >> =09 >> Rolf >> =09 >> NEC Europe Limited | Registered Office: NEC House, 1 Victoria Road, Lon= don W3 6BL | Registered in England 2832014=20 >> =09 >>=20 >>=20 >>=20 >=20 > _______________________________________________ > ledbat mailing list > ledbat@ietf.org > https://www.ietf.org/mailman/listinfo/ledbat >=20 >=20 From Rolf.Winter@neclab.eu Thu Jun 24 05:45:49 2010 Return-Path: X-Original-To: ledbat@core3.amsl.com Delivered-To: ledbat@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 5B3803A6955 for ; Thu, 24 Jun 2010 05:45:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.773 X-Spam-Level: X-Spam-Status: No, score=-1.773 tagged_above=-999 required=5 tests=[AWL=0.826, 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-yaV6THJqt2 for ; Thu, 24 Jun 2010 05:45:45 -0700 (PDT) Received: from smtp0.neclab.eu (smtp0.neclab.eu [195.37.70.41]) by core3.amsl.com (Postfix) with ESMTP id CC32A3A6851 for ; Thu, 24 Jun 2010 05:45:44 -0700 (PDT) Received: from localhost (localhost.localdomain [127.0.0.1]) by smtp0.neclab.eu (Postfix) with ESMTP id E45C82C000F05 for ; Thu, 24 Jun 2010 14:45:52 +0200 (CEST) X-Virus-Scanned: Amavisd on Debian GNU/Linux (atlas2.office) Received: from smtp0.neclab.eu ([127.0.0.1]) by localhost (atlas2.office [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id pxdDUP+6cbgG for ; Thu, 24 Jun 2010 14:45:52 +0200 (CEST) Received: from VENUS.office (mx1.office [192.168.24.3]) by smtp0.neclab.eu (Postfix) with ESMTP id C83C92C000C0F for ; Thu, 24 Jun 2010 14:45:47 +0200 (CEST) Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable X-MIMEOLE: Produced By Microsoft Exchange V6.5 Date: Thu, 24 Jun 2010 14:45:46 +0200 Message-ID: <547F018265F92642B577B986577D671C0152C318@VENUS.office> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Nomcom 2010-2011: Second Call for Volunteers Thread-index: AcsSXEWEF2joLN6xT2KS5SoRZzzk/gBPodYQ From: "Rolf Winter" To: Subject: [ledbat] FW: Nomcom 2010-2011: Second Call for Volunteers X-BeenThere: ledbat@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Mailing list of the LEDBAT WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 24 Jun 2010 12:45:49 -0000 Hi, please consider volunteering. Best, Rolf NEC Europe Limited | Registered Office: NEC House, 1 Victoria Road, = London W3 6BL | Registered in England 2832014=20 > From: NomCom Chair > Date: June 21, 2010 5:49:08 PM EDT > To: IETF Announcement list > Subject: Nomcom 2010-2011: Second Call for Volunteers > > Hi all, > > This is the Second call for Volunteers for the 2010-11 nomcom. We are > just about halfway through the volunteer period so if you are =20 > considering > volunteering please do so very soon. > > I am pleased to report that we have 29 volunteers thus far whose > qualifications have been confirmed by the secretariat. I have notified > each of these volunteers by email. > > If you volunteered before 08:00 PDT (15:00 UTC) on June 21 to serve =20 > as a > voting member and have not received a confirmation email from me, =20 > please > re-submit and bring to my attention right away! > > However, we need many more volunteers. You have until 17:00 PDT =20 > (24:00 > UTC) on July 8, 2010 to volunteer for nomcom but it is much better =20 > if you > volunteer as early as possible. The more volunteers, the better =20 > chance we > have of choosing a random yet representative cross section of the IETF > pouplation. > > As a reminder, volunteers must have attended 3 of the past 5 IETF > meetings - per RFC 3777, which means 3 of the following meetings: =20 > IETF-73, > IETF-74, IETF-75, IETF-76 and IETF-77. If you qualify, and are =20 > willing to > forgo appointment to any of the positions for which the nominating > committee is responsible, please volunteer. > > The 10 nominating committee members are selected randomly from a =20 > pool of > volunteers. The details of the operation of nomcom may be found in =20 > RFC > 3777. The process on how to volunteer for nomcom is in the initial > announcement: https://datatracker.ietf.org/ann/nomcom/2330/ > > The lists of open positions and people whose terms end in March 2011 =20 > and > thus the positions for which the nominating committee is responsible =20 > are > summarized in the initial announcement: > https://datatracker.ietf.org/ann/nomcom/2330/ > > The 29 volunteers who have thus far been qualified by the secretariat > are: > > Fred Baker, Cisco Systems > > Stephan Wenger, Vidyo, Inc. > > Marc Blanchet, Viagenie > > Lixia Zhang, UCLA > > John Drake, Juniper Networks > > Ole Troan, Cisco > > Jiankang Yao, CNNIC > > Wassim Haddad, Ericsson > > Yi Zhao, Huawei USA > > Teemu Savolainen, Nokia > > Jouni Korhonen, Nokia Siemens Networks > > Mehmet Ersue, Nokia Siemens Networks > > Christian Schmidt, Nokia Siemens Networks > > Stephen Hanna, Juniper Networks > > Suresh Krishnan, Ericsson > > Eric Gray, Ericsson > > David Sinicrope, Ericsson > > Jan Melen, Ericsson > > Richard Barnes, BBN Technologies > > Hugo Salgado Hernandez, NIC Chile > > Ning Zong, Huawei Technologies > > Qin Wu, Huawei Technologies > > Karen Seo, BBN Technologies > > Haibin Song, Huawei Technologies > > Susan Hares, Huawei Technologies > > Tony Hansen. AT&T Labs > > Fuqing Huang, Huawei Technologies Co., Ltd. > > Huub van Helvoort, Huawei Technologies > > Miya Kohno, Juniper Networks > > The primary activity for this nomcom will begin just prior to =20 > IETF-78 in > Maastricht and should be completed in early January 2011. The =20 > nomcom will > be collecting requirements from the community, as well as talking to > candidates and to community members about candidates. There will be =20 > weekly > conference calls to ensure progress. Thus, being a nomcom member does > require some time commitment. > > While, there is no requirement in RFC 3777 that a participant attend =20 > IETF > meetings while serving on nomcom, please consider that during the IETF > meetings, people that do not attend would be expected to remotely > participate during the day in the time zones of the meeting =20 > locations - > Maastricht at the end of July and Beijing in November. > > If you are not yet sure you would like to volunteer, please consider =20 > that > nomcom members play a very important role in shaping the leadership =20 > of the > IETF. Ensuring the leadership of the IETF is fair and balanced and > comprised of those who can lead the IETF in the right direction is an > important responsibility that rests on the IETF participants at large. > Volunteering for the nomcom is a good way of contributing in that > direction. > > Please volunteer by sending an email before: > 17:00 PDT (24:00 UTC) July 8, 2010 as follows: > > To: nomcom-chair@ietf.org > Subject: Nomcom 2010-11 Volunteer > > Please include the following information in the body: > > // As you enter in the IETF Registration Form, > // First/Given name followed by Last/Family Name > > > // typically what goes in the Company field > // in the IETF Registration Form > > [] > // > > // For confirmation if selected > > Please expect an email response from me within 3 days stating =20 > whether or > not you are qualified. If you don't receive a response, please re-=20 > send > your email with the tag "Duplicate:" added to the subject line. > > Thank you and I hope to hear from you, > > Thomas Walsh > Chair, Nomcom 2010-11 > Email: nomcom-chair@ietf.org > > > _______________________________________________ > IETF-Announce mailing list > IETF-Announce@ietf.org > https://www.ietf.org/mailman/listinfo/ietf-announce > From Rolf.Winter@neclab.eu Fri Jun 25 08:19:33 2010 Return-Path: X-Original-To: ledbat@core3.amsl.com Delivered-To: ledbat@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id D7A1D3A699C for ; Fri, 25 Jun 2010 08:19:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.532 X-Spam-Level: X-Spam-Status: No, score=-0.532 tagged_above=-999 required=5 tests=[AWL=-0.533, 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 90MgQpbzt2hc for ; Fri, 25 Jun 2010 08:19:33 -0700 (PDT) Received: from smtp0.neclab.eu (smtp0.neclab.eu [195.37.70.41]) by core3.amsl.com (Postfix) with ESMTP id C511A3A68FC for ; Fri, 25 Jun 2010 08:19:32 -0700 (PDT) Received: from localhost (localhost.localdomain [127.0.0.1]) by smtp0.neclab.eu (Postfix) with ESMTP id 117CA2C000C03 for ; Fri, 25 Jun 2010 17:19:41 +0200 (CEST) X-Virus-Scanned: Amavisd on Debian GNU/Linux (atlas2.office) Received: from smtp0.neclab.eu ([127.0.0.1]) by localhost (atlas2.office [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 21CgFMeF5icI for ; Fri, 25 Jun 2010 17:19:41 +0200 (CEST) Received: from VENUS.office (mx1.office [192.168.24.3]) by smtp0.neclab.eu (Postfix) with ESMTP id E8F6B2C000308 for ; Fri, 25 Jun 2010 17:19:35 +0200 (CEST) Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable X-MIMEOLE: Produced By Microsoft Exchange V6.5 Date: Fri, 25 Jun 2010 17:19:35 +0200 Message-ID: <547F018265F92642B577B986577D671C0152C499@VENUS.office> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Maastricht meeting Thread-index: AcsUedHGLvTgBBHVQ/+roFTfdfzUZw== From: "Rolf Winter" To: Subject: [ledbat] Maastricht meeting X-BeenThere: ledbat@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Mailing list of the LEDBAT WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 25 Jun 2010 15:19:34 -0000 Hi, Murari and I have talked and decided not to meet in Maastricht. = Nevertheless, I'd like to ask the document authors to update the = documents before the meeting and if people want to talk to us during the = meeting please send us an Email.=20 Rolf NEC Europe Limited | Registered Office: NEC House, 1 Victoria Road, = London W3 6BL | Registered in England 2832014=20