From Rolf.Winter@neclab.eu Fri Mar 4 01:19:47 2011 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 081883A696F for ; Fri, 4 Mar 2011 01:19:47 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.96 X-Spam-Level: X-Spam-Status: No, score=-101.96 tagged_above=-999 required=5 tests=[AWL=0.289, BAYES_00=-2.599, HELO_EQ_DE=0.35, 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 zHg-oCa14Fk0 for ; Fri, 4 Mar 2011 01:19:46 -0800 (PST) Received: from smtp0.netlab.nec.de (smtp0.netlab.nec.de [195.37.70.40]) by core3.amsl.com (Postfix) with ESMTP id 350C73A6942 for ; Fri, 4 Mar 2011 01:19:46 -0800 (PST) Received: from localhost (localhost.localdomain [127.0.0.1]) by smtp0.netlab.nec.de (Postfix) with ESMTP id 3037628000194 for ; Fri, 4 Mar 2011 10:22:11 +0100 (CET) X-Virus-Scanned: Amavisd on Debian GNU/Linux (atlas1.office.hd) Received: from smtp0.netlab.nec.de ([127.0.0.1]) by localhost (atlas1.office.hd [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 2DTi9Mby+tDb for ; Fri, 4 Mar 2011 10:22:11 +0100 (CET) Received: from METHONE.office.hd (Methone.office.hd [192.168.24.54]) by smtp0.netlab.nec.de (Postfix) with ESMTP id 14C7428000190 for ; Fri, 4 Mar 2011 10:22:06 +0100 (CET) Received: from DAPHNIS.office.hd ([169.254.2.136]) by METHONE.office.hd ([192.168.24.54]) with mapi id 14.01.0270.001; Fri, 4 Mar 2011 10:20:50 +0100 From: Rolf Winter To: Rolf Winter , "ledbat@ietf.org" Thread-Topic: LEDBAT WG last call on draft-ietf-ledbat-survey-05 Thread-Index: AcvOtgrL/lxgu3lMTJ2fixNnnXX9pALlywpw Date: Fri, 4 Mar 2011 09:20:47 +0000 Message-ID: <791AD3077F94194BB2BDD13565B6295D05DE3B0B@DAPHNIS.office.hd> References: <791AD3077F94194BB2BDD13565B6295D05DBB212@PALLENE.office.hd> In-Reply-To: <791AD3077F94194BB2BDD13565B6295D05DBB212@PALLENE.office.hd> Accept-Language: en-US, de-DE Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.1.6.28] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: Re: [ledbat] LEDBAT WG last call on draft-ietf-ledbat-survey-05 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 Mar 2011 09:19:47 -0000 Hi, this WG last call has ended. We have received no further comments and previ= ous comments have been addressed according to the reviewers. We will now pr= oceed with this document. Thanks everybody, The chairs 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 Rolf Winter > Sent: Donnerstag, 17. Februar 2011 16:19 > To: ledbat@ietf.org > Subject: [ledbat] LEDBAT WG last call on draft-ietf-ledbat-survey-05 >=20 > Working group, >=20 > this is to start a two week WG last call on "A Survey of Lower-than- > Best-Effort Transport Protocols" (draft-ietf-ledbat-survey-05). >=20 > Please send comments to the ledbat@ietf.org mailing list. >=20 > This working group last call ends on March 03, 2011. >=20 > The chairs. >=20 >=20 >=20 > NEC Europe Limited | Registered Office: NEC House, 1 Victoria Road, > London W3 6BL | Registered in England 2832014 >=20 >=20 > _______________________________________________ > ledbat mailing list > ledbat@ietf.org > https://www.ietf.org/mailman/listinfo/ledbat From lars.eggert@nokia.com Thu Mar 10 00:16:59 2011 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 42B6F3A6875 for ; Thu, 10 Mar 2011 00:16:59 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.256 X-Spam-Level: X-Spam-Status: No, score=-103.256 tagged_above=-999 required=5 tests=[AWL=0.343, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ZIsMoBsQ5Kxt for ; Thu, 10 Mar 2011 00:16:58 -0800 (PST) Received: from mgw-da01.nokia.com (smtp.nokia.com [147.243.128.24]) by core3.amsl.com (Postfix) with ESMTP id 31DE73A68C6 for ; Thu, 10 Mar 2011 00:16:58 -0800 (PST) Received: from mail.fit.nokia.com (esdhcp030222.research.nokia.com [172.21.30.222]) by mgw-da01.nokia.com (Switch-3.4.3/Switch-3.4.3) with ESMTP id p2A8ICFG002668 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Thu, 10 Mar 2011 10:18:14 +0200 From: Lars Eggert X-Virus-Status: Clean X-Virus-Scanned: clamav-milter 0.97 at fit.nokia.com Content-Type: multipart/signed; boundary=Apple-Mail-3--684661459; protocol="application/pkcs7-signature"; micalg=sha1 Date: Thu, 10 Mar 2011 10:18:05 +0200 Message-Id: <64367B0E-2375-46C4-8EE8-7791E9DC06A7@nokia.com> To: ledbat@ietf.org Mime-Version: 1.0 (Apple Message framework v1082) X-Mailer: Apple Mail (2.1082) X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.2.6 (mail.fit.nokia.com); Thu, 10 Mar 2011 10:18:10 +0200 (EET) X-Nokia-AV: Clean Subject: [ledbat] AD review: draft-ietf-ledbat-congestion-05 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 Mar 2011 08:16:59 -0000 --Apple-Mail-3--684661459 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii High-level comment: Ready for IETF last call. Take the comments below as = IETF last call comments. Lars > Internet-Draft LBE Transport Survey February = 2011 Nit: It's not super-great to have the LBE acronym in the footer. Section 1., paragraph 3: > This document is a product of the Low Extra Delay Background > Transport (LEDBAT) Working Group. It aims at putting the = congestion > control algorithm that the working group is specifying in the = context > of the state of the art in LBE transport. Most techniques = discussed > here were tested in limited simulations or experimental testbeds, = but > the LEDBAT algorithm is already widely deployed. It's not fully clear if "the LEDBAT algorithm" is still very similar to what has been shipping in BitTorrent. It may therefore be better to rephrase this and say that "an algorithm that is very similar to the initial proposal for LEDBAT has been shipping" or something like that. Also, you should really cite draft-ietf-ledbat-congestion when you talk about the LEDBAT algorithm (it currently isn't cited at all...) Section 2., paragraph 7: > seen during the connections's lifetime; if it does, this condition = is Nit: s/connections's/connection's/ Section 2.1., paragraph 3: > interest, and it can underly fluctuations that are not related = to Nit: s/underly/undergo/ Section 6., paragraph 1: > The previous sections have shown that there is a large amount of = work > on attaining an LBE service, and that it is quite heterogeneous in > nature. What most of the discussed mechanisms have in common, > however, is the fact that they have only been tested in limited > simulations or experimental testbeds. As we have initially stated, > the algorithm produced by the LEDBAT Working Group (which is itself > also called LEDBAT) is already under widespread deployment. See previous comment on Section 1. --Apple-Mail-3--684661459 Content-Disposition: attachment; filename=smime.p7s Content-Type: application/pkcs7-signature; name=smime.p7s Content-Transfer-Encoding: base64 MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIMRjCCBVAw ggQ4oAMCAQICEGxdPUZzCwUJ8KBiJwH+bYgwDQYJKoZIhvcNAQEFBQAwgd0xCzAJBgNVBAYTAlVT MRcwFQYDVQQKEw5WZXJpU2lnbiwgSW5jLjEfMB0GA1UECxMWVmVyaVNpZ24gVHJ1c3QgTmV0d29y azE7MDkGA1UECxMyVGVybXMgb2YgdXNlIGF0IGh0dHBzOi8vd3d3LnZlcmlzaWduLmNvbS9ycGEg KGMpMDkxHjAcBgNVBAsTFVBlcnNvbmEgTm90IFZhbGlkYXRlZDE3MDUGA1UEAxMuVmVyaVNpZ24g Q2xhc3MgMSBJbmRpdmlkdWFsIFN1YnNjcmliZXIgQ0EgLSBHMzAeFw0xMDEwMTUwMDAwMDBaFw0x MTEwMTUyMzU5NTlaMIIBEzEXMBUGA1UEChMOVmVyaVNpZ24sIEluYy4xHzAdBgNVBAsTFlZlcmlT aWduIFRydXN0IE5ldHdvcmsxRjBEBgNVBAsTPXd3dy52ZXJpc2lnbi5jb20vcmVwb3NpdG9yeS9S UEEgSW5jb3JwLiBieSBSZWYuLExJQUIuTFREKGMpOTgxHjAcBgNVBAsTFVBlcnNvbmEgTm90IFZh bGlkYXRlZDEzMDEGA1UECxMqRGlnaXRhbCBJRCBDbGFzcyAxIC0gTmV0c2NhcGUgRnVsbCBTZXJ2 aWNlMRQwEgYDVQQDFAtMYXJzIEVnZ2VydDEkMCIGCSqGSIb3DQEJARYVbGFycy5lZ2dlcnRAbm9r aWEuY29tMIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAwolKEyOz/NQZJJlw0x9XBS9W wCmabdY1fXpbWSdcaJiEWhQpRzSIC/pgIwCgaUW9g3JsWioXCawyjUVeg8xR42sR690f4z+OPAUm 3jokZxsuRaGX6fuPkPQomYAGz7htUHws/8FZIU+4dciETQf4vF5ptitJ+QZCVRCTLqisj6mG/kG4 65Op3G5/YZF9F/a390LdhuRP6vdY2Y+dqm8LDa0zmENPpoE98u1pIZGqCcnskN/nNBtEPd+a4lNh ZSGnPuL4XCUSJYR9NB7FAYBvi5N7LSWHR3fspwa5EgpXynJcsLzaLA0iGfjFOBYFxul/07edmyw4 FIXuCIkaMDUfEwIDAQABo4HSMIHPMAkGA1UdEwQCMAAwRAYDVR0gBD0wOzA5BgtghkgBhvhFAQcX ATAqMCgGCCsGAQUFBwIBFhxodHRwczovL3d3dy52ZXJpc2lnbi5jb20vcnBhMAsGA1UdDwQEAwIF oDAdBgNVHSUEFjAUBggrBgEFBQcDBAYIKwYBBQUHAwIwUAYDVR0fBEkwRzBFoEOgQYY/aHR0cDov L2luZGMxZGlnaXRhbGlkLWczLWNybC52ZXJpc2lnbi5jb20vSW5kQzFEaWdpdGFsSUQtRzMuY3Js MA0GCSqGSIb3DQEBBQUAA4IBAQAlSTzUKqa3ZouKWFQfIJ+4l/KsztPnY4Onwzt8lqAmeiFPqOmf kLTXbXDKtC6caFadNtyHpnsmQFFKXwhe5Z9/AaVSwryu6F9992DzYLp3j8PE0DSU0wmpUXUtp+rz TFqJRkzB8RCBoq/TPBmkMPr68qB0TkU3dbYiVIvscOt1MRkdHiwG4wKQLyCf8XRRWqmMY6lbun7g kiEWiris5StGKRvE5+e1SrcdnoZxIKQFF7Etr+4ftClrsDQWX9nRCEjYcmz4y/deq+HU8ylBaKZE 0ZJmcnYlAaD50OYWi0ckGDnKYyeMUEtCZJSV0otm2LqyIUAu9WPv/GNHt2ntjnUaMIIG7jCCBdag AwIBAgIQcRVmBUrkkSFN6bxE+azT3DANBgkqhkiG9w0BAQUFADCByjELMAkGA1UEBhMCVVMxFzAV BgNVBAoTDlZlcmlTaWduLCBJbmMuMR8wHQYDVQQLExZWZXJpU2lnbiBUcnVzdCBOZXR3b3JrMTow OAYDVQQLEzEoYykgMTk5OSBWZXJpU2lnbiwgSW5jLiAtIEZvciBhdXRob3JpemVkIHVzZSBvbmx5 MUUwQwYDVQQDEzxWZXJpU2lnbiBDbGFzcyAxIFB1YmxpYyBQcmltYXJ5IENlcnRpZmljYXRpb24g QXV0aG9yaXR5IC0gRzMwHhcNMDkwNTAxMDAwMDAwWhcNMTkwNDMwMjM1OTU5WjCB3TELMAkGA1UE BhMCVVMxFzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMR8wHQYDVQQLExZWZXJpU2lnbiBUcnVzdCBO ZXR3b3JrMTswOQYDVQQLEzJUZXJtcyBvZiB1c2UgYXQgaHR0cHM6Ly93d3cudmVyaXNpZ24uY29t L3JwYSAoYykwOTEeMBwGA1UECxMVUGVyc29uYSBOb3QgVmFsaWRhdGVkMTcwNQYDVQQDEy5WZXJp U2lnbiBDbGFzcyAxIEluZGl2aWR1YWwgU3Vic2NyaWJlciBDQSAtIEczMIIBIjANBgkqhkiG9w0B AQEFAAOCAQ8AMIIBCgKCAQEA7cRH3yooHXwGa7vXITLJbBOP6bGNQU4099oL42r6ZYggCxET6Zvg SU6Lb9UB0F8NR5GKWkx0Pj/GkQm7TDSejW6hglFi92l2WJYHr54UGAdPWr2f0jGyVBlzRmoZQhHs EnMhjfXcMM3l2VYKMcU2bSkUl70t2olHGYjYSwQ967Y8Zx50ABMN0Ibak2f4MwOuGjxraXj2wCyO 4YM/d/mZ//6fUlrCtIcK2GypR8FUKWVDPkrAlh/Brfd3r2yxBF6+wbaULZeQLSfSux7pg2qE9sSy riMGZSalJ1grByK0b6ZiSBp38tVQJ5op05b7KPW6JHZi44xZ6/tu1ULEvkHH9QIDAQABo4ICuTCC ArUwNAYIKwYBBQUHAQEEKDAmMCQGCCsGAQUFBzABhhhodHRwOi8vb2NzcC52ZXJpc2lnbi5jb20w EgYDVR0TAQH/BAgwBgEB/wIBADBwBgNVHSAEaTBnMGUGC2CGSAGG+EUBBxcBMFYwKAYIKwYBBQUH AgEWHGh0dHBzOi8vd3d3LnZlcmlzaWduLmNvbS9jcHMwKgYIKwYBBQUHAgIwHhocaHR0cHM6Ly93 d3cudmVyaXNpZ24uY29tL3JwYTA0BgNVHR8ELTArMCmgJ6AlhiNodHRwOi8vY3JsLnZlcmlzaWdu LmNvbS9wY2ExLWczLmNybDAOBgNVHQ8BAf8EBAMCAQYwbgYIKwYBBQUHAQwEYjBgoV6gXDBaMFgw VhYJaW1hZ2UvZ2lmMCEwHzAHBgUrDgMCGgQUS2u5KJYGDLvQUjibKaxLB4shBRgwJhYkaHR0cDov L2xvZ28udmVyaXNpZ24uY29tL3ZzbG9nbzEuZ2lmMC4GA1UdEQQnMCWkIzAhMR8wHQYDVQQDExZQ cml2YXRlTGFiZWw0LTIwNDgtMTE4MB0GA1UdDgQWBBR5R2EIQf04BKJL57XM9UP2SSsR+DCB8QYD VR0jBIHpMIHmoYHQpIHNMIHKMQswCQYDVQQGEwJVUzEXMBUGA1UEChMOVmVyaVNpZ24sIEluYy4x HzAdBgNVBAsTFlZlcmlTaWduIFRydXN0IE5ldHdvcmsxOjA4BgNVBAsTMShjKSAxOTk5IFZlcmlT aWduLCBJbmMuIC0gRm9yIGF1dGhvcml6ZWQgdXNlIG9ubHkxRTBDBgNVBAMTPFZlcmlTaWduIENs YXNzIDEgUHVibGljIFByaW1hcnkgQ2VydGlmaWNhdGlvbiBBdXRob3JpdHkgLSBHM4IRAItbdVaE VIULAM+vOEjOsaQwDQYJKoZIhvcNAQEFBQADggEBADlNz0GZgbWpBbVSOOk5hIls5DSoWufYbAlM JBq6WaSHO3Mh8ZOBz79oY1pn/jWFK6HDXaNKwjoZ3TDWzE3v8dKBl8pUWkO/N4t6jhmND0OojPKv YLMVirOVnDzgnrMnmKQ1chfl/Cpdh9OKDcLRRSr4wPSsKpM61a4ScAjr+zvid+zoK2Q1ds262uDR yxTWcVibvtU+fbbZ6CTFJGZMXZEfdrMXPn8NxiGJL7M3uKH/XLJtSd5lUkL7DojS7Uodv0vj+Mxy +kgOZY5JyNb4mZg7t5Q+MXEGh/psWVMu198r7V9jAKwV7QO4VRaMxmgD5yKocwuxvKDaUljdCg5/ wYIxggSLMIIEhwIBATCB8jCB3TELMAkGA1UEBhMCVVMxFzAVBgNVBAoTDlZlcmlTaWduLCBJbmMu MR8wHQYDVQQLExZWZXJpU2lnbiBUcnVzdCBOZXR3b3JrMTswOQYDVQQLEzJUZXJtcyBvZiB1c2Ug YXQgaHR0cHM6Ly93d3cudmVyaXNpZ24uY29tL3JwYSAoYykwOTEeMBwGA1UECxMVUGVyc29uYSBO b3QgVmFsaWRhdGVkMTcwNQYDVQQDEy5WZXJpU2lnbiBDbGFzcyAxIEluZGl2aWR1YWwgU3Vic2Ny aWJlciBDQSAtIEczAhBsXT1GcwsFCfCgYicB/m2IMAkGBSsOAwIaBQCgggJtMBgGCSqGSIb3DQEJ AzELBgkqhkiG9w0BBwEwHAYJKoZIhvcNAQkFMQ8XDTExMDMxMDA4MTgwNlowIwYJKoZIhvcNAQkE MRYEFOaLBaTICCQ8n8GFfV9Jzwa8FO48MIIBAwYJKwYBBAGCNxAEMYH1MIHyMIHdMQswCQYDVQQG EwJVUzEXMBUGA1UEChMOVmVyaVNpZ24sIEluYy4xHzAdBgNVBAsTFlZlcmlTaWduIFRydXN0IE5l dHdvcmsxOzA5BgNVBAsTMlRlcm1zIG9mIHVzZSBhdCBodHRwczovL3d3dy52ZXJpc2lnbi5jb20v cnBhIChjKTA5MR4wHAYDVQQLExVQZXJzb25hIE5vdCBWYWxpZGF0ZWQxNzA1BgNVBAMTLlZlcmlT aWduIENsYXNzIDEgSW5kaXZpZHVhbCBTdWJzY3JpYmVyIENBIC0gRzMCEGxdPUZzCwUJ8KBiJwH+ bYgwggEFBgsqhkiG9w0BCRACCzGB9aCB8jCB3TELMAkGA1UEBhMCVVMxFzAVBgNVBAoTDlZlcmlT aWduLCBJbmMuMR8wHQYDVQQLExZWZXJpU2lnbiBUcnVzdCBOZXR3b3JrMTswOQYDVQQLEzJUZXJt cyBvZiB1c2UgYXQgaHR0cHM6Ly93d3cudmVyaXNpZ24uY29tL3JwYSAoYykwOTEeMBwGA1UECxMV UGVyc29uYSBOb3QgVmFsaWRhdGVkMTcwNQYDVQQDEy5WZXJpU2lnbiBDbGFzcyAxIEluZGl2aWR1 YWwgU3Vic2NyaWJlciBDQSAtIEczAhBsXT1GcwsFCfCgYicB/m2IMA0GCSqGSIb3DQEBAQUABIIB AGcQpy91AkKHwG5XjWMqJU6OZ2xFYK4Z2C6Ti/JfNm7A/8Tp0qzBNxUDjQjuOPIIvVf8xalxSWbn vA3EhhvbhVcO2chtS2nnQnC/YsWSmHYJ3DQeuMT7eDD29Tx+5s8AVO7NYKe4m9i2Sr8wGA2jLpgY 9BQB1fXrQg4R28bljC8Oy/Lvbw89BqD5l/z4SnU0qH3uGYikfskF0FfEovoPwIs3nI6Ddq6gcjvg dMd6/8muik7VsNv/TDSWXqT0HA6djBQA+7jbt6VmgYJCvTUBL1EUqA5Y/3NZBNcClhugZZPt5gWr cqNdsTz2Mg39hjl4WYa+4SUc8LIVbGElpjsE+lEAAAAAAAA= --Apple-Mail-3--684661459-- From iesg-secretary@ietf.org Thu Mar 10 06:18:08 2011 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 030AC3A6AA5; Thu, 10 Mar 2011 06:18:08 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.543 X-Spam-Level: X-Spam-Status: No, score=-102.543 tagged_above=-999 required=5 tests=[AWL=0.056, BAYES_00=-2.599, 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 BoR96V9m2DDa; Thu, 10 Mar 2011 06:18:07 -0800 (PST) Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 61DA23A69B0; Thu, 10 Mar 2011 06:18:07 -0800 (PST) Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit From: The IESG To: IETF-Announce X-Test-IDTracker: no X-IETF-IDTracker: 3.12 Message-ID: <20110310141807.26311.80558.idtracker@localhost> Date: Thu, 10 Mar 2011 06:18:07 -0800 Cc: ledbat@ietf.org Subject: [ledbat] Last Call: (A Survey of Lower-than-Best-Effort Transport Protocols) to Informational RFC X-BeenThere: ledbat@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: ietf@ietf.org List-Id: Mailing list of the LEDBAT WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 10 Mar 2011 14:18:08 -0000 The IESG has received a request from the Low Extra Delay Background Transport WG (ledbat) to consider the following document: - 'A Survey of Lower-than-Best-Effort Transport Protocols' as an Informational RFC The IESG plans to make a decision in the next few weeks, and solicits final comments on this action. Please send substantive comments to the ietf@ietf.org mailing lists by 2011-03-24. Exceptionally, comments may be sent to iesg@ietf.org instead. In either case, please retain the beginning of the Subject line to allow automated sorting. The file can be obtained via http://datatracker.ietf.org/doc/draft-ietf-ledbat-survey/ IESG discussion can be tracked via http://datatracker.ietf.org/doc/draft-ietf-ledbat-survey/ No IPR declarations have been submitted directly on this I-D. From jana.iyengar@gmail.com Tue Mar 15 14:52:18 2011 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 37AA93A6EF2 for ; Tue, 15 Mar 2011 14:52:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.599 X-Spam-Level: X-Spam-Status: No, score=-3.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id SkEgCeyQICJL for ; Tue, 15 Mar 2011 14:52:16 -0700 (PDT) Received: from mail-qy0-f179.google.com (mail-qy0-f179.google.com [209.85.216.179]) by core3.amsl.com (Postfix) with ESMTP id A00E73A6BAC for ; Tue, 15 Mar 2011 14:52:16 -0700 (PDT) Received: by qyk7 with SMTP id 7so901177qyk.10 for ; Tue, 15 Mar 2011 14:53:41 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:message-id:date:from:reply-to:organization :user-agent:mime-version:to:cc:subject:content-type :content-transfer-encoding; bh=ACKeN/7CzLE2NHaJdd3KwNRPkH7XyF1y4/ZvB3kXDDU=; b=pnUoncT7EL4qXS2ErjGv2eod54cOm80oC7vDsUyY2GePSgkqlNhFBfcZgQ21Ah9Oz0 TPII/GE/F60e0LAL8sU7NMPtiyfDGyD+k2YgIZQn0dKs7wWfoMCUMRsdToZCpEEfSTM5 Pj4M71rt48q6a2Dv71prpNulpWIasi9W/Gd1c= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=message-id:date:from:reply-to:organization:user-agent:mime-version :to:cc:subject:content-type:content-transfer-encoding; b=ZahlRBD/UdnCaUyp0es2YTyOciw/PqgHjsKy7vZtXZtqpk6aujzQoqxqbJ63wNcHf6 EWbdmESX+x/7yQIcLK9iCc8jQFFYGimLtHLb4pIWM55ac+cQ2B8+MBDIVJB/Y4MebtRF CVIUWncndNDWwlupmxOLRO6FZAZeg5fDH2Q8Q= Received: by 10.229.99.80 with SMTP id t16mr38229qcn.73.1300226021730; Tue, 15 Mar 2011 14:53:41 -0700 (PDT) Received: from surutti.fandm.edu (50-32-6-52.drr01.hrbg.pa.frontiernet.net [50.32.6.52]) by mx.google.com with ESMTPS id s9sm198355qco.24.2011.03.15.14.53.40 (version=TLSv1/SSLv3 cipher=OTHER); Tue, 15 Mar 2011 14:53:41 -0700 (PDT) Message-ID: <4D7FDFE3.6000003@fandm.edu> Date: Tue, 15 Mar 2011 17:53:39 -0400 From: Janardhan Iyengar Organization: Franklin & Marshall College User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.6; en-US; rv:1.9.2.15) Gecko/20110303 Lightning/1.0b2 Thunderbird/3.1.9 MIME-Version: 1.0 To: ledbat@ietf.org Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: "Rolf Winter \(Rolf.Winter@neclab.eu\)" Subject: [ledbat] NEW! draft-ietf-ledbat-congestion-04 X-BeenThere: ledbat@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: janardhan.iyengar@fandm.edu List-Id: Mailing list of the LEDBAT WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 15 Mar 2011 21:52:18 -0000 Dear all, The latest version of draft-ietf-ledbat-congestion (-04) is now available at http://datatracker.ietf.org/doc/draft-ietf-ledbat-congestion/. Besides editorial changes (some significant) to make the language consistent and precise, specific content changes in -04 from -03 are listed below. 1. LEDBAT now includes bytes_newly_acked as a variable that is taken into account in the cwnd computations, -> similar to ABC for TCP, and -> to reduce differences in behavior due to differences in framing. 2. off_target changed to off_target = (TARGET - queuing_delay) / TARGET -> This ensures that GAIN = 1 (or less) actually limits the cwnd to rampup not faster than standard TCP in congestion avoidance 3. A LEDBAT sender clamps down its cwnd if the sender has a "data lull"--the cwnd is clamped down to flightsize ("use-it-or-lose-it"). ->This makes sense for LEDBAT since performance is not the highest priority concern. 4. random_input() removed -> see discussion on the list 5. INIT_CWND and MIN_CWND params introduced, and param values finalized. -> see discussion in '3.5. Parameter Values' 6. Further discussion in '5.3. Fairness Among LEDBAT Flows' on random fluctuations in inter-packet transmission and late-comer's advantage. We think the draft is close to getting done. Please read the draft and send comments to the list! (We'll let the chairs push for going towards WGLC as they see appropriate, but we would like to see it go there as quickly as it can.) Thanks, Jana and Mirja -- Janardhan Iyengar Assistant Professor, Computer Science Franklin & Marshall College http://www.fandm.edu/jiyengar From Rolf.Winter@neclab.eu Wed Mar 16 05:42:34 2011 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 885223A68EA for ; Wed, 16 Mar 2011 05:42:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.361 X-Spam-Level: X-Spam-Status: No, score=-102.361 tagged_above=-999 required=5 tests=[AWL=0.238, BAYES_00=-2.599, 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 JKhYsqxp9i4E for ; Wed, 16 Mar 2011 05:42:33 -0700 (PDT) Received: from smtp0.neclab.eu (smtp0.neclab.eu [195.37.70.41]) by core3.amsl.com (Postfix) with ESMTP id 2FCE33A67FA for ; Wed, 16 Mar 2011 05:42:33 -0700 (PDT) Received: from localhost (localhost.localdomain [127.0.0.1]) by smtp0.neclab.eu (Postfix) with ESMTP id 1EA3B2C0002EF; Wed, 16 Mar 2011 13:45:55 +0100 (CET) X-Virus-Scanned: Amavisd on Debian GNU/Linux (atlas2.office.hd) Received: from smtp0.neclab.eu ([127.0.0.1]) by localhost (atlas2.office.hd [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id p2CPuNX36Vv1; Wed, 16 Mar 2011 13:45:55 +0100 (CET) Received: from ENCELADUS.office.hd (ENCELADUS.office.hd [192.168.24.52]) by smtp0.neclab.eu (Postfix) with ESMTP id 01F352C000202; Wed, 16 Mar 2011 13:45:35 +0100 (CET) Received: from DAPHNIS.office.hd ([169.254.2.136]) by ENCELADUS.office.hd ([192.168.24.52]) with mapi id 14.01.0270.001; Wed, 16 Mar 2011 13:43:39 +0100 From: Rolf Winter To: "janardhan.iyengar@fandm.edu" , "ledbat@ietf.org" Thread-Topic: NEW! draft-ietf-ledbat-congestion-04 Thread-Index: AQHL41t3pOUytc6nmEWMQbc8R4StfpQv58/Q Date: Wed, 16 Mar 2011 12:43:39 +0000 Message-ID: <791AD3077F94194BB2BDD13565B6295D05DEB661@DAPHNIS.office.hd> References: <4D7FDFE3.6000003@fandm.edu> In-Reply-To: <4D7FDFE3.6000003@fandm.edu> Accept-Language: en-US, de-DE Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.1.6.28] Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: Re: [ledbat] NEW! draft-ietf-ledbat-congestion-04 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 Mar 2011 12:42:34 -0000 Thanks Mirja and Jana, With you two aboard, the congestion control draft is making some real progr= ess again. WG please review the draft! We would like to last call this draf= t soon. Given the new content and the upcoming meeting, this will likely be= sometime soon after the Prague meeting. Best, Rolf NEC Europe Limited | Registered Office: NEC House, 1 Victoria Road, London = W3 6BL | Registered in England 2832014=20 > -----Original Message----- > From: Janardhan Iyengar [mailto:jana.iyengar@gmail.com] > Sent: Dienstag, 15. M=E4rz 2011 22:54 > To: ledbat@ietf.org > Cc: Mirja Kuehlewind; Rolf Winter; Murari Sridharan > Subject: NEW! draft-ietf-ledbat-congestion-04 >=20 > Dear all, >=20 > The latest version of draft-ietf-ledbat-congestion (-04) is now > available at http://datatracker.ietf.org/doc/draft-ietf-ledbat- > congestion/. > Besides editorial changes (some significant) to make the language > consistent and precise, specific content changes in -04 from -03 are > listed below. >=20 > 1. LEDBAT now includes bytes_newly_acked as a variable that is taken > into account in the cwnd computations, > -> similar to ABC for TCP, and > -> to reduce differences in behavior due to differences in framing. >=20 > 2. off_target changed to off_target =3D (TARGET - queuing_delay) / TARGET > -> This ensures that GAIN =3D 1 (or less) actually limits the cwnd to > rampup not faster than standard TCP in congestion avoidance >=20 > 3. A LEDBAT sender clamps down its cwnd if the sender has a "data > lull"--the cwnd is clamped down to flightsize ("use-it-or-lose-it"). > ->This makes sense for LEDBAT since performance is not the highest > priority concern. >=20 > 4. random_input() removed > -> see discussion on the list >=20 > 5. INIT_CWND and MIN_CWND params introduced, and param values finalized. > -> see discussion in '3.5. Parameter Values' >=20 > 6. Further discussion in '5.3. Fairness Among LEDBAT Flows' on random > fluctuations in inter-packet transmission and late-comer's advantage. >=20 > We think the draft is close to getting done. Please read the draft and > send comments to the list! > (We'll let the chairs push for going towards WGLC as they see > appropriate, but we would like to see it go there as quickly as it > can.) >=20 > Thanks, > Jana and Mirja >=20 > -- > Janardhan Iyengar > Assistant Professor, Computer Science > Franklin & Marshall College > http://www.fandm.edu/jiyengar From Rolf.Winter@neclab.eu Fri Mar 18 00:02:31 2011 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 EF8F13A6AE8 for ; Fri, 18 Mar 2011 00:02:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.198 X-Spam-Level: X-Spam-Status: No, score=-102.198 tagged_above=-999 required=5 tests=[AWL=0.051, BAYES_00=-2.599, HELO_EQ_DE=0.35, 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 9PmbpY2P9wT8 for ; Fri, 18 Mar 2011 00:02:31 -0700 (PDT) Received: from smtp0.netlab.nec.de (smtp0.netlab.nec.de [195.37.70.40]) by core3.amsl.com (Postfix) with ESMTP id DAEC03A6AD6 for ; Fri, 18 Mar 2011 00:02:30 -0700 (PDT) Received: from localhost (localhost.localdomain [127.0.0.1]) by smtp0.netlab.nec.de (Postfix) with ESMTP id BB4DB2800018C for ; Fri, 18 Mar 2011 08:05:15 +0100 (CET) X-Virus-Scanned: Amavisd on Debian GNU/Linux (atlas1.office.hd) Received: from smtp0.netlab.nec.de ([127.0.0.1]) by localhost (atlas1.office.hd [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 3vTrnBPG+HAR for ; Fri, 18 Mar 2011 08:05:15 +0100 (CET) Received: from METHONE.office.hd (Methone.office.hd [192.168.24.54]) by smtp0.netlab.nec.de (Postfix) with ESMTP id 9E2E428000171 for ; Fri, 18 Mar 2011 08:05:10 +0100 (CET) Received: from DAPHNIS.office.hd ([169.254.2.136]) by METHONE.office.hd ([192.168.24.54]) with mapi id 14.01.0270.001; Fri, 18 Mar 2011 08:03:53 +0100 From: Rolf Winter To: "ledbat@ietf.org" Thread-Topic: Gen-art review of draft-ietf-ledbat-survey-05 Thread-Index: AQHL5PFPfrUgTtvi9EqPiXt9d4nV8JQyq1Kg Date: Fri, 18 Mar 2011 07:03:53 +0000 Message-ID: <791AD3077F94194BB2BDD13565B6295D05DEBEBC@DAPHNIS.office.hd> Accept-Language: en-US, de-DE Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.7.0.198] Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: [ledbat] FW: Gen-art review of draft-ietf-ledbat-survey-05 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, 18 Mar 2011 07:02:32 -0000 FYI. NEC Europe Limited | Registered Office: NEC House, 1 Victoria Road, London = W3 6BL | Registered in England 2832014=20 > -----Original Message----- > From: Elwyn Davies [mailto:elwynd@folly.org.uk] > Sent: Donnerstag, 17. M=E4rz 2011 23:21 > To: General Area Review Team > Cc: draft-ietf-ledbat-survey.all@tools.ietf.org > Subject: Gen-art review of draft-ietf-ledbat-survey-05 >=20 > I am the assigned Gen-ART reviewer for this draft. For background on > Gen-ART, please see the FAQ at > . >=20 > Please resolve these comments along with any other Last Call comments > you may receive. >=20 > Document: draft-ietf-ledbat-survey-05.txt > Reviewer: Elwyn Davies > Review Date: 17 March 2011 > IETF LC End Date:24 March 2011 > IESG Telechat date: (if known) - >=20 > Summary: I don't have any major problems with the survey of other work > - I can't say if it is really complete and accurate or deals with the > most relevant poroposals but it seems a good piece of work apart form > one rather cavalier set of statements at the beginning of Section 2. >=20 > However there is a bit of a Catch 22: LEDBAT's own proposal is still a > work in progress but in both sections 1 and 6 there are cryptic > references to its status as a real network deployed mechanism as > compared with the simulations and testbed network deployments used to > characterize the majority of the surveyed, and to the mechanisms which > it uses. In neither case are any references adduced. >=20 > Clearly there is a problem if the LEDBAT WG want this document > published > as an RFC before the LEDBAT mechanism is finalized - referencing the > definitive LEDBAT draft will not be helpful here, but on the other hand > it would be useful either to have some sort of way of (a) justifying > the > implicit assumption of LEDBAT's superiority in Section 1 and (b) > pointing to some work that justifies the approach taken in LEDBAT other > than the comparative studies noted (which may not be comparing against > the current LEDBAT proposal as is noted in the draft), or if > appropriate > references cannot be found, then adjusting the language to be more > neutral in Section 1 and more explicative in Section 6. >=20 > Major issues: > None >=20 > Minor issues: > s2, para 1: > > In the absence of > > any other traffic, this is even true for TCP itself when its > maximum > > send window is limited to the bandwidth*round-trip time (RTT) > > product. > Some evidence for this in the form of a reference would be desirable. >=20 > Nits/editorial comments: > s2, para 1: expand ECN. From ingemar.s.johansson@ericsson.com Mon Mar 21 06:20:45 2011 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 155BB3A685D for ; Mon, 21 Mar 2011 06:20:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id iBkqFfeypaMP for ; Mon, 21 Mar 2011 06:20:42 -0700 (PDT) Received: from mailgw9.se.ericsson.net (mailgw9.se.ericsson.net [193.180.251.57]) by core3.amsl.com (Postfix) with ESMTP id 947F03A684D for ; Mon, 21 Mar 2011 06:20:38 -0700 (PDT) X-AuditID: c1b4fb39-b7c6dae0000023f2-47-4d87510192be Received: from esessmw0247.eemea.ericsson.se (Unknown_Domain [153.88.253.125]) by mailgw9.se.ericsson.net (Symantec Mail Security) with SMTP id 55.7B.09202.101578D4; Mon, 21 Mar 2011 14:22:10 +0100 (CET) Received: from ESESSCMS0366.eemea.ericsson.se ([169.254.1.230]) by esessmw0247.eemea.ericsson.se ([10.2.3.116]) with mapi; Mon, 21 Mar 2011 14:22:09 +0100 From: Ingemar Johansson S To: "ledbat@ietf.org" Date: Mon, 21 Mar 2011 14:22:07 +0100 Thread-Topic: Reaction to packet drops Thread-Index: AcvfXoMJN0khFfymTUOPBxWr2sKLvgIawxhA Message-ID: References: In-Reply-To: Accept-Language: sv-SE, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: sv-SE, en-US Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Brightmail-Tracker: AAAAAA== Subject: [ledbat] Reaction to packet drops 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, 21 Mar 2011 13:20:45 -0000 Hi I have a question on the latest version of=20 http://tools.ietf.org/wg/ledbat/draft-ietf-ledbat-congestion/ If I get things right LEDBAT should react to packet drops in the same was a= s TCP Reno.=20 For some reason I get the feeling that it is more reasonable to react more = than TCP reno even to packet drops and that this can also be controlled by = the GAIN parameter. The reason I can bring up is that in the strive to redu= ce buffer bloat it is more likely that packet dops are used to signal conge= stion which means that the delay increase may be very small.=20 So if the GAIN parameter is also included in the cwnd calculation when pack= et drops occur then the delay and packet drop sensing algos would complemen= t one another. I guess this has probably been discussed earlier ? /Ingemar =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D INGEMAR JOHANSSON M.Sc.=20 Senior Researcher Ericsson AB Wireless Area Networks Labratoriegr=E4nd 11 971 28, Lule=E5, Sweden Phone +46-1071 43042 SMS/MMS +46-73 078 3289 ingemar.s.johansson@ericsson.com www.ericsson.com Visit http://labs.ericsson.com ! =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D From mirja.kuehlewind@ikr.uni-stuttgart.de Mon Mar 21 08:09:49 2011 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 C23FF28C15D for ; Mon, 21 Mar 2011 08:09:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.096 X-Spam-Level: X-Spam-Status: No, score=-2.096 tagged_above=-999 required=5 tests=[AWL=0.153, BAYES_00=-2.599, HELO_EQ_DE=0.35] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id MXVKyTQBbxL6 for ; Mon, 21 Mar 2011 08:09:48 -0700 (PDT) Received: from mailsrv.ikr.uni-stuttgart.de (mailsrv.ikr.uni-stuttgart.de [129.69.170.2]) by core3.amsl.com (Postfix) with ESMTP id 0DB5328C15C for ; Mon, 21 Mar 2011 08:09:47 -0700 (PDT) Received: from netsrv1.ikr.uni-stuttgart.de (netsrv1-c [10.11.12.12]) by mailsrv.ikr.uni-stuttgart.de (Postfix) with ESMTP id A4101633B1; Mon, 21 Mar 2011 16:11:18 +0100 (CET) Received: from vpn-2-cl177 (vpn-2-cl177 [10.41.21.177]) by netsrv1.ikr.uni-stuttgart.de (Postfix) with ESMTP id 9184B59A8A; Mon, 21 Mar 2011 16:11:18 +0100 (CET) From: Mirja Kuehlewind Organization: University of Stuttgart (Germany), IKR To: ledbat@ietf.org Date: Mon, 21 Mar 2011 16:11:17 +0100 User-Agent: KMail/1.9.10 (enterprise35 0.20101217.1207316) References: In-Reply-To: X-KMail-QuotePrefix: > MIME-Version: 1.0 Content-Type: Text/Plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Content-Disposition: inline Message-Id: <201103211611.17450.mirja.kuehlewind@ikr.uni-stuttgart.de> Cc: Ingemar Johansson S Subject: Re: [ledbat] Reaction to packet drops 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, 21 Mar 2011 15:09:49 -0000 Hi Ingemar, if LEDBAT works correctly, it will not see any packet losses at all. LEDBAT= is=20 already decreasing the CWND if the current queuing delay is larger than=20 TARGET. This is usually the case when a competing flow is increasing the=20 rate. Standard TCP increases until the queue is filled up. By that time=20 LEDBAT should already have decreased its own rate to MIN_CWND (=3D2). If th= e=20 competing flow(s) is/are increasing more aggressive LEDBAT will back off=20 quicker as the delay-based back off already depends on off_target.=20 If LEDBAT see losses because of the very aggressive increase of a completin= g=20 flow in Slow-Start, the halving of the cwnd will help to speed-up the=20 decrease process but LEDBAT is anyway decreasing further as soon as the=20 completing TCP fills the queue again in Congestion Avoidance. Halving on loss is basically only a fall-back for the error case. If the=20 total possible queuing delay (because of really, really small buffers) is=20 smaller than TARGET, LEDBAT will not work. This is an error case and LEDBAT= =20 will behave like standard TCP. Not sure if we want to decrease more than=20 standard TCP in this case. To change the loss-based decrease will probably= =20 also provide a possibility to have a less-than-best-effort traffic but this= =20 is a completely different algorithm from my point of view. Actually, we still have to discuss the delay-based decrease more detailed i= n=20 the draft, as we have to make sure to decrease quicker than an completing=20 standard TCP would increase...=20 Anyway, how would you actually include GAIN (or do you mean off_target) int= o=20 the decrease on loss behavior? Mirja On Monday 21 March 2011 14:22:07 Ingemar Johansson S wrote: > Hi > > I have a question on the latest version of > http://tools.ietf.org/wg/ledbat/draft-ietf-ledbat-congestion/ > If I get things right LEDBAT should react to packet drops in the same was > as TCP Reno. > > For some reason I get the feeling that it is more reasonable to react more > than TCP reno even to packet drops and that this can also be controlled by > the GAIN parameter. The reason I can bring up is that in the strive to > reduce buffer bloat it is more likely that packet dops are used to signal > congestion which means that the delay increase may be very small. So if t= he > GAIN parameter is also included in the cwnd calculation when packet drops > occur then the delay and packet drop sensing algos would complement one > another. I guess this has probably been discussed earlier ? > > /Ingemar > =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D > INGEMAR JOHANSSON M.Sc. > Senior Researcher > > Ericsson AB > Wireless Area Networks > Labratoriegr=E4nd 11 > 971 28, Lule=E5, Sweden > Phone +46-1071 43042 > SMS/MMS +46-73 078 3289 > ingemar.s.johansson@ericsson.com > www.ericsson.com > Visit http://labs.ericsson.com ! > =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D > _______________________________________________ > ledbat mailing list > ledbat@ietf.org > https://www.ietf.org/mailman/listinfo/ledbat =2D-=20 =2D------------------------------------------------------------------ Dipl.-Ing. Mirja K=FChlewind Institute of Communication Networks and Computer Engineering (IKR) University of Stuttgart, Germany Pfaffenwaldring 47, D-70569 Stuttgart tel: +49(0)711/685-67973 email: mirja.kuehlewind@ikr.uni-stuttgart.de web: www.ikr.uni-stuttgart.de =2D------------------------------------------------------------------ From nweaver@icsi.berkeley.edu Mon Mar 21 08:37:01 2011 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 247BE28C0E1 for ; Mon, 21 Mar 2011 08:37:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.549 X-Spam-Level: X-Spam-Status: No, score=-2.549 tagged_above=-999 required=5 tests=[AWL=0.050, 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 rN1HkzhvDdlr for ; Mon, 21 Mar 2011 08:37:00 -0700 (PDT) Received: from taffy.ICSI.Berkeley.EDU (taffy.ICSI.Berkeley.EDU [192.150.187.26]) by core3.amsl.com (Postfix) with ESMTP id 64B863A687D for ; Mon, 21 Mar 2011 08:37:00 -0700 (PDT) Received: from gala.icir.org (gala.ICIR.org [192.150.187.49]) (Authenticated sender: nweaver) by taffy.ICSI.Berkeley.EDU (Postfix) with ESMTP id 3A53A36A429; Mon, 21 Mar 2011 08:38:33 -0700 (PDT) References: <201103211611.17450.mirja.kuehlewind@ikr.uni-stuttgart.de> In-Reply-To: <201103211611.17450.mirja.kuehlewind@ikr.uni-stuttgart.de> Mime-Version: 1.0 (Apple Message framework v1082) Content-Type: text/plain; charset=us-ascii Message-Id: Content-Transfer-Encoding: quoted-printable From: Nicholas Weaver Date: Mon, 21 Mar 2011 08:38:32 -0700 To: Mirja Kuehlewind X-Mailer: Apple Mail (2.1082) Cc: Ingemar Johansson S , ledbat@ietf.org Subject: Re: [ledbat] Reaction to packet drops 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, 21 Mar 2011 15:37:01 -0000 On Mar 21, 2011, at 8:11 AM, Mirja Kuehlewind wrote: > Halving on loss is basically only a fall-back for the error case. If = the=20 > total possible queuing delay (because of really, really small buffers) = is=20 > smaller than TARGET, LEDBAT will not work. This is an error case and = LEDBAT=20 > will behave like standard TCP. Not sure if we want to decrease more = than=20 > standard TCP in this case. To change the loss-based decrease will = probably=20 > also provide a possibility to have a less-than-best-effort traffic but = this=20 > is a completely different algorithm from my point of view. I'd vote no or yes depending on a mode selector: mode 1 is "No bufferbloat": you want the transfer to go through but not = cause problems with all the overbuffered equipment out there. In that = case, if your buffer is less than TARGET, you aren't in a problematic = buffering situation and you should behave like ordinary TCP. =20 This would, eg, be very good for Flash to adopt for streaming video. Mode 2 is "True scavenger service": You want to yield to normal TCP in = all cases, not just when there are buffer problems in the network. In = that case, drops should cause LEDBAT to back off further than normal TCP = would in the same conditions. From michawe@ifi.uio.no Mon Mar 21 08:42:02 2011 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 890CE28C0E2 for ; Mon, 21 Mar 2011 08:42:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.599 X-Spam-Level: X-Spam-Status: No, score=-106.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id J5EfB0KcG+Qv for ; Mon, 21 Mar 2011 08:42:01 -0700 (PDT) Received: from mail-out1.uio.no (mail-out1.uio.no [129.240.10.57]) by core3.amsl.com (Postfix) with ESMTP id 4999828C0E1 for ; Mon, 21 Mar 2011 08:42:01 -0700 (PDT) Received: from mail-mx3.uio.no ([129.240.10.44]) by mail-out1.uio.no with esmtp (Exim 4.72) (envelope-from ) id 1Q1hGV-0000Qd-PT; Mon, 21 Mar 2011 16:43:31 +0100 Received: from 1x-193-157-192-133.uio.no ([193.157.192.133]) by mail-mx3.uio.no with esmtpsa (TLSv1:AES128-SHA:128) user michawe (Exim 4.72) (envelope-from ) id 1Q1hGV-0003MK-AE; Mon, 21 Mar 2011 16:43:31 +0100 Mime-Version: 1.0 (Apple Message framework v1082) Content-Type: text/plain; charset=us-ascii From: michawe In-Reply-To: Date: Mon, 21 Mar 2011 16:43:30 +0100 Content-Transfer-Encoding: quoted-printable Message-Id: <07926440-0C3E-4E42-A037-D44C0A6F582E@ifi.uio.no> References: <201103211611.17450.mirja.kuehlewind@ikr.uni-stuttgart.de> To: Nicholas Weaver X-Mailer: Apple Mail (2.1082) X-UiO-Ratelimit-Test: rcpts/h 7 msgs/h 2 sum rcpts/h 9 sum msgs/h 4 total rcpts 7702 max rcpts/h 36 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: C2F27A630604DD565653B078CF722A545CB35547 X-UiO-SPAM-Test: remote_host: 193.157.192.133 spam_score: -49 maxlevel 80 minaction 2 bait 0 mail/h: 2 total 47 max/h 9 blacklist 0 greylist 0 ratelimit 0 Cc: Ingemar Johansson S , ledbat@ietf.org Subject: Re: [ledbat] Reaction to packet drops 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, 21 Mar 2011 15:42:02 -0000 +1 On Mar 21, 2011, at 4:38 PM, Nicholas Weaver wrote: >=20 > On Mar 21, 2011, at 8:11 AM, Mirja Kuehlewind wrote: >> Halving on loss is basically only a fall-back for the error case. If = the=20 >> total possible queuing delay (because of really, really small = buffers) is=20 >> smaller than TARGET, LEDBAT will not work. This is an error case and = LEDBAT=20 >> will behave like standard TCP. Not sure if we want to decrease more = than=20 >> standard TCP in this case. To change the loss-based decrease will = probably=20 >> also provide a possibility to have a less-than-best-effort traffic = but this=20 >> is a completely different algorithm from my point of view. >=20 > I'd vote no or yes depending on a mode selector: >=20 > mode 1 is "No bufferbloat": you want the transfer to go through but = not cause problems with all the overbuffered equipment out there. In = that case, if your buffer is less than TARGET, you aren't in a = problematic buffering situation and you should behave like ordinary TCP. = =20 >=20 > This would, eg, be very good for Flash to adopt for streaming video. >=20 >=20 > Mode 2 is "True scavenger service": You want to yield to normal TCP in = all cases, not just when there are buffer problems in the network. In = that case, drops should cause LEDBAT to back off further than normal TCP = would in the same conditions. >=20 >=20 > _______________________________________________ > ledbat mailing list > ledbat@ietf.org > https://www.ietf.org/mailman/listinfo/ledbat From touch@isi.edu Mon Mar 21 08:45:03 2011 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 A658E28C0EF for ; Mon, 21 Mar 2011 08:45:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.512 X-Spam-Level: X-Spam-Status: No, score=-103.512 tagged_above=-999 required=5 tests=[AWL=-0.913, BAYES_00=-2.599, 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 0ud1A1+lxy1j for ; Mon, 21 Mar 2011 08:45:03 -0700 (PDT) Received: from vapor.isi.edu (vapor.isi.edu [128.9.64.64]) by core3.amsl.com (Postfix) with ESMTP id E513028C0E7 for ; Mon, 21 Mar 2011 08:45:02 -0700 (PDT) Received: from [192.168.1.93] (pool-71-105-81-169.lsanca.dsl-w.verizon.net [71.105.81.169]) (authenticated bits=0) by vapor.isi.edu (8.13.8/8.13.8) with ESMTP id p2LFkCO4027218 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=NOT); Mon, 21 Mar 2011 08:46:24 -0700 (PDT) Message-ID: <4D8772C3.7040809@isi.edu> Date: Mon, 21 Mar 2011 08:46:11 -0700 From: Joe Touch User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.1; en-US; rv:1.9.2.15) Gecko/20110303 Thunderbird/3.1.9 MIME-Version: 1.0 To: Ingemar Johansson S References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-ISI-4-43-8-MailScanner: Found to be clean X-MailScanner-From: touch@isi.edu Cc: "ledbat@ietf.org" Subject: Re: [ledbat] Reaction to packet drops 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, 21 Mar 2011 15:45:03 -0000 Hi, all, On 3/21/2011 6:22 AM, Ingemar Johansson S wrote: > Hi > > I have a question on the latest version of > http://tools.ietf.org/wg/ledbat/draft-ietf-ledbat-congestion/ > If I get things right LEDBAT should react to packet drops in the same was as TCP Reno. > > For some reason I get the feeling that it is more reasonable to > react more than TCP reno even to packet drops and that this can also be > controlled by the GAIN parameter. The reason I can bring up is that in > the strive to reduce buffer bloat it is more likely that packet dops are > used to signal congestion which means that the delay increase may be > very small. Buffer bloat shouldn't drive this discussion. You're talking about reacting to drops; buffer bloat can still occur with zero drops. AFAICT, BB is an artifact of poor buffering and queue management implementation and configuration. We should not strive to tune TCP to correct for flaws in, e.g., Linux. Joe From Rolf.Winter@neclab.eu Mon Mar 21 08:53:48 2011 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 7C73A28C0E2 for ; Mon, 21 Mar 2011 08:53:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.385 X-Spam-Level: X-Spam-Status: No, score=-102.385 tagged_above=-999 required=5 tests=[AWL=0.214, BAYES_00=-2.599, 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 8WN+MlqscIcG for ; Mon, 21 Mar 2011 08:53:47 -0700 (PDT) Received: from smtp0.neclab.eu (smtp0.neclab.eu [195.37.70.41]) by core3.amsl.com (Postfix) with ESMTP id 935753A6881 for ; Mon, 21 Mar 2011 08:53:47 -0700 (PDT) Received: from localhost (localhost.localdomain [127.0.0.1]) by smtp0.neclab.eu (Postfix) with ESMTP id 9BDA32C0002E9; Mon, 21 Mar 2011 16:57:32 +0100 (CET) X-Virus-Scanned: Amavisd on Debian GNU/Linux (atlas2.office.hd) Received: from smtp0.neclab.eu ([127.0.0.1]) by localhost (atlas2.office.hd [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id f-BnKrZZzvOj; Mon, 21 Mar 2011 16:57:32 +0100 (CET) Received: from ENCELADUS.office.hd (ENCELADUS.office.hd [192.168.24.52]) by smtp0.neclab.eu (Postfix) with ESMTP id 7AC0F2C0002E8; Mon, 21 Mar 2011 16:57:17 +0100 (CET) Received: from DAPHNIS.office.hd ([169.254.2.136]) by ENCELADUS.office.hd ([192.168.24.52]) with mapi id 14.01.0270.001; Mon, 21 Mar 2011 16:55:04 +0100 From: Rolf Winter To: Mirja Kuehlewind , "ledbat@ietf.org" Thread-Topic: [ledbat] Reaction to packet drops Thread-Index: AcvfXoMJN0khFfymTUOPBxWr2sKLvgIawxhAAAISLIAAAzid8A== Date: Mon, 21 Mar 2011 15:55:04 +0000 Message-ID: <791AD3077F94194BB2BDD13565B6295D05DEC921@DAPHNIS.office.hd> References: <201103211611.17450.mirja.kuehlewind@ikr.uni-stuttgart.de> In-Reply-To: <201103211611.17450.mirja.kuehlewind@ikr.uni-stuttgart.de> Accept-Language: en-US, de-DE Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.1.6.28] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: Ingemar Johansson S Subject: Re: [ledbat] Reaction to packet drops 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, 21 Mar 2011 15:53:48 -0000 Speaking as non-chair, > Halving on loss is basically only a fall-back for the error case. If > the > total possible queuing delay (because of really, really small buffers) > is > smaller than TARGET, LEDBAT will not work. This is an error case and > LEDBAT > will behave like standard TCP. Not sure if we want to decrease more > than > standard TCP in this case. To change the loss-based decrease will > probably > also provide a possibility to have a less-than-best-effort traffic but > this > is a completely different algorithm from my point of view. >=20 I think it is wrong to assume this is in fact an error case. The observatio= n we have made with a range of DSL home gateways is that buffers indeed bec= ome smaller over time (we observed 256 packets worth of buffer in old ones = to around 32 nowadays). Of course there are other delay contributors, but h= ome gateways initially triggered the development of LEDBAT. Paired with an = increase in access speed queuing delay will reduce over time and 100 ms wil= l be too much. That is why we now allow a smaller target in the new spec. T= he hope therefore will be that LEDBAT will over time lower its de facto tar= get. But given that this situation of running into loss will likely happen = in the future, we need to find an adequate answer. I believe the current an= swer is fine - behave like TCP. In case you have this situation persistentl= y, i.e. small buffers, you can lower your target. That's even better than a= binary on/off switch.=20 Best, Rolf From Rolf.Winter@neclab.eu Mon Mar 21 09:02:24 2011 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 A489C28C0EB for ; Mon, 21 Mar 2011 09:02:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.395 X-Spam-Level: X-Spam-Status: No, score=-102.395 tagged_above=-999 required=5 tests=[AWL=0.204, BAYES_00=-2.599, 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 nlRwNbyVjcCe for ; Mon, 21 Mar 2011 09:02:24 -0700 (PDT) Received: from smtp0.neclab.eu (smtp0.neclab.eu [195.37.70.41]) by core3.amsl.com (Postfix) with ESMTP id D2C6B3A6881 for ; Mon, 21 Mar 2011 09:02:23 -0700 (PDT) Received: from localhost (localhost.localdomain [127.0.0.1]) by smtp0.neclab.eu (Postfix) with ESMTP id E46C52C0002EB for ; Mon, 21 Mar 2011 17:06:08 +0100 (CET) X-Virus-Scanned: Amavisd on Debian GNU/Linux (atlas2.office.hd) Received: from smtp0.neclab.eu ([127.0.0.1]) by localhost (atlas2.office.hd [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id A12rar9UkM0w for ; Mon, 21 Mar 2011 17:06:08 +0100 (CET) Received: from METHONE.office.hd (Methone.office.hd [192.168.24.54]) by smtp0.neclab.eu (Postfix) with ESMTP id C28652C0002EA for ; Mon, 21 Mar 2011 17:06:03 +0100 (CET) Received: from DAPHNIS.office.hd ([169.254.2.136]) by METHONE.office.hd ([192.168.24.54]) with mapi id 14.01.0270.001; Mon, 21 Mar 2011 17:03:51 +0100 From: Rolf Winter To: "ledbat@ietf.org" Thread-Topic: congestion control draft Thread-Index: Acvn4ZEpj6VZSAvxQIOVWSnUxKXmZA== Date: Mon, 21 Mar 2011 16:03:51 +0000 Message-ID: <791AD3077F94194BB2BDD13565B6295D05DEC935@DAPHNIS.office.hd> Accept-Language: en-US, de-DE Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.1.6.28] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: [ledbat] congestion control draft 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, 21 Mar 2011 16:02:24 -0000 Hi, since people clearly have started to read and digest the newest version of = the draft, the chairs would appreciate if you could post your general feedb= ack about the document. Something like "I think this is good now" or "it ha= s addressed my previous concerns" etc. would be good feedback for us. Thanks, Rolf NEC Europe Limited | Registered Office: NEC House, 1 Victoria Road, London = W3 6BL | Registered in England 2832014=20 From ingemar.s.johansson@ericsson.com Tue Mar 22 00:35:13 2011 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 B41CE3A699A for ; Tue, 22 Mar 2011 00:35:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.299 X-Spam-Level: X-Spam-Status: No, score=-6.299 tagged_above=-999 required=5 tests=[AWL=-0.300, BAYES_00=-2.599, J_CHICKENPOX_34=0.6, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id eF4Q1K3ySnN4 for ; Tue, 22 Mar 2011 00:35:12 -0700 (PDT) Received: from mailgw10.se.ericsson.net (mailgw10.se.ericsson.net [193.180.251.61]) by core3.amsl.com (Postfix) with ESMTP id 1B9A93A699D for ; Tue, 22 Mar 2011 00:35:11 -0700 (PDT) X-AuditID: c1b4fb3d-b7bbbae000005311-e9-4d88518bfcbf Received: from esessmw0191.eemea.ericsson.se (Unknown_Domain [153.88.253.125]) by mailgw10.se.ericsson.net (Symantec Mail Security) with SMTP id 8E.4E.21265.B81588D4; Tue, 22 Mar 2011 08:36:44 +0100 (CET) Received: from ESESSCMS0366.eemea.ericsson.se ([169.254.1.230]) by esessmw0191.eemea.ericsson.se ([153.88.115.84]) with mapi; Tue, 22 Mar 2011 08:36:43 +0100 From: Ingemar Johansson S To: Rolf Winter , Mirja Kuehlewind , "ledbat@ietf.org" Date: Tue, 22 Mar 2011 08:36:42 +0100 Thread-Topic: [ledbat] Reaction to packet drops Thread-Index: AcvfXoMJN0khFfymTUOPBxWr2sKLvgIawxhAAAISLIAAAzid8AAfLt9w Message-ID: References: <201103211611.17450.mirja.kuehlewind@ikr.uni-stuttgart.de> <791AD3077F94194BB2BDD13565B6295D05DEC921@DAPHNIS.office.hd> In-Reply-To: <791AD3077F94194BB2BDD13565B6295D05DEC921@DAPHNIS.office.hd> Accept-Language: sv-SE, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: sv-SE, en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Brightmail-Tracker: AAAAAA== Cc: Ingemar Johansson S , Nicholas Weaver Subject: Re: [ledbat] Reaction to packet drops 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, 22 Mar 2011 07:35:13 -0000 Mirja, Rolf, all One of the reasons I see to introduce a more agressive backoff in the prese= nce of packet loss is that I have problems to determine a good TARGET value= for wireless access. It all depends on the type of radio access (HSDPA, EU= L, LTE..) and also on the type of scheduling algorithm one use. As the user= can be mobile he may as well do handover between access types and this com= plicates things even more. I see a particulal issue if the threshold of an AQM algorithm along the tra= nsmission path is tuned such that the packets are dropped when the delay is= below TARGET. This will as I understand things cause LEDBAT and TCP to bac= koff in the same way. I would say that the statement in the draft "LEDBAT d= oes not induce losses and so a LEDBAT sender is not expected to normally re= ly on losses to determine the sending rate." is not true in this case. It would make more sense to me if LEDBAT backs off more than TCP in the pre= sence of packet losses. One way to implement this is to modify section 3.4.2 slighly and include GA= IN in the "on data loss:" code # atmost once per RTT cwnd =3D GAIN*cwnd/2 cwnd =3D max(cwnd, MIN_CWND * MSS) I am not sure if that creates a too strong backoff behavior if GAIN is very= low so perhaps something like # atmost once per RTT cwnd =3D max(GAIN,MIN_GAIN)*cwnd/2 cwnd =3D max(cwnd, MIN_CWND * MSS) Where MIN_GAIN can be set to for instance 0.25 There is also a political angle to all this. File sharing is often looked a= t with not too kind eyes from certain players. It is sometimes voiced that = the whole thing should be blocked as it kills the performance for all users= (you all know the story that goes like "10% of the users consume 90% of th= e bandwidth"). If one can say that LEDBAT is indeed more than TCP friendly = in all possible cases, then the above concerns wont hold (at least not for = the technically oriented person :-). The delay based part of LEDBAT fulfill= s this requirement but I believe that the loss based (or ECN based for that= matter) needs to be modified. Regards Ingemar -----Original Message----- From: Rolf Winter [mailto:Rolf.Winter@neclab.eu]=20 Sent: den 21 mars 2011 16:55 To: Mirja Kuehlewind; ledbat@ietf.org Cc: Ingemar Johansson S Subject: RE: [ledbat] Reaction to packet drops Speaking as non-chair, > Halving on loss is basically only a fall-back for the error case. If=20 > the total possible queuing delay (because of really, really small=20 > buffers) is smaller than TARGET, LEDBAT will not work. This is an=20 > error case and LEDBAT will behave like standard TCP. Not sure if we=20 > want to decrease more than standard TCP in this case. To change the=20 > loss-based decrease will probably also provide a possibility to have a=20 > less-than-best-effort traffic but this is a completely different=20 > algorithm from my point of view. >=20 I think it is wrong to assume this is in fact an error case. The observatio= n we have made with a range of DSL home gateways is that buffers indeed bec= ome smaller over time (we observed 256 packets worth of buffer in old ones = to around 32 nowadays). Of course there are other delay contributors, but h= ome gateways initially triggered the development of LEDBAT. Paired with an = increase in access speed queuing delay will reduce over time and 100 ms wil= l be too much. That is why we now allow a smaller target in the new spec. T= he hope therefore will be that LEDBAT will over time lower its de facto tar= get. But given that this situation of running into loss will likely happen = in the future, we need to find an adequate answer. I believe the current an= swer is fine - behave like TCP. In case you have this situation persistentl= y, i.e. small buffers, you can lower your target. That's even better than a= binary on/off switch.=20 Best, Rolf From Rolf.Winter@neclab.eu Tue Mar 22 00:58:23 2011 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 7D8B63A67A1 for ; Tue, 22 Mar 2011 00:58:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.103 X-Spam-Level: X-Spam-Status: No, score=-102.103 tagged_above=-999 required=5 tests=[AWL=-0.104, BAYES_00=-2.599, J_CHICKENPOX_34=0.6, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id AyMhRxjHVX8K for ; Tue, 22 Mar 2011 00:58:22 -0700 (PDT) Received: from smtp0.neclab.eu (smtp0.neclab.eu [195.37.70.41]) by core3.amsl.com (Postfix) with ESMTP id 49D943A659A for ; Tue, 22 Mar 2011 00:58:22 -0700 (PDT) Received: from localhost (localhost.localdomain [127.0.0.1]) by smtp0.neclab.eu (Postfix) with ESMTP id F0F992C0002EA; Tue, 22 Mar 2011 09:02:09 +0100 (CET) X-Virus-Scanned: Amavisd on Debian GNU/Linux (atlas2.office.hd) Received: from smtp0.neclab.eu ([127.0.0.1]) by localhost (atlas2.office.hd [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id eJK8qdO95L-0; Tue, 22 Mar 2011 09:02:09 +0100 (CET) Received: from ENCELADUS.office.hd (ENCELADUS.office.hd [192.168.24.52]) by smtp0.neclab.eu (Postfix) with ESMTP id CE7D32C0002E9; Tue, 22 Mar 2011 09:01:44 +0100 (CET) Received: from DAPHNIS.office.hd ([169.254.2.136]) by ENCELADUS.office.hd ([192.168.24.52]) with mapi id 14.01.0270.001; Tue, 22 Mar 2011 08:59:29 +0100 From: Rolf Winter To: Ingemar Johansson S , Mirja Kuehlewind , "ledbat@ietf.org" Thread-Topic: [ledbat] Reaction to packet drops Thread-Index: AcvfXoMJN0khFfymTUOPBxWr2sKLvgIawxhAAAISLIAAAzid8AAfLt9wAAKnyvA= Date: Tue, 22 Mar 2011 07:59:28 +0000 Message-ID: <791AD3077F94194BB2BDD13565B6295D05DECB82@DAPHNIS.office.hd> References: <201103211611.17450.mirja.kuehlewind@ikr.uni-stuttgart.de> <791AD3077F94194BB2BDD13565B6295D05DEC921@DAPHNIS.office.hd> In-Reply-To: Accept-Language: en-US, de-DE Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.1.6.28] Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: Nicholas Weaver Subject: Re: [ledbat] Reaction to packet drops 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, 22 Mar 2011 07:58:23 -0000 Hi Ingemar, (as individual)=20 there are at least two more things to consider. For one the design goals of= which two are: 4. utilize end-to-end available bandwidth, and 5. operate well in networks with FIFO queues and tail-drop queue management Actually, an earlier version of the document had this as well: where available, use explicit congestion notification (ECN), active queue m= anagement (AQM), and/or end-to-end differentiated services (DiffServ)... Now the second thing to consider is that even if LEDBAT backs off in the sa= me way as TCP does in case of loss, it will ramp up more slowly (max as TCP= when in congestion avoidance which is when there is no competing traffic w= hich is not what we are talking about in this case). Best, Rolf NEC Europe Limited | Registered Office: NEC House, 1 Victoria Road, London = W3 6BL | Registered in England 2832014=20 > -----Original Message----- > From: Ingemar Johansson S [mailto:ingemar.s.johansson@ericsson.com] > Sent: Dienstag, 22. M=E4rz 2011 08:37 > To: Rolf Winter; Mirja Kuehlewind; ledbat@ietf.org > Cc: Nicholas Weaver; michawe; Ingemar Johansson S > Subject: RE: [ledbat] Reaction to packet drops >=20 > Mirja, Rolf, all >=20 > One of the reasons I see to introduce a more agressive backoff in the > presence of packet loss is that I have problems to determine a good > TARGET value for wireless access. It all depends on the type of radio > access (HSDPA, EUL, LTE..) and also on the type of scheduling algorithm > one use. As the user can be mobile he may as well do handover between > access types and this complicates things even more. >=20 > I see a particulal issue if the threshold of an AQM algorithm along the > transmission path is tuned such that the packets are dropped when the > delay is below TARGET. This will as I understand things cause LEDBAT > and TCP to backoff in the same way. I would say that the statement in > the draft "LEDBAT does not induce losses and so a LEDBAT sender is not > expected to normally rely on losses to determine the sending rate." is > not true in this case. >=20 >=20 > It would make more sense to me if LEDBAT backs off more than TCP in the > presence of packet losses. >=20 > One way to implement this is to modify section 3.4.2 slighly and > include GAIN in the "on data loss:" code > # atmost once per RTT > cwnd =3D GAIN*cwnd/2 > cwnd =3D max(cwnd, MIN_CWND * MSS) >=20 > I am not sure if that creates a too strong backoff behavior if GAIN is > very low so perhaps something like > # atmost once per RTT > cwnd =3D max(GAIN,MIN_GAIN)*cwnd/2 > cwnd =3D max(cwnd, MIN_CWND * MSS) >=20 > Where MIN_GAIN can be set to for instance 0.25 >=20 > There is also a political angle to all this. File sharing is often > looked at with not too kind eyes from certain players. It is sometimes > voiced that the whole thing should be blocked as it kills the > performance for all users (you all know the story that goes like "10% > of the users consume 90% of the bandwidth"). If one can say that LEDBAT > is indeed more than TCP friendly in all possible cases, then the above > concerns wont hold (at least not for the technically oriented person :- > ). The delay based part of LEDBAT fulfills this requirement but I > believe that the loss based (or ECN based for that matter) needs to be > modified. >=20 > Regards > Ingemar >=20 >=20 > -----Original Message----- > From: Rolf Winter [mailto:Rolf.Winter@neclab.eu] > Sent: den 21 mars 2011 16:55 > To: Mirja Kuehlewind; ledbat@ietf.org > Cc: Ingemar Johansson S > Subject: RE: [ledbat] Reaction to packet drops >=20 > Speaking as non-chair, >=20 > > Halving on loss is basically only a fall-back for the error case. If > > the total possible queuing delay (because of really, really small > > buffers) is smaller than TARGET, LEDBAT will not work. This is an > > error case and LEDBAT will behave like standard TCP. Not sure if we > > want to decrease more than standard TCP in this case. To change the > > loss-based decrease will probably also provide a possibility to have > a > > less-than-best-effort traffic but this is a completely different > > algorithm from my point of view. > > >=20 > I think it is wrong to assume this is in fact an error case. The > observation we have made with a range of DSL home gateways is that > buffers indeed become smaller over time (we observed 256 packets worth > of buffer in old ones to around 32 nowadays). Of course there are other > delay contributors, but home gateways initially triggered the > development of LEDBAT. Paired with an increase in access speed queuing > delay will reduce over time and 100 ms will be too much. That is why we > now allow a smaller target in the new spec. The hope therefore will be > that LEDBAT will over time lower its de facto target. But given that > this situation of running into loss will likely happen in the future, > we need to find an adequate answer. I believe the current answer is > fine - behave like TCP. In case you have this situation persistently, > i.e. small buffers, you can lower your target. That's even better than > a binary on/off switch. >=20 > Best, >=20 > Rolf From ingemar.s.johansson@ericsson.com Tue Mar 22 03:12:56 2011 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 14FE73A682A for ; Tue, 22 Mar 2011 03:12:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.224 X-Spam-Level: X-Spam-Status: No, score=-6.224 tagged_above=-999 required=5 tests=[AWL=-0.225, BAYES_00=-2.599, J_CHICKENPOX_34=0.6, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id N+3b3L87LoSo for ; Tue, 22 Mar 2011 03:12:55 -0700 (PDT) Received: from mailgw9.se.ericsson.net (mailgw9.se.ericsson.net [193.180.251.57]) by core3.amsl.com (Postfix) with ESMTP id 8667C3A6814 for ; Tue, 22 Mar 2011 03:12:54 -0700 (PDT) X-AuditID: c1b4fb39-b7c6dae0000023f2-a3-4d887682db9c Received: from esessmw0247.eemea.ericsson.se (Unknown_Domain [153.88.253.125]) by mailgw9.se.ericsson.net (Symantec Mail Security) with SMTP id 9C.0C.09202.286788D4; Tue, 22 Mar 2011 11:14:26 +0100 (CET) Received: from ESESSCMS0366.eemea.ericsson.se ([169.254.1.230]) by esessmw0247.eemea.ericsson.se ([10.2.3.116]) with mapi; Tue, 22 Mar 2011 11:14:25 +0100 From: Ingemar Johansson S To: Rolf Winter , Mirja Kuehlewind , "ledbat@ietf.org" Date: Tue, 22 Mar 2011 11:14:24 +0100 Thread-Topic: [ledbat] Reaction to packet drops Thread-Index: AcvfXoMJN0khFfymTUOPBxWr2sKLvgIawxhAAAISLIAAAzid8AAfLt9wAAKnyvAABNDxoA== Message-ID: References: <201103211611.17450.mirja.kuehlewind@ikr.uni-stuttgart.de> <791AD3077F94194BB2BDD13565B6295D05DEC921@DAPHNIS.office.hd> <791AD3077F94194BB2BDD13565B6295D05DECB82@DAPHNIS.office.hd> In-Reply-To: <791AD3077F94194BB2BDD13565B6295D05DECB82@DAPHNIS.office.hd> Accept-Language: sv-SE, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: sv-SE, en-US Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Brightmail-Tracker: AAAAAA== Cc: Nicholas Weaver Subject: Re: [ledbat] Reaction to packet drops 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, 22 Mar 2011 10:12:56 -0000 Hmm. Good point, the slower ramp up will definitely make LEDBAT more than T= CP friendly if GAIN < 1.0. This means that there should be no concern. Thanks=20 /Ingemar -----Original Message----- From: Rolf Winter [mailto:Rolf.Winter@neclab.eu]=20 Sent: den 22 mars 2011 08:59 To: Ingemar Johansson S; Mirja Kuehlewind; ledbat@ietf.org Cc: Nicholas Weaver; michawe Subject: RE: [ledbat] Reaction to packet drops Hi Ingemar, (as individual)=20 there are at least two more things to consider. For one the design goals of= which two are: 4. utilize end-to-end available bandwidth, and 5. operate well in networks = with FIFO queues and tail-drop queue management Actually, an earlier version of the document had this as well: where available, use explicit congestion notification (ECN), active queue m= anagement (AQM), and/or end-to-end differentiated services (DiffServ)... Now the second thing to consider is that even if LEDBAT backs off in the sa= me way as TCP does in case of loss, it will ramp up more slowly (max as TCP= when in congestion avoidance which is when there is no competing traffic w= hich is not what we are talking about in this case). Best, Rolf NEC Europe Limited | Registered Office: NEC House, 1 Victoria Road, London = W3 6BL | Registered in England 2832014=20 > -----Original Message----- > From: Ingemar Johansson S [mailto:ingemar.s.johansson@ericsson.com] > Sent: Dienstag, 22. M=E4rz 2011 08:37 > To: Rolf Winter; Mirja Kuehlewind; ledbat@ietf.org > Cc: Nicholas Weaver; michawe; Ingemar Johansson S > Subject: RE: [ledbat] Reaction to packet drops >=20 > Mirja, Rolf, all >=20 > One of the reasons I see to introduce a more agressive backoff in the=20 > presence of packet loss is that I have problems to determine a good=20 > TARGET value for wireless access. It all depends on the type of radio=20 > access (HSDPA, EUL, LTE..) and also on the type of scheduling=20 > algorithm one use. As the user can be mobile he may as well do=20 > handover between access types and this complicates things even more. >=20 > I see a particulal issue if the threshold of an AQM algorithm along=20 > the transmission path is tuned such that the packets are dropped when=20 > the delay is below TARGET. This will as I understand things cause=20 > LEDBAT and TCP to backoff in the same way. I would say that the=20 > statement in the draft "LEDBAT does not induce losses and so a LEDBAT=20 > sender is not expected to normally rely on losses to determine the=20 > sending rate." is not true in this case. >=20 >=20 > It would make more sense to me if LEDBAT backs off more than TCP in=20 > the presence of packet losses. >=20 > One way to implement this is to modify section 3.4.2 slighly and=20 > include GAIN in the "on data loss:" code > # atmost once per RTT > cwnd =3D GAIN*cwnd/2 > cwnd =3D max(cwnd, MIN_CWND * MSS) >=20 > I am not sure if that creates a too strong backoff behavior if GAIN is=20 > very low so perhaps something like > # atmost once per RTT > cwnd =3D max(GAIN,MIN_GAIN)*cwnd/2 > cwnd =3D max(cwnd, MIN_CWND * MSS) >=20 > Where MIN_GAIN can be set to for instance 0.25 >=20 > There is also a political angle to all this. File sharing is often=20 > looked at with not too kind eyes from certain players. It is sometimes=20 > voiced that the whole thing should be blocked as it kills the=20 > performance for all users (you all know the story that goes like "10%=20 > of the users consume 90% of the bandwidth"). If one can say that=20 > LEDBAT is indeed more than TCP friendly in all possible cases, then=20 > the above concerns wont hold (at least not for the technically=20 > oriented person :- ). The delay based part of LEDBAT fulfills this=20 > requirement but I believe that the loss based (or ECN based for that=20 > matter) needs to be modified. >=20 > Regards > Ingemar >=20 >=20 > -----Original Message----- > From: Rolf Winter [mailto:Rolf.Winter@neclab.eu] > Sent: den 21 mars 2011 16:55 > To: Mirja Kuehlewind; ledbat@ietf.org > Cc: Ingemar Johansson S > Subject: RE: [ledbat] Reaction to packet drops >=20 > Speaking as non-chair, >=20 > > Halving on loss is basically only a fall-back for the error case.=20 > > If the total possible queuing delay (because of really, really small > > buffers) is smaller than TARGET, LEDBAT will not work. This is an=20 > > error case and LEDBAT will behave like standard TCP. Not sure if we=20 > > want to decrease more than standard TCP in this case. To change the=20 > > loss-based decrease will probably also provide a possibility to have > a > > less-than-best-effort traffic but this is a completely different=20 > > algorithm from my point of view. > > >=20 > I think it is wrong to assume this is in fact an error case. The=20 > observation we have made with a range of DSL home gateways is that=20 > buffers indeed become smaller over time (we observed 256 packets worth=20 > of buffer in old ones to around 32 nowadays). Of course there are=20 > other delay contributors, but home gateways initially triggered the=20 > development of LEDBAT. Paired with an increase in access speed queuing=20 > delay will reduce over time and 100 ms will be too much. That is why=20 > we now allow a smaller target in the new spec. The hope therefore will=20 > be that LEDBAT will over time lower its de facto target. But given=20 > that this situation of running into loss will likely happen in the=20 > future, we need to find an adequate answer. I believe the current=20 > answer is fine - behave like TCP. In case you have this situation=20 > persistently, i.e. small buffers, you can lower your target. That's=20 > even better than a binary on/off switch. >=20 > Best, >=20 > Rolf From serveh_ram21@yahoo.com Tue Mar 22 04:18:19 2011 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 0285D28C0DF for ; Tue, 22 Mar 2011 04:18:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.998 X-Spam-Level: X-Spam-Status: No, score=-1.998 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, J_CHICKENPOX_34=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 hCzNd-CSap48 for ; Tue, 22 Mar 2011 04:18:15 -0700 (PDT) Received: from web114607.mail.gq1.yahoo.com (web114607.mail.gq1.yahoo.com [98.136.183.40]) by core3.amsl.com (Postfix) with SMTP id ACCF328C0DE for ; Tue, 22 Mar 2011 04:18:15 -0700 (PDT) Received: (qmail 89759 invoked by uid 60001); 22 Mar 2011 11:19:46 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s1024; t=1300792786; bh=JPpy/C3uWX6vUMErYWhOvUcgCzGo5pxpPGsP4LEKShI=; h=Message-ID:X-YMail-OSG:Received:X-Mailer:Date:From:Subject:To:MIME-Version:Content-Type; b=vNatSKcqjzv6v8G2lyE9X6WT2pqa4SYdh5i3QweGhjFnDRYdl7tFeP0OaYhpTD1ESh0zajubRIdjxD4LjPLJXPbkyvN3B5GPvmhd6KA+Fes5JkH6bt1QADccQez3WfCpMn2saPGa+Gy04K8yDBmlDskb6tunjLuTl9ayQQXUlGc= DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=s1024; d=yahoo.com; h=Message-ID:X-YMail-OSG:Received:X-Mailer:Date:From:Subject:To:MIME-Version:Content-Type; b=PJhKYPWg44J/37duUvbuam5c3ToatknOldbUm5KH8ZD+XqFR/RvMlyVfA46vSkKIDK8XM+Ta0ntvVm8PWrZ0y/0fdlNzMv1P1cHtB0Y2CnFXy0ldGsujN8VHgqGN2PCcP5ks7rjd1IDxcfBFwi+kwSZfD2tpJxl81uIHgbj8vRs=; Message-ID: <71538.84873.qm@web114607.mail.gq1.yahoo.com> X-YMail-OSG: osimfeoVM1nFWlfAKgVlkKXQbc.RSfF4BRODo3JRTnFtVJI CHL5TDfs_bDHRanRBUL5PqRjh2bxV5zKX7T0QSlYZeIXr967ed0Lq28i8oNh kF_rCNffL0VM6.tVIMTvrMnaAxlqoT3iV1xCXOezoshS3jAp7A4XMOEHIl4X glPxuF3TuRyEbqbsPguJdfc9g09_n8vHie4l57l.8Um4dtFaTjSfp_1ztR0d 8jwr4fqjxef4Cjia7ofX4o3JXvDgIGuwsKR0wtFczCNPRntJHzS9_QtfMdKS 65mGOhdrXdqCiuLFLyVgrw4kPRYttTMdsqAGM.0WMnpHy7taaNiG6z3GwguR OVHR5ogaLmANFapDFg6i7Vc5NvrSgWNNnvcITnh8aIGR0iOfCiF_df20- Received: from [193.10.67.130] by web114607.mail.gq1.yahoo.com via HTTP; Tue, 22 Mar 2011 04:19:45 PDT X-Mailer: YahooMailRC/559 YahooMailWebService/0.8.109.295617 Date: Tue, 22 Mar 2011 04:19:45 -0700 (PDT) From: serveh sadeghi To: ledbat@ietf.org MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="0-1991020822-1300792785=:84873" Subject: [ledbat] flightSize & cwnd 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, 22 Mar 2011 11:19:55 -0000 --0-1991020822-1300792785=:84873 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Hi guys,=0AI=E2=80=99m implementing the congestion control mechanism used i= n =C2=B5TP (LEDBAT ) and I =0Aencountered some problems .=0AHere is what LE= DBAT specification says about how to calculate cwnd:=0Aoff_target =3D TARGE= T - queuing_delay + random_input()=0Acwnd +=3D GAIN * off_target / cwnd=0A#= flight_size() is the amount of currently not acked data.=0Amax_allowed_cwn= d =3D ALLOWED_INCREASE + TETHER*flight_size()=0Acwnd =3D min(cwnd, max_allo= wed_cwnd)=0AAnd here is the values spec suggests for the parameters:=0ATARG= ET =3D 100;=0AGAIN =3D 1.0;=0AALLOWED_INCREASE =3D 1.0;=0ATETHER =3D 1.5;= =0AConsidering these , if flight_size becomes 0 at some point, max_allowed_= cwnd =0Abecomes 1.0, so whatever calculatedcwnd is, finalcwnd would be 1.0(= The minimum =0Aamount of cwnd while a TCP flow exists!). Even worse , ifcwn= d becomes 1.0, it =0Aremains 1.0 forever. Becausecwnd =3D 1.0 means just se= nd 1 packet. So on receiving =0Aack, flight_size would be 0 and againmax_al= lowed_cwnd would be 1.0 ! =0A=0A=0Acould you please guide me where I'm maki= ng mistake .=0A=0A=0A --0-1991020822-1300792785=:84873 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: quoted-printable

Hi guys,=0A=0A

I=E2=80=99m implementing the=0Acongestion control= mechanism used in =C2=B5TP (LEDBAT ) and I encountered some=0Aproblems .

=0A=0A

Here is what=0AL= EDBAT specification says about how to calculate cwnd:

=0A=0A

off_target=0A=3D TARGET - queuing_delay + random_input()

=0A=0A

cwnd +=3D=0AGAIN * off_target / cwnd

=0A=0A

#=0Aflight_size() is the amount of currently not acked dat= a.

=0A=0A

max_allowed_cwnd=0A=3D ALLOWED_INCREASE + = TETHER*flight_size()

=0A=0A

cwnd =3D=0Amin(cwnd, max_= allowed_cwnd)

=0A=0A

And here = is the values spec=0Asuggests for the parameters:<= /span>

=0A=0A

TARGET =3D=0A100;

=0A=0A

GAIN =3D=0A1.0;

=0A=0A

ALLOWED_INCREASE=0A=3D 1.0;

=0A=0A

TETHER =3D=0A1.5;

=0A=0A

Considering these , if flight_size becomes=0A0 at some point,=0Amax_allowed_cw= nd becomes 1.0, so=0Awhatever calculated=0Acwnd is, final cwnd would=0Abe 1.0(The minimum a= mount of cwnd while a TCP flow exists!). Even worse , if c= wnd becomes=0A1.0, it remains 1.0 forever.= Because cwnd =3D 1.0 mea= ns just send=0A1 packet. So on receiving ack, flight_size = would=0Abe 0 and again=0A= max_allowed_cwnd would be 1.0 !


could you please guide me where I'm making mistake .=

=0A=0A

 

=0A=0A

 

=
=0A=0A=0A
=0A=0A=0A=0A=0A=0A=0A=0A --0-1991020822-1300792785=:84873-- From mirja.kuehlewind@ikr.uni-stuttgart.de Tue Mar 22 04:29:57 2011 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 C085F3A6820 for ; Tue, 22 Mar 2011 04:29:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.655 X-Spam-Level: X-Spam-Status: No, score=-1.655 tagged_above=-999 required=5 tests=[AWL=-0.306, BAYES_00=-2.599, HELO_EQ_DE=0.35, J_CHICKENPOX_34=0.6, MIME_8BIT_HEADER=0.3] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id TZddO85zISbq for ; Tue, 22 Mar 2011 04:29:56 -0700 (PDT) Received: from mailsrv.ikr.uni-stuttgart.de (mailsrv.ikr.uni-stuttgart.de [129.69.170.2]) by core3.amsl.com (Postfix) with ESMTP id BF3383A67B7 for ; Tue, 22 Mar 2011 04:29:56 -0700 (PDT) Received: from netsrv1.ikr.uni-stuttgart.de (netsrv1-c [10.11.12.12]) by mailsrv.ikr.uni-stuttgart.de (Postfix) with ESMTP id 93528633B1; Tue, 22 Mar 2011 12:31:28 +0100 (CET) Received: from vpn-2-cl177 (vpn-2-cl177 [10.41.21.177]) by netsrv1.ikr.uni-stuttgart.de (Postfix) with ESMTP id 8066859A8A; Tue, 22 Mar 2011 12:31:28 +0100 (CET) From: Mirja =?utf-8?q?K=C3=BChlewind?= To: ledbat@ietf.org Date: Tue, 22 Mar 2011 12:31:27 +0100 User-Agent: KMail/1.9.10 (enterprise35 0.20101217.1207316) References: <71538.84873.qm@web114607.mail.gq1.yahoo.com> In-Reply-To: <71538.84873.qm@web114607.mail.gq1.yahoo.com> X-KMail-QuotePrefix: > MIME-Version: 1.0 Content-Type: Text/Plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable Content-Disposition: inline Message-Id: <201103221231.27983.mkuehle@ikr.uni-stuttgart.de> Cc: serveh sadeghi Subject: Re: [ledbat] flightSize & cwnd 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, 22 Mar 2011 11:29:58 -0000 Hi Serveh, you are right, but we changed a couple of things in the just newly updated= =20 version of the draft (draft-ietf-ledbat-congestion-04). Please have a look = at=20 this version; there shouldn't any problem anymore. Mirja =2D- =2D-------------------- Here the code from the current draft: on acknowledgement: # flightsize is the amount of data oustanding before this ack # was received and is updated later by update_flightsize(); # bytes_newly_acked is the number of bytes that this ack # newly acknowledges, and it MAY be set to MSS; and # cwnd is in bytes. delay =3D acknowledgement.delay update_base_delay(delay) update_current_delay(delay) queuing_delay =3D MIN(current_delays) - MIN(base_delays) off_target =3D (TARGET - queuing_delay) / TARGET cwnd +=3D GAIN * off_target * bytes_newly_acked / cwnd max_allowed_cwnd =3D flightsize + ALLOWED_INCREASE * MSS cwnd =3D min(cwnd, max_allowed_cwnd) cwnd =3D max(cwnd, MIN_CWND * MSS) update_flightsize() #subtracts bytes_newly_acked from flightsize On Tuesday 22 March 2011 12:19:45 serveh sadeghi wrote: > Hi guys, > I=E2=80=99m implementing the congestion control mechanism used in =C2=B5T= P (LEDBAT ) and > I encountered some problems . > Here is what LEDBAT specification says about how to calculate cwnd: > off_target =3D TARGET - queuing_delay + random_input() > cwnd +=3D GAIN * off_target / cwnd > # flight_size() is the amount of currently not acked data. > max_allowed_cwnd =3D ALLOWED_INCREASE + TETHER*flight_size() > cwnd =3D min(cwnd, max_allowed_cwnd) > And here is the values spec suggests for the parameters: > TARGET =3D 100; > GAIN =3D 1.0; > ALLOWED_INCREASE =3D 1.0; > TETHER =3D 1.5; > Considering these , if flight_size becomes 0 at some point, > max_allowed_cwnd becomes 1.0, so whatever calculatedcwnd is, finalcwnd > would be 1.0(The minimum amount of cwnd while a TCP flow exists!). Even > worse , ifcwnd becomes 1.0, it remains 1.0 forever. Becausecwnd =3D 1.0 m= eans > just send 1 packet. So on receiving ack, flight_size would be 0 and > againmax_allowed_cwnd would be 1.0 ! > > > could you please guide me where I'm making mistake . From Rolf.Winter@neclab.eu Tue Mar 22 04:30:46 2011 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 BB1DB3A6820 for ; Tue, 22 Mar 2011 04:30:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.1 X-Spam-Level: X-Spam-Status: No, score=-102.1 tagged_above=-999 required=5 tests=[AWL=-0.101, BAYES_00=-2.599, J_CHICKENPOX_34=0.6, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id LOU5Wz5D5PXK for ; Tue, 22 Mar 2011 04:30:45 -0700 (PDT) Received: from smtp0.neclab.eu (smtp0.neclab.eu [195.37.70.41]) by core3.amsl.com (Postfix) with ESMTP id B782B3A67B7 for ; Tue, 22 Mar 2011 04:30:45 -0700 (PDT) Received: from localhost (localhost.localdomain [127.0.0.1]) by smtp0.neclab.eu (Postfix) with ESMTP id 11A552C0002E9; Tue, 22 Mar 2011 12:34:34 +0100 (CET) X-Virus-Scanned: Amavisd on Debian GNU/Linux (atlas2.office.hd) Received: from smtp0.neclab.eu ([127.0.0.1]) by localhost (atlas2.office.hd [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id R6yOAhQs5wOV; Tue, 22 Mar 2011 12:34:33 +0100 (CET) Received: from METHONE.office.hd (Methone.office.hd [192.168.24.54]) by smtp0.neclab.eu (Postfix) with ESMTP id E731B2C0002E8; Tue, 22 Mar 2011 12:34:23 +0100 (CET) Received: from DAPHNIS.office.hd ([169.254.2.136]) by METHONE.office.hd ([192.168.24.54]) with mapi id 14.01.0270.001; Tue, 22 Mar 2011 12:32:08 +0100 From: Rolf Winter To: serveh sadeghi , "ledbat@ietf.org" Thread-Topic: [ledbat] flightSize & cwnd Thread-Index: AQHL6INTjHa143+9UEuGSJ1YqK76cJQ5OD0g Date: Tue, 22 Mar 2011 11:32:08 +0000 Message-ID: <791AD3077F94194BB2BDD13565B6295D05DECD4B@DAPHNIS.office.hd> References: <71538.84873.qm@web114607.mail.gq1.yahoo.com> In-Reply-To: <71538.84873.qm@web114607.mail.gq1.yahoo.com> Accept-Language: en-US, de-DE Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.1.6.28] Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 Subject: Re: [ledbat] flightSize & cwnd 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, 22 Mar 2011 11:30:46 -0000 SGksDQoNCnRoZSBvbGQgY29uZ2VzdGlvbiBjb250cm9sIGZvcm11bGEgaGFkIGEgYnVnLiBDb3Vs ZCB5b3UgcmUtZXZhbHVhdGUgd2l0aCB0aGUgbmV3ZXN0IHZlcnNpb24gZm91bmQgYXQgDQoNCmh0 dHA6Ly90b29scy5pZXRmLm9yZy9odG1sL2RyYWZ0LWlldGYtbGVkYmF0LWNvbmdlc3Rpb24tMDQu DQoNCkJlc3QsDQoNClJvbGYNCg0KDQpORUMgRXVyb3BlIExpbWl0ZWQgfCBSZWdpc3RlcmVkIE9m ZmljZTogTkVDIEhvdXNlLCAxIFZpY3RvcmlhIFJvYWQsIExvbmRvbiBXMyA2QkwgfCBSZWdpc3Rl cmVkIGluIEVuZ2xhbmQgMjgzMjAxNCANCg0KDQo+IC0tLS0tT3JpZ2luYWwgTWVzc2FnZS0tLS0t DQo+IEZyb206IGxlZGJhdC1ib3VuY2VzQGlldGYub3JnIFttYWlsdG86bGVkYmF0LWJvdW5jZXNA aWV0Zi5vcmddIE9uDQo+IEJlaGFsZiBPZiBzZXJ2ZWggc2FkZWdoaQ0KPiBTZW50OiBEaWVuc3Rh ZywgMjIuIE3DpHJ6IDIwMTEgMTI6MjANCj4gVG86IGxlZGJhdEBpZXRmLm9yZw0KPiBTdWJqZWN0 OiBbbGVkYmF0XSBmbGlnaHRTaXplICYgY3duZA0KPiANCj4gSGkgZ3V5cywNCj4gDQo+IEnigJlt IGltcGxlbWVudGluZyB0aGUgY29uZ2VzdGlvbiBjb250cm9sIG1lY2hhbmlzbSB1c2VkIGluIMK1 VFAgKExFREJBVCApDQo+IGFuZCBJIGVuY291bnRlcmVkIHNvbWUgcHJvYmxlbXMgLg0KPiANCj4g SGVyZSBpcyB3aGF0IExFREJBVCBzcGVjaWZpY2F0aW9uIHNheXMgYWJvdXQgaG93IHRvIGNhbGN1 bGF0ZSBjd25kOg0KPiANCj4gb2ZmX3RhcmdldCA9IFRBUkdFVCAtIHF1ZXVpbmdfZGVsYXkgKyBy YW5kb21faW5wdXQoKQ0KPiANCj4gY3duZCArPSBHQUlOICogb2ZmX3RhcmdldCAvIGN3bmQNCj4g DQo+ICMgZmxpZ2h0X3NpemUoKSBpcyB0aGUgYW1vdW50IG9mIGN1cnJlbnRseSBub3QgYWNrZWQg ZGF0YS4NCj4gDQo+IG1heF9hbGxvd2VkX2N3bmQgPSBBTExPV0VEX0lOQ1JFQVNFICsgVEVUSEVS KmZsaWdodF9zaXplKCkNCj4gDQo+IGN3bmQgPSBtaW4oY3duZCwgbWF4X2FsbG93ZWRfY3duZCkN Cj4gDQo+IEFuZCBoZXJlIGlzIHRoZSB2YWx1ZXMgc3BlYyBzdWdnZXN0cyBmb3IgdGhlIHBhcmFt ZXRlcnM6DQo+IA0KPiBUQVJHRVQgPSAxMDA7DQo+IA0KPiBHQUlOID0gMS4wOw0KPiANCj4gQUxM T1dFRF9JTkNSRUFTRSA9IDEuMDsNCj4gDQo+IFRFVEhFUiA9IDEuNTsNCj4gDQo+IENvbnNpZGVy aW5nIHRoZXNlICwgaWYgZmxpZ2h0X3NpemUgYmVjb21lcyAwIGF0IHNvbWUgcG9pbnQsDQo+IG1h eF9hbGxvd2VkX2N3bmQgYmVjb21lcyAxLjAsIHNvIHdoYXRldmVyIGNhbGN1bGF0ZWQgY3duZCBp cywgZmluYWwNCj4gY3duZCB3b3VsZCBiZSAxLjAoVGhlIG1pbmltdW0gYW1vdW50IG9mIGN3bmQg d2hpbGUgYSBUQ1AgZmxvdyBleGlzdHMhKS4NCj4gRXZlbiB3b3JzZSAsIGlmIGN3bmQgYmVjb21l cyAxLjAsIGl0IHJlbWFpbnMgMS4wIGZvcmV2ZXIuIEJlY2F1c2UgY3duZA0KPiA9IDEuMCBtZWFu cyBqdXN0IHNlbmQgMSBwYWNrZXQuIFNvIG9uIHJlY2VpdmluZyBhY2ssIGZsaWdodF9zaXplIHdv dWxkDQo+IGJlIDAgYW5kIGFnYWluIG1heF9hbGxvd2VkX2N3bmQgd291bGQgYmUgMS4wICENCj4g DQo+IA0KPiANCj4gDQo+IGNvdWxkIHlvdSBwbGVhc2UgZ3VpZGUgbWUgd2hlcmUgSSdtIG1ha2lu ZyBtaXN0YWtlIC4NCj4gDQo+IA0KPiANCj4gDQo+IA0KDQo= From muraris@microsoft.com Sun Mar 27 05:45:15 2011 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 4941D28C112 for ; Sun, 27 Mar 2011 05:45:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -109.999 X-Spam-Level: X-Spam-Status: No, score=-109.999 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, J_CHICKENPOX_34=0.6, RCVD_IN_DNSWL_HI=-8, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id wpzR817eygbS for ; Sun, 27 Mar 2011 05:45:14 -0700 (PDT) Received: from smtp.microsoft.com (smtp.microsoft.com [131.107.115.214]) by core3.amsl.com (Postfix) with ESMTP id 1C4F93A6823 for ; Sun, 27 Mar 2011 05:45:14 -0700 (PDT) Received: from TK5EX14MLTC102.redmond.corp.microsoft.com (157.54.79.180) by TK5-EXGWY-E803.partners.extranet.microsoft.com (10.251.56.169) with Microsoft SMTP Server (TLS) id 8.2.176.0; Sun, 27 Mar 2011 05:46:50 -0700 Received: from tk5ex14mbxc105.redmond.corp.microsoft.com ([169.254.2.31]) by TK5EX14MLTC102.redmond.corp.microsoft.com ([157.54.79.180]) with mapi id 14.01.0270.002; Sun, 27 Mar 2011 05:46:50 -0700 From: Murari Sridharan To: Rolf Winter , "ledbat@ietf.org" Thread-Topic: Review of ledbat draft Thread-Index: AcvsfQEARBe2LkGHTnawo+Cz7i7JwA== Date: Sun, 27 Mar 2011 12:46:50 +0000 Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [157.54.123.12] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: [ledbat] Review of ledbat draft 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: Sun, 27 Mar 2011 12:45:15 -0000 My review as an individual contributor.=20 I think the draft is almost there thanks to Jana and Mirja's efforts. There= are a couple of issues that I'd like taken care of. I think (assuming I re= ad it right) #3 and #8 are critical and must be fixed.=20 1. " LEDBAT can be used, with appropriate extensions where necessary, with= TCP" - I'd like to add some serious caveats as this statement makes it loo= k like it is easily doable. Getting Ledbat to work over TCP requires re-pur= posing timestamps in a way end nodes agree and understand. I am not questio= ning the ease of implementation but this would require a decent amount of w= ork which the statement above doesn't quite reflect.=20 2. Editorial: " LEDBAT decreases its sending rate quickly as a response to = potential congestion in the network" - I'd remove the word potential here.= Potential makes it look like we either don't believe delay increase implie= s congestion or we don't trust our delay measurements.=20 3. May be I am reading this wrong but I think the following is incorrect.=20 queuing_delay =3D MIN(current_delays) - MIN(base_delays) update_current_delay(delay) # Maintain a list of CURRENT_FILTER last delays observed. delete first item in current_delays list append delay to current_delays list The above seems wrong to me because all you need is a few packets to go thr= ough without queueing and infact ledbat relies on this to get the correct b= ase delay. Some form of average is needed to protect from this otherwise MI= N (current delays) has a pretty good chance of being same as MIN(base delay= ) and therefore we continue to ramp up when infact we shouldn't. 4. GAIN MUST be set to 1 or less. - Why not just say MUST be set to 1, per = our goals that's the right value 5. In practice other delay based algorithms dump the base delay and history= when it hits a timeout which is the safe thing to do, we should be recomme= nding something along those lines in the discussion section.=20 6. Editorial: " end-to-end delay measurement" - It may avoid confusion if = we keep using one-way delay throughout. For a second I misread E2E as RTT. 7. " delay of 150 ms to be acceptable for most user voice applications." = - Hmm seems high, I always thought that this number was more like 50ms from= SONET numbers.=20 8. "LEDBAT does require that the receiver MUST transmit at least one ack in= every RTT"=20 I think this is a problem as it will make the Ledbat controller ineffective= due to bursty release of packets from the send queues upon ACK. Large burs= ts means flows in the network often see uncharacteristic spikes which makes= them go back only to find that further measurements are clean. I think we = should recommend that the receiver ACK once every 2 data packets similar t= o TCP to keep the ack clock going. 9. RFC 3390 doesn't sound normative to me and if we are making 5681 normati= ve for loss based cc then Bra94 should also be made normative for delay bas= ed cc.=20 -----Original Message----- From: ledbat-bounces@ietf.org [mailto:ledbat-bounces@ietf.org] On Behalf Of= Rolf Winter Sent: Monday, March 21, 2011 9:04 AM To: ledbat@ietf.org Subject: [ledbat] congestion control draft Hi, since people clearly have started to read and digest the newest version of = the draft, the chairs would appreciate if you could post your general feedb= ack about the document. Something like "I think this is good now" or "it ha= s addressed my previous concerns" etc. would be good feedback for us. Thanks, Rolf NEC Europe Limited | Registered Office: NEC House, 1 Victoria Road, London = W3 6BL | Registered in England 2832014=20 _______________________________________________ ledbat mailing list ledbat@ietf.org https://www.ietf.org/mailman/listinfo/ledbat From muraris@microsoft.com Sun Mar 27 05:46:54 2011 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 830823A67E3 for ; Sun, 27 Mar 2011 05:46:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -109.999 X-Spam-Level: X-Spam-Status: No, score=-109.999 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, J_CHICKENPOX_34=0.6, RCVD_IN_DNSWL_HI=-8, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id yjbEdtss5iRd for ; Sun, 27 Mar 2011 05:46:53 -0700 (PDT) Received: from smtp.microsoft.com (mail3.microsoft.com [131.107.115.214]) by core3.amsl.com (Postfix) with ESMTP id 6CD9F3A67CC for ; Sun, 27 Mar 2011 05:46:53 -0700 (PDT) Received: from TK5EX14HUBC102.redmond.corp.microsoft.com (157.54.7.154) by TK5-EXGWY-E803.partners.extranet.microsoft.com (10.251.56.169) with Microsoft SMTP Server (TLS) id 8.2.176.0; Sun, 27 Mar 2011 05:48:29 -0700 Received: from tk5ex14mbxc105.redmond.corp.microsoft.com ([169.254.2.31]) by TK5EX14HUBC102.redmond.corp.microsoft.com ([157.54.7.154]) with mapi id 14.01.0270.002; Sun, 27 Mar 2011 05:48:30 -0700 From: Murari Sridharan To: Murari Sridharan , Rolf Winter , "ledbat@ietf.org" Thread-Topic: Review of ledbat draft Thread-Index: AcvsfQEARBe2LkGHTnawo+Cz7i7JwAAAC1dg Date: Sun, 27 Mar 2011 12:48:29 +0000 Message-ID: References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [157.54.123.12] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: Re: [ledbat] Review of ledbat draft 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: Sun, 27 Mar 2011 12:46:54 -0000 Rolf, I have some other typos fixed will fwd a commented version to Jana an= d Mirja offline.=20 Thanks -----Original Message----- From: ledbat-bounces@ietf.org [mailto:ledbat-bounces@ietf.org] On Behalf Of= Murari Sridharan Sent: Sunday, March 27, 2011 5:47 AM To: Rolf Winter; ledbat@ietf.org Subject: [ledbat] Review of ledbat draft My review as an individual contributor.=20 I think the draft is almost there thanks to Jana and Mirja's efforts. There= are a couple of issues that I'd like taken care of. I think (assuming I re= ad it right) #3 and #8 are critical and must be fixed.=20 1. " LEDBAT can be used, with appropriate extensions where necessary, with= TCP" - I'd like to add some serious caveats as this statement makes it loo= k like it is easily doable. Getting Ledbat to work over TCP requires re-pur= posing timestamps in a way end nodes agree and understand. I am not questio= ning the ease of implementation but this would require a decent amount of w= ork which the statement above doesn't quite reflect.=20 2. Editorial: " LEDBAT decreases its sending rate quickly as a response to = potential congestion in the network" - I'd remove the word potential here.= Potential makes it look like we either don't believe delay increase implie= s congestion or we don't trust our delay measurements.=20 3. May be I am reading this wrong but I think the following is incorrect.=20 queuing_delay =3D MIN(current_delays) - MIN(base_delays) update_current_delay(delay) # Maintain a list of CURRENT_FILTER last delays observed. delete first item in current_delays list append delay to current_delays list The above seems wrong to me because all you need is a few packets to go thr= ough without queueing and infact ledbat relies on this to get the correct b= ase delay. Some form of average is needed to protect from this otherwise MI= N (current delays) has a pretty good chance of being same as MIN(base delay= ) and therefore we continue to ramp up when infact we shouldn't. 4. GAIN MUST be set to 1 or less. - Why not just say MUST be set to 1, per = our goals that's the right value 5. In practice other delay based algorithm= s dump the base delay and history when it hits a timeout which is the safe = thing to do, we should be recommending something along those lines in the d= iscussion section.=20 6. Editorial: " end-to-end delay measurement" - It may avoid confusion if = we keep using one-way delay throughout. For a second I misread E2E as RTT. 7. " delay of 150 ms to be acceptable for most user voice applications." = - Hmm seems high, I always thought that this number was more like 50ms from= SONET numbers.=20 8. "LEDBAT does require that the receiver MUST transmit at least one ack in= every RTT"=20 I think this is a problem as it will make the Ledbat controller ineffective= due to bursty release of packets from the send queues upon ACK. Large burs= ts means flows in the network often see uncharacteristic spikes which makes= them go back only to find that further measurements are clean. I think we = should recommend that the receiver ACK once every 2 data packets similar t= o TCP to keep the ack clock going. 9. RFC 3390 doesn't sound normative to me and if we are making 5681 normati= ve for loss based cc then Bra94 should also be made normative for delay bas= ed cc.=20 -----Original Message----- From: ledbat-bounces@ietf.org [mailto:ledbat-bounces@ietf.org] On Behalf Of= Rolf Winter Sent: Monday, March 21, 2011 9:04 AM To: ledbat@ietf.org Subject: [ledbat] congestion control draft Hi, since people clearly have started to read and digest the newest version of = the draft, the chairs would appreciate if you could post your general feedb= ack about the document. Something like "I think this is good now" or "it ha= s addressed my previous concerns" etc. would be good feedback for us. Thanks, Rolf NEC Europe Limited | Registered Office: NEC House, 1 Victoria Road, London = W3 6BL | Registered in England 2832014=20 _______________________________________________ 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 richard_woundy@cable.comcast.com Mon Mar 28 01:37:00 2011 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 33E073A6927 for ; Mon, 28 Mar 2011 01:37:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.291 X-Spam-Level: X-Spam-Status: No, score=-102.291 tagged_above=-999 required=5 tests=[AWL=-1.156, BAYES_00=-2.599, HELO_MISMATCH_COM=0.553, HOST_MISMATCH_NET=0.311, J_CHICKENPOX_34=0.6, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id hQEHn4EJiDx8 for ; Mon, 28 Mar 2011 01:36:59 -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 0CC5C3A6940 for ; Mon, 28 Mar 2011 01:36:58 -0700 (PDT) Received: from ([24.40.55.40]) by copdcimo01.cable.comcast.com with ESMTP with TLS id 5503630.31198385; Mon, 28 Mar 2011 02:41:14 -0600 Received: from PACDCEXMB05.cable.comcast.com ([fe80::a5b0:e5c4:df1b:2367]) by pacdcexhub03.cable.comcast.com ([fe80::d1dd:b302:b617:3755%12]) with mapi id 14.01.0270.001; Mon, 28 Mar 2011 04:38:34 -0400 From: "Woundy, Richard" To: Murari Sridharan , Rolf Winter Thread-Topic: Review of ledbat draft Thread-Index: AcvsfQEARBe2LkGHTnawo+Cz7i7JwAAo7cCw Date: Mon, 28 Mar 2011 08:38:32 +0000 Message-ID: <1CA25301D2219F40B3AA37201F0EACD1134D2943@PACDCEXMB05.cable.comcast.com> References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [76.96.111.6] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "ledbat@ietf.org" Subject: Re: [ledbat] Review of ledbat draft 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, 28 Mar 2011 08:37:00 -0000 I wanted to make a quick comment on Murari's excellent review. >7. " delay of 150 ms to be acceptable for most user voice applications."= - Hmm seems high, I always thought that this number was more like 50ms fro= m SONET numbers. 50ms is about SONET restoration time, not typical SONET delay. A definitive reference for acceptable delay for voice applications is: ITU-= T G.114 (5/2003) SERIES G: TRANSMISSION SYSTEMS AND MEDIA, DIGITAL SYSTEMS = AND NETWORKS, Figure 1, page 3, One way transmission time. That ITU diagram shows that voice quality begins to drop when the end-to-en= d one-way delay exceeds 150ms, and crosses the threshold from "users very s= atisfied" to "users satisfied" around 200ms. But note that the end-to-end delay includes factors beyond the network tran= smission delay, such as codec delay, packetization delay, jitter buffer del= ay, etc. This is why the target delay for network transmission tends to be = lower. -- Rich -----Original Message----- From: ledbat-bounces@ietf.org [mailto:ledbat-bounces@ietf.org] On Behalf Of= Murari Sridharan Sent: Sunday, March 27, 2011 8:47 AM To: Rolf Winter; ledbat@ietf.org Subject: [ledbat] Review of ledbat draft My review as an individual contributor.=20 I think the draft is almost there thanks to Jana and Mirja's efforts. There= are a couple of issues that I'd like taken care of. I think (assuming I re= ad it right) #3 and #8 are critical and must be fixed.=20 1. " LEDBAT can be used, with appropriate extensions where necessary, with= TCP" - I'd like to add some serious caveats as this statement makes it loo= k like it is easily doable. Getting Ledbat to work over TCP requires re-pur= posing timestamps in a way end nodes agree and understand. I am not questio= ning the ease of implementation but this would require a decent amount of w= ork which the statement above doesn't quite reflect.=20 2. Editorial: " LEDBAT decreases its sending rate quickly as a response to = potential congestion in the network" - I'd remove the word potential here.= Potential makes it look like we either don't believe delay increase implie= s congestion or we don't trust our delay measurements.=20 3. May be I am reading this wrong but I think the following is incorrect.=20 queuing_delay =3D MIN(current_delays) - MIN(base_delays) update_current_delay(delay) # Maintain a list of CURRENT_FILTER last delays observed. delete first item in current_delays list append delay to current_delays list The above seems wrong to me because all you need is a few packets to go thr= ough without queueing and infact ledbat relies on this to get the correct b= ase delay. Some form of average is needed to protect from this otherwise MI= N (current delays) has a pretty good chance of being same as MIN(base delay= ) and therefore we continue to ramp up when infact we shouldn't. 4. GAIN MUST be set to 1 or less. - Why not just say MUST be set to 1, per = our goals that's the right value 5. In practice other delay based algorithms dump the base delay and history= when it hits a timeout which is the safe thing to do, we should be recomme= nding something along those lines in the discussion section.=20 6. Editorial: " end-to-end delay measurement" - It may avoid confusion if = we keep using one-way delay throughout. For a second I misread E2E as RTT. 7. " delay of 150 ms to be acceptable for most user voice applications." = - Hmm seems high, I always thought that this number was more like 50ms from= SONET numbers.=20 8. "LEDBAT does require that the receiver MUST transmit at least one ack in= every RTT"=20 I think this is a problem as it will make the Ledbat controller ineffective= due to bursty release of packets from the send queues upon ACK. Large burs= ts means flows in the network often see uncharacteristic spikes which makes= them go back only to find that further measurements are clean. I think we = should recommend that the receiver ACK once every 2 data packets similar t= o TCP to keep the ack clock going. 9. RFC 3390 doesn't sound normative to me and if we are making 5681 normati= ve for loss based cc then Bra94 should also be made normative for delay bas= ed cc.=20 -----Original Message----- From: ledbat-bounces@ietf.org [mailto:ledbat-bounces@ietf.org] On Behalf Of= Rolf Winter Sent: Monday, March 21, 2011 9:04 AM To: ledbat@ietf.org Subject: [ledbat] congestion control draft Hi, since people clearly have started to read and digest the newest version of = the draft, the chairs would appreciate if you could post your general feedb= ack about the document. Something like "I think this is good now" or "it ha= s addressed my previous concerns" etc. would be good feedback for us. Thanks, Rolf NEC Europe Limited | Registered Office: NEC House, 1 Victoria Road, London = W3 6BL | Registered in England 2832014=20 _______________________________________________ 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 serveh_ram21@yahoo.com Mon Mar 28 01:49:15 2011 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 65A7B3A68EE for ; Mon, 28 Mar 2011 01:49:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.998 X-Spam-Level: X-Spam-Status: No, score=-1.998 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, J_CHICKENPOX_34=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 Hgt4JCv+Lyn2 for ; Mon, 28 Mar 2011 01:49:14 -0700 (PDT) Received: from web114606.mail.gq1.yahoo.com (web114606.mail.gq1.yahoo.com [98.136.183.35]) by core3.amsl.com (Postfix) with SMTP id 5A2903A684E for ; Mon, 28 Mar 2011 01:49:14 -0700 (PDT) Received: (qmail 70521 invoked by uid 60001); 28 Mar 2011 08:50:49 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s1024; t=1301302249; bh=h74Lwz91z1huBw58vOwU1Ehe7LmkE/e76q4G34qjNWk=; h=Message-ID:X-YMail-OSG:Received:X-Mailer:References:Date:From:Subject:To:In-Reply-To:MIME-Version:Content-Type; b=YeKllohTe45OfBuHbu5RTWw2OkudLh0Dbdzo1NlJLFPufQVs51HTYJarKZKpacrOqPHqjEkvFW9HF38yRsn+0ux2o+Xmc2Qat80DWXNPLM9WK2fnEkV9B2noYn1vVx6AUpXKjsbTVdHIstRozttRVp9gh3RS71piiHdZY64kB8A= DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=s1024; d=yahoo.com; h=Message-ID:X-YMail-OSG:Received:X-Mailer:References:Date:From:Subject:To:In-Reply-To:MIME-Version:Content-Type; b=Oreqaaj3ubeyKkSzTsQ5AtvGyPNAIBThkXzNY7x1n/2bGOKUYJmQR/ESoXAObL8UJN0OkrG5z19NrT0zgqSgcb1pNzrghR8vFzI4tOxJlLnYB4OKlzfH3QSNS5F9S5Rnk1IpqhqkSWTy4VBNX8xq1NfiQb53/p4KbVIg+NyFpRc=; Message-ID: <14772.69381.qm@web114606.mail.gq1.yahoo.com> X-YMail-OSG: 7tYElk0VM1k4l5WgecuC3o4805qMoFrTrQaPDK4tgVUysK3 vZpBz55oqvRVyKScGU3mvcMGb0fjXblbYsp6XvlnfU4fcj.zcRuJGF4B_KjX Mp0lw_OTiwSgtCruqrD7Jm868UJw80HSlcvrswURm_A4fthD.nyGnIsESNrM ETD3k7fy1rGo06o456HzB8U71zR.3RdlIhzvlRZQFRYrv14wXW7WjxaG6Jeo gTl4X6si6cc8_synE7axZZdP.G3l_gceZ0KEFICZwgYZWxMGP5hkX37QwyRD MyPDbRGgTxw7QQce91ItdVZbpBhvDBicLSP8hQN3PhP8e7NVyY1vYxysLNN9 vjjtvGmV7cTA4NOUY19lrzMJX5v0kU1PjbuQeLjsJc1MtoYx6ihvrflc- Received: from [213.103.204.231] by web114606.mail.gq1.yahoo.com via HTTP; Mon, 28 Mar 2011 01:50:48 PDT X-Mailer: YahooMailRC/559 YahooMailWebService/0.8.109.295617 References: <71538.84873.qm@web114607.mail.gq1.yahoo.com> <791AD3077F94194BB2BDD13565B6295D05DECD4B@DAPHNIS.office.hd> Date: Mon, 28 Mar 2011 01:50:48 -0700 (PDT) From: serveh sadeghi To: ledbat@ietf.org In-Reply-To: <791AD3077F94194BB2BDD13565B6295D05DECD4B@DAPHNIS.office.hd> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="0-385426931-1301302248=:69381" Subject: Re: [ledbat] flightSize & cwnd 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, 28 Mar 2011 08:49:15 -0000 --0-385426931-1301302248=:69381 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Hi guys,=0AIf you start with init_cwnd=3D2 packets and your mss is 1500 ,in= itial cwnd is 3000 =0Abytes. on receiving the ack for both sent packets, = having queuing_delay 0, =0Aoff_target would be 1.0.=0Aoff_target =3D (TARG= ET - queuing_delay) / TARGET=0Acwnd +=3D GAIN * off_target * bytes_newly_ac= ked / cwnd=0A =0Aand new cwnd would be 3000 + 1.0 * 1.0 * 3000 / 3000 =3D 3= 001=0ASo if you just send 2 packets and receive both, and there is no conge= stion at =0Aall(queuing_delay =3D 0), you expect that new cwnd would increa= se very much, not =0Aonly one byte. I run this in a long time and the chart= produced for cwnd size is =0Anot increasing that much.The chart is not wha= t I expected.=0A=0A=0A=0A________________________________=0AFrom: Rolf Wint= er =0ATo: serveh sadeghi ; "= ledbat@ietf.org" =0ASent: Tue, March 22, 2011 12:32:08 PM= =0ASubject: RE: [ledbat] flightSize & cwnd=0A=0AHi,=0A=0Athe old congestion= control formula had a bug. Could you re-evaluate with the =0Anewest versio= n found at =0A=0A=0Ahttp://tools.ietf.org/html/draft-ietf-ledbat-congestion= -04. =0A=0ABest,=0A=0ARolf=0A=0A=0ANEC Europe Limited | Registered Office: = NEC House, 1 Victoria Road, London W3 =0A6BL | Registered in England 283201= 4 =0A=0A=0A=0A> -----Original Message-----=0A> From: ledbat-bounces@ietf.or= g [mailto:ledbat-bounces@ietf.org] On=0A> Behalf Of serveh sadeghi=0A> Sent= : Dienstag, 22. M=C3=A4rz 2011 12:20=0A> To: ledbat@ietf.org=0A> Subject: [= ledbat] flightSize & cwnd=0A> =0A> Hi guys,=0A> =0A> I=E2=80=99m implementi= ng the congestion control mechanism used in =C2=B5TP (LEDBAT )=0A> and I en= countered some problems .=0A> =0A> Here is what LEDBAT specification says a= bout how to calculate cwnd:=0A> =0A> off_target =3D TARGET - queuing_delay = + random_input()=0A> =0A> cwnd +=3D GAIN * off_target / cwnd=0A> =0A> # fli= ght_size() is the amount of currently not acked data.=0A> =0A> max_allowed_= cwnd =3D ALLOWED_INCREASE + TETHER*flight_size()=0A> =0A> cwnd =3D min(cwnd= , max_allowed_cwnd)=0A> =0A> And here is the values spec suggests for the p= arameters:=0A> =0A> TARGET =3D 100;=0A> =0A> GAIN =3D 1.0;=0A> =0A> ALLOWED= _INCREASE =3D 1.0;=0A> =0A> TETHER =3D 1.5;=0A> =0A> Considering these , if= flight_size becomes 0 at some point,=0A> max_allowed_cwnd becomes 1.0, so = whatever calculated cwnd is, final=0A> cwnd would be 1.0(The minimum amount= of cwnd while a TCP flow exists!).=0A> Even worse , if cwnd becomes 1.0, i= t remains 1.0 forever. Because cwnd=0A> =3D 1.0 means just send 1 packet. S= o on receiving ack, flight_size would=0A> be 0 and again max_allowed_cwnd w= ould be 1.0 !=0A> =0A> =0A> =0A> =0A> could you please guide me where I'm m= aking mistake .=0A> =0A> =0A> =0A> =0A> =0A=0A=0A --0-385426931-1301302248=:69381 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: quoted-printable

Hi guys,

If you start with init_cwn= d=3D2=0Apackets and your mss is 1500 ,initial cwnd is 3000 bytes. on  = receiving  the ack for both sent packets,  having queuing_de= lay 0, off_target would be 1.0.

=0A=0Aoff_target =3D (T= ARGET -=0Aqueuing_delay) / TARGET

=0A=0A

cwnd +=3D GAIN *=0Aoff_target * bytes_newly_acked = / cwnd

=0A=0A

 

=0A= =0A

and new cwnd would be 3000 +=0A1.0 * 1.0 * 3000 / 3000 =3D 3001

=0A=0A

So if you just send 2=0Apackets and receive both, and t= here is no congestion at all(queuing_delay =3D 0),=0Ayou expect that new cw= nd would increase very much, not only one byte. I run=0Athis in a long time= and the chart produced for cwnd size is not increasing that=0Amuch.The cha= rt is not what I expected.


From:= Rolf Winter <Rolf.Winter@neclab.eu>
To: serveh sadeghi <serveh_ram21@yahoo.com>; "led= bat@ietf.org" <ledbat@ietf.org>
Sent: Tue, March 22, 2011 12:32:08 PM
Subject: RE: [ledbat] flightSize & cwnd
=0AHi,

the old congestion control formula had a bug. Co= uld you re-evaluate with the newest version found at

http://tools.ietf.org/html/draft-ietf-ledbat-congestion-04.=0A
<= br>Best,

Rolf


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

> -----Original Message-----
> From: ledbat-bou= nces@ietf.org [mailto:ledbat-bounces@ietf.org] On
>= ; Behalf Of serveh sadeghi
> Sent: Dienstag, 22. M=C3=A4rz 2011 12:20=
> To: ledbat@ietf.org
> Subject: [ledbat] flightSize & cwnd=
>
> Hi guys,
>
> I=E2=80=99m implementing the co= ngestion control mechanism used in =C2=B5TP (LEDBAT )
> and I encount= ered some problems .
>
> Here is what LEDBAT specification say= s about how to calculate cwnd:
>
> off_target =3D TARGET - que= uing_delay + random_input()
>
> cwnd +=3D GAIN * off_target / cwnd
>=
> # flight_size() is the amount of currently not acked data.
>= ;
> max_allowed_cwnd =3D ALLOWED_INCREASE + TETHER*flight_size()
= >
> cwnd =3D min(cwnd, max_allowed_cwnd)
>
> And her= e is the values spec suggests for the parameters:
>
> TARGET = =3D 100;
>
> GAIN =3D 1.0;
>
> ALLOWED_INCREASE = =3D 1.0;
>
> TETHER =3D 1.5;
>
> Considering thes= e , if flight_size becomes 0 at some point,
> max_allowed_cwnd become= s 1.0, so whatever calculated cwnd is, final
> cwnd would be 1.0(The = minimum amount of cwnd while a TCP flow exists!).
> Even worse , if c= wnd becomes 1.0, it remains 1.0 forever. Because cwnd
> =3D 1.0 means= just send 1 packet. So on receiving ack, flight_size would
> be 0 an= d again max_allowed_cwnd would be 1.0 !
>
>
>
> =
> could you please guide me where I'm making mistake .
>
>
= >
>
>

=0A= =0A=0A

=0A=0A --0-385426931-1301302248=:69381-- From mirja.kuehlewind@ikr.uni-stuttgart.de Mon Mar 28 02:03:52 2011 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 8F4323A687A for ; Mon, 28 Mar 2011 02:03:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.788 X-Spam-Level: X-Spam-Status: No, score=-1.788 tagged_above=-999 required=5 tests=[AWL=-0.139, BAYES_00=-2.599, HELO_EQ_DE=0.35, J_CHICKENPOX_34=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 CNwaznjTBWED for ; Mon, 28 Mar 2011 02:03:51 -0700 (PDT) Received: from mailsrv.ikr.uni-stuttgart.de (mailsrv.ikr.uni-stuttgart.de [129.69.170.2]) by core3.amsl.com (Postfix) with ESMTP id 150D23A6864 for ; Mon, 28 Mar 2011 02:03:51 -0700 (PDT) Received: from netsrv1.ikr.uni-stuttgart.de (netsrv1-c [10.11.12.12]) by mailsrv.ikr.uni-stuttgart.de (Postfix) with ESMTP id 769CC633B1; Mon, 28 Mar 2011 11:05:26 +0200 (CEST) Received: from vpn-2-cl177 (vpn-2-cl177 [10.41.21.177]) by netsrv1.ikr.uni-stuttgart.de (Postfix) with ESMTP id 5D14A59A8A; Mon, 28 Mar 2011 11:05:26 +0200 (CEST) From: Mirja Kuehlewind Organization: University of Stuttgart (Germany), IKR To: ledbat@ietf.org, Janardhan Iyengar Date: Mon, 28 Mar 2011 11:05:25 +0200 User-Agent: KMail/1.9.10 (enterprise35 0.20101217.1207316) References: <71538.84873.qm@web114607.mail.gq1.yahoo.com> <791AD3077F94194BB2BDD13565B6295D05DECD4B@DAPHNIS.office.hd> <14772.69381.qm@web114606.mail.gq1.yahoo.com> In-Reply-To: <14772.69381.qm@web114606.mail.gq1.yahoo.com> X-KMail-QuotePrefix: > MIME-Version: 1.0 Content-Type: Text/Plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable Content-Disposition: inline Message-Id: <201103281105.25707.mirja.kuehlewind@ikr.uni-stuttgart.de> Cc: serveh sadeghi Subject: Re: [ledbat] flightSize & cwnd 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, 28 Mar 2011 09:03:52 -0000 Hi Serveh, sorry, we've been missing an *MSS here: cwnd +=3D GAIN * off_target * bytes_newly_acked / cwnd * MSS That's because we've just changed from a cwnd in packets to a cwnd in bytes= =2E.. Thanks for the pointer!! Mirja On Monday 28 March 2011 10:50:48 serveh sadeghi wrote: > Hi guys, > If you start with init_cwnd=3D2 packets and your mss is 1500 ,initial cwn= d is > 3000 bytes. on receiving the ack for both sent packets, having > queuing_delay 0, off_target would be 1.0. > off_target =3D (TARGET - queuing_delay) / TARGET > cwnd +=3D GAIN * off_target * bytes_newly_acked / cwnd > > and new cwnd would be 3000 + 1.0 * 1.0 * 3000 / 3000 =3D 3001 > So if you just send 2 packets and receive both, and there is no congestion > at all(queuing_delay =3D 0), you expect that new cwnd would increase very > much, not only one byte. I run this in a long time and the chart produced > for cwnd size is not increasing that much.The chart is not what I expecte= d. > > > > ________________________________ > From: Rolf Winter > To: serveh sadeghi ; "ledbat@ietf.org" > Sent: Tue, March 22, 2011 12:32:08 PM > Subject: RE: [ledbat] flightSize & cwnd > > Hi, > > the old congestion control formula had a bug. Could you re-evaluate with > the newest version found at > > > http://tools.ietf.org/html/draft-ietf-ledbat-congestion-04. > > Best, > > Rolf > > > NEC Europe Limited | Registered Office: NEC House, 1 Victoria Road, London > W3 6BL | Registered in England 2832014 > > > -----Original Message----- > > From: ledbat-bounces@ietf.org [mailto:ledbat-bounces@ietf.org] On > > Behalf Of serveh sadeghi > > Sent: Dienstag, 22. M=C3=A4rz 2011 12:20 > > To: ledbat@ietf.org > > Subject: [ledbat] flightSize & cwnd > > > > Hi guys, > > > > I=E2=80=99m implementing the congestion control mechanism used in =C2= =B5TP (LEDBAT ) > > and I encountered some problems . > > > > Here is what LEDBAT specification says about how to calculate cwnd: > > > > off_target =3D TARGET - queuing_delay + random_input() > > > > cwnd +=3D GAIN * off_target / cwnd > > > > # flight_size() is the amount of currently not acked data. > > > > max_allowed_cwnd =3D ALLOWED_INCREASE + TETHER*flight_size() > > > > cwnd =3D min(cwnd, max_allowed_cwnd) > > > > And here is the values spec suggests for the parameters: > > > > TARGET =3D 100; > > > > GAIN =3D 1.0; > > > > ALLOWED_INCREASE =3D 1.0; > > > > TETHER =3D 1.5; > > > > Considering these , if flight_size becomes 0 at some point, > > max_allowed_cwnd becomes 1.0, so whatever calculated cwnd is, final > > cwnd would be 1.0(The minimum amount of cwnd while a TCP flow exists!). > > Even worse , if cwnd becomes 1.0, it remains 1.0 forever. Because cwnd > > =3D 1.0 means just send 1 packet. So on receiving ack, flight_size would > > be 0 and again max_allowed_cwnd would be 1.0 ! > > > > > > > > > > could you please guide me where I'm making mistake . =2D-=20 =2D------------------------------------------------------------------ Dipl.-Ing. Mirja K=C3=BChlewind Institute of Communication Networks and Computer Engineering (IKR) University of Stuttgart, Germany Pfaffenwaldring 47, D-70569 Stuttgart tel: +49(0)711/685-67973 email: mirja.kuehlewind@ikr.uni-stuttgart.de web: www.ikr.uni-stuttgart.de =2D------------------------------------------------------------------ From muraris@microsoft.com Mon Mar 28 02:14:01 2011 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 6E2523A684B for ; Mon, 28 Mar 2011 02:14:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -109.999 X-Spam-Level: X-Spam-Status: No, score=-109.999 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, J_CHICKENPOX_34=0.6, RCVD_IN_DNSWL_HI=-8, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id R-+d7QAwyBCG for ; Mon, 28 Mar 2011 02:14:00 -0700 (PDT) Received: from smtp.microsoft.com (mailb.microsoft.com [131.107.115.215]) by core3.amsl.com (Postfix) with ESMTP id 5C9323A6843 for ; Mon, 28 Mar 2011 02:14:00 -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, 28 Mar 2011 02:15:37 -0700 Received: from tk5ex14mbxc105.redmond.corp.microsoft.com ([169.254.2.31]) by TK5EX14MLTC101.redmond.corp.microsoft.com ([157.54.79.178]) with mapi id 14.01.0270.002; Mon, 28 Mar 2011 02:15:37 -0700 From: Murari Sridharan To: "Woundy, Richard" , Rolf Winter Thread-Topic: Review of ledbat draft Thread-Index: AcvsfQEARBe2LkGHTnawo+Cz7i7JwAAo7cCwAAH+yG0= Date: Mon, 28 Mar 2011 09:15:37 +0000 Message-ID: References: , <1CA25301D2219F40B3AA37201F0EACD1134D2943@PACDCEXMB05.cable.comcast.com> In-Reply-To: <1CA25301D2219F40B3AA37201F0EACD1134D2943@PACDCEXMB05.cable.comcast.com> 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] Review of ledbat draft 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, 28 Mar 2011 09:14:01 -0000 Ok. I thought the sonet restoration time was motivated due to voice quality= issues beyond 50ms. In any case below reference is authoritative enough. Sent from my Windows Phone -----Original Message----- From: Woundy, Richard Sent: Monday, March 28, 2011 1:38 AM To: Murari Sridharan; Rolf Winter Cc: ledbat@ietf.org Subject: RE: Review of ledbat draft I wanted to make a quick comment on Murari's excellent review. >7. " delay of 150 ms to be acceptable for most user voice applications."= - Hmm seems high, I always thought that this number was more like 50ms fro= m SONET numbers. 50ms is about SONET restoration time, not typical SONET delay. A definitive reference for acceptable delay for voice applications is: ITU-= T G.114 (5/2003) SERIES G: TRANSMISSION SYSTEMS AND MEDIA, DIGITAL SYSTEMS = AND NETWORKS, Figure 1, page 3, One way transmission time. That ITU diagram shows that voice quality begins to drop when the end-to-en= d one-way delay exceeds 150ms, and crosses the threshold from "users very s= atisfied" to "users satisfied" around 200ms. But note that the end-to-end delay includes factors beyond the network tran= smission delay, such as codec delay, packetization delay, jitter buffer del= ay, etc. This is why the target delay for network transmission tends to be = lower. -- Rich -----Original Message----- From: ledbat-bounces@ietf.org [mailto:ledbat-bounces@ietf.org] On Behalf Of= Murari Sridharan Sent: Sunday, March 27, 2011 8:47 AM To: Rolf Winter; ledbat@ietf.org Subject: [ledbat] Review of ledbat draft My review as an individual contributor. I think the draft is almost there thanks to Jana and Mirja's efforts. There= are a couple of issues that I'd like taken care of. I think (assuming I re= ad it right) #3 and #8 are critical and must be fixed. 1. " LEDBAT can be used, with appropriate extensions where necessary, with= TCP" - I'd like to add some serious caveats as this statement makes it loo= k like it is easily doable. Getting Ledbat to work over TCP requires re-pur= posing timestamps in a way end nodes agree and understand. I am not questio= ning the ease of implementation but this would require a decent amount of w= ork which the statement above doesn't quite reflect. 2. Editorial: " LEDBAT decreases its sending rate quickly as a response to = potential congestion in the network" - I'd remove the word potential here.= Potential makes it look like we either don't believe delay increase implie= s congestion or we don't trust our delay measurements. 3. May be I am reading this wrong but I think the following is incorrect. queuing_delay =3D MIN(current_delays) - MIN(base_delays) update_current_delay(delay) # Maintain a list of CURRENT_FILTER last delays observed. delete first item in current_delays list append delay to current_delays list The above seems wrong to me because all you need is a few packets to go thr= ough without queueing and infact ledbat relies on this to get the correct b= ase delay. Some form of average is needed to protect from this otherwise MI= N (current delays) has a pretty good chance of being same as MIN(base delay= ) and therefore we continue to ramp up when infact we shouldn't. 4. GAIN MUST be set to 1 or less. - Why not just say MUST be set to 1, per = our goals that's the right value 5. In practice other delay based algorithms dump the base delay and history= when it hits a timeout which is the safe thing to do, we should be recomme= nding something along those lines in the discussion section. 6. Editorial: " end-to-end delay measurement" - It may avoid confusion if = we keep using one-way delay throughout. For a second I misread E2E as RTT. 7. " delay of 150 ms to be acceptable for most user voice applications." = - Hmm seems high, I always thought that this number was more like 50ms from= SONET numbers. 8. "LEDBAT does require that the receiver MUST transmit at least one ack in= every RTT" I think this is a problem as it will make the Ledbat controller ineffective= due to bursty release of packets from the send queues upon ACK. Large burs= ts means flows in the network often see uncharacteristic spikes which makes= them go back only to find that further measurements are clean. I think we = should recommend that the receiver ACK once every 2 data packets similar t= o TCP to keep the ack clock going. 9. RFC 3390 doesn't sound normative to me and if we are making 5681 normati= ve for loss based cc then Bra94 should also be made normative for delay bas= ed cc. -----Original Message----- From: ledbat-bounces@ietf.org [mailto:ledbat-bounces@ietf.org] On Behalf Of= Rolf Winter Sent: Monday, March 21, 2011 9:04 AM To: ledbat@ietf.org Subject: [ledbat] congestion control draft Hi, since people clearly have started to read and digest the newest version of = the draft, the chairs would appreciate if you could post your general feedb= ack about the document. Something like "I think this is good now" or "it ha= s addressed my previous concerns" etc. would be good feedback for us. Thanks, Rolf NEC Europe Limited | Registered Office: NEC House, 1 Victoria Road, London = W3 6BL | Registered in England 2832014 _______________________________________________ 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 serveh_ram21@yahoo.com Mon Mar 28 05:21:38 2011 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 03B9E3A6A24 for ; Mon, 28 Mar 2011 05:21:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.998 X-Spam-Level: X-Spam-Status: No, score=-1.998 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, J_CHICKENPOX_34=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 gyoJ+eOeaqzE for ; Mon, 28 Mar 2011 05:21:36 -0700 (PDT) Received: from web114608.mail.gq1.yahoo.com (web114608.mail.gq1.yahoo.com [98.136.183.45]) by core3.amsl.com (Postfix) with SMTP id 8B1DF3A692E for ; Mon, 28 Mar 2011 05:21:36 -0700 (PDT) Received: (qmail 95237 invoked by uid 60001); 28 Mar 2011 12:23:11 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s1024; t=1301314991; bh=KTvtvRV2sZNt3oeO6KgMhRgc8ZlFBtWwT9N4JgNXa8c=; h=Message-ID:X-YMail-OSG:Received:X-Mailer:References:Date:From:Subject:To:In-Reply-To:MIME-Version:Content-Type; b=rwgo78+a7+GEWEyYL/lMSAeOwGtb2dKoaRaMM32/3XwyatRRM7NYEIerwaV0u9DwYKkfuinyoRInhFM4hSp6Hh5TTEtj/EMsgskFPYwwTn3jmQ6nBHa7TkFx5sI6/HqCU6Mf7D8iGy5sWR5tbdJ+qXnkVOdBW1dN7iQUMkhk8/8= DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=s1024; d=yahoo.com; h=Message-ID:X-YMail-OSG:Received:X-Mailer:References:Date:From:Subject:To:In-Reply-To:MIME-Version:Content-Type; b=blleRNU3oYwZEo1JF4XUCvZrjurh1YSuKLHwuMaIFJ8E81LmHGkS3OyvBM31Gdmcl4HYwgxkNN/zLhzsEoEBQRy7uxuHEwTTAuC3CNTcSzjIEWNO0JrBnopFmw+xtFQoDp2SllYpOcv1DybhzHpzJjB1E7Jj0mepgoVB1enu9Nw=; Message-ID: <61748.86864.qm@web114608.mail.gq1.yahoo.com> X-YMail-OSG: Cuo_kQkVM1lMDkUKYtC5_1xRK0gzguuBzBkOJ_JjbFqkA6q mtTcamvSXIAc1tx4KbhGikEtwWUIC.Je1pFXc8_Ydv0Vam6G_cV6Bg3tpo51 NVbOHAhgf_r97xNUuWScSNNODWj61N0MD2YMF5rwfVYxVoK9B2dtTkEo9LrO aN2r7XAQGpWdVuRHXZziVhf057VOcxiJ8ruqlziBg5zDnbjHDjvsn5x6YHPg Vb9xv4xDZ_iiVnpVGHa0sxLLYTljFcBh1XdCRaWtwFkZpDVLBvC2ThnHqlGy xX6ZSCu94Vv2MwOuwd0Xs4AzqkdJ_Tk656JEMLuGM.v8t9n4yPzDckywy5ic k7BZgLvdXzlxVSUJXU8sPRjy1iUZsEyiBlA5ynTYNOVYafKp36rH0Q3w- Received: from [213.103.204.231] by web114608.mail.gq1.yahoo.com via HTTP; Mon, 28 Mar 2011 05:23:10 PDT X-Mailer: YahooMailRC/559 YahooMailWebService/0.8.109.295617 References: <71538.84873.qm@web114607.mail.gq1.yahoo.com> <791AD3077F94194BB2BDD13565B6295D05DECD4B@DAPHNIS.office.hd> <14772.69381.qm@web114606.mail.gq1.yahoo.com> <201103281105.25707.mirja.kuehlewind@ikr.uni-stuttgart.de> Date: Mon, 28 Mar 2011 05:23:10 -0700 (PDT) From: serveh sadeghi To: ledbat mailing list In-Reply-To: <201103281105.25707.mirja.kuehlewind@ikr.uni-stuttgart.de> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="0-426303812-1301314990=:86864" Subject: [ledbat] Fw: flightSize & cwnd 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, 28 Mar 2011 12:21:38 -0000 --0-426303812-1301314990=:86864 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable =0A=0AAre you sure? because I already put cwnd as number of bytes (3000 mea= ns 2 * mss)=0A=0A=0A=0A________________________________=0AFrom: Mirja Kuehl= ewind =0ATo: ledbat@ietf.org; Janard= han Iyengar =0ACc: serveh sadeghi =0ASent: Mon, March 28, 2011 11:05:25 AM=0ASubject: Re: [ledbat] fli= ghtSize & cwnd=0A=0AHi Serveh,=0A=0Asorry, we've been missing an *MSS here:= =0A=0Acwnd +=3D GAIN * off_target * bytes_newly_acked / cwnd * MSS=0A=0ATha= t's because we've just changed from a cwnd in packets to a cwnd in bytes...= =0A=0AThanks for the pointer!!=0AMirja=0A=0A=0A=0AOn Monday 28 March 2011 1= 0:50:48 serveh sadeghi wrote:=0A> Hi guys,=0A> If you start with init_cwnd= =3D2 packets and your mss is 1500 ,initial cwnd is=0A> 3000 bytes. on rece= iving the ack for both sent packets, having=0A> queuing_delay 0, off_targ= et would be 1.0.=0A> off_target =3D (TARGET - queuing_delay) / TARGET=0A> c= wnd +=3D GAIN * off_target * bytes_newly_acked / cwnd=0A>=0A> and new cwnd = would be 3000 + 1.0 * 1.0 * 3000 / 3000 =3D 3001=0A> So if you just send 2 = packets and receive both, and there is no congestion=0A> at all(queuing_del= ay =3D 0), you expect that new cwnd would increase very=0A> much, not only = one byte. I run this in a long time and the chart produced=0A> for cwnd si= ze is not increasing that much.The chart is not what I expected.=0A>=0A>=0A= >=0A> ________________________________=0A> From: Rolf Winter =0A> To: serveh sadeghi ; "ledbat@ietf.org= "=0A> Sent: Tue, March 22, 2011 12:32:08 PM=0A> Subject: = RE: [ledbat] flightSize & cwnd=0A>=0A> Hi,=0A>=0A> the old congestion contr= ol formula had a bug. Could you re-evaluate with=0A> the newest version fou= nd at=0A>=0A>=0A> http://tools.ietf.org/html/draft-ietf-ledbat-congestion-0= 4.=0A>=0A> Best,=0A>=0A> Rolf=0A>=0A>=0A> NEC Europe Limited | Registered O= ffice: NEC House, 1 Victoria Road, London=0A> W3 6BL | Registered in Englan= d 2832014=0A>=0A> > -----Original Message-----=0A> > From: ledbat-bounces@i= etf.org [mailto:ledbat-bounces@ietf.org] On=0A> > Behalf Of serveh sadeghi= =0A> > Sent: Dienstag, 22. M=C3=A4rz 2011 12:20=0A> > To: ledbat@ietf.org= =0A> > Subject: [ledbat] flightSize & cwnd=0A> >=0A> > Hi guys,=0A> >=0A> >= I=E2=80=99m implementing the congestion control mechanism used in =C2=B5T= P (LEDBAT )=0A> > and I encountered some problems .=0A> >=0A> > Here is wha= t LEDBAT specification says about how to calculate cwnd:=0A> >=0A> > off_ta= rget =3D TARGET - queuing_delay + random_input()=0A> >=0A> > cwnd +=3D GAIN= * off_target / cwnd=0A> >=0A> > # flight_size() is the amount of currently= not acked data.=0A> >=0A> > max_allowed_cwnd =3D ALLOWED_INCREASE + TETHER= *flight_size()=0A> >=0A> > cwnd =3D min(cwnd, max_allowed_cwnd)=0A> >=0A> >= And here is the values spec suggests for the parameters:=0A> >=0A> > TARGE= T =3D 100;=0A> >=0A> > GAIN =3D 1.0;=0A> >=0A> > ALLOWED_INCREASE =3D 1.0;= =0A> >=0A> > TETHER =3D 1.5;=0A> >=0A> > Considering these , if flight_size= becomes 0 at some point,=0A> > max_allowed_cwnd becomes 1.0, so whatever c= alculated cwnd is, final=0A> > cwnd would be 1.0(The minimum amount of cwn= d while a TCP flow exists!).=0A> > Even worse , if cwnd becomes 1.0, it rem= ains 1.0 forever. Because cwnd=0A> > =3D 1.0 means just send 1 packet. So o= n receiving ack, flight_size would=0A> > be 0 and again max_allowed_cwnd wo= uld be 1.0 !=0A> >=0A> >=0A> >=0A> >=0A> > could you please guide me where = I'm making mistake .=0A=0A=0A=0A-- =0A-------------------------------------= ------------------------------=0ADipl.-Ing. Mirja K=C3=BChlewind=0AInstitut= e of Communication Networks and Computer Engineering (IKR)=0AUniversity of = Stuttgart, Germany=0APfaffenwaldring 47, D-70569 Stuttgart=0A=0Atel: +49(0)= 711/685-67973=0Aemail: mirja.kuehlewind@ikr.uni-stuttgart.de=0Aweb: www.ikr= .uni-stuttgart.de=0A-------------------------------------------------------= ------------=0A=0A=0A --0-426303812-1301314990=:86864 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: quoted-printable

=0A
Are you sure? because I already put cwnd= as number of bytes (3000 means 2 * mss)

From: Mi= rja Kuehlewind <mirja.kuehlewind@ikr.uni-stuttgart.de>
To: ledbat@ietf.org; Janardh= an Iyengar <jana.iyengar@gmail.com>
Cc: serveh sadeghi <serveh_ram21@yahoo.com>
<= span style=3D"font-weight:bold;">Sent: Mon, March 28, 2011 11:05= :25 AM
Subject: Re: [led= bat] flightSize & cwnd

=0AHi Serveh,

sorry, we've = been missing an *MSS here:

cwnd +=3D GAIN * off_target * bytes_newly= _acked / cwnd * MSS

That's because we've just changed from a cwnd in= packets to a cwnd in bytes...

Thanks for the pointer!!
Mirja
=


On Monday 28 March 2011 10:50:48 serveh sadeghi wrote:
> = Hi guys,
> If you start with init_cwnd=3D2 packets and your mss is 15= 00 ,initial cwnd is
> 3000 bytes. on  receiving  the ack fo= r both sent packets,  having
> queuing_delay 0, off_target would= be 1.0.
> off_target =3D (TARGET - queuing_delay) / TARGET
> c= wnd +=3D GAIN * off_target * bytes_newly_acked / cwnd
>
> and n= ew cwnd would be 3000 + 1.0 * 1.0 * 3000 / 3000 =3D 3001
> So if you = just send 2 packets and receive both, and there is no congestion
> at= all(queuing_delay =3D 0), you expect that new cwnd would increase very
= > much, not only one byte. I run this in a=0A long time and the chart pr= oduced
> for cwnd size is not increasing that much.The chart is not w= hat I expected.
>
>
>
> ___________________________= _____
> From: Rolf Winter <Rolf.Winter@neclab.eu>
> To: serveh sadeghi <serveh_ram21@yahoo.com>; "ledbat@ietf.org"
> <ledbat@ietf.org> Sent: Tue, March 22, 2011 12:32:08 PM> Subject: RE: [ledbat] flightSize & cwnd
>
> Hi,
&= gt;
> the old congestion control formula had a bug. Could you re-evaluate with
> the newest version found at
>
>
> http://tools.ietf.org/html/draft-ietf-ledbat-c= ongestion-04.
>
> Best,
>
> Rolf<= br>>
>
> NEC Europe Limited | Registered Office: NEC House, = 1 Victoria Road, London
> W3 6BL | Registered in England 2832014
&= gt;
> > -----Original Message-----
> > From: ledbat-bounces@ietf.org [mailto:ledbat-bounces@ietf.org] On<= br>> > Behalf Of serveh sadeghi
> > Sent: Dienstag, 22. M=C3= =A4rz 2011 12:20
> > To: ledbat@ietf.org
&= gt; > Subject: [ledbat] flightSize & cwnd
> >
> > = Hi guys,
> >
> > I=E2=80=99m implementing the congestion= =0A control mechanism used in =C2=B5TP (LEDBAT )
> > and I encount= ered some problems .
> >
> > Here is what LEDBAT specific= ation says about how to calculate cwnd:
> >
> > off_targe= t =3D TARGET - queuing_delay + random_input()
> >
> > cwn= d +=3D GAIN * off_target / cwnd
> >
> > # flight_size() i= s the amount of currently not acked data.
> >
> > max_all= owed_cwnd =3D ALLOWED_INCREASE + TETHER*flight_size()
> >
> = > cwnd =3D min(cwnd, max_allowed_cwnd)
> >
> > And her= e is the values spec suggests for the parameters:
> >
> >= TARGET =3D 100;
> >
> > GAIN =3D 1.0;
> >
&g= t; > ALLOWED_INCREASE =3D 1.0;
> >
> > TETHER =3D 1.5;=
> >
> > Considering these , if flight_size becomes 0 at = some point,
> > max_allowed_cwnd becomes 1.0, so whatever calculat= ed cwnd is,=0A final
> > cwnd would be 1.0(The minimum amount of c= wnd while a TCP flow exists!).
> > Even worse , if cwnd becomes 1.= 0, it remains 1.0 forever. Because cwnd
> > =3D 1.0 means just sen= d 1 packet. So on receiving ack, flight_size would
> > be 0 and ag= ain max_allowed_cwnd would be 1.0 !
> >
> >
> ><= br>> >
> > could you please guide me where I'm making mistak= e .



--
-------------------------------------------------= ------------------
Dipl.-Ing. Mirja K=C3=BChlewind
Institute of Commu= nication Networks and Computer Engineering (IKR)
University of Stuttgart= , Germany
Pfaffenwaldring 47, D-70569 Stuttgart

tel: +49(0)711/68= 5-67973
email: mirja.kuehlewind@ikr.uni-stuttgart.de
web: www.ikr.uni-stu= ttgart.de
----------------------------------------------------------= ---------
=0A=0A=0A

=0A=0A =
=0A=0A=0A

=0A=0A=0A=0A= =0A=0A=0A=0A --0-426303812-1301314990=:86864-- From mirja.kuehlewind@ikr.uni-stuttgart.de Mon Mar 28 05:27:10 2011 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 7ED723A68F0 for ; Mon, 28 Mar 2011 05:27:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.781 X-Spam-Level: X-Spam-Status: No, score=-1.781 tagged_above=-999 required=5 tests=[AWL=-0.132, BAYES_00=-2.599, HELO_EQ_DE=0.35, J_CHICKENPOX_34=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 mIS1h4cBXgTH for ; Mon, 28 Mar 2011 05:27:09 -0700 (PDT) Received: from mailsrv.ikr.uni-stuttgart.de (mailsrv.ikr.uni-stuttgart.de [129.69.170.2]) by core3.amsl.com (Postfix) with ESMTP id F0DFB3A68EB for ; Mon, 28 Mar 2011 05:27:08 -0700 (PDT) Received: from netsrv1.ikr.uni-stuttgart.de (netsrv1-c [10.11.12.12]) by mailsrv.ikr.uni-stuttgart.de (Postfix) with ESMTP id 2D536633B1; Mon, 28 Mar 2011 14:28:45 +0200 (CEST) Received: from vpn-2-cl177 (vpn-2-cl177 [10.41.21.177]) by netsrv1.ikr.uni-stuttgart.de (Postfix) with ESMTP id 18E9259A8A; Mon, 28 Mar 2011 14:28:45 +0200 (CEST) From: Mirja Kuehlewind Organization: University of Stuttgart (Germany), IKR To: ledbat@ietf.org Date: Mon, 28 Mar 2011 14:28:44 +0200 User-Agent: KMail/1.9.10 (enterprise35 0.20101217.1207316) References: <71538.84873.qm@web114607.mail.gq1.yahoo.com> <201103281105.25707.mirja.kuehlewind@ikr.uni-stuttgart.de> <61748.86864.qm@web114608.mail.gq1.yahoo.com> In-Reply-To: <61748.86864.qm@web114608.mail.gq1.yahoo.com> X-KMail-QuotePrefix: > MIME-Version: 1.0 Content-Type: Text/Plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable Content-Disposition: inline Message-Id: <201103281428.44527.mirja.kuehlewind@ikr.uni-stuttgart.de> Cc: serveh sadeghi Subject: Re: [ledbat] Fw: flightSize & cwnd 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, 28 Mar 2011 12:27:10 -0000 yes, I'm sure, because you add this value again to the cwnd which is in=20 bytes... cwnd +=3D GAIN * off_target * bytes_newly_acked / cwnd * MSS in_bytes +=3D no_unit * no_unit * in_bytes / in_bytes * in_bytes =3D in_byt= es Mirja On Monday 28 March 2011 14:23:10 serveh sadeghi wrote: > Are you sure? because I already put cwnd as number of bytes (3000 means 2= * > mss) > > > > ________________________________ > From: Mirja Kuehlewind > To: ledbat@ietf.org; Janardhan Iyengar > Cc: serveh sadeghi > Sent: Mon, March 28, 2011 11:05:25 AM > Subject: Re: [ledbat] flightSize & cwnd > > Hi Serveh, > > sorry, we've been missing an *MSS here: > > cwnd +=3D GAIN * off_target * bytes_newly_acked / cwnd * MSS > > That's because we've just changed from a cwnd in packets to a cwnd in > bytes... > > Thanks for the pointer!! > Mirja > > On Monday 28 March 2011 10:50:48 serveh sadeghi wrote: > > Hi guys, > > If you start with init_cwnd=3D2 packets and your mss is 1500 ,initial c= wnd > > is 3000 bytes. on receiving the ack for both sent packets, having > > queuing_delay 0, off_target would be 1.0. > > off_target =3D (TARGET - queuing_delay) / TARGET > > cwnd +=3D GAIN * off_target * bytes_newly_acked / cwnd > > > > and new cwnd would be 3000 + 1.0 * 1.0 * 3000 / 3000 =3D 3001 > > So if you just send 2 packets and receive both, and there is no > > congestion at all(queuing_delay =3D 0), you expect that new cwnd would > > increase very much, not only one byte. I run this in a long time and t= he > > chart produced for cwnd size is not increasing that much.The chart is n= ot > > what I expected. > > > > > > > > ________________________________ > > From: Rolf Winter > > To: serveh sadeghi ; "ledbat@ietf.org" > > Sent: Tue, March 22, 2011 12:32:08 PM > > Subject: RE: [ledbat] flightSize & cwnd > > > > Hi, > > > > the old congestion control formula had a bug. Could you re-evaluate with > > the newest version found at > > > > > > http://tools.ietf.org/html/draft-ietf-ledbat-congestion-04. > > > > Best, > > > > Rolf > > > > > > NEC Europe Limited | Registered Office: NEC House, 1 Victoria Road, > > London W3 6BL | Registered in England 2832014 > > > > > -----Original Message----- > > > From: ledbat-bounces@ietf.org [mailto:ledbat-bounces@ietf.org] On > > > Behalf Of serveh sadeghi > > > Sent: Dienstag, 22. M=C3=A4rz 2011 12:20 > > > To: ledbat@ietf.org > > > Subject: [ledbat] flightSize & cwnd > > > > > > Hi guys, > > > > > > I=E2=80=99m implementing the congestion control mechanism used in = =C2=B5TP (LEDBAT > > > ) and I encountered some problems . > > > > > > Here is what LEDBAT specification says about how to calculate cwnd: > > > > > > off_target =3D TARGET - queuing_delay + random_input() > > > > > > cwnd +=3D GAIN * off_target / cwnd > > > > > > # flight_size() is the amount of currently not acked data. > > > > > > max_allowed_cwnd =3D ALLOWED_INCREASE + TETHER*flight_size() > > > > > > cwnd =3D min(cwnd, max_allowed_cwnd) > > > > > > And here is the values spec suggests for the parameters: > > > > > > TARGET =3D 100; > > > > > > GAIN =3D 1.0; > > > > > > ALLOWED_INCREASE =3D 1.0; > > > > > > TETHER =3D 1.5; > > > > > > Considering these , if flight_size becomes 0 at some point, > > > max_allowed_cwnd becomes 1.0, so whatever calculated cwnd is, final > > > cwnd would be 1.0(The minimum amount of cwnd while a TCP flow exists!= ). > > > Even worse , if cwnd becomes 1.0, it remains 1.0 forever. Because cwnd > > > =3D 1.0 means just send 1 packet. So on receiving ack, flight_size wo= uld > > > be 0 and again max_allowed_cwnd would be 1.0 ! > > > > > > > > > > > > > > > could you please guide me where I'm making mistake . =2D-=20 =2D------------------------------------------------------------------ Dipl.-Ing. Mirja K=C3=BChlewind Institute of Communication Networks and Computer Engineering (IKR) University of Stuttgart, Germany Pfaffenwaldring 47, D-70569 Stuttgart tel: +49(0)711/685-67973 email: mirja.kuehlewind@ikr.uni-stuttgart.de web: www.ikr.uni-stuttgart.de =2D------------------------------------------------------------------