From lastewart@swin.edu.au Tue Aug 3 01:19:28 2010 Return-Path: X-Original-To: ledbat@core3.amsl.com Delivered-To: ledbat@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 04B8D3A67DA; Tue, 3 Aug 2010 01:19:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.001 X-Spam-Level: X-Spam-Status: No, score=0.001 tagged_above=-999 required=5 tests=[BAYES_50=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id dozcjAP4mxzb; Tue, 3 Aug 2010 01:19:24 -0700 (PDT) Received: from lauren.room52.net (lauren.room52.net [210.50.193.198]) by core3.amsl.com (Postfix) with ESMTP id 209613A6767; Tue, 3 Aug 2010 01:19:23 -0700 (PDT) Received: from lstewart.caia.swin.edu.au (lstewart.caia.swin.edu.au [136.186.229.95]) by lauren.room52.net (Postfix) with ESMTPSA id 3A0727E8CE; Tue, 3 Aug 2010 18:19:50 +1000 (EST) Message-ID: <4C57D125.3010706@swin.edu.au> Date: Tue, 03 Aug 2010 18:19:49 +1000 From: Lawrence Stewart User-Agent: Mozilla/5.0 (X11; U; FreeBSD amd64; en-US; rv:1.9.1.11) Gecko/20100726 Thunderbird/3.0.6 MIME-Version: 1.0 To: iccrg@cs.ucl.ac.uk, end2end-interest@postel.org, freebsd-net@freebsd.org, tmrg-interest@ICSI.Berkeley.EDU, ledbat@ietf.org, multipathtcp@ietf.org, tcpm@ietf.org X-Enigmail-Version: 1.0.1 Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 7bit Cc: David Hayes , grenville armitage Subject: [ledbat] Software for FreeBSD TCP R&D 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, 03 Aug 2010 08:19:28 -0000 Hi all, (apologies for any duplicates you receive and please trim the CC list appropriately if you reply to this email) We're pleased to announce the release of a substantial set of new and updated BSD licenced software for TCP experimentation and research using FreeBSD: - "CAIA-Hamilton Delay" Congestion Control Algorithm v0.1 (new) - "Hamilton Delay" Congestion Control Algorithm v0.2 (update) - Vegas Congestion Control Algorithm v0.2 (update) - H-TCP Congestion Control Algorithm v0.12 (update) - CUBIC Congestion Control Algorithm v0.10 (update) - Statistical Information For TCP Research (SIFTR) v1.2.3 (update) - Enhanced Round Trip Time (ERTT) Khelp Module v0.2 (update) - Khelp Framework for FreeBSD v0.1.1 (update) - Modular TCP Congestion Control for FreeBSD v0.10.0 (update) A more detailed summary of the various tools/patches is included at the end of this email. Everything mentioned above along with other papers, patches and software relevant/useful for protocol analysis, debugging and experimental research is available from: http://caia.swin.edu.au/urp/newtcp/tools.html The software was developed as part of the NewTCP research project at Swinburne University's Centre for Advanced Internet Architectures, made possible in part by a grant from the Cisco University Research Program Fund at Community Foundation Silicon Valley. Testing and development was further assisted by a grant from the FreeBSD Foundation. We welcome any feedback and hope you enjoy playing with the code and tools. Cheers, Lawrence Stewart, David Hayes and Grenville Armitage http://caia.swin.edu.au NB: "CAIA-Hamilton Delay" and "Hamilton Delay" are our working names for algorithms which do not have established names in the literature. "CAIA-Hamilton Delay" Congestion Control Algorithm v0.1 [1,2] ---------------------------------------------------------------------- A FreeBSD loadable kernel module that implements an experimental delay based congestion control algorithm proposed by the Hamilton Institute [3] but with modifications made by CAIA [4]. It builds on Hamilton's initial proposal by adding tolerance to non-congestion related losses and still aims to allow delay- and loss-based algorithms to fairly coexist. "Hamilton Delay" Congestion Control Algorithm v0.2 [5,6] ---------------------------------------------------------------------- A FreeBSD loadable kernel module that implements an experimental delay based congestion control algorithm proposed by the Hamilton Institute [3]. It provides a first step toward the ability of delay based algorithms to fairly coexist with loss based algorithms. Vegas Congestion Control Algorithm v0.2 [7,8] ---------------------------------------------------------------------- A FreeBSD loadable kernel module that implements the Vegas delay-based congestion control algorithm [9]. H-TCP Congestion Control Algorithm v0.12 [10,11] ---------------------------------------------------------------------- A FreeBSD loadable kernel module that implements the H-TCP loss based TCP congestion control algorithm [12]. CUBIC Congestion Control Algorithm v0.10 [13,14] ---------------------------------------------------------------------- A FreeBSD loadable kernel module that implements the CUBIC loss based TCP congestion control algorithm [15]. CUBIC is the current default algorithm used by Linux. Statistical Information For TCP Research (SIFTR) v1.2.3 [16,17] ---------------------------------------------------------------------- A FreeBSD 6/7/8/9 kernel module that logs a range of statistics on active TCP connections to a log file. It provides the ability to make highly granular measurements of TCP connection state, aimed at system administrators, developers and researchers. NB: SIFTR has been imported into FreeBSD's "head" svn branch (a.k.a. 9-CURRENT) as revision 209662 and will be backported to 8-STABLE in time for 8.2-RELEASE. Enhanced Round Trip Time (ERTT) Khelp Module v0.2 [18,19] ---------------------------------------------------------------------- A FreeBSD loadable kernel module that provides enhanced RTT measurements for use by delay and rate based TCP congestion control algorithms. Robust estimates of RTT are provided even when the receiver uses delayed acknowledgements, TCP segmentation offload (TSO) or Selective Acknowledgements (SACK). This module is required by the delay based congestion control algorithms. Khelp Framework for FreeBSD v0.1.1 [20,21] ---------------------------------------------------------------------- A FreeBSD kernel patch that provides support for generic kernel modules known as "helpers" to hook into arbitrary points within the kernel and provide service(s) to the running system. This forms the foundation for the ERTT Khelp module. Modular TCP Congestion Control for FreeBSD v0.10.0 [22,23] ------------------------------------------------- This revision of the modular TCP congestion control framework patch provides a current snapshot of the project's development branch. Some fairly major changes and refactoring have gone into this release, along with numerous tweaks, bug fixes and enhancements to support the new delay based congestion control algorithms we have been working on. In theory, the framework now also supports sharing of congestion control algorithms between congestion aware transport protocols like TCP and SCTP, though this integration work is yet to be done. [1] http://caia.swin.edu.au/urp/newtcp/tools/cc_chd-0.1.tar.gz [2] http://caia.swin.edu.au/urp/newtcp/tools/cc_chd-readme-0.1.txt [3] L. Budzisz, R. Stanojevic, R. Shorten, and F. Baker, "A strategy for fair coexistence of loss and delay-based congestion control algorithms", IEEE Commun. Lett., vol. 13, no. 7, pp. 555-557, Jul. 2009. [4] D. A. Hayes and G. Armitage, "Improved coexistence and loss tolerance for delay based TCP congestion control", in Proceedings of 35th Annual IEEE Conference on Local Computer Networks (LCN 2010), Denver, Colorado, USA, 11-14 October 2010. [5] http://caia.swin.edu.au/urp/newtcp/tools/cc_hd-0.2.tar.gz [6] http://caia.swin.edu.au/urp/newtcp/tools/cc_hd-readme-0.2.txt [7] http://caia.swin.edu.au/urp/newtcp/tools/cc_vegas-0.2.tar.gz [8] http://caia.swin.edu.au/urp/newtcp/tools/cc_vegas-readme-0.2.txt [9] L. S. Brakmo and L. L. Peterson, "TCP Vegas: end to end congestion avoidance on a global internet", IEEE J. Sel. Areas Commun., vol. 13, no. 8, pp. 1465-1480, Oct. 1995. [10] http://caia.swin.edu.au/urp/newtcp/tools/cc_htcp-0.12.tar.gz [11] http://caia.swin.edu.au/urp/newtcp/tools/cc_htcp-readme-0.12.txt [12] D. Leith, R. Shorten, "H-TCP: TCP for high-speed and long-distance networks", in Second International Workshop on Protocols for Fast Long-Distance Networks, Argonne, Illinois USA, February 2004. [13] http://caia.swin.edu.au/urp/newtcp/tools/cc_cubic-0.10.tar.gz [14] http://caia.swin.edu.au/urp/newtcp/tools/cc_cubic-readme-0.10.txt [15] I. Rhee, L. Xu, S. Ha, "CUBIC for Fast Long-Distance Networks", Internet Draft, draft-rhee-tcpm-cubic-02.txt, August 2008. [16] http://caia.swin.edu.au/urp/newtcp/tools/siftr-1.2.3.tar.gz [17] http://caia.swin.edu.au/urp/newtcp/tools/siftr-readme-1.2.3.txt [18] http://caia.swin.edu.au/urp/newtcp/tools/h_ertt-0.2.tar.gz [19] http://caia.swin.edu.au/urp/newtcp/tools/h_ertt-readme-0.2.txt [20] http://caia.swin.edu.au/urp/newtcp/tools/caia_khelp_framework_v0.1.1_9.x.r209905.patch [21] http://caia.swin.edu.au/urp/newtcp/tools/khelp-readme-0.1.1.txt [22] http://caia.swin.edu.au/urp/newtcp/tools/caia_modularcc_v0.10.0_9.x.r209905.patch [23] http://caia.swin.edu.au/urp/newtcp/tools/modularcc-readme-0.10.0.txt From Rolf.Winter@neclab.eu Thu Aug 5 01:25:34 2010 Return-Path: X-Original-To: ledbat@core3.amsl.com Delivered-To: ledbat@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 8AD693A69DA for ; Thu, 5 Aug 2010 01:25:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -100.994 X-Spam-Level: X-Spam-Status: No, score=-100.994 tagged_above=-999 required=5 tests=[AWL=-0.809, BAYES_40=-0.185, 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 cjIWhgmpdcez for ; Thu, 5 Aug 2010 01:25:33 -0700 (PDT) Received: from smtp0.neclab.eu (smtp0.neclab.eu [195.37.70.41]) by core3.amsl.com (Postfix) with ESMTP id 63B1B3A69E8 for ; Thu, 5 Aug 2010 01:25:33 -0700 (PDT) Received: from localhost (localhost.localdomain [127.0.0.1]) by smtp0.neclab.eu (Postfix) with ESMTP id 3C6132C0001B6; Thu, 5 Aug 2010 10:26:03 +0200 (CEST) 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 qrYgeaSvlweK; Thu, 5 Aug 2010 10:26:03 +0200 (CEST) Received: from ENCELADUS.office.hd (Enceladus.office.hd [192.168.24.52]) by smtp0.neclab.eu (Postfix) with ESMTP id 1ED802C0001B2; Thu, 5 Aug 2010 10:25:53 +0200 (CEST) Received: from PALLENE.office.hd ([169.254.1.17]) by ENCELADUS.office.hd ([192.168.24.52]) with mapi; Thu, 5 Aug 2010 10:24:49 +0200 From: Rolf Winter To: Gengyu WEI Thread-Topic: [ledbat] review of draft-ietf-ledbat-congestion Thread-Index: AQHLLVrPyGiM3AJg1UKlAw9EccrgxJLSkbGg Date: Thu, 5 Aug 2010 08:24:48 +0000 Message-ID: <791AD3077F94194BB2BDD13565B6295D64358A@PALLENE.office.hd> References: <547F018265F92642B577B986577D671C01594038@VENUS.office> In-Reply-To: Accept-Language: de-DE, 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 draft-ietf-ledbat-congestion 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, 05 Aug 2010 08:25:34 -0000 Gengyu, I think I have not answered you yet. Sorry for that, the IETF meeting and a= ll... To answer your question. In an ideal world LEDBAT would consume 100% of the= available bandwidth if no other traffic passes the bottleneck, which we as= sume to be at the modem in your uplink direction. Once other traffic compet= es for the bandwidth, LEDBAT would ideally disappear or consume some of the= bandwidth in case the extra delay of the other traffic is < 25ms. Now that= is the theory, in practice you want to get as close to that behavior as po= ssible.=20 Best, Rolf NEC Europe Limited | Registered Office: NEC House, 1 Victoria Road, London = W3 6BL | Registered in England 2832014=20 > -----Original Message----- > From: ledbat-bounces@ietf.org [mailto:ledbat-bounces@ietf.org] On > Behalf Of Gengyu WEI > Sent: Dienstag, 27. Juli 2010 09:11 > To: Rolf Winter > Cc: ledbat@ietf.org > Subject: Re: [ledbat] review of draft-ietf-ledbat-congestion >=20 > Rof, >=20 > There is a question. >=20 > What do you mean "saturate the bottleneck" ? > Does it mean that the bottleneck link utilization is more than 90%, or > 95%, or even more? >=20 > In the draft, >=20 > LEDBAT design goals are: >=20 > 1. saturate the bottleneck >=20 > 2. keep delay low when no other traffic is present >=20 > ... >=20 > Regards, >=20 > Gengyu >=20 > ----- Original Message ----- > From: "Rolf Winter" > To: > Sent: Friday, July 16, 2010 4:31 PM > Subject: [ledbat] review of draft-ietf-ledbat-congestion >=20 >=20 > > WG, > > > > please review draft-ietf-ledbat-congestion, and see if your comments > have been adequately addressed. If you do not see any issues please > also speak up. I'd like to get a feeling whether the group thinks the > draft is done or not. > > > > 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 the8472@infinite-source.de Thu Aug 5 04:47:20 2010 Return-Path: X-Original-To: ledbat@core3.amsl.com Delivered-To: ledbat@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 80D8A3A6B18 for ; Thu, 5 Aug 2010 04:47:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.249 X-Spam-Level: X-Spam-Status: No, score=-2.249 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_DE=0.35] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id lGRMFpJExeNh for ; Thu, 5 Aug 2010 04:47:02 -0700 (PDT) Received: from mo-p00-ob.rzone.de (mo-p00-ob.rzone.de [81.169.146.162]) by core3.amsl.com (Postfix) with ESMTP id DBBB93A6B07 for ; Thu, 5 Aug 2010 04:46:48 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; t=1281008837; l=2845; s=domk; d=infinite-source.de; h=Content-Transfer-Encoding:Content-Type:In-Reply-To:References: Subject:CC:To:MIME-Version:From:Date:X-RZG-CLASS-ID:X-RZG-AUTH; bh=hsq8+TbgpVXGx8YHDDT3n6YTtUg=; b=BHmihGz7l05R/KYruzI37bfoCsEPjmgs0n9rnI/5PpIrzV7AMb8+VQi6gk+MBHdjJwO tPHWVdK2QTSwDcnDy3NmbrUvCmvS2yVMSpRV7RAQiOC4UYrvk9Gpdj6GF/r3kJBTpbxct 91xworlpIUXHKo1kNu3PDy3CS9DZB4q5XgY= X-RZG-AUTH: :LW0Wek7mfO1Vkr5kPgWDvaJNkQpNEn8ylntakOISso1hE0McXW12o8AG24SD41nTjiZr3INXm/0ZjY2cbw== X-RZG-CLASS-ID: mo00 Received: from [192.168.1.103] (p5B17188A.dip0.t-ipconnect.de [91.23.24.138]) by post.strato.de (jimi mo57) (RZmta 23.4) with ESMTP id w035bbm75AXkGo ; Thu, 5 Aug 2010 13:47:16 +0200 (MEST) Message-ID: <4C5AA4BD.1050407@infinite-source.de> Date: Thu, 05 Aug 2010 13:47:09 +0200 From: The 8472 User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.1; en-GB; rv:1.9.1.11) Gecko/20100711 Lightning/1.0b1 Thunderbird/3.0.6 MIME-Version: 1.0 To: Rolf Winter References: <547F018265F92642B577B986577D671C01594038@VENUS.office> <791AD3077F94194BB2BDD13565B6295D64358A@PALLENE.office.hd> In-Reply-To: <791AD3077F94194BB2BDD13565B6295D64358A@PALLENE.office.hd> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: "ledbat@ietf.org" Subject: Re: [ledbat] review of draft-ietf-ledbat-congestion 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, 05 Aug 2010 11:47:21 -0000 In practice you will probably see that high link utilization at the bottleneck would cause AQM algorithms like RED or BLUE to drop packets or ECN-mark them, which as far as i understand it would induce TCP-like AIMD-see-saw-ing in LEDBAT like you see it in most other congestion control algorithms. On 05.08.2010 10:24, Rolf Winter wrote: > Gengyu, > > I think I have not answered you yet. Sorry for that, the IETF meeting and all... > > To answer your question. In an ideal world LEDBAT would consume 100% of the available bandwidth if no other traffic passes the bottleneck, which we assume to be at the modem in your uplink direction. Once other traffic competes for the bandwidth, LEDBAT would ideally disappear or consume some of the bandwidth in case the extra delay of the other traffic is< 25ms. Now that is the theory, in practice you want to get as close to that behavior as possible. > > 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 Gengyu WEI >> Sent: Dienstag, 27. Juli 2010 09:11 >> To: Rolf Winter >> Cc: ledbat@ietf.org >> Subject: Re: [ledbat] review of draft-ietf-ledbat-congestion >> >> Rof, >> >> There is a question. >> >> What do you mean "saturate the bottleneck" ? >> Does it mean that the bottleneck link utilization is more than 90%, or >> 95%, or even more? >> >> In the draft, >> >> LEDBAT design goals are: >> >> 1. saturate the bottleneck >> >> 2. keep delay low when no other traffic is present >> >> ... >> >> Regards, >> >> Gengyu >> >> ----- Original Message ----- >> From: "Rolf Winter" >> To: >> Sent: Friday, July 16, 2010 4:31 PM >> Subject: [ledbat] review of draft-ietf-ledbat-congestion >> >> >> >>> WG, >>> >>> please review draft-ietf-ledbat-congestion, and see if your comments >>> >> have been adequately addressed. If you do not see any issues please >> also speak up. I'd like to get a feeling whether the group thinks the >> draft is done or not. >> >>> 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 >> > _______________________________________________ > ledbat mailing list > ledbat@ietf.org > https://www.ietf.org/mailman/listinfo/ledbat > > From richard_woundy@cable.comcast.com Thu Aug 5 05:02:19 2010 Return-Path: X-Original-To: ledbat@core3.amsl.com Delivered-To: ledbat@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id DC6983A696E for ; Thu, 5 Aug 2010 05:02:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -108.145 X-Spam-Level: X-Spam-Status: No, score=-108.145 tagged_above=-999 required=5 tests=[AWL=0.318, BAYES_00=-2.599, HELO_EQ_MODEMCABLE=0.768, HOST_EQ_MODEMCABLE=1.368, 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 cKBOyHAr3QNF for ; Thu, 5 Aug 2010 05:02:14 -0700 (PDT) Received: from pacdcimo01.cable.comcast.com (PacdcIMO01.cable.comcast.com [24.40.8.145]) by core3.amsl.com (Postfix) with ESMTP id 906FB3A687B for ; Thu, 5 Aug 2010 05:02:14 -0700 (PDT) Received: from ([24.40.55.42]) by pacdcimo01.cable.comcast.com with ESMTP with TLS id 5503620.88540224; Thu, 05 Aug 2010 08:02:43 -0400 Received: from PACDCEXCSMTP03.cable.comcast.com (24.40.15.92) by PACDCEXHUB01.cable.comcast.com (24.40.55.42) with Microsoft SMTP Server id 14.0.702.0; Thu, 5 Aug 2010 08:02:42 -0400 Received: from pacdcexcmb05.cable.comcast.com ([24.40.15.116]) by PACDCEXCSMTP03.cable.comcast.com with Microsoft SMTPSVC(6.0.3790.4675); Thu, 5 Aug 2010 08:02:41 -0400 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-Class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Date: Thu, 5 Aug 2010 08:01:54 -0400 Message-ID: In-Reply-To: <4C5AA4BD.1050407@infinite-source.de> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [ledbat] review of draft-ietf-ledbat-congestion Thread-Index: Acs0lBC3LqszLcyoTG2ZsejMPwonxgAAe4bs From: "Woundy, Richard" To: , X-OriginalArrivalTime: 05 Aug 2010 12:02:41.0213 (UTC) FILETIME=[1AF406D0:01CB3496] Cc: ledbat@ietf.org Subject: Re: [ledbat] review of draft-ietf-ledbat-congestion 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, 05 Aug 2010 12:02:20 -0000 >In practice you will probably see that high link utilization at the = bottleneck would cause AQM algorithms like RED or BLUE to drop packets = or ECN-mark them Assuming the bottleneck link *has* implemented AQM, which tends not to = be the case for many broadband modems for example. ----- Original Message ----- From: ledbat-bounces@ietf.org To: Rolf Winter Cc: ledbat@ietf.org Sent: Thu Aug 05 07:47:09 2010 Subject: Re: [ledbat] review of draft-ietf-ledbat-congestion In practice you will probably see that high link utilization at the=20 bottleneck would cause AQM algorithms like RED or BLUE to drop packets=20 or ECN-mark them, which as far as i understand it would induce TCP-like=20 AIMD-see-saw-ing in LEDBAT like you see it in most other congestion=20 control algorithms. On 05.08.2010 10:24, Rolf Winter wrote: > Gengyu, > > I think I have not answered you yet. Sorry for that, the IETF meeting = and all... > > To answer your question. In an ideal world LEDBAT would consume 100% = of the available bandwidth if no other traffic passes the bottleneck, = which we assume to be at the modem in your uplink direction. Once other = traffic competes for the bandwidth, LEDBAT would ideally disappear or = consume some of the bandwidth in case the extra delay of the other = traffic is< 25ms. Now that is the theory, in practice you want to get = as close to that behavior as possible. > > Best, > > Rolf > > > NEC Europe Limited | Registered Office: NEC House, 1 Victoria Road, = London W3 6BL | Registered in England 2832014 > > > =20 >> -----Original Message----- >> From: ledbat-bounces@ietf.org [mailto:ledbat-bounces@ietf.org] On >> Behalf Of Gengyu WEI >> Sent: Dienstag, 27. Juli 2010 09:11 >> To: Rolf Winter >> Cc: ledbat@ietf.org >> Subject: Re: [ledbat] review of draft-ietf-ledbat-congestion >> >> Rof, >> >> There is a question. >> >> What do you mean "saturate the bottleneck" ? >> Does it mean that the bottleneck link utilization is more than 90%, = or >> 95%, or even more? >> >> In the draft, >> >> LEDBAT design goals are: >> >> 1. saturate the bottleneck >> >> 2. keep delay low when no other traffic is present >> >> ... >> >> Regards, >> >> Gengyu >> >> ----- Original Message ----- >> From: "Rolf Winter" >> To: >> Sent: Friday, July 16, 2010 4:31 PM >> Subject: [ledbat] review of draft-ietf-ledbat-congestion >> >> >> =20 >>> WG, >>> >>> please review draft-ietf-ledbat-congestion, and see if your comments >>> =20 >> have been adequately addressed. If you do not see any issues please >> also speak up. I'd like to get a feeling whether the group thinks the >> draft is done or not. >> =20 >>> Thanks, >>> >>> Rolf >>> >>> >>> NEC Europe Limited | Registered Office: NEC House, 1 Victoria Road, >>> =20 >> London W3 6BL | Registered in England 2832014 >> =20 >>> >>> _______________________________________________ >>> ledbat mailing list >>> ledbat@ietf.org >>> https://www.ietf.org/mailman/listinfo/ledbat >>> >>> =20 >> _______________________________________________ >> ledbat mailing list >> ledbat@ietf.org >> https://www.ietf.org/mailman/listinfo/ledbat >> =20 > _______________________________________________ > ledbat mailing list > ledbat@ietf.org > https://www.ietf.org/mailman/listinfo/ledbat > > =20 _______________________________________________ ledbat mailing list ledbat@ietf.org https://www.ietf.org/mailman/listinfo/ledbat From Rolf.Winter@neclab.eu Thu Aug 5 06:22:37 2010 Return-Path: X-Original-To: ledbat@core3.amsl.com Delivered-To: ledbat@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 7C4E03A69FD for ; Thu, 5 Aug 2010 06:22:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.968 X-Spam-Level: X-Spam-Status: No, score=-101.968 tagged_above=-999 required=5 tests=[AWL=0.281, 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 OVYLstF9fC9Z for ; Thu, 5 Aug 2010 06:22:36 -0700 (PDT) Received: from smtp0.netlab.nec.de (smtp0.netlab.nec.de [195.37.70.40]) by core3.amsl.com (Postfix) with ESMTP id 71EF93A680C for ; Thu, 5 Aug 2010 06:22:35 -0700 (PDT) Received: from localhost (localhost.localdomain [127.0.0.1]) by smtp0.netlab.nec.de (Postfix) with ESMTP id 956C42800017B; Thu, 5 Aug 2010 15:23:05 +0200 (CEST) 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 Z2JMQayg5puZ; Thu, 5 Aug 2010 15:23:05 +0200 (CEST) Received: from ENCELADUS.office.hd (Enceladus.office.hd [192.168.24.52]) by smtp0.netlab.nec.de (Postfix) with ESMTP id 7825528000167; Thu, 5 Aug 2010 15:22:50 +0200 (CEST) Received: from PALLENE.office.hd ([169.254.1.17]) by ENCELADUS.office.hd ([192.168.24.52]) with mapi; Thu, 5 Aug 2010 15:21:47 +0200 From: Rolf Winter To: "Woundy, Richard" , "the8472@infinite-source.de" Thread-Topic: [ledbat] review of draft-ietf-ledbat-congestion Thread-Index: AQHLLVrPyGiM3AJg1UKlAw9EccrgxJLSkbGggAAZ8ICAAAQfAIAANoew Date: Thu, 5 Aug 2010 13:21:45 +0000 Message-ID: <791AD3077F94194BB2BDD13565B6295D644CE9@PALLENE.office.hd> References: <4C5AA4BD.1050407@infinite-source.de> In-Reply-To: Accept-Language: de-DE, 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 draft-ietf-ledbat-congestion 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, 05 Aug 2010 13:22:37 -0000 Hi, We have found some modern DSL home gateways to implement some sort of traff= ic shaping to prioritize predefined traffic types such as VoIP and certain = high priority packets (ACKs, ICMP etc.). These actually solve the LEDBAT pr= oblem, i.e. with those LEDBAT is not needed any more (if you get the traffi= c classification right) and you can use TCP for your P2P apps. But as Richa= rd has mentioned, we found none that do RED or ECN marking. But Lars owns a= gazillion home gateways and does some test. Hopefully, he'll at some point= do some tests to shed more light on this. Best, Rolf NEC Europe Limited | Registered Office: NEC House, 1 Victoria Road, London = W3 6BL | Registered in England 2832014=20 > -----Original Message----- > From: ledbat-bounces@ietf.org [mailto:ledbat-bounces@ietf.org] On > Behalf Of Woundy, Richard > Sent: Donnerstag, 5. August 2010 14:02 > To: the8472@infinite-source.de; Rolf Winter > Cc: ledbat@ietf.org > Subject: Re: [ledbat] review of draft-ietf-ledbat-congestion >=20 > >In practice you will probably see that high link utilization at the > bottleneck would cause AQM algorithms like RED or BLUE to drop packets > or ECN-mark them >=20 > Assuming the bottleneck link *has* implemented AQM, which tends not to > be the case for many broadband modems for example. >=20 >=20 >=20 > ----- Original Message ----- > From: ledbat-bounces@ietf.org > To: Rolf Winter > Cc: ledbat@ietf.org > Sent: Thu Aug 05 07:47:09 2010 > Subject: Re: [ledbat] review of draft-ietf-ledbat-congestion >=20 > In practice you will probably see that high link utilization at the > bottleneck would cause AQM algorithms like RED or BLUE to drop packets > or ECN-mark them, which as far as i understand it would induce TCP-like > AIMD-see-saw-ing in LEDBAT like you see it in most other congestion > control algorithms. >=20 > On 05.08.2010 10:24, Rolf Winter wrote: > > Gengyu, > > > > I think I have not answered you yet. Sorry for that, the IETF meeting > and all... > > > > To answer your question. In an ideal world LEDBAT would consume 100% > of the available bandwidth if no other traffic passes the bottleneck, > which we assume to be at the modem in your uplink direction. Once other > traffic competes for the bandwidth, LEDBAT would ideally disappear or > consume some of the bandwidth in case the extra delay of the other > traffic is< 25ms. Now that is the theory, in practice you want to get > as close to that behavior as possible. > > > > 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 Gengyu WEI > >> Sent: Dienstag, 27. Juli 2010 09:11 > >> To: Rolf Winter > >> Cc: ledbat@ietf.org > >> Subject: Re: [ledbat] review of draft-ietf-ledbat-congestion > >> > >> Rof, > >> > >> There is a question. > >> > >> What do you mean "saturate the bottleneck" ? > >> Does it mean that the bottleneck link utilization is more than 90%, > or > >> 95%, or even more? > >> > >> In the draft, > >> > >> LEDBAT design goals are: > >> > >> 1. saturate the bottleneck > >> > >> 2. keep delay low when no other traffic is present > >> > >> ... > >> > >> Regards, > >> > >> Gengyu > >> > >> ----- Original Message ----- > >> From: "Rolf Winter" > >> To: > >> Sent: Friday, July 16, 2010 4:31 PM > >> Subject: [ledbat] review of draft-ietf-ledbat-congestion > >> > >> > >> > >>> WG, > >>> > >>> please review draft-ietf-ledbat-congestion, and see if your > comments > >>> > >> have been adequately addressed. If you do not see any issues please > >> also speak up. I'd like to get a feeling whether the group thinks > the > >> draft is done or not. > >> > >>> 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 > >> > > _______________________________________________ > > ledbat mailing list > > ledbat@ietf.org > > https://www.ietf.org/mailman/listinfo/ledbat > > > > >=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 Thu Aug 5 06:36:43 2010 Return-Path: X-Original-To: ledbat@core3.amsl.com Delivered-To: ledbat@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id C36333A67D9 for ; Thu, 5 Aug 2010 06:36:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -108.168 X-Spam-Level: X-Spam-Status: No, score=-108.168 tagged_above=-999 required=5 tests=[AWL=0.295, BAYES_00=-2.599, HELO_EQ_MODEMCABLE=0.768, HOST_EQ_MODEMCABLE=1.368, 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 4L0V9srRIMQ9 for ; Thu, 5 Aug 2010 06:36:42 -0700 (PDT) Received: from pacdcimo01.cable.comcast.com (PacdcIMO01.cable.comcast.com [24.40.8.145]) by core3.amsl.com (Postfix) with ESMTP id CD2703A6827 for ; Thu, 5 Aug 2010 06:36:41 -0700 (PDT) Received: from ([24.40.55.41]) by pacdcimo01.cable.comcast.com with ESMTP with TLS id 5503620.88550006; Thu, 05 Aug 2010 09:37:09 -0400 Received: from PACDCEXCSMTP03.cable.comcast.com (24.40.15.92) by PACDCEXHUB02.cable.comcast.com (24.40.55.41) with Microsoft SMTP Server id 14.0.702.0; Thu, 5 Aug 2010 09:37:09 -0400 Received: from pacdcexcmb05.cable.comcast.com ([24.40.15.116]) by PACDCEXCSMTP03.cable.comcast.com with Microsoft SMTPSVC(6.0.3790.4675); Thu, 5 Aug 2010 09:37:05 -0400 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-Class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Thu, 5 Aug 2010 09:36:27 -0400 Message-ID: In-Reply-To: <791AD3077F94194BB2BDD13565B6295D644CE9@PALLENE.office.hd> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [ledbat] review of draft-ietf-ledbat-congestion Thread-Index: AQHLLVrPyGiM3AJg1UKlAw9EccrgxJLSkbGggAAZ8ICAAAQfAIAANoewgAAFBuA= References: <4C5AA4BD.1050407@infinite-source.de> <791AD3077F94194BB2BDD13565B6295D644CE9@PALLENE.office.hd> From: "Woundy, Richard" To: Rolf Winter , X-OriginalArrivalTime: 05 Aug 2010 13:37:05.0686 (UTC) FILETIME=[4B3E0360:01CB34A3] Cc: ledbat@ietf.org Subject: Re: [ledbat] review of draft-ietf-ledbat-congestion 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, 05 Aug 2010 13:36:43 -0000 > But as Richard has mentioned, we found none that do RED or ECN marking. But Lars owns a gazillion home gateways and does some test. Hopefully, he'll at some point do some tests to shed more light on this. >From section 4.3.2 of http://conferences.sigcomm.org/imc/2007/papers/imc137.pdf: "We found that 26.2% of the DSL hosts show a RED-style drop policy on their upstream queues. The three providers owned by AT&T (i.e., Ameritech, BellSouth, and PacBell) exhibit deployment rates between 50.3% and 60.5%, whereas all other DSL providers' deployment rates are below 23.0%. The partial deployment of RED-style policies within ISPs could be due to heterogeneity in the ISPs' equipment. We did not detect RED in any of the cable ISPs measured." It would be good to see what Lars sees in his lab testing. -- Rich -----Original Message----- From: ledbat-bounces@ietf.org [mailto:ledbat-bounces@ietf.org] On Behalf Of Rolf Winter Sent: Thursday, August 05, 2010 9:22 AM To: Woundy, Richard; the8472@infinite-source.de Cc: ledbat@ietf.org Subject: Re: [ledbat] review of draft-ietf-ledbat-congestion Hi, We have found some modern DSL home gateways to implement some sort of traffic shaping to prioritize predefined traffic types such as VoIP and certain high priority packets (ACKs, ICMP etc.). These actually solve the LEDBAT problem, i.e. with those LEDBAT is not needed any more (if you get the traffic classification right) and you can use TCP for your P2P apps. But as Richard has mentioned, we found none that do RED or ECN marking. But Lars owns a gazillion home gateways and does some test. Hopefully, he'll at some point do some tests to shed more light on this. Best, Rolf NEC Europe Limited | Registered Office: NEC House, 1 Victoria Road, London W3 6BL | Registered in England 2832014=20 > -----Original Message----- > From: ledbat-bounces@ietf.org [mailto:ledbat-bounces@ietf.org] On > Behalf Of Woundy, Richard > Sent: Donnerstag, 5. August 2010 14:02 > To: the8472@infinite-source.de; Rolf Winter > Cc: ledbat@ietf.org > Subject: Re: [ledbat] review of draft-ietf-ledbat-congestion >=20 > >In practice you will probably see that high link utilization at the > bottleneck would cause AQM algorithms like RED or BLUE to drop packets > or ECN-mark them >=20 > Assuming the bottleneck link *has* implemented AQM, which tends not to > be the case for many broadband modems for example. >=20 >=20 >=20 > ----- Original Message ----- > From: ledbat-bounces@ietf.org > To: Rolf Winter > Cc: ledbat@ietf.org > Sent: Thu Aug 05 07:47:09 2010 > Subject: Re: [ledbat] review of draft-ietf-ledbat-congestion >=20 > In practice you will probably see that high link utilization at the > bottleneck would cause AQM algorithms like RED or BLUE to drop packets > or ECN-mark them, which as far as i understand it would induce TCP-like > AIMD-see-saw-ing in LEDBAT like you see it in most other congestion > control algorithms. >=20 > On 05.08.2010 10:24, Rolf Winter wrote: > > Gengyu, > > > > I think I have not answered you yet. Sorry for that, the IETF meeting > and all... > > > > To answer your question. In an ideal world LEDBAT would consume 100% > of the available bandwidth if no other traffic passes the bottleneck, > which we assume to be at the modem in your uplink direction. Once other > traffic competes for the bandwidth, LEDBAT would ideally disappear or > consume some of the bandwidth in case the extra delay of the other > traffic is< 25ms. Now that is the theory, in practice you want to get > as close to that behavior as possible. > > > > 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 Gengyu WEI > >> Sent: Dienstag, 27. Juli 2010 09:11 > >> To: Rolf Winter > >> Cc: ledbat@ietf.org > >> Subject: Re: [ledbat] review of draft-ietf-ledbat-congestion > >> > >> Rof, > >> > >> There is a question. > >> > >> What do you mean "saturate the bottleneck" ? > >> Does it mean that the bottleneck link utilization is more than 90%, > or > >> 95%, or even more? > >> > >> In the draft, > >> > >> LEDBAT design goals are: > >> > >> 1. saturate the bottleneck > >> > >> 2. keep delay low when no other traffic is present > >> > >> ... > >> > >> Regards, > >> > >> Gengyu > >> > >> ----- Original Message ----- > >> From: "Rolf Winter" > >> To: > >> Sent: Friday, July 16, 2010 4:31 PM > >> Subject: [ledbat] review of draft-ietf-ledbat-congestion > >> > >> > >> > >>> WG, > >>> > >>> please review draft-ietf-ledbat-congestion, and see if your > comments > >>> > >> have been adequately addressed. If you do not see any issues please > >> also speak up. I'd like to get a feeling whether the group thinks > the > >> draft is done or not. > >> > >>> 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 > >> > > _______________________________________________ > > ledbat mailing list > > ledbat@ietf.org > > https://www.ietf.org/mailman/listinfo/ledbat > > > > >=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 _______________________________________________ ledbat mailing list ledbat@ietf.org https://www.ietf.org/mailman/listinfo/ledbat From the8472@infinite-source.de Thu Aug 5 07:00:18 2010 Return-Path: X-Original-To: ledbat@core3.amsl.com Delivered-To: ledbat@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id CE0823A68DA for ; Thu, 5 Aug 2010 07:00:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.249 X-Spam-Level: X-Spam-Status: No, score=-2.249 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_DE=0.35] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id cJ4Dnk7GObJi for ; Thu, 5 Aug 2010 07:00:17 -0700 (PDT) Received: from mo-p00-ob.rzone.de (mo-p00-ob.rzone.de [81.169.146.161]) by core3.amsl.com (Postfix) with ESMTP id 466D03A69D6 for ; Thu, 5 Aug 2010 07:00:16 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; t=1281016846; l=4018; s=domk; d=infinite-source.de; h=Content-Transfer-Encoding:Content-Type:In-Reply-To:References: Subject:CC:To:MIME-Version:From:Date:X-RZG-CLASS-ID:X-RZG-AUTH; bh=jaxTKmyAvKbnw4vEIt7hyYH6orQ=; b=cMOUL/gQrcXZMvifYMvOeCK7Op+wdyWn5fiwszi2TCIVygMVESEECGDF6cje7dDm3F5 j0RkMtlbmVCW2WXRtvd+z2fu9535Kt7KRy1bEMU2k4vnxA3qjACF8biICP8n9CnnZBUZE /HChJHXWaWKHaPdLXRgHaWyOqb8mlfKpmcs= X-RZG-AUTH: :LW0Wek7mfO1Vkr5kPgWDvaJNkQpNEn8ylntakOISso1hE0McXW12o8AG24SD41nTjiZr3INXm/0ZjY2cbw== X-RZG-CLASS-ID: mo00 Received: from [192.168.1.103] (p5B17188A.dip0.t-ipconnect.de [91.23.24.138]) by post.strato.de (jimi mo20) (RZmta 23.4) with ESMTP id z01c5am75DJM1R ; Thu, 5 Aug 2010 16:00:37 +0200 (MEST) Message-ID: <4C5AC3F8.7030103@infinite-source.de> Date: Thu, 05 Aug 2010 16:00:24 +0200 From: The 8472 User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.1; en-GB; rv:1.9.1.11) Gecko/20100711 Lightning/1.0b1 Thunderbird/3.0.6 MIME-Version: 1.0 To: "Woundy, Richard" References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: ledbat@ietf.org, Rolf.Winter@neclab.eu Subject: Re: [ledbat] review of draft-ietf-ledbat-congestion 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, 05 Aug 2010 14:00:18 -0000 keep in mind that it's not always the modem that's the bottlneck. Artificial throttling employed by some ISPs, shared local loops in cable networks and other side-effects of overselling available bandwidth can cause packet drops too and might include AQM too. On 05.08.2010 14:01, Woundy, Richard wrote: >> In practice you will probably see that high link utilization at the bottleneck would cause AQM algorithms like RED or BLUE to drop packets or ECN-mark them >> > Assuming the bottleneck link *has* implemented AQM, which tends not to be the case for many broadband modems for example. > > > > ----- Original Message ----- > From: ledbat-bounces@ietf.org > To: Rolf Winter > Cc: ledbat@ietf.org > Sent: Thu Aug 05 07:47:09 2010 > Subject: Re: [ledbat] review of draft-ietf-ledbat-congestion > > In practice you will probably see that high link utilization at the > bottleneck would cause AQM algorithms like RED or BLUE to drop packets > or ECN-mark them, which as far as i understand it would induce TCP-like > AIMD-see-saw-ing in LEDBAT like you see it in most other congestion > control algorithms. > > On 05.08.2010 10:24, Rolf Winter wrote: > >> Gengyu, >> >> I think I have not answered you yet. Sorry for that, the IETF meeting and all... >> >> To answer your question. In an ideal world LEDBAT would consume 100% of the available bandwidth if no other traffic passes the bottleneck, which we assume to be at the modem in your uplink direction. Once other traffic competes for the bandwidth, LEDBAT would ideally disappear or consume some of the bandwidth in case the extra delay of the other traffic is< 25ms. Now that is the theory, in practice you want to get as close to that behavior as possible. >> >> 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 Gengyu WEI >>> Sent: Dienstag, 27. Juli 2010 09:11 >>> To: Rolf Winter >>> Cc: ledbat@ietf.org >>> Subject: Re: [ledbat] review of draft-ietf-ledbat-congestion >>> >>> Rof, >>> >>> There is a question. >>> >>> What do you mean "saturate the bottleneck" ? >>> Does it mean that the bottleneck link utilization is more than 90%, or >>> 95%, or even more? >>> >>> In the draft, >>> >>> LEDBAT design goals are: >>> >>> 1. saturate the bottleneck >>> >>> 2. keep delay low when no other traffic is present >>> >>> ... >>> >>> Regards, >>> >>> Gengyu >>> >>> ----- Original Message ----- >>> From: "Rolf Winter" >>> To: >>> Sent: Friday, July 16, 2010 4:31 PM >>> Subject: [ledbat] review of draft-ietf-ledbat-congestion >>> >>> >>> >>> >>>> WG, >>>> >>>> please review draft-ietf-ledbat-congestion, and see if your comments >>>> >>>> >>> have been adequately addressed. If you do not see any issues please >>> also speak up. I'd like to get a feeling whether the group thinks the >>> draft is done or not. >>> >>> >>>> 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 >>> >>> >> _______________________________________________ >> 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 mirja.kuehlewind@ikr.uni-stuttgart.de Thu Aug 5 09:25:38 2010 Return-Path: X-Original-To: ledbat@core3.amsl.com Delivered-To: ledbat@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 769713A6978 for ; Thu, 5 Aug 2010 09:25:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.638 X-Spam-Level: X-Spam-Status: No, score=-1.638 tagged_above=-999 required=5 tests=[AWL=0.611, 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 w1Apc8V67oJk for ; Thu, 5 Aug 2010 09:25:37 -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 E7E8D3A68B6 for ; Thu, 5 Aug 2010 09:25:36 -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 5CC26633FA for ; Thu, 5 Aug 2010 18:26:06 +0200 (CEST) Received: from vpn-1-cl05 (vpn-1-cl05 [10.88.11.15]) by netsrv1.ikr.uni-stuttgart.de (Postfix) with ESMTP id 2AB7DBC07E for ; Thu, 5 Aug 2010 18:26:06 +0200 (CEST) From: Mirja Kuehlewind Organization: University of Stuttgart (Germany), IKR To: ledbat@ietf.org Date: Thu, 5 Aug 2010 18:26:02 +0200 User-Agent: KMail/1.9.10 (enterprise35 0.20090731.1005176) References: <547F018265F92642B577B986577D671C01594038@VENUS.office> <791AD3077F94194BB2BDD13565B6295D64358A@PALLENE.office.hd> <4C5AA4BD.1050407@infinite-source.de> In-Reply-To: <4C5AA4BD.1050407@infinite-source.de> 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: <201008051826.02708.mirja.kuehlewind@ikr.uni-stuttgart.de> Subject: Re: [ledbat] review of draft-ietf-ledbat-congestion 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, 05 Aug 2010 16:25:38 -0000 Hi, LEDBAT's aim is to avoid queuing delays that means LEDBAT tries to fully=20 utilize the capacity but keep the queue empty. Of cause LEDBAT will not be= =20 able to keep the queue completely empty but the queue length will be=20 determined by the TARGET value and the bottleneck bandwidth. Anyway the que= ue=20 length should be smaller than a dropping/marking threshold in a RED router. Mirja On Thursday 05 August 2010 13:47:09 The 8472 wrote: > In practice you will probably see that high link utilization at the > bottleneck would cause AQM algorithms like RED or BLUE to drop packets > or ECN-mark them, which as far as i understand it would induce TCP-like > AIMD-see-saw-ing in LEDBAT like you see it in most other congestion > control algorithms. > > On 05.08.2010 10:24, Rolf Winter wrote: > > Gengyu, > > > > I think I have not answered you yet. Sorry for that, the IETF meeting a= nd > > all... > > > > To answer your question. In an ideal world LEDBAT would consume 100% of > > the available bandwidth if no other traffic passes the bottleneck, which > > we assume to be at the modem in your uplink direction. Once other traff= ic > > competes for the bandwidth, LEDBAT would ideally disappear or consume > > some of the bandwidth in case the extra delay of the other traffic is<= =20 > > 25ms. Now that is the theory, in practice you want to get as close to > > that behavior as possible. > > > > 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 Gengyu WEI > >> Sent: Dienstag, 27. Juli 2010 09:11 > >> To: Rolf Winter > >> Cc: ledbat@ietf.org > >> Subject: Re: [ledbat] review of draft-ietf-ledbat-congestion > >> > >> Rof, > >> > >> There is a question. > >> > >> What do you mean "saturate the bottleneck" ? > >> Does it mean that the bottleneck link utilization is more than 90%, or > >> 95%, or even more? > >> > >> In the draft, > >> > >> LEDBAT design goals are: > >> > >> 1. saturate the bottleneck > >> > >> 2. keep delay low when no other traffic is present > >> > >> ... > >> > >> Regards, > >> > >> Gengyu > >> > >> ----- Original Message ----- > >> From: "Rolf Winter" > >> To: > >> Sent: Friday, July 16, 2010 4:31 PM > >> Subject: [ledbat] review of draft-ietf-ledbat-congestion > >> > >>> WG, > >>> > >>> please review draft-ietf-ledbat-congestion, and see if your comments > >> > >> have been adequately addressed. If you do not see any issues please > >> also speak up. I'd like to get a feeling whether the group thinks the > >> draft is done or not. > >> > >>> 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 > > > > _______________________________________________ > > 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 =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 muraris@microsoft.com Thu Aug 5 11:13:06 2010 Return-Path: X-Original-To: ledbat@core3.amsl.com Delivered-To: ledbat@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 7F26B3A6A98 for ; Thu, 5 Aug 2010 11:13:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -110.599 X-Spam-Level: X-Spam-Status: No, score=-110.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id UfmVRytxhRpP for ; Thu, 5 Aug 2010 11:13:05 -0700 (PDT) Received: from smtp.microsoft.com (smtp.microsoft.com [131.107.115.215]) by core3.amsl.com (Postfix) with ESMTP id ECBB83A6971 for ; Thu, 5 Aug 2010 11:13:04 -0700 (PDT) Received: from TK5EX14HUBC105.redmond.corp.microsoft.com (157.54.80.48) by TK5-EXGWY-E802.partners.extranet.microsoft.com (10.251.56.168) with Microsoft SMTP Server (TLS) id 8.2.176.0; Thu, 5 Aug 2010 11:13:35 -0700 Received: from tk5ex14mbxc105.redmond.corp.microsoft.com ([169.254.2.233]) by TK5EX14HUBC105.redmond.corp.microsoft.com ([157.54.80.48]) with mapi id 14.01.0180.004; Thu, 5 Aug 2010 11:13:35 -0700 From: Murari Sridharan To: The 8472 , "Woundy, Richard" Thread-Topic: [ledbat] review of draft-ietf-ledbat-congestion Thread-Index: AcskwUWQ2PKWShuZTuqPJcBe3eGeEAImZiKhAdXePwAABxEmgAAAg+AAAAQjeQAABeQNYA== Date: Thu, 5 Aug 2010 18:13:35 +0000 Message-ID: <902F4C8483487C40A366621E25F01D96267AE4EE@tk5ex14mbxc105.redmond.corp.microsoft.com> References: <4C5AC3F8.7030103@infinite-source.de> In-Reply-To: <4C5AC3F8.7030103@infinite-source.de> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [157.54.51.73] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "ledbat@ietf.org" , "Rolf.Winter@neclab.eu" Subject: Re: [ledbat] review of draft-ietf-ledbat-congestion 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, 05 Aug 2010 18:13:06 -0000 Even if AQM support itself is available in silicon, configuring the paramet= ers will still be a pain. Also if you try AQM in places that have low stat = mux the link will not be work conserving due to the saw tooth behavior, so = unless this is a high stat mux background router chances of AQM being enabl= ed and configured appropriately is low, IMO.=20 -----Original Message----- From: ledbat-bounces@ietf.org [mailto:ledbat-bounces@ietf.org] On Behalf Of= The 8472 Sent: Thursday, August 05, 2010 7:00 AM To: Woundy, Richard Cc: ledbat@ietf.org; Rolf.Winter@neclab.eu Subject: Re: [ledbat] review of draft-ietf-ledbat-congestion keep in mind that it's not always the modem that's the bottlneck.=20 Artificial throttling employed by some ISPs, shared local loops in cable ne= tworks and other side-effects of overselling available bandwidth can cause = packet drops too and might include AQM too. On 05.08.2010 14:01, Woundy, Richard wrote: >> In practice you will probably see that high link utilization at the=20 >> bottleneck would cause AQM algorithms like RED or BLUE to drop=20 >> packets or ECN-mark them >> =20 > Assuming the bottleneck link *has* implemented AQM, which tends not to be= the case for many broadband modems for example. > > > > ----- Original Message ----- > From: ledbat-bounces@ietf.org > To: Rolf Winter > Cc: ledbat@ietf.org > Sent: Thu Aug 05 07:47:09 2010 > Subject: Re: [ledbat] review of draft-ietf-ledbat-congestion > > In practice you will probably see that high link utilization at the=20 > bottleneck would cause AQM algorithms like RED or BLUE to drop packets=20 > or ECN-mark them, which as far as i understand it would induce=20 > TCP-like AIMD-see-saw-ing in LEDBAT like you see it in most other=20 > congestion control algorithms. > > On 05.08.2010 10:24, Rolf Winter wrote: > =20 >> Gengyu, >> >> I think I have not answered you yet. Sorry for that, the IETF meeting an= d all... >> >> To answer your question. In an ideal world LEDBAT would consume 100% of = the available bandwidth if no other traffic passes the bottleneck, which we= assume to be at the modem in your uplink direction. Once other traffic com= petes for the bandwidth, LEDBAT would ideally disappear or consume some of = the bandwidth in case the extra delay of the other traffic is< 25ms. Now = that is the theory, in practice you want to get as close to that behavior a= s possible. >> >> Best, >> >> Rolf >> >> >> NEC Europe Limited | Registered Office: NEC House, 1 Victoria Road,=20 >> London W3 6BL | Registered in England 2832014 >> >> >> >> =20 >>> -----Original Message----- >>> From: ledbat-bounces@ietf.org [mailto:ledbat-bounces@ietf.org] On=20 >>> Behalf Of Gengyu WEI >>> Sent: Dienstag, 27. Juli 2010 09:11 >>> To: Rolf Winter >>> Cc: ledbat@ietf.org >>> Subject: Re: [ledbat] review of draft-ietf-ledbat-congestion >>> >>> Rof, >>> >>> There is a question. >>> >>> What do you mean "saturate the bottleneck" ? >>> Does it mean that the bottleneck link utilization is more than 90%,=20 >>> or 95%, or even more? >>> >>> In the draft, >>> >>> LEDBAT design goals are: >>> >>> 1. saturate the bottleneck >>> >>> 2. keep delay low when no other traffic is present >>> >>> ... >>> >>> Regards, >>> >>> Gengyu >>> >>> ----- Original Message ----- >>> From: "Rolf Winter" To: >>> Sent: Friday, July 16, 2010 4:31 PM >>> Subject: [ledbat] review of draft-ietf-ledbat-congestion >>> >>> >>> >>> =20 >>>> WG, >>>> >>>> please review draft-ietf-ledbat-congestion, and see if your comments >>>> >>>> =20 >>> have been adequately addressed. If you do not see any issues please >>> also speak up. I'd like to get a feeling whether the group thinks the >>> draft is done or not. >>> >>> =20 >>>> Thanks, >>>> >>>> Rolf >>>> >>>> >>>> NEC Europe Limited | Registered Office: NEC House, 1 Victoria Road, >>>> >>>> =20 >>> London W3 6BL | Registered in England 2832014 >>> >>> =20 >>>> _______________________________________________ >>>> ledbat mailing list >>>> ledbat@ietf.org >>>> https://www.ietf.org/mailman/listinfo/ledbat >>>> >>>> >>>> =20 >>> _______________________________________________ >>> ledbat mailing list >>> ledbat@ietf.org >>> https://www.ietf.org/mailman/listinfo/ledbat >>> >>> =20 >> _______________________________________________ >> ledbat mailing list >> ledbat@ietf.org >> https://www.ietf.org/mailman/listinfo/ledbat >> >> >> =20 > _______________________________________________ > ledbat mailing list > ledbat@ietf.org > https://www.ietf.org/mailman/listinfo/ledbat > > =20 _______________________________________________ ledbat mailing list ledbat@ietf.org https://www.ietf.org/mailman/listinfo/ledbat From weigengyu@vip.sina.com Thu Aug 5 16:48:22 2010 Return-Path: X-Original-To: ledbat@core3.amsl.com Delivered-To: ledbat@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id BE2103A689E for ; Thu, 5 Aug 2010 16:48:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.566 X-Spam-Level: * X-Spam-Status: No, score=1.566 tagged_above=-999 required=5 tests=[BAYES_20=-0.74, HELO_MISMATCH_COM=0.553, MIME_BASE64_TEXT=1.753] 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 Zxm99VKXqLJA for ; Thu, 5 Aug 2010 16:48:20 -0700 (PDT) Received: from smtp-6-96.vip.sina.com (mail3-172.sinamail.sina.com.cn [202.108.3.172]) by core3.amsl.com (Postfix) with ESMTP id 3C8133A684B for ; Thu, 5 Aug 2010 16:48:19 -0700 (PDT) Received: from ironsmtp-xd5-210.sinamail.sina.com.cn (unknown [10.55.5.210]) by smtp-6-96.vip.sina.com (SINAMAIL) with ESMTP id 317E54CECDA for ; Fri, 6 Aug 2010 07:48:48 +0800 (CST) X-Originating-IP: [221.218.42.139] X-Auth-ID: weigengyu X-Auth-ID: weigengyu X-Originating-IP: 221.218.42.139 X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AkoFAGOPWkzd2iqL/3poAIhvlmFqccczhToEhB6HYQ Received: from unknown (HELO Notebook) ([221.218.42.139]) by ironsmtp-xd5-210.sinamail.sina.com.cn with ESMTP; 06 Aug 2010 07:48:48 +0800 Message-ID: From: "Gengyu WEI" To: "Rolf Winter" References: <547F018265F92642B577B986577D671C01594038@VENUS.office> <791AD3077F94194BB2BDD13565B6295D64358A@PALLENE.office.hd> Date: Fri, 6 Aug 2010 07:48:47 +0800 MIME-Version: 1.0 Content-Type: text/plain; charset="ISO-8859-1" Content-Transfer-Encoding: base64 X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2900.5931 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.5931 Cc: ledbat@ietf.org Subject: Re: [ledbat] review of draft-ietf-ledbat-congestion 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, 05 Aug 2010 23:48:22 -0000 Um9sZiwgDQoNClRoYW5rIHlvdSBmb3IgeW91ciBhbnN3ZXJpbmcuDQoNCklzIFRoZSAiPDI1bXMi IG9mIHRoZSBleHRyYSBkZWxheSBvZiB0aGUgb3RoZXIgdHJhZmZpYyB3aXRoaW4gb25lIHF1ZXVl PyANCkhvdyBjb3VsZCB5b3Uga25vdyB0aGF0IGlzIHNpZ25pZmljYW50IGZyb20gdGhlIGVuZCB0 byBlbmQgcG9pbnQgb2Ygdmlldz8NCg0KR2VuZ3l1DQoNCi0tLS0tIE9yaWdpbmFsIE1lc3NhZ2Ug LS0tLS0gDQpGcm9tOiAiUm9sZiBXaW50ZXIiIDxSb2xmLldpbnRlckBuZWNsYWIuZXU+DQpUbzog Ikdlbmd5dSBXRUkiIDx3ZWlnZW5neXVAdmlwLnNpbmEuY29tPg0KQ2M6IDxsZWRiYXRAaWV0Zi5v cmc+DQpTZW50OiBUaHVyc2RheSwgQXVndXN0IDA1LCAyMDEwIDQ6MjQgUE0NClN1YmplY3Q6IFJF OiBbbGVkYmF0XSByZXZpZXcgb2YgZHJhZnQtaWV0Zi1sZWRiYXQtY29uZ2VzdGlvbg0KDQoNCkdl bmd5dSwNCg0KSSB0aGluayBJIGhhdmUgbm90IGFuc3dlcmVkIHlvdSB5ZXQuIFNvcnJ5IGZvciB0 aGF0LCB0aGUgSUVURiBtZWV0aW5nIGFuZCBhbGwuLi4NCg0KVG8gYW5zd2VyIHlvdXIgcXVlc3Rp b24uIEluIGFuIGlkZWFsIHdvcmxkIExFREJBVCB3b3VsZCBjb25zdW1lIDEwMCUgb2YgdGhlIGF2 YWlsYWJsZSBiYW5kd2lkdGggaWYgbm8gb3RoZXIgdHJhZmZpYyBwYXNzZXMgdGhlIGJvdHRsZW5l Y2ssIHdoaWNoIHdlIGFzc3VtZSB0byBiZSBhdCB0aGUgbW9kZW0gaW4geW91ciB1cGxpbmsgZGly ZWN0aW9uLiBPbmNlIG90aGVyIHRyYWZmaWMgY29tcGV0ZXMgZm9yIHRoZSBiYW5kd2lkdGgsIExF REJBVCB3b3VsZCBpZGVhbGx5IGRpc2FwcGVhciBvciBjb25zdW1lIHNvbWUgb2YgdGhlIGJhbmR3 aWR0aCBpbiBjYXNlIHRoZSBleHRyYSBkZWxheSBvZiB0aGUgb3RoZXIgdHJhZmZpYyBpcyA8IDI1 bXMuIE5vdyB0aGF0IGlzIHRoZSB0aGVvcnksIGluIHByYWN0aWNlIHlvdSB3YW50IHRvIGdldCBh cyBjbG9zZSB0byB0aGF0IGJlaGF2aW9yIGFzIHBvc3NpYmxlLiANCg0KQmVzdCwNCg0KUm9sZg0K DQoNCk5FQyBFdXJvcGUgTGltaXRlZCB8IFJlZ2lzdGVyZWQgT2ZmaWNlOiBORUMgSG91c2UsIDEg VmljdG9yaWEgUm9hZCwgTG9uZG9uIFczIDZCTCB8IFJlZ2lzdGVyZWQgaW4gRW5nbGFuZCAyODMy MDE0IA0KDQoNCj4gLS0tLS1PcmlnaW5hbCBNZXNzYWdlLS0tLS0NCj4gRnJvbTogbGVkYmF0LWJv dW5jZXNAaWV0Zi5vcmcgW21haWx0bzpsZWRiYXQtYm91bmNlc0BpZXRmLm9yZ10gT24NCj4gQmVo YWxmIE9mIEdlbmd5dSBXRUkNCj4gU2VudDogRGllbnN0YWcsIDI3LiBKdWxpIDIwMTAgMDk6MTEN Cj4gVG86IFJvbGYgV2ludGVyDQo+IENjOiBsZWRiYXRAaWV0Zi5vcmcNCj4gU3ViamVjdDogUmU6 IFtsZWRiYXRdIHJldmlldyBvZiBkcmFmdC1pZXRmLWxlZGJhdC1jb25nZXN0aW9uDQo+IA0KPiBS b2YsDQo+IA0KPiBUaGVyZSBpcyBhIHF1ZXN0aW9uLg0KPiANCj4gV2hhdCBkbyB5b3UgbWVhbiAi c2F0dXJhdGUgdGhlIGJvdHRsZW5lY2siID8NCj4gRG9lcyBpdCBtZWFuIHRoYXQgdGhlIGJvdHRs ZW5lY2sgbGluayB1dGlsaXphdGlvbiBpcyBtb3JlIHRoYW4gOTAlLCBvcg0KPiA5NSUsIG9yIGV2 ZW4gbW9yZT8NCj4gDQo+IEluIHRoZSBkcmFmdCwNCj4gDQo+ICBMRURCQVQgZGVzaWduIGdvYWxz IGFyZToNCj4gDQo+ICAgIDEuICBzYXR1cmF0ZSB0aGUgYm90dGxlbmVjaw0KPiANCj4gICAgMi4g IGtlZXAgZGVsYXkgbG93IHdoZW4gbm8gb3RoZXIgdHJhZmZpYyBpcyBwcmVzZW50DQo+IA0KPiAg ICAgIC4uLg0KPiANCj4gUmVnYXJkcywNCj4gDQo+IEdlbmd5dQ0KPiANCj4gLS0tLS0gT3JpZ2lu YWwgTWVzc2FnZSAtLS0tLQ0KPiBGcm9tOiAiUm9sZiBXaW50ZXIiIDxSb2xmLldpbnRlckBuZWNs YWIuZXU+DQo+IFRvOiA8bGVkYmF0QGlldGYub3JnPg0KPiBTZW50OiBGcmlkYXksIEp1bHkgMTYs IDIwMTAgNDozMSBQTQ0KPiBTdWJqZWN0OiBbbGVkYmF0XSByZXZpZXcgb2YgZHJhZnQtaWV0Zi1s ZWRiYXQtY29uZ2VzdGlvbg0KPiANCj4gDQo+ID4gV0csDQo+ID4NCj4gPiBwbGVhc2UgcmV2aWV3 IGRyYWZ0LWlldGYtbGVkYmF0LWNvbmdlc3Rpb24sIGFuZCBzZWUgaWYgeW91ciBjb21tZW50cw0K PiBoYXZlIGJlZW4gYWRlcXVhdGVseSBhZGRyZXNzZWQuIElmIHlvdSBkbyBub3Qgc2VlIGFueSBp c3N1ZXMgcGxlYXNlDQo+IGFsc28gc3BlYWsgdXAuIEknZCBsaWtlIHRvIGdldCBhIGZlZWxpbmcg d2hldGhlciB0aGUgZ3JvdXAgdGhpbmtzIHRoZQ0KPiBkcmFmdCBpcyBkb25lIG9yIG5vdC4NCj4g Pg0KPiA+IFRoYW5rcywNCj4gPg0KPiA+IFJvbGYNCj4gPg0KPiA+DQo+ID4gTkVDIEV1cm9wZSBM aW1pdGVkIHwgUmVnaXN0ZXJlZCBPZmZpY2U6IE5FQyBIb3VzZSwgMSBWaWN0b3JpYSBSb2FkLA0K PiBMb25kb24gVzMgNkJMIHwgUmVnaXN0ZXJlZCBpbiBFbmdsYW5kIDI4MzIwMTQNCj4gPg0KPiA+ DQo+ID4gX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18NCj4g PiBsZWRiYXQgbWFpbGluZyBsaXN0DQo+ID4gbGVkYmF0QGlldGYub3JnDQo+ID4gaHR0cHM6Ly93 d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9sZWRiYXQNCj4gPg0KPiBfX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXw0KPiBsZWRiYXQgbWFpbGluZyBsaXN0 DQo+IGxlZGJhdEBpZXRmLm9yZw0KPiBodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3Rp bmZvL2xlZGJhdA0K From shalunov@bittorrent.com Thu Aug 5 21:37:21 2010 Return-Path: X-Original-To: ledbat@core3.amsl.com Delivered-To: ledbat@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 2E9EF3A68DE for ; Thu, 5 Aug 2010 21:37:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.099 X-Spam-Level: X-Spam-Status: No, score=-3.099 tagged_above=-999 required=5 tests=[AWL=-0.500, 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 wtK2u5jxh7FY for ; Thu, 5 Aug 2010 21:37:18 -0700 (PDT) Received: from mail-px0-f172.google.com (mail-px0-f172.google.com [209.85.212.172]) by core3.amsl.com (Postfix) with ESMTP id D2B173A68B0 for ; Thu, 5 Aug 2010 21:37:18 -0700 (PDT) Received: by pxi20 with SMTP id 20so3158356pxi.31 for ; Thu, 05 Aug 2010 21:37:50 -0700 (PDT) Received: by 10.114.204.7 with SMTP id b7mr13496079wag.124.1281069469679; Thu, 05 Aug 2010 21:37:49 -0700 (PDT) Received: from [192.168.1.105] (c-67-188-254-19.hsd1.ca.comcast.net [67.188.254.19]) by mx.google.com with ESMTPS id s5sm1933631wak.0.2010.08.05.21.37.48 (version=TLSv1/SSLv3 cipher=RC4-MD5); Thu, 05 Aug 2010 21:37:48 -0700 (PDT) Message-Id: <373CC01B-6319-44DE-B58A-FD36265EDA58@bittorrent.com> From: Stanislav Shalunov To: ledbat@ietf.org In-Reply-To: <201008051826.02708.mirja.kuehlewind@ikr.uni-stuttgart.de> Content-Type: text/plain; charset=ISO-8859-1; format=flowed; delsp=yes Content-Transfer-Encoding: quoted-printable Mime-Version: 1.0 (Apple Message framework v936) Date: Thu, 5 Aug 2010 21:37:46 -0700 References: <547F018265F92642B577B986577D671C01594038@VENUS.office> <791AD3077F94194BB2BDD13565B6295D64358A@PALLENE.office.hd> <4C5AA4BD.1050407@infinite-source.de> <201008051826.02708.mirja.kuehlewind@ikr.uni-stuttgart.de> X-Mailer: Apple Mail (2.936) Subject: Re: [ledbat] review of draft-ietf-ledbat-congestion 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, 06 Aug 2010 04:37:21 -0000 That's correct. Even if silicon support is nominally present and configured, with the =20= upstream queue sizes seen in the wild, AQM drops should probably not =20 kick in when it's just LEDBAT using the link. --=20 Stanislav Shalunov BitTorrent Inc shalunov@bittorrent.com personal: http://shlang.com On Aug 5, 2010, at 9:26 AM, Mirja Kuehlewind wrote: > Hi, > > LEDBAT's aim is to avoid queuing delays that means LEDBAT tries to =20 > fully > utilize the capacity but keep the queue empty. Of cause LEDBAT will =20= > not be > able to keep the queue completely empty but the queue length will be > determined by the TARGET value and the bottleneck bandwidth. Anyway =20= > the queue > length should be smaller than a dropping/marking threshold in a RED =20= > router. > > Mirja > > > On Thursday 05 August 2010 13:47:09 The 8472 wrote: >> In practice you will probably see that high link utilization at the >> bottleneck would cause AQM algorithms like RED or BLUE to drop =20 >> packets >> or ECN-mark them, which as far as i understand it would induce TCP-=20= >> like >> AIMD-see-saw-ing in LEDBAT like you see it in most other congestion >> control algorithms. >> >> On 05.08.2010 10:24, Rolf Winter wrote: >>> Gengyu, >>> >>> I think I have not answered you yet. Sorry for that, the IETF =20 >>> meeting and >>> all... >>> >>> To answer your question. In an ideal world LEDBAT would consume =20 >>> 100% of >>> the available bandwidth if no other traffic passes the bottleneck, =20= >>> which >>> we assume to be at the modem in your uplink direction. Once other =20= >>> traffic >>> competes for the bandwidth, LEDBAT would ideally disappear or =20 >>> consume >>> some of the bandwidth in case the extra delay of the other traffic =20= >>> is< >>> 25ms. Now that is the theory, in practice you want to get as close =20= >>> to >>> that behavior as possible. >>> >>> 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 Gengyu WEI >>>> Sent: Dienstag, 27. Juli 2010 09:11 >>>> To: Rolf Winter >>>> Cc: ledbat@ietf.org >>>> Subject: Re: [ledbat] review of draft-ietf-ledbat-congestion >>>> >>>> Rof, >>>> >>>> There is a question. >>>> >>>> What do you mean "saturate the bottleneck" ? >>>> Does it mean that the bottleneck link utilization is more than =20 >>>> 90%, or >>>> 95%, or even more? >>>> >>>> In the draft, >>>> >>>> LEDBAT design goals are: >>>> >>>> 1. saturate the bottleneck >>>> >>>> 2. keep delay low when no other traffic is present >>>> >>>> ... >>>> >>>> Regards, >>>> >>>> Gengyu >>>> >>>> ----- Original Message ----- >>>> From: "Rolf Winter" >>>> To: >>>> Sent: Friday, July 16, 2010 4:31 PM >>>> Subject: [ledbat] review of draft-ietf-ledbat-congestion >>>> >>>>> WG, >>>>> >>>>> please review draft-ietf-ledbat-congestion, and see if your =20 >>>>> comments >>>> >>>> have been adequately addressed. If you do not see any issues please >>>> also speak up. I'd like to get a feeling whether the group thinks =20= >>>> the >>>> draft is done or not. >>>> >>>>> Thanks, >>>>> >>>>> Rolf >>>>> >>>>> >>>>> NEC Europe Limited | Registered Office: NEC House, 1 Victoria =20 >>>>> 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 >>> >>> _______________________________________________ >>> 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 > > > > --=20 > ------------------------------------------------------------------- > 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 > ------------------------------------------------------------------- > _______________________________________________ > ledbat mailing list > ledbat@ietf.org > https://www.ietf.org/mailman/listinfo/ledbat From Rolf.Winter@neclab.eu Fri Aug 6 00:18:59 2010 Return-Path: X-Original-To: ledbat@core3.amsl.com Delivered-To: ledbat@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id D6F623A6A34 for ; Fri, 6 Aug 2010 00:18:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.162 X-Spam-Level: X-Spam-Status: No, score=-102.162 tagged_above=-999 required=5 tests=[AWL=0.437, 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 gkUonzShH-Pi for ; Fri, 6 Aug 2010 00:18:56 -0700 (PDT) Received: from smtp0.neclab.eu (smtp0.neclab.eu [195.37.70.41]) by core3.amsl.com (Postfix) with ESMTP id 0C67A3A6A6C for ; Fri, 6 Aug 2010 00:18:55 -0700 (PDT) Received: from localhost (localhost.localdomain [127.0.0.1]) by smtp0.neclab.eu (Postfix) with ESMTP id D831B2C0001B7; Fri, 6 Aug 2010 09:19:25 +0200 (CEST) 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 h2MsDlUXmrKR; Fri, 6 Aug 2010 09:19:25 +0200 (CEST) Received: from ENCELADUS.office.hd (Enceladus.office.hd [192.168.24.52]) by smtp0.neclab.eu (Postfix) with ESMTP id B8E1E2C0001B0; Fri, 6 Aug 2010 09:19:15 +0200 (CEST) Received: from PALLENE.office.hd ([169.254.1.17]) by ENCELADUS.office.hd ([192.168.24.52]) with mapi; Fri, 6 Aug 2010 09:17:53 +0200 From: Rolf Winter To: Gengyu WEI Thread-Topic: [ledbat] review of draft-ietf-ledbat-congestion Thread-Index: AQHLLVrPyGiM3AJg1UKlAw9EccrgxJLSkbGggAEE2ziAAHzKIA== Date: Fri, 6 Aug 2010 07:17:52 +0000 Message-ID: <791AD3077F94194BB2BDD13565B6295D646CEA@PALLENE.office.hd> References: <547F018265F92642B577B986577D671C01594038@VENUS.office> <791AD3077F94194BB2BDD13565B6295D64358A@PALLENE.office.hd> In-Reply-To: Accept-Language: de-DE, 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 draft-ietf-ledbat-congestion 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, 06 Aug 2010 07:19:00 -0000 Gengyu, This is not based on a single queue but on the one-way delay as described i= n the draft. The 25ms extra delay are based on the lowest one-way delay obs= erved in a certain time period. Assuming that all factors that contribute t= o delay (such as serialization delay) are fairly constant, all the differen= ce you will see is coming from queuing delay as the only variable component= in the end-to-end delay. But this is fairly well explained in the draft. Best, Rolf NEC Europe Limited | Registered Office: NEC House, 1 Victoria Road, London = W3 6BL | Registered in England 2832014=20 > -----Original Message----- > From: Gengyu WEI [mailto:weigengyu@vip.sina.com] > Sent: Freitag, 6. August 2010 01:49 > To: Rolf Winter > Cc: ledbat@ietf.org > Subject: Re: [ledbat] review of draft-ietf-ledbat-congestion >=20 > Rolf, >=20 > Thank you for your answering. >=20 > Is The "<25ms" of the extra delay of the other traffic within one > queue? > How could you know that is significant from the end to end point of > view? >=20 > Gengyu >=20 > ----- Original Message ----- > From: "Rolf Winter" > To: "Gengyu WEI" > Cc: > Sent: Thursday, August 05, 2010 4:24 PM > Subject: RE: [ledbat] review of draft-ietf-ledbat-congestion >=20 >=20 > Gengyu, >=20 > I think I have not answered you yet. Sorry for that, the IETF meeting > and all... >=20 > To answer your question. In an ideal world LEDBAT would consume 100% of > the available bandwidth if no other traffic passes the bottleneck, > which we assume to be at the modem in your uplink direction. Once other > traffic competes for the bandwidth, LEDBAT would ideally disappear or > consume some of the bandwidth in case the extra delay of the other > traffic is < 25ms. Now that is the theory, in practice you want to get > as close to that behavior as possible. >=20 > Best, >=20 > Rolf >=20 >=20 > NEC Europe Limited | Registered Office: NEC House, 1 Victoria Road, > London W3 6BL | Registered in England 2832014 >=20 >=20 > > -----Original Message----- > > From: ledbat-bounces@ietf.org [mailto:ledbat-bounces@ietf.org] On > > Behalf Of Gengyu WEI > > Sent: Dienstag, 27. Juli 2010 09:11 > > To: Rolf Winter > > Cc: ledbat@ietf.org > > Subject: Re: [ledbat] review of draft-ietf-ledbat-congestion > > > > Rof, > > > > There is a question. > > > > What do you mean "saturate the bottleneck" ? > > Does it mean that the bottleneck link utilization is more than 90%, > or > > 95%, or even more? > > > > In the draft, > > > > LEDBAT design goals are: > > > > 1. saturate the bottleneck > > > > 2. keep delay low when no other traffic is present > > > > ... > > > > Regards, > > > > Gengyu > > > > ----- Original Message ----- > > From: "Rolf Winter" > > To: > > Sent: Friday, July 16, 2010 4:31 PM > > Subject: [ledbat] review of draft-ietf-ledbat-congestion > > > > > > > WG, > > > > > > please review draft-ietf-ledbat-congestion, and see if your > comments > > have been adequately addressed. If you do not see any issues please > > also speak up. I'd like to get a feeling whether the group thinks the > > draft is done or not. > > > > > > 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 touch@isi.edu Fri Aug 6 15:33:31 2010 Return-Path: X-Original-To: ledbat@core3.amsl.com Delivered-To: ledbat@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id C50F13A6980 for ; Fri, 6 Aug 2010 15:33:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.599 X-Spam-Level: X-Spam-Status: No, score=-102.599 tagged_above=-999 required=5 tests=[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 gfBZ4B0XQqtM for ; Fri, 6 Aug 2010 15:33:30 -0700 (PDT) Received: from vapor.isi.edu (vapor.isi.edu [128.9.64.64]) by core3.amsl.com (Postfix) with ESMTP id B7BE33A6948 for ; Fri, 6 Aug 2010 15:33:30 -0700 (PDT) Received: from [75.217.108.71] (71.sub-75-217-108.myvzw.com [75.217.108.71]) (authenticated bits=0) by vapor.isi.edu (8.13.8/8.13.8) with ESMTP id o76MWx5C023394 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Fri, 6 Aug 2010 15:33:09 -0700 (PDT) Message-ID: <4C5C8D9A.8030106@isi.edu> Date: Fri, 06 Aug 2010 15:32:58 -0700 From: Joe Touch User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.1; en-US; rv:1.9.1.11) Gecko/20100711 Thunderbird/3.0.6 MIME-Version: 1.0 To: Mirja Kuehlewind References: <547F018265F92642B577B986577D671C01594038@VENUS.office> <791AD3077F94194BB2BDD13565B6295D64358A@PALLENE.office.hd> <4C5AA4BD.1050407@infinite-source.de> <201008051826.02708.mirja.kuehlewind@ikr.uni-stuttgart.de> In-Reply-To: <201008051826.02708.mirja.kuehlewind@ikr.uni-stuttgart.de> 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] review of draft-ietf-ledbat-congestion 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, 06 Aug 2010 22:33:32 -0000 On 8/5/2010 9:26 AM, Mirja Kuehlewind wrote: > Hi, > > LEDBAT's aim is to avoid queuing delays that means LEDBAT tries to fully > utilize the capacity but keep the queue empty. If that's the case, we should be talking about bottlenecks (plural). There are two such cases: striped paths (parallel links), and cascaded links in which we compete for resources on each cascade. IMO, our goal is: on any link where we present more capacity than that link can carry, we should consume 100% of the available capacity of that link Joe From mirja.kuehlewind@ikr.uni-stuttgart.de Tue Aug 10 07:50:58 2010 Return-Path: X-Original-To: ledbat@core3.amsl.com Delivered-To: ledbat@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 9909B3A682E for ; Tue, 10 Aug 2010 07:50:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.264 X-Spam-Level: X-Spam-Status: No, score=-0.264 tagged_above=-999 required=5 tests=[AWL=-0.915, BAYES_50=0.001, HELO_EQ_DE=0.35, MIME_8BIT_HEADER=0.3] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 2O+sv5Hsjjei for ; Tue, 10 Aug 2010 07:50:57 -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 747563A6843 for ; Tue, 10 Aug 2010 07:50:57 -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 4AA82633F7 for ; Tue, 10 Aug 2010 16:51:31 +0200 (CEST) Received: from vpn-1-cl02 (vpn-1-cl02 [10.88.11.12]) by netsrv1.ikr.uni-stuttgart.de (Postfix) with ESMTP id 3163ABC07E for ; Tue, 10 Aug 2010 16:51:31 +0200 (CEST) From: Mirja =?iso-8859-1?q?K=FChlewind?= To: ledbat@ietf.org Date: Tue, 10 Aug 2010 16:51:27 +0200 User-Agent: KMail/1.9.10 (enterprise35 0.20090731.1005176) References: <547F018265F92642B577B986577D671C01594038@VENUS.office> <201008051826.02708.mirja.kuehlewind@ikr.uni-stuttgart.de> <4C5C8D9A.8030106@isi.edu> In-Reply-To: <4C5C8D9A.8030106@isi.edu> X-KMail-QuotePrefix: > MIME-Version: 1.0 Content-Type: Text/Plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-Id: <201008101651.27534.mkuehle@ikr.uni-stuttgart.de> Subject: Re: [ledbat] review of draft-ietf-ledbat-congestion 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, 10 Aug 2010 14:50:58 -0000 Not sure about that. First of all we want to design a Low Extra Delay Background Transport that means back off early if other traffic arises and keep the queues as empty as possible. To utilize the available capacity is 'just' another thing that is valuable to keep the transport running. If utilization is the first goal, we should probably switch to a mechanism like RAPID [1]. Mirja [1] V. Konda and 1. Kaur, "RAPID: Shrinking the Congestion-Control Timescale:' in Proc. INFOCOM 2009, 19-25 April 2009, pp. 1-9. On Saturday 07 August 2010 00:32:58 Joe Touch wrote: > On 8/5/2010 9:26 AM, Mirja Kuehlewind wrote: > > Hi, > > > > LEDBAT's aim is to avoid queuing delays that means LEDBAT tries to fully > > utilize the capacity but keep the queue empty. > > If that's the case, we should be talking about bottlenecks (plural). > There are two such cases: striped paths (parallel links), and cascaded > links in which we compete for resources on each cascade. > > IMO, our goal is: > > on any link where we present more capacity than that link can carry, we > should consume 100% of the available capacity of that link > > Joe From Rolf.Winter@neclab.eu Thu Aug 19 08:44:59 2010 Return-Path: X-Original-To: ledbat@core3.amsl.com Delivered-To: ledbat@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 67CE43A698C for ; Thu, 19 Aug 2010 08:44:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -100.786 X-Spam-Level: X-Spam-Status: No, score=-100.786 tagged_above=-999 required=5 tests=[AWL=-0.787, BAYES_50=0.001, 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 82Fdza1ovkSR for ; Thu, 19 Aug 2010 08:44:58 -0700 (PDT) Received: from smtp0.neclab.eu (smtp0.neclab.eu [195.37.70.41]) by core3.amsl.com (Postfix) with ESMTP id 4551D3A696E for ; Thu, 19 Aug 2010 08:44:58 -0700 (PDT) Received: from localhost (localhost.localdomain [127.0.0.1]) by smtp0.neclab.eu (Postfix) with ESMTP id DC7632C0001B8 for ; Thu, 19 Aug 2010 17:45:32 +0200 (CEST) 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 8jCVVcPL0aQv for ; Thu, 19 Aug 2010 17:45:32 +0200 (CEST) Received: from ENCELADUS.office.hd (Enceladus.office.hd [192.168.24.52]) by smtp0.neclab.eu (Postfix) with ESMTP id BB7F42C0001B5 for ; Thu, 19 Aug 2010 17:45:27 +0200 (CEST) Received: from DAPHNIS.office.hd ([169.254.2.160]) by ENCELADUS.office.hd ([192.168.24.52]) with mapi; Thu, 19 Aug 2010 17:44:23 +0200 From: Rolf Winter To: "ledbat@ietf.org" Thread-Topic: Review draft-ietf-ledbat-congestion-02 Thread-Index: Acs/tWUKoKTkpASxTvy7sxrBVqrawA== Date: Thu, 19 Aug 2010 15:44:22 +0000 Message-ID: <791AD3077F94194BB2BDD13565B6295D6A3741@DAPHNIS.office.hd> Accept-Language: de-DE, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: [ledbat] Review draft-ietf-ledbat-congestion-02 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, 19 Aug 2010 15:44:59 -0000 Hi, I will follow-up with a second Email on this. In case the group has not not= iced, the draft has changed the delay target from 25 to 100ms. I would like= to hear some comments on this. In particular, I would like to hear from th= e BitTorrent folks as to why this has changed (a bit more information than = the half sentence in the new version of the draft please). 25ms before was = kind of coming out of thin air I admit but felt reasonably low, but now thi= s is increased 4 fold - 50ms away from the ITU-T recommendation on the maxi= mum delay on VoIP. Thoughts/comments? Best, Rolf NEC Europe Limited | Registered Office: NEC House, 1 Victoria Road, London = W3 6BL | Registered in England 2832014=20 From Rolf.Winter@neclab.eu Thu Aug 19 09:04:01 2010 Return-Path: X-Original-To: ledbat@core3.amsl.com Delivered-To: ledbat@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id D01FE3A6926 for ; Thu, 19 Aug 2010 09:04:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -100.744 X-Spam-Level: X-Spam-Status: No, score=-100.744 tagged_above=-999 required=5 tests=[AWL=-0.745, BAYES_50=0.001, 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 6jyWHtQqnDmw for ; Thu, 19 Aug 2010 09:04:00 -0700 (PDT) Received: from smtp0.neclab.eu (smtp0.neclab.eu [195.37.70.41]) by core3.amsl.com (Postfix) with ESMTP id C54C43A6857 for ; Thu, 19 Aug 2010 09:04:00 -0700 (PDT) Received: from localhost (localhost.localdomain [127.0.0.1]) by smtp0.neclab.eu (Postfix) with ESMTP id 688E62C0001B6 for ; Thu, 19 Aug 2010 18:04:35 +0200 (CEST) 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 ZCL+JXvDQNVL for ; Thu, 19 Aug 2010 18:04:35 +0200 (CEST) Received: from METHONE.office.hd (Methone.office.hd [192.168.24.54]) by smtp0.neclab.eu (Postfix) with ESMTP id 4BFB92C0001B2 for ; Thu, 19 Aug 2010 18:04:30 +0200 (CEST) Received: from DAPHNIS.office.hd ([169.254.2.160]) by METHONE.office.hd ([192.168.24.54]) with mapi; Thu, 19 Aug 2010 18:03:25 +0200 From: Rolf Winter To: "ledbat@ietf.org" Thread-Topic: Review draft-ietf-ledbat-congestion-02 Thread-Index: Acs/uA1MtclCQY4KRw6P8GxTGcHJNg== Date: Thu, 19 Aug 2010 16:03:23 +0000 Message-ID: <791AD3077F94194BB2BDD13565B6295D6A4A1F@DAPHNIS.office.hd> Accept-Language: de-DE, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: [ledbat] Review draft-ietf-ledbat-congestion-02 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, 19 Aug 2010 16:04:01 -0000 Hi, here are some more comments on the draft: Please, I believe we do not endorse, rate or market products. Please remove= "which is currently the most popular BitTorrent client". Add the mandatory IANA considerations section. "LEDBAT enables other advanced networking". You deleted "advanced" in the a= bstract, you might want to do that here too. Add reference for the One-Way Active Measurement Protocol s/To deal, base delay needs to be computed over a period of last few minute= s instead of since the start of connection. The tradeoff is: for longer int= ervals, base is more accurate; for shorter intervals, reaction to route cha= nges is faster./To deal with route change, the base delay needs to be compu= ted over the last few minutes instead of since the start of connection. The= tradeoff is: for longer intervals, the base delay is more accurate; for sh= orter intervals, the reaction to route change is faster. s/as Network Time Protocol (NTP)/as the Network Time Protocol (NTP)/ "A 100-PPM skew means accumulating 6 milliseconds of error per minute. The= expiration of base delay related to route changes mostly takes care of clo= ck skew." I am not sure this is a good suggestion. Given that we recommend = a 10 minute base history (and up to 20 mins) the 6ms sum up to 60ms which i= s far above the delay target. Shouldn't we rather suggest to actually make = use of a skew compensation scheme even if it is not specified in the docume= nt? I think the skew correction alternatives should go into an appendix if we w= ant to keep them as they are not part of the spec but rather a reference. I= am not sure we should include the Byzantine skew correction algorithm. Tha= t, I feel at least, seems the least cooked. Alternatively it could be bette= r explained. I don't see e.g. why the median across all skews is a useful m= etric. "GAIN SHOULD be set so that max rampup rate is the same as for TCP and MAY = be up to twice more." This is new and needs to be discussed. Is LEDBAT allo= wed to ramp up twice as fast as TCP? Best, Rolf NEC Europe Limited | Registered Office: NEC House, 1 Victoria Road, London = W3 6BL | Registered in England 2832014=20 From mirja.kuehlewind@ikr.uni-stuttgart.de Thu Aug 26 10:48:14 2010 Return-Path: X-Original-To: ledbat@core3.amsl.com Delivered-To: ledbat@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 401B83A69A9 for ; Thu, 26 Aug 2010 10:48:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.354 X-Spam-Level: X-Spam-Status: No, score=-0.354 tagged_above=-999 required=5 tests=[AWL=-0.749, BAYES_50=0.001, DATE_IN_PAST_03_06=0.044, 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 hUdHpbCjBWjQ for ; Thu, 26 Aug 2010 10:48:13 -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 0763D3A68CD for ; Thu, 26 Aug 2010 10:48:13 -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 BE35C633F7 for ; Thu, 26 Aug 2010 19:48:43 +0200 (CEST) Received: from vpn-2-cl177 (vpn-2-cl177 [10.41.21.177]) by netsrv1.ikr.uni-stuttgart.de (Postfix) with ESMTP id AA38028DC4 for ; Thu, 26 Aug 2010 19:48:43 +0200 (CEST) From: Mirja Kuehlewind Organization: University of Stuttgart (Germany), IKR To: ledbat@ietf.org Date: Thu, 26 Aug 2010 15:15:18 +0200 User-Agent: KMail/1.9.10 (enterprise35 0.20090731.1005176) References: <791AD3077F94194BB2BDD13565B6295D6A3741@DAPHNIS.office.hd> In-Reply-To: <791AD3077F94194BB2BDD13565B6295D6A3741@DAPHNIS.office.hd> 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: <201008261515.18622.mirja.kuehlewind@ikr.uni-stuttgart.de> Subject: Re: [ledbat] Review draft-ietf-ledbat-congestion-02 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, 26 Aug 2010 17:48:14 -0000 Hi, could the authors please answer this question! I would be curious as well... Mirja On Thursday 19 August 2010 17:44:22 Rolf Winter wrote: > Hi, > > I will follow-up with a second Email on this. In case the group has not > noticed, the draft has changed the delay target from 25 to 100ms. I would > like to hear some comments on this. In particular, I would like to hear > from the BitTorrent folks as to why this has changed (a bit more > information than the half sentence in the new version of the draft please= ). > 25ms before was kind of coming out of thin air I admit but felt reasonably > low, but now this is increased 4 fold - 50ms away from the ITU-T > recommendation on the maximum delay on VoIP. Thoughts/comments? > > Best, > > 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 =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------------------------------------------------------------------