From Rolf.Winter@neclab.eu Wed Jun 1 00:17:31 2011 Return-Path: X-Original-To: ledbat@ietfa.amsl.com Delivered-To: ledbat@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 75ADEE06B6 for ; Wed, 1 Jun 2011 00:17:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.424 X-Spam-Level: X-Spam-Status: No, score=-102.424 tagged_above=-999 required=5 tests=[AWL=-0.175, BAYES_00=-2.599, HELO_EQ_DE=0.35, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Xf66jM+j3EVk for ; Wed, 1 Jun 2011 00:17:31 -0700 (PDT) Received: from smtp0.netlab.nec.de (smtp0.netlab.nec.de [195.37.70.40]) by ietfa.amsl.com (Postfix) with ESMTP id E82CFE0774 for ; Wed, 1 Jun 2011 00:17:30 -0700 (PDT) Received: from localhost (localhost.localdomain [127.0.0.1]) by smtp0.netlab.nec.de (Postfix) with ESMTP id C6BE72800034C for ; Wed, 1 Jun 2011 09:17:29 +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 NcQK9ePAsVWY for ; Wed, 1 Jun 2011 09:17:29 +0200 (CEST) Received: from ENCELADUS.office.hd (ENCELADUS.office.hd [192.168.24.52]) by smtp0.netlab.nec.de (Postfix) with ESMTP id AA1C128000191 for ; Wed, 1 Jun 2011 09:17:24 +0200 (CEST) Received: from PALLENE.office.hd ([169.254.1.225]) by ENCELADUS.office.hd ([192.168.24.52]) with mapi id 14.01.0270.001; Wed, 1 Jun 2011 09:17:24 +0200 From: Rolf Winter To: "ledbat@ietf.org" Thread-Topic: 2 week last call for draft-ietf-ledbat-congestion-06 Thread-Index: AcwgK/PMpAcMkcw3T7yc+05bRSEkcQ== Date: Wed, 1 Jun 2011 07:17:24 +0000 Message-ID: <791AD3077F94194BB2BDD13565B6295D05E6DF22@PALLENE.office.hd> Accept-Language: en-US, de-DE Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.1.6.28] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: [ledbat] 2 week last call for draft-ietf-ledbat-congestion-06 X-BeenThere: ledbat@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Mailing list of the LEDBAT WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 01 Jun 2011 07:17:31 -0000 Working Group, this is to start a two week working group last call of draft-ietf-ledbat-co= ngestion-06. Please send all comments you have to ledbat@ietf.org. This WG last call ends on the 15th of June. The chairs. NEC Europe Limited | Registered Office: NEC House, 1 Victoria Road, London = W3 6BL | Registered in England 2832014=20 From michawe@ifi.uio.no Sun Jun 12 00:41:57 2011 Return-Path: X-Original-To: ledbat@ietfa.amsl.com Delivered-To: ledbat@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2391A11E80D4 for ; Sun, 12 Jun 2011 00:41:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.999 X-Spam-Level: X-Spam-Status: No, score=-101.999 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, J_CHICKENPOX_23=0.6, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id B88OBna4Jawr for ; Sun, 12 Jun 2011 00:41:56 -0700 (PDT) Received: from mail-out2.uio.no (mail-out2.uio.no [IPv6:2001:700:100:10::58]) by ietfa.amsl.com (Postfix) with ESMTP id 693F411E80C8 for ; Sun, 12 Jun 2011 00:41:55 -0700 (PDT) Received: from mail-mx4.uio.no ([129.240.10.45]) by mail-out2.uio.no with esmtp (Exim 4.75) (envelope-from ) id 1QVfIp-0001VZ-Rb; Sun, 12 Jun 2011 09:41:47 +0200 Received: from cm-84.208.175.27.getinternet.no ([84.208.175.27] helo=[192.168.0.199]) by mail-mx4.uio.no with esmtpsa (TLSv1:AES128-SHA:128) user michawe (Exim 4.76) (envelope-from ) id 1QVfIp-00045X-Bi; Sun, 12 Jun 2011 09:41:47 +0200 Message-Id: <99DCCD6E-1203-4CA6-92A0-E0554AF82719@ifi.uio.no> From: Michael Welzl To: Lisong Xu In-Reply-To: <4DF46256.1000809@cse.unl.edu> Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v936) Date: Sun, 12 Jun 2011 09:41:24 +0200 References: <94D3019D-33B6-4205-8B65-02923DBCA2DE@ifi.uio.no> <4DF46256.1000809@cse.unl.edu> X-Mailer: Apple Mail (2.936) X-UiO-Ratelimit-Test: rcpts/h 5 msgs/h 1 sum rcpts/h 7 sum msgs/h 3 total rcpts 9892 max rcpts/h 36 ratelimit 0 X-UiO-Spam-info: not spam, SpamAssassin (score=-5.0, required=5.0, autolearn=disabled, UIO_MAIL_IS_INTERNAL=-5, uiobl=NO, uiouri=NO) X-UiO-Scanned: 47D4E1AAF1ECDBB5F2D3945262DE18ABFD747895 X-UiO-SPAM-Test: remote_host: 84.208.175.27 spam_score: -49 maxlevel 80 minaction 2 bait 0 mail/h: 1 total 1209 max/h 18 blacklist 0 greylist 0 ratelimit 0 Cc: ledbat@ietf.org, "iccrg@cs.ucl.ac.uk list" Subject: Re: [ledbat] [Iccrg] Looking for reviewer for draft-ietf-ledbat-congestion-06 X-BeenThere: ledbat@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Mailing list of the LEDBAT WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 12 Jun 2011 07:41:57 -0000 thank you! I'm cc'ing ledbat in my answer. Cheers, Michael On Jun 12, 2011, at 8:53 AM, Lisong Xu wrote: > Hi Michael, > > Below are my comments after reading the draft. > Thanks > Lisong > > > **** Section 3.1 **** > First sentence: "a loss occurs [RFC5681], which, in the absence of > any Active Queue Management (AQM) in the network, occurs only when > the queue at the bottleneck link on the end-to-end path overflows " > > Since a loss may occur due to link errors, such as fiber errors and > wireless errors, we may change the first sentence to > "... (AQM) and link errors in the network,...." > > **** Section 3.3 **** > The data type of each variable is not specified. Since some > variables must be signed variables, it is important to specify the > type of each variable in order to correctly implement the algorithm. > > For example, tcp_time_stamp is an unsigned int, so local_timestamp > and remote_timestamp are also unsigned int. But variable > acknowledgement.delay should be a signed int, since local_timestamp- > remote_timestamp may be negative. > > **** Section 3.4.2 **** > "a LEDBAT sender stores BASE_HISTORY+1 separate minima- one each for > the last BASE_HISTORY minutes, and one for the running current > minute." > > But the update_current_delay(delay) code maintains only BASE_HISTORY > minima. So the above sentence should be changed to > "a LEDBAT sender stores BASE_HISTORY separate minima- one each for > the last BASE_HISTORY-1 minutes, and one for the running current > minute." > > **** Section 3.5 **** > "we recommend that the sender SHOULD use at least 4 samples in each > RTT. Thus, CURRENT_FILTER SHOULD be at least 4, and limited such > that no samples in list are older than an RTT in the > past." > > But what if cwnd is less than 4? In this case, there are less than 4 > samples in each RTT. > > > **** General ***** > > It is not clear what the relation between cwnd and flightsize is. Is > flightsize always the same as cwnd, or could be less than cwnd? When > is flightsize less than cwnd? > > > On 6/5/2011 12:38 AM, Michael Welzl wrote: >> Hi, >> >> We're urgently looking for a volunteer to review >> draft-ietf-ledbat-congestion-06: >> http://tools.ietf.org/html/draft-ietf-ledbat-congestion-06 >> which is currently in Last Call, ending in less than two weeks (15 >> June). >> >> If anyone here is willing to do a review, please drop Murari and me a >> note ASAP! >> >> Thanks, >> Michael >> >> >> _______________________________________________ >> Iccrg mailing list >> Iccrg@cs.ucl.ac.uk >> http://oakham.cs.ucl.ac.uk/mailman/listinfo/iccrg >> > > -- > Lisong Xu, Associate Professor > Computer Science & Engineering > University of Nebraska-Lincoln > http://cse.unl.edu/~xu From wes@mti-systems.com Mon Jun 13 11:14:14 2011 Return-Path: X-Original-To: ledbat@ietfa.amsl.com Delivered-To: ledbat@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0345511E80F0 for ; Mon, 13 Jun 2011 11:14:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Cpk97ANTMTNO for ; Mon, 13 Jun 2011 11:14:12 -0700 (PDT) Received: from omr8.networksolutionsemail.com (omr8.networksolutionsemail.com [205.178.146.58]) by ietfa.amsl.com (Postfix) with ESMTP id 1F47F21F8569 for ; Mon, 13 Jun 2011 11:14:11 -0700 (PDT) Received: from cm-omr8 (mail.networksolutionsemail.com [205.178.146.50]) by omr8.networksolutionsemail.com (8.13.6/8.13.6) with ESMTP id p5DIE8TB015718 for ; Mon, 13 Jun 2011 14:14:10 -0400 Authentication-Results: cm-omr8 smtp.user=wes@mti-systems.com; auth=pass (PLAIN) X-Authenticated-UID: wes@mti-systems.com Received: from [108.98.121.160] ([108.98.121.160:45631] helo=[192.168.9.2]) by cm-omr8 (envelope-from ) (ecelerity 2.2.2.41 r(31179/31189)) with ESMTPA id 45/46-24574-F6356FD4; Mon, 13 Jun 2011 14:14:08 -0400 Message-ID: <4DF65370.7000003@mti-systems.com> Date: Mon, 13 Jun 2011 14:14:08 -0400 From: Wesley Eddy Organization: MTI Systems User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9.2.17) Gecko/20110414 Lightning/1.0b2 Thunderbird/3.1.10 MIME-Version: 1.0 To: ledbat@ietf.org References: <791AD3077F94194BB2BDD13565B6295D05E6DF22@PALLENE.office.hd> In-Reply-To: <791AD3077F94194BB2BDD13565B6295D05E6DF22@PALLENE.office.hd> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: [ledbat] 2 week last call for draft-ietf-ledbat-congestion-06 X-BeenThere: ledbat@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Mailing list of the LEDBAT WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 13 Jun 2011 18:14:14 -0000 On 6/1/2011 3:17 AM, Rolf Winter wrote: > Working Group, > > this is to start a two week working group last call of draft-ietf-ledbat-congestion-06. > > Please send all comments you have to ledbat@ietf.org. > > This WG last call ends on the 15th of June. > > The chairs. > This is a combined WGLC response and AD review. I think the technical description is pretty good modulo some of the comments from Lisong Xu. I only have a few editorial suggestions: - The document should probably note somewhere that ECN is not handled by LEDBAT and making LEDBAT flows ECN capable would be potential future work (maybe related to the AQM effects mentioned in the second paragraph of section 2.2) - In the security considerations, it might be worth noting that LEDBAT is not known to introduce any new concerns with privacy, integrity, or other security issues for flows that use it. It should be compatible with use of IPsec and TLS/DTLS. - In the abstract, LEDBAT yields not just to TCP but to any other flows once latency builds. This is an important design feature in order for delay-sensitive real-time flows to coexist with bulk transfers. It works whether or not the other flows use TCP. - Same comment as above in second paragraph of the Introduction. - Same comment as above in section 2.1 - For Vegas, I suggest also citing "Understanding TCP Vegas: A Duality Model" by Low, Peterson, and Wang from JACM 49 (2), March 2002. This provides additional analysis that's useful to understand in the context of minimizing network queues - Section 3.1, first sentence, suggest adding "or ECN mark is received" -- Wes Eddy MTI Systems From Rolf.Winter@neclab.eu Tue Jun 14 01:07:25 2011 Return-Path: X-Original-To: ledbat@ietfa.amsl.com Delivered-To: ledbat@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3505811E8123 for ; Tue, 14 Jun 2011 01:07:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.424 X-Spam-Level: X-Spam-Status: No, score=-102.424 tagged_above=-999 required=5 tests=[AWL=-0.175, BAYES_00=-2.599, HELO_EQ_DE=0.35, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id lHq1r003xMwG for ; Tue, 14 Jun 2011 01:07:24 -0700 (PDT) Received: from smtp0.netlab.nec.de (smtp0.netlab.nec.de [195.37.70.40]) by ietfa.amsl.com (Postfix) with ESMTP id A977811E8070 for ; Tue, 14 Jun 2011 01:07:24 -0700 (PDT) Received: from localhost (localhost.localdomain [127.0.0.1]) by smtp0.netlab.nec.de (Postfix) with ESMTP id 983252800035B for ; Tue, 14 Jun 2011 10:07:23 +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 HgDTRvGvuAie for ; Tue, 14 Jun 2011 10:07:23 +0200 (CEST) Received: from ENCELADUS.office.hd (ENCELADUS.office.hd [192.168.24.52]) by smtp0.netlab.nec.de (Postfix) with ESMTP id 7E09728000189 for ; Tue, 14 Jun 2011 10:07:18 +0200 (CEST) Received: from DAPHNIS.office.hd ([169.254.2.223]) by ENCELADUS.office.hd ([192.168.24.52]) with mapi id 14.01.0270.001; Tue, 14 Jun 2011 10:07:18 +0200 From: Rolf Winter To: "ledbat@ietf.org" Thread-Topic: 2 week last call for draft-ietf-ledbat-congestion-06 Thread-Index: AcwgK/PMpAcMkcw3T7yc+05bRSEkcQKPfIvQ Date: Tue, 14 Jun 2011 08:07:18 +0000 Message-ID: <791AD3077F94194BB2BDD13565B6295D13B44CCB@DAPHNIS.office.hd> References: <791AD3077F94194BB2BDD13565B6295D05E6DF22@PALLENE.office.hd> In-Reply-To: <791AD3077F94194BB2BDD13565B6295D05E6DF22@PALLENE.office.hd> Accept-Language: en-US, de-DE Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.1.6.28] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: Re: [ledbat] 2 week last call for draft-ietf-ledbat-congestion-06 X-BeenThere: ledbat@ietf.org X-Mailman-Version: 2.1.12 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, 14 Jun 2011 08:07:25 -0000 Hi, There is only one day left, but the chairs would seriously like a few more = reviews. Also just a two thumbs up or similar is valuable feedback. Thanks, 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 Rolf Winter > Sent: Mittwoch, 1. Juni 2011 09:17 > To: ledbat@ietf.org > Subject: [ledbat] 2 week last call for draft-ietf-ledbat-congestion-06 >=20 > Working Group, >=20 > this is to start a two week working group last call of draft-ietf- > ledbat-congestion-06. >=20 > Please send all comments you have to ledbat@ietf.org. >=20 > This WG last call ends on the 15th of June. >=20 > The chairs. >=20 >=20 >=20 > NEC Europe Limited | Registered Office: NEC House, 1 Victoria Road, > London W3 6BL | Registered in England 2832014 >=20 > _______________________________________________ > ledbat mailing list > ledbat@ietf.org > https://www.ietf.org/mailman/listinfo/ledbat From john@jlc.net Tue Jun 14 09:34:49 2011 Return-Path: X-Original-To: ledbat@ietfa.amsl.com Delivered-To: ledbat@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BE2EA9E802E for ; Tue, 14 Jun 2011 09:34:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.124 X-Spam-Level: X-Spam-Status: No, score=-106.124 tagged_above=-999 required=5 tests=[AWL=0.475, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id pCOZfr4nj5ZC for ; Tue, 14 Jun 2011 09:34:49 -0700 (PDT) Received: from mailhost.jlc.net (mailhost.jlc.net [199.201.159.4]) by ietfa.amsl.com (Postfix) with ESMTP id D9A7211E807F for ; Tue, 14 Jun 2011 09:34:48 -0700 (PDT) Received: by mailhost.jlc.net (Postfix, from userid 104) id 6678133C22; Tue, 14 Jun 2011 12:34:48 -0400 (EDT) Date: Tue, 14 Jun 2011 12:34:48 -0400 From: John Leslie To: Rolf Winter Message-ID: <20110614163448.GG96377@verdi> References: <791AD3077F94194BB2BDD13565B6295D05E6DF22@PALLENE.office.hd> <791AD3077F94194BB2BDD13565B6295D13B44CCB@DAPHNIS.office.hd> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <791AD3077F94194BB2BDD13565B6295D13B44CCB@DAPHNIS.office.hd> User-Agent: Mutt/1.4.1i Cc: "ledbat@ietf.org" Subject: Re: [ledbat] 2 week last call for draft-ietf-ledbat-congestion-06 X-BeenThere: ledbat@ietf.org X-Mailman-Version: 2.1.12 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, 14 Jun 2011 16:34:49 -0000 Rolf Winter wrote: > > There is only one day left, but the chairs would seriously like a few > more reviews. Also just a two thumbs up or similar is valuable feedback. My goodness, it's changed a lot over 20 months! It looks ready for publication to me... However: ] ] 2.2. Applicability ]... ] LEDBAT seeks to operate in networks with FIFO queues and with tail- ] drop queue management. Further study is required to understand the ] implications of Active Queue Management (AQM) schemes on LEDBAT ] mechanisms. This could be read as "may break under AQM" -- which I believe to be quite false. IMHO, we believe that ECN marking per AQM would be no problem at all, and packet-drop under AQM would merely cause backoff sooner than needed; and we have consensus to just accept that consequence. I think the language here should be more like "to fully understand..." and we should record that problems due to AQM are considered manageable. -- John Leslie From nweaver@icsi.berkeley.edu Tue Jun 14 11:13:33 2011 Return-Path: X-Original-To: ledbat@ietfa.amsl.com Delivered-To: ledbat@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id ADB1C21F8540 for ; Tue, 14 Jun 2011 11:13:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id VcgHgB7a+mnJ for ; Tue, 14 Jun 2011 11:13:32 -0700 (PDT) Received: from taffy.ICSI.Berkeley.EDU (taffy.ICSI.Berkeley.EDU [192.150.187.26]) by ietfa.amsl.com (Postfix) with ESMTP id 5BF9621F8546 for ; Tue, 14 Jun 2011 11:13:32 -0700 (PDT) Received: from gala.icir.org (gala.ICIR.org [192.150.187.49]) (Authenticated sender: nweaver) by taffy.ICSI.Berkeley.EDU (Postfix) with ESMTP id B685136A035; Tue, 14 Jun 2011 11:13:31 -0700 (PDT) References: <791AD3077F94194BB2BDD13565B6295D05E6DF22@PALLENE.office.hd> <791AD3077F94194BB2BDD13565B6295D13B44CCB@DAPHNIS.office.hd> <20110614163448.GG96377@verdi> In-Reply-To: <20110614163448.GG96377@verdi> Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: text/plain; charset=us-ascii Message-Id: <55EFB471-D668-4BA9-ABEE-75C51E1A1F1F@icsi.berkeley.edu> Content-Transfer-Encoding: quoted-printable From: Nicholas Weaver Date: Tue, 14 Jun 2011 11:13:31 -0700 To: John Leslie X-Mailer: Apple Mail (2.1084) Cc: "ledbat@ietf.org" Subject: Re: [ledbat] 2 week last call for draft-ietf-ledbat-congestion-06 X-BeenThere: ledbat@ietf.org X-Mailman-Version: 2.1.12 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, 14 Jun 2011 18:13:33 -0000 On Jun 14, 2011, at 9:34 AM, John Leslie wrote: > Rolf Winter wrote: >>=20 >> There is only one day left, but the chairs would seriously like a few >> more reviews. Also just a two thumbs up or similar is valuable = feedback. >=20 > My goodness, it's changed a lot over 20 months! >=20 > It looks ready for publication to me... However: > ]=20 > ] 2.2. Applicability > ]... > ] LEDBAT seeks to operate in networks with FIFO queues and with tail- > ] drop queue management. Further study is required to understand the > ] implications of Active Queue Management (AQM) schemes on LEDBAT > ] mechanisms. >=20 > This could be read as "may break under AQM" -- which I believe to > be quite false. >=20 > IMHO, we believe that ECN marking per AQM would be no problem at = all, > and packet-drop under AQM would merely cause backoff sooner than = needed; > and we have consensus to just accept that consequence. >=20 > I think the language here should be more like "to fully = understand..." > and we should record that problems due to AQM are considered = manageable. Perhaps something like: It is unclear how LEDBAT will operate in an environment with AQM at the = bottleneck, but as LEDBAT still includes a TCP-equivelent loss-based = secondary rate control, it will never acquire more bandwidth than a = competing TCP flow would and would be likely to acquire less bandwidth = because the packet-drop will cause an earlier backoff. There is a = consensus that, although the exact details are not yet fully understood, = the behavior under AQM should be safe and any performance degradation = under AQM is acceptable and compatible with LEDBAT's objectives. Otherwise, thumbsup for me. From wes@mti-systems.com Tue Jun 14 12:58:42 2011 Return-Path: X-Original-To: ledbat@ietfa.amsl.com Delivered-To: ledbat@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id ECE3A1F0C55 for ; Tue, 14 Jun 2011 12:58:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id s3gReAlzcndO for ; Tue, 14 Jun 2011 12:58:38 -0700 (PDT) Received: from omr15.networksolutionsemail.com (omr15.networksolutionsemail.com [205.178.146.65]) by ietfa.amsl.com (Postfix) with ESMTP id 4AF1C1F0C44 for ; Tue, 14 Jun 2011 12:58:38 -0700 (PDT) Received: from cm-omr3 (mail.networksolutionsemail.com [205.178.146.50]) by omr15.networksolutionsemail.com (8.13.6/8.13.6) with ESMTP id p5EJwbeJ008457 for ; Tue, 14 Jun 2011 15:58:37 -0400 Authentication-Results: cm-omr3 smtp.user=wes@mti-systems.com; auth=pass (PLAIN) X-Authenticated-UID: wes@mti-systems.com Received: from [68.31.249.225] ([68.31.249.225:31923] helo=[192.168.9.2]) by cm-omr3 (envelope-from ) (ecelerity 2.2.2.41 r(31179/31189)) with ESMTPA id 85/DE-27068-C6DB7FD4; Tue, 14 Jun 2011 15:58:37 -0400 Message-ID: <4DF7BD6A.8030202@mti-systems.com> Date: Tue, 14 Jun 2011 15:58:34 -0400 From: Wesley Eddy Organization: MTI Systems User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9.2.17) Gecko/20110414 Lightning/1.0b2 Thunderbird/3.1.10 MIME-Version: 1.0 To: ledbat@ietf.org References: <791AD3077F94194BB2BDD13565B6295D05E6DF22@PALLENE.office.hd> <791AD3077F94194BB2BDD13565B6295D13B44CCB@DAPHNIS.office.hd> <20110614163448.GG96377@verdi> In-Reply-To: <20110614163448.GG96377@verdi> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: [ledbat] 2 week last call for draft-ietf-ledbat-congestion-06 X-BeenThere: ledbat@ietf.org X-Mailman-Version: 2.1.12 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, 14 Jun 2011 19:58:43 -0000 On 6/14/2011 12:34 PM, John Leslie wrote: > > IMHO, we believe that ECN marking per AQM would be no problem at all, > and packet-drop under AQM would merely cause backoff sooner than needed; > and we have consensus to just accept that consequence. > Since AQMs will generally only mark packets when there is a queue, and LEDBAT strives to minimize its contribution to queues, it may be a lot less likely that LEDBAT flows would be marked compared to other flows. They would have adapted their rates as they received RTT estimates indicating the buildup of the queue, and potentially already reacted prior to losses being detected which takes longer without ECN. -- Wes Eddy MTI Systems From mirja.kuehlewind@ikr.uni-stuttgart.de Wed Jun 15 06:07:51 2011 Return-Path: X-Original-To: ledbat@ietfa.amsl.com Delivered-To: ledbat@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5535E11E811C for ; Wed, 15 Jun 2011 06:07:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.949 X-Spam-Level: X-Spam-Status: No, score=-1.949 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_DE=0.35, MIME_8BIT_HEADER=0.3] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id SmBzrNuhu+IH for ; Wed, 15 Jun 2011 06:07:50 -0700 (PDT) Received: from mailsrv.ikr.uni-stuttgart.de (mailsrv.ikr.uni-stuttgart.de [129.69.170.2]) by ietfa.amsl.com (Postfix) with ESMTP id 5CB5E11E80EF for ; Wed, 15 Jun 2011 06:07:50 -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 C76F0633B1; Wed, 15 Jun 2011 15:07:47 +0200 (CEST) Received: from vpn-2-cl177 (vpn-2-cl177 [10.41.21.177]) by netsrv1.ikr.uni-stuttgart.de (Postfix) with ESMTP id BD2A659A8A; Wed, 15 Jun 2011 15:07:47 +0200 (CEST) From: Mirja =?iso-8859-1?q?K=FChlewind?= To: iccrg@cs.ucl.ac.uk Date: Wed, 15 Jun 2011 15:07:46 +0200 User-Agent: KMail/1.9.10 (enterprise35 0.20101217.1207316) References: <94D3019D-33B6-4205-8B65-02923DBCA2DE@ifi.uio.no> <4DF46256.1000809@cse.unl.edu> In-Reply-To: <4DF46256.1000809@cse.unl.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: <201106151507.46768.mkuehle@ikr.uni-stuttgart.de> Cc: ledbat@ietf.org, Lisong Xu Subject: Re: [ledbat] [Iccrg] Looking for reviewer for draft-ietf-ledbat-congestion-06 X-BeenThere: ledbat@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Mailing list of the LEDBAT WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 15 Jun 2011 13:07:51 -0000 Hi Lisong thank you very much for your review! Please see comments inline. Mirja On Sunday 12 June 2011 08:53:10 Lisong Xu wrote: > Hi Michael, > > Below are my comments after reading the draft. > Thanks > Lisong > > > **** Section 3.1 **** > First sentence: "a loss occurs [RFC5681], which, in the absence of any > Active Queue Management (AQM) in the network, occurs only when the queue > at the bottleneck link on the end-to-end path overflows " > > Since a loss may occur due to link errors, such as fiber errors and > wireless errors, we may change the first sentence to > "... (AQM) and link errors in the network,...." Done. > **** Section 3.3 **** > The data type of each variable is not specified. Since some variables > must be signed variables, it is important to specify the type of each > variable in order to correctly implement the algorithm. > > For example, tcp_time_stamp is an unsigned int, so local_timestamp and > remote_timestamp are also unsigned int. But variable > acknowledgement.delay should be a signed int, since > local_timestamp-remote_timestamp may be negative. I don't want to specify any data type here because that's only pseudo code of the algorithm and the range and resolution of a variable are implementation specific and might depend on the framing protocol used and of course as well on the programming language. Your example is a quite special case as one would assume that delay is always positive but you might get negative values because of the clock offset. Issues like clock offset and skew, which can come up in a real system, are not regarded as part of the algorithm. Anyway there is some discussion in the appendix. Moreover, in fact in this special example it doesn't matter if the delay is positive or negative because its canceled out in the calculation of the queuing delay and even an overflow would work here. The only case where it is important that a value can/must get negative is the off_target and this is mentioned explicit in 3.4.1. > > **** Section 3.4.2 **** > "a LEDBAT sender stores BASE_HISTORY+1 separate minima- one each for the > last BASE_HISTORY minutes, and one for the running current minute." > > But the update_current_delay(delay) code maintains only BASE_HISTORY > minima. So the above sentence should be changed to > "a LEDBAT sender stores BASE_HISTORY separate minima- one each for the > last BASE_HISTORY-1 minutes, and one for the running current minute." Thanks. You are right! Done. > **** Section 3.5 **** > "we recommend that the sender SHOULD use at least 4 samples in each RTT. > Thus, CURRENT_FILTER SHOULD be at least 4, and limited such that no > samples in list are older than an RTT in the > past." > > But what if cwnd is less than 4? In this case, there are less than 4 > samples in each RTT. That's why there is a SHOULD and not a MUST. If you have less samples, you can, of course, only use whatever you get. But the results might be very noisy and if you permanently have less then 4 samples, LEDBAT might not work correctly (because of noise in real systems). Should we make this more explicit? > > > **** General ***** > > It is not clear what the relation between cwnd and flightsize is. Is > flightsize always the same as cwnd, or could be less than cwnd? When is > flightsize less than cwnd? flightsize can be less if your transfer is application-limited (and ALLOWED_INCREASE is large enough). Thus you don't have enough data to fill the cwnd. In the code you find " on acknowledgment: # flightsize is the amount of data outstanding before this ack # was received and is updated later by update_flightsize(); # bytes_newly_acked is the number of bytes that this ack # newly acknowledges, and it MAY be set to MSS; and # cwnd is in bytes." I've added the following to 'on initialization:' (eventhough you find the same explanation in 3.2.) " # cwnd is the amount of data that is allowed to send in one RTT and # is defined in bytes." Does this help? > > On 6/5/2011 12:38 AM, Michael Welzl wrote: > > Hi, > > > > We're urgently looking for a volunteer to review > > draft-ietf-ledbat-congestion-06: > > http://tools.ietf.org/html/draft-ietf-ledbat-congestion-06 > > which is currently in Last Call, ending in less than two weeks (15 June). > > > > If anyone here is willing to do a review, please drop Murari and me a > > note ASAP! > > > > Thanks, > > Michael > > > > > > _______________________________________________ > > Iccrg mailing list > > Iccrg@cs.ucl.ac.uk > > http://oakham.cs.ucl.ac.uk/mailman/listinfo/iccrg From mirja.kuehlewind@ikr.uni-stuttgart.de Wed Jun 15 06:29:41 2011 Return-Path: X-Original-To: ledbat@ietfa.amsl.com Delivered-To: ledbat@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B8A1711E813A for ; Wed, 15 Jun 2011 06:29:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.949 X-Spam-Level: X-Spam-Status: No, score=-1.949 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_DE=0.35, MIME_8BIT_HEADER=0.3] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id zyBiPu8BV5Sc for ; Wed, 15 Jun 2011 06:29:41 -0700 (PDT) Received: from mailsrv.ikr.uni-stuttgart.de (mailsrv.ikr.uni-stuttgart.de [129.69.170.2]) by ietfa.amsl.com (Postfix) with ESMTP id CC3AA11E812C for ; Wed, 15 Jun 2011 06:29:40 -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 C1941633B1; Wed, 15 Jun 2011 15:29:39 +0200 (CEST) Received: from vpn-2-cl177 (vpn-2-cl177 [10.41.21.177]) by netsrv1.ikr.uni-stuttgart.de (Postfix) with ESMTP id B90C359A8A; Wed, 15 Jun 2011 15:29:39 +0200 (CEST) From: Mirja =?iso-8859-1?q?K=FChlewind?= To: ledbat@ietf.org Date: Wed, 15 Jun 2011 15:29:39 +0200 User-Agent: KMail/1.9.10 (enterprise35 0.20101217.1207316) References: <791AD3077F94194BB2BDD13565B6295D05E6DF22@PALLENE.office.hd> <4DF65370.7000003@mti-systems.com> In-Reply-To: <4DF65370.7000003@mti-systems.com> X-KMail-QuotePrefix: > MIME-Version: 1.0 Content-Type: Text/Plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-Id: <201106151529.39099.mkuehle@ikr.uni-stuttgart.de> Subject: Re: [ledbat] 2 week last call for draft-ietf-ledbat-congestion-06 X-BeenThere: ledbat@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Mailing list of the LEDBAT WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 15 Jun 2011 13:29:41 -0000 Hi Wesley, thanks for you review. Please see comments inline. Mirja > - The document should probably note somewhere that ECN is not handled by > LEDBAT and making LEDBAT flows ECN capable would be potential future > work (maybe related to the AQM effects mentioned in the second > paragraph of section 2.2) See other emails... > > - In the security considerations, it might be worth noting that LEDBAT > is not known to introduce any new concerns with privacy, integrity, > or other security issues for flows that use it. It should be > compatible with use of IPsec and TLS/DTLS. Done. > > - In the abstract, LEDBAT yields not just to TCP but to any other flows > once latency builds. This is an important design feature in order for > delay-sensitive real-time flows to coexist with bulk transfers. It > works whether or not the other flows use TCP. s/any competing TCP flows/any competing flows when latency builds/ Okay? Or should we even add more text here? > > - Same comment as above in second paragraph of the Introduction. Same here s/performance of competing TCP flows/performance of competing flows/ s/interference with competing TCP flows/interference with competing flows when latency builds/ > > - Same comment as above in section 2.1 s/concurrent TCP flows/concurrent flows/ > > - For Vegas, I suggest also citing "Understanding TCP Vegas: A Duality > Model" by Low, Peterson, and Wang from JACM 49 (2), March 2002. This > provides additional analysis that's useful to understand in the > context of minimizing network queues I've been adding the reference. Should I also add a sentence here? > > - Section 3.1, first sentence, suggest adding "or ECN mark is received" Done. From mirja.kuehlewind@ikr.uni-stuttgart.de Wed Jun 15 06:46:54 2011 Return-Path: X-Original-To: ledbat@ietfa.amsl.com Delivered-To: ledbat@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6109421F84E4 for ; Wed, 15 Jun 2011 06:46:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.836 X-Spam-Level: X-Spam-Status: No, score=-1.836 tagged_above=-999 required=5 tests=[AWL=-0.114, BAYES_00=-2.599, HELO_EQ_DE=0.35, MIME_8BIT_HEADER=0.3, SARE_SUB_OBFU_Q1=0.227] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ZIBWVdoGHozb for ; Wed, 15 Jun 2011 06:46:54 -0700 (PDT) Received: from mailsrv.ikr.uni-stuttgart.de (mailsrv.ikr.uni-stuttgart.de [129.69.170.2]) by ietfa.amsl.com (Postfix) with ESMTP id C38BC21F84E5 for ; Wed, 15 Jun 2011 06:46:52 -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 C51D0633B1 for ; Wed, 15 Jun 2011 15:46:51 +0200 (CEST) Received: from vpn-2-cl177 (vpn-2-cl177 [10.41.21.177]) by netsrv1.ikr.uni-stuttgart.de (Postfix) with ESMTP id BB01159A8A for ; Wed, 15 Jun 2011 15:46:51 +0200 (CEST) From: Mirja =?iso-8859-1?q?K=FChlewind?= To: ledbat@ietf.org Date: Wed, 15 Jun 2011 15:46:51 +0200 User-Agent: KMail/1.9.10 (enterprise35 0.20101217.1207316) References: <791AD3077F94194BB2BDD13565B6295D05E6DF22@PALLENE.office.hd> <20110614163448.GG96377@verdi> <4DF7BD6A.8030202@mti-systems.com> In-Reply-To: <4DF7BD6A.8030202@mti-systems.com> X-KMail-QuotePrefix: > MIME-Version: 1.0 Content-Type: Text/Plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-Id: <201106151546.51111.mkuehle@ikr.uni-stuttgart.de> Subject: [ledbat] ECN/AQM, was: 2 week last call for draft-ietf-ledbat-congestion-06 X-BeenThere: ledbat@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Mailing list of the LEDBAT WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 15 Jun 2011 13:46:54 -0000 Hi, > On 6/14/2011 12:34 PM, John Leslie wrote: > > IMHO, we believe that ECN marking per AQM would be no problem at all, > > and packet-drop under AQM would merely cause backoff sooner than needed; > > and we have consensus to just accept that consequence. > > Since AQMs will generally only mark packets when there is a queue, and > LEDBAT strives to minimize its contribution to queues, it may be a lot > less likely that LEDBAT flows would be marked compared to other flows. > They would have adapted their rates as they received RTT estimates > indicating the buildup of the queue, and potentially already reacted > prior to losses being detected which takes longer without ECN. The question is, should we add somewhere that LEDBAT should halve its window when receiving a ECN mark? Actually in RFC3168 its already mentioned that (every) congestion control should react in the same way to ECN marks as it would to loss. But, as for loss, this would only be a fallback for LEDBAT as it should not build up a large queue. This can happen e.g. when the marking threshold is quite low and the TARGET value quiet high. By reacting on ECN marks with halving, LEDBAT would fallback to normal TCP behavior (with maybe increasing the window a little slower). And that's also the general issue about AQM. Depending on the parametrization of the AQM and LEDBAT, LEDBAT might fallback to standard TCP behavior. Implementors could try to recognize this and adapt there parametrization but that's not part of the LEDBAT algo itself. Mirja From Rolf.Winter@neclab.eu Wed Jun 15 08:37:56 2011 Return-Path: X-Original-To: ledbat@ietfa.amsl.com Delivered-To: ledbat@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D463C11E8118 for ; Wed, 15 Jun 2011 08:37:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.337 X-Spam-Level: X-Spam-Status: No, score=-102.337 tagged_above=-999 required=5 tests=[AWL=-0.087, BAYES_00=-2.599, HELO_EQ_DE=0.35, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id fN4PSiMAMFCa for ; Wed, 15 Jun 2011 08:37:56 -0700 (PDT) Received: from smtp0.netlab.nec.de (smtp0.netlab.nec.de [195.37.70.40]) by ietfa.amsl.com (Postfix) with ESMTP id 3F04011E8081 for ; Wed, 15 Jun 2011 08:37:56 -0700 (PDT) Received: from localhost (localhost.localdomain [127.0.0.1]) by smtp0.netlab.nec.de (Postfix) with ESMTP id 6FE042800039F for ; Wed, 15 Jun 2011 17:37:55 +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 KmZyNRynD+cM for ; Wed, 15 Jun 2011 17:37:55 +0200 (CEST) Received: from ENCELADUS.office.hd (ENCELADUS.office.hd [192.168.24.52]) by smtp0.netlab.nec.de (Postfix) with ESMTP id 4ED0328000189 for ; Wed, 15 Jun 2011 17:37:50 +0200 (CEST) Received: from Polydeuces.office.hd ([169.254.3.115]) by ENCELADUS.office.hd ([192.168.24.52]) with mapi id 14.01.0270.001; Wed, 15 Jun 2011 17:37:49 +0200 From: Rolf Winter To: "ledbat@ietf.org" Thread-Topic: 2 week last call for draft-ietf-ledbat-congestion-06 Thread-Index: AcwgK/PMpAcMkcw3T7yc+05bRSEkcQLRPQVg Date: Wed, 15 Jun 2011 15:37:47 +0000 Message-ID: <791AD3077F94194BB2BDD13565B6295D13B54A35@Polydeuces.office.hd> References: <791AD3077F94194BB2BDD13565B6295D05E6DF22@PALLENE.office.hd> In-Reply-To: <791AD3077F94194BB2BDD13565B6295D05E6DF22@PALLENE.office.hd> Accept-Language: en-US, de-DE Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.1.6.28] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: Re: [ledbat] 2 week last call for draft-ietf-ledbat-congestion-06 X-BeenThere: ledbat@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Mailing list of the LEDBAT WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 15 Jun 2011 15:37:57 -0000 Hi, (chair's hat off. Please treat these comments as any other last call commen= ts received.) A fine document. Some points below. "update_current_delay() maintains a list of one-way delay measurements, of = which the minimum is used as an estimate of the current end-to-end delay". = This is not mentioned when you talk about the implementation of FILTER() wh= ich actually gives a very different algorithm as an example. "In limited experiments with Bittorrent nodes, this controller seems to wor= k well." Refs would be good. "In the worse case, if the first flow yields at the same rate as the new fl= ow increases its sending rate, the new flow will see constant end-to-end de= lay, which it assumes is the base delay, until the first flow backs off com= pletely. As a result, by the time the second flow stops increasing its cwnd= , it would have added twice the target queueing delay to the network." Mayb= e I am misreading this but I believe this is not entirely and necessarily c= orrect. The base delay estimation is the minimum of all measured delay samp= les. Assume the first flow backs off completely, the second flow should be = able to get quite close to the absolute base delay with one of its packets = and it'll add TARGET on top. s/In other words, A LEDBAT/In other words, a LEDBAT/ s/senders's/sender's/ Best, Rolf =20 NEC Europe Limited | Registered Office: NEC House, 1 Victoria Road, London = W3 6BL | Registered in England 2832014=20 > -----Original Message----- > From: ledbat-bounces@ietf.org [mailto:ledbat-bounces@ietf.org] On > Behalf Of Rolf Winter > Sent: Mittwoch, 1. Juni 2011 09:17 > To: ledbat@ietf.org > Subject: [ledbat] 2 week last call for draft-ietf-ledbat-congestion-06 >=20 > Working Group, >=20 > this is to start a two week working group last call of draft-ietf- > ledbat-congestion-06. >=20 > Please send all comments you have to ledbat@ietf.org. >=20 > This WG last call ends on the 15th of June. >=20 > The chairs. >=20 >=20 >=20 > NEC Europe Limited | Registered Office: NEC House, 1 Victoria Road, > London W3 6BL | Registered in England 2832014 >=20 > _______________________________________________ > ledbat mailing list > ledbat@ietf.org > https://www.ietf.org/mailman/listinfo/ledbat From mirja.kuehlewind@ikr.uni-stuttgart.de Wed Jun 15 09:21:20 2011 Return-Path: X-Original-To: ledbat@ietfa.amsl.com Delivered-To: ledbat@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D703921F857F for ; Wed, 15 Jun 2011 09:21:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.061 X-Spam-Level: X-Spam-Status: No, score=-2.061 tagged_above=-999 required=5 tests=[AWL=0.188, BAYES_00=-2.599, HELO_EQ_DE=0.35] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id QFNwFeaJWJT0 for ; Wed, 15 Jun 2011 09:21:19 -0700 (PDT) Received: from mailsrv.ikr.uni-stuttgart.de (mailsrv.ikr.uni-stuttgart.de [129.69.170.2]) by ietfa.amsl.com (Postfix) with ESMTP id A597C21F857C for ; Wed, 15 Jun 2011 09:21:18 -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 5C325633B1 for ; Wed, 15 Jun 2011 18:21:16 +0200 (CEST) Received: from vpn-2-cl177 (vpn-2-cl177 [10.41.21.177]) by netsrv1.ikr.uni-stuttgart.de (Postfix) with ESMTP id 4CF2159A8A for ; Wed, 15 Jun 2011 18:21:16 +0200 (CEST) From: Mirja Kuehlewind Organization: University of Stuttgart (Germany), IKR To: ledbat@ietf.org Date: Wed, 15 Jun 2011 18:21:15 +0200 User-Agent: KMail/1.9.10 (enterprise35 0.20101217.1207316) References: <791AD3077F94194BB2BDD13565B6295D05E6DF22@PALLENE.office.hd> <791AD3077F94194BB2BDD13565B6295D13B54A35@Polydeuces.office.hd> In-Reply-To: <791AD3077F94194BB2BDD13565B6295D13B54A35@Polydeuces.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: <201106151821.15361.mirja.kuehlewind@ikr.uni-stuttgart.de> Subject: Re: [ledbat] 2 week last call for draft-ietf-ledbat-congestion-06 X-BeenThere: ledbat@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Mailing list of the LEDBAT WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 15 Jun 2011 16:21:21 -0000 Hi, thanks for the review. Please see my comments inline. Mirja On Wednesday 15 June 2011 17:37:47 Rolf Winter wrote: > Hi, > > (chair's hat off. Please treat these comments as any other last call > comments received.) > > A fine document. Some points below. > > "update_current_delay() maintains a list of one-way delay measurements, of > which the minimum is used as an estimate of the current end-to-end delay". > This is not mentioned when you talk about the implementation of FILTER() > which actually gives a very different algorithm as an example. Good catch! We changed MIN() to FILTER() and we forgot to adapt the text he= re=20 (there are two more places we have to change). > > "In limited experiments with Bittorrent nodes, this controller seems to > work well." Refs would be good. That's the problem, there are no refs... > > "In the worse case, if the first flow yields at the same rate as the new > flow increases its sending rate, the new flow will see constant end-to-end > delay, which it assumes is the base delay, until the first flow backs off > completely. As a result, by the time the second flow stops increasing its > cwnd, it would have added twice the target queueing delay to the network." > Maybe I am misreading this but I believe this is not entirely and > necessarily correct. The base delay estimation is the minimum of all > measured delay samples. Assume the first flow backs off completely, the > second flow should be able to get quite close to the absolute base delay > with one of its packets and it'll add TARGET on top. No, its correct. By the time the first flow backs off completely, the secon= d=20 flow has already increase its sending rate such that TARGET extra delay is = on=20 the link. So every packet that is send out after the back off will still=20 measure the base_delay + TARGET and there has never been and will never be = a=20 lower sample. So during the time period the first one needed to back off, t= he=20 delay was constant (all delay samples have been the same). cwnd ^ | __________________________________ | / | / | / | / | \ / | \ /=20 | / \ | / \ =2D------------------------------------------------------------------> time t1 delay ^ | __________________________________ | / | / | / |_________ / |=20 | | | =2D------------------------------------------------------------------> time t1 > > s/In other words, A LEDBAT/In other words, a LEDBAT/ > s/senders's/sender's/ Done. > > 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 Rolf Winter > > Sent: Mittwoch, 1. Juni 2011 09:17 > > To: ledbat@ietf.org > > Subject: [ledbat] 2 week last call for draft-ietf-ledbat-congestion-06 > > > > Working Group, > > > > this is to start a two week working group last call of draft-ietf- > > ledbat-congestion-06. > > > > Please send all comments you have to ledbat@ietf.org. > > > > This WG last call ends on the 15th of June. > > > > The chairs. > > > > > > > > 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 =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 wes@mti-systems.com Wed Jun 15 12:06:46 2011 Return-Path: X-Original-To: ledbat@ietfa.amsl.com Delivered-To: ledbat@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0240D21F85D4 for ; Wed, 15 Jun 2011 12:06:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.299 X-Spam-Level: X-Spam-Status: No, score=-2.299 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, MIME_8BIT_HEADER=0.3] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 4unHfNEBXbpm for ; Wed, 15 Jun 2011 12:06:45 -0700 (PDT) Received: from omr1.networksolutionsemail.com (omr1.networksolutionsemail.com [205.178.146.51]) by ietfa.amsl.com (Postfix) with ESMTP id F393621F85D3 for ; Wed, 15 Jun 2011 12:06:44 -0700 (PDT) Received: from cm-omr8 (mail.networksolutionsemail.com [205.178.146.50]) by omr1.networksolutionsemail.com (8.13.6/8.13.6) with ESMTP id p5FJ6Evp007347 for ; Wed, 15 Jun 2011 15:06:14 -0400 Authentication-Results: cm-omr8 smtp.user=wes@mti-systems.com; auth=pass (PLAIN) X-Authenticated-UID: wes@mti-systems.com Received: from [173.120.241.66] ([173.120.241.66:39418] helo=[192.168.9.2]) by cm-omr8 (envelope-from ) (ecelerity 2.2.2.41 r(31179/31189)) with ESMTPA id 94/9E-24574-5A209FD4; Wed, 15 Jun 2011 15:06:14 -0400 Message-ID: <4DF902A5.2000405@mti-systems.com> Date: Wed, 15 Jun 2011 15:06:13 -0400 From: Wesley Eddy Organization: MTI Systems User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9.2.17) Gecko/20110414 Lightning/1.0b2 Thunderbird/3.1.10 MIME-Version: 1.0 To: =?ISO-8859-1?Q?Mirja_K=FChlewind?= References: <791AD3077F94194BB2BDD13565B6295D05E6DF22@PALLENE.office.hd> <4DF65370.7000003@mti-systems.com> <201106151529.39099.mkuehle@ikr.uni-stuttgart.de> In-Reply-To: <201106151529.39099.mkuehle@ikr.uni-stuttgart.de> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit Cc: ledbat@ietf.org Subject: Re: [ledbat] 2 week last call for draft-ietf-ledbat-congestion-06 X-BeenThere: ledbat@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Mailing list of the LEDBAT WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 15 Jun 2011 19:06:46 -0000 On 6/15/2011 9:29 AM, Mirja Kühlewind wrote: > ... > >> - In the abstract, LEDBAT yields not just to TCP but to any other flows >> once latency builds. This is an important design feature in order for >> delay-sensitive real-time flows to coexist with bulk transfers. It >> works whether or not the other flows use TCP. > s/any competing TCP flows/any competing flows when latency builds/ > Okay? Or should we even add more text here? Sounds good. >> - Same comment as above in second paragraph of the Introduction. > Same here > s/performance of competing TCP flows/performance of competing flows/ > s/interference with competing TCP flows/interference with competing flows when > latency builds/ >> >> - Same comment as above in section 2.1 > s/concurrent TCP flows/concurrent flows/ Sounds good. >> - For Vegas, I suggest also citing "Understanding TCP Vegas: A Duality >> Model" by Low, Peterson, and Wang from JACM 49 (2), March 2002. This >> provides additional analysis that's useful to understand in the >> context of minimizing network queues > I've been adding the reference. Should I also add a sentence here? It doesn't matter to me; I'm happy just with the reference that a reader could follow if they want to. -- Wes Eddy MTI Systems From wes@mti-systems.com Wed Jun 15 12:16:02 2011 Return-Path: X-Original-To: ledbat@ietfa.amsl.com Delivered-To: ledbat@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7B11211E80EB for ; Wed, 15 Jun 2011 12:16:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.336 X-Spam-Level: X-Spam-Status: No, score=-2.336 tagged_above=-999 required=5 tests=[AWL=0.036, BAYES_00=-2.599, SARE_SUB_OBFU_Q1=0.227] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id aOK2Dd1wjw2D for ; Wed, 15 Jun 2011 12:16:01 -0700 (PDT) Received: from omr3.networksolutionsemail.com (omr3.networksolutionsemail.com [205.178.146.53]) by ietfa.amsl.com (Postfix) with ESMTP id BD02911E80DC for ; Wed, 15 Jun 2011 12:16:00 -0700 (PDT) Received: from cm-omr4 (mail.networksolutionsemail.com [205.178.146.50]) by omr3.networksolutionsemail.com (8.13.6/8.13.6) with ESMTP id p5FJE4It026134 for ; Wed, 15 Jun 2011 15:14:06 -0400 Authentication-Results: cm-omr4 smtp.user=wes@mti-systems.com; auth=pass (PLAIN) X-Authenticated-UID: wes@mti-systems.com Received: from [173.120.241.66] ([173.120.241.66:32148] helo=[192.168.9.2]) by cm-omr4 (envelope-from ) (ecelerity 2.2.2.41 r(31179/31189)) with ESMTPA id 29/AD-27025-B7409FD4; Wed, 15 Jun 2011 15:14:04 -0400 Message-ID: <4DF90477.4080906@mti-systems.com> Date: Wed, 15 Jun 2011 15:13:59 -0400 From: Wesley Eddy Organization: MTI Systems User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9.2.17) Gecko/20110414 Lightning/1.0b2 Thunderbird/3.1.10 MIME-Version: 1.0 To: ledbat@ietf.org References: <791AD3077F94194BB2BDD13565B6295D05E6DF22@PALLENE.office.hd> <20110614163448.GG96377@verdi> <4DF7BD6A.8030202@mti-systems.com> <201106151546.51111.mkuehle@ikr.uni-stuttgart.de> In-Reply-To: <201106151546.51111.mkuehle@ikr.uni-stuttgart.de> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit Subject: Re: [ledbat] ECN/AQM, was: 2 week last call for draft-ietf-ledbat-congestion-06 X-BeenThere: ledbat@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Mailing list of the LEDBAT WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 15 Jun 2011 19:16:02 -0000 On 6/15/2011 9:46 AM, Mirja Kühlewind wrote: > > The question is, should we add somewhere that LEDBAT should halve its window > when receiving a ECN mark? Actually in RFC3168 its already mentioned that > (every) congestion control should react in the same way to ECN marks as it > would to loss. It doesn't seem that many LEDBAT flows will be ECN-Capable Transports, but it's probably worth saying that *if* an implementation is ECN-capable, then it should react to ECN marks as losses. -- Wes Eddy MTI Systems From Rolf.Winter@neclab.eu Thu Jun 16 00:19:09 2011 Return-Path: X-Original-To: ledbat@ietfa.amsl.com Delivered-To: ledbat@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7CDFB11E8078 for ; Thu, 16 Jun 2011 00:19:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.378 X-Spam-Level: X-Spam-Status: No, score=-101.378 tagged_above=-999 required=5 tests=[AWL=-0.988, BAYES_20=-0.74, HELO_EQ_DE=0.35, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id lKUBDZZJrpyy for ; Thu, 16 Jun 2011 00:19:08 -0700 (PDT) Received: from smtp0.netlab.nec.de (smtp0.netlab.nec.de [195.37.70.40]) by ietfa.amsl.com (Postfix) with ESMTP id 395FE228006 for ; Thu, 16 Jun 2011 00:19:07 -0700 (PDT) Received: from localhost (localhost.localdomain [127.0.0.1]) by smtp0.netlab.nec.de (Postfix) with ESMTP id CDB272800039F for ; Thu, 16 Jun 2011 09:19:06 +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 TAiuYdmHv+zG for ; Thu, 16 Jun 2011 09:19:06 +0200 (CEST) Received: from METHONE.office.hd (Methone.office.hd [192.168.24.54]) by smtp0.netlab.nec.de (Postfix) with ESMTP id B008B28000189 for ; Thu, 16 Jun 2011 09:19:01 +0200 (CEST) Received: from Polydeuces.office.hd ([169.254.3.115]) by METHONE.office.hd ([192.168.24.54]) with mapi id 14.01.0270.001; Thu, 16 Jun 2011 09:18:57 +0200 From: Rolf Winter To: "ledbat@ietf.org" Thread-Topic: WG last call on draft-ietf-ledbat-congestion-06 ended Thread-Index: Acwr9adIkoZcUcq9SjS+vvSBYU9mqg== Date: Thu, 16 Jun 2011 07:18:56 +0000 Message-ID: <791AD3077F94194BB2BDD13565B6295D13B59440@Polydeuces.office.hd> Accept-Language: en-US, de-DE Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.1.6.28] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: [ledbat] WG last call on draft-ietf-ledbat-congestion-06 ended X-BeenThere: ledbat@ietf.org X-Mailman-Version: 2.1.12 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, 16 Jun 2011 07:19:09 -0000 WG, the last call on draft-ietf-ledbat-congestion-06 has ended yesterday. There= were a few comments. Could the authors please resolve the comments publish= a new version of the draft and make sure the comments were adequately addr= essed. Thanks,=20 Rolf NEC Europe Limited | Registered Office: NEC House, 1 Victoria Road, London = W3 6BL | Registered in England 2832014=20 From gorry@erg.abdn.ac.uk Thu Jun 16 10:44:39 2011 Return-Path: X-Original-To: ledbat@ietfa.amsl.com Delivered-To: ledbat@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8A05411E81FD for ; Thu, 16 Jun 2011 10:44:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.486 X-Spam-Level: X-Spam-Status: No, score=-102.486 tagged_above=-999 required=5 tests=[AWL=-0.114, BAYES_00=-2.599, SARE_SUB_OBFU_Q1=0.227, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id WPFrFYDmdEZT for ; Thu, 16 Jun 2011 10:44:38 -0700 (PDT) Received: from erg.abdn.ac.uk (dee.erg.abdn.ac.uk [IPv6:2001:630:241:204:203:baff:fe9a:8c9b]) by ietfa.amsl.com (Postfix) with ESMTP id 2EE0B11E8128 for ; Thu, 16 Jun 2011 10:44:36 -0700 (PDT) Received: from gorry-mac.erg.abdn.ac.uk (gorry-mac.erg.abdn.ac.uk [139.133.207.5]) (authenticated bits=0) by erg.abdn.ac.uk (8.13.4/8.13.4) with ESMTP id p5GHiWPF018915 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NOT) for ; Thu, 16 Jun 2011 18:44:33 +0100 (BST) Message-ID: <4DFA4101.9000306@erg.abdn.ac.uk> Date: Thu, 16 Jun 2011 18:44:33 +0100 From: Gorry Fairhurst Organization: The University of Aberdeen is a charity registered in Scotland, No SC013683. User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.6; en-US; rv:1.9.2.17) Gecko/20110414 Thunderbird/3.1.10 MIME-Version: 1.0 To: ledbat@ietf.org References: <791AD3077F94194BB2BDD13565B6295D05E6DF22@PALLENE.office.hd> <20110614163448.GG96377@verdi> <4DF7BD6A.8030202@mti-systems.com> <201106151546.51111.mkuehle@ikr.uni-stuttgart.de> <4DF90477.4080906@mti-systems.com> In-Reply-To: <4DF90477.4080906@mti-systems.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit X-ERG-MailScanner: Found to be clean X-ERG-MailScanner-From: gorry@erg.abdn.ac.uk Subject: Re: [ledbat] ECN/AQM, was: 2 week last call for draft-ietf-ledbat-congestion-06 X-BeenThere: ledbat@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: gorry@erg.abdn.ac.uk List-Id: Mailing list of the LEDBAT WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 16 Jun 2011 17:44:39 -0000 On 15/06/2011 20:13, Wesley Eddy wrote: > On 6/15/2011 9:46 AM, Mirja Kühlewind wrote: >> >> The question is, should we add somewhere that LEDBAT should halve its >> window >> when receiving a ECN mark? Actually in RFC3168 its already mentioned that >> (every) congestion control should react in the same way to ECN marks >> as it >> would to loss. > > > It doesn't seem that many LEDBAT flows will be ECN-Capable Transports, > but it's probably worth saying that *if* an implementation is > ECN-capable, then it should react to ECN marks as losses. > Mirja seems to raise a valid point... I think it would be extremely good to encourage the use of ECN for such applications, by saying explicitly that ECN could offer benefit when the infrastructure supports this. To allow this, a LEDBAT session needs to send packets with ECT(x), and then MUST include appropriate control functions. If ECN were supported, then an ECN mark (CE) indicates actual congestion, which could (?) be taken as more significant than a loss, especially since the goal of LEDBAT was to keep the queue low, and therefore I suggest it could be reasonable to regard actual reported congestion as significant (or take RFC3168's view that at least ECN is equivalent to loss). - whatever, I think reception of an ECN mark MUST cause the corresponding sender to perform a congestion response - i.e. can not be ignored. Gorry From mirja.kuehlewind@ikr.uni-stuttgart.de Fri Jun 17 02:33:12 2011 Return-Path: X-Original-To: ledbat@ietfa.amsl.com Delivered-To: ledbat@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8644A9E8015 for ; Fri, 17 Jun 2011 02:33:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.136 X-Spam-Level: X-Spam-Status: No, score=-2.136 tagged_above=-999 required=5 tests=[AWL=0.113, BAYES_00=-2.599, HELO_EQ_DE=0.35] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id pifPSZ0GroOO for ; Fri, 17 Jun 2011 02:33:11 -0700 (PDT) Received: from mailsrv.ikr.uni-stuttgart.de (mailsrv.ikr.uni-stuttgart.de [129.69.170.2]) by ietfa.amsl.com (Postfix) with ESMTP id 3EFF09E8014 for ; Fri, 17 Jun 2011 02:33:10 -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 71345633B1; Fri, 17 Jun 2011 11:33:09 +0200 (CEST) Received: from vpn-2-cl177 (vpn-2-cl177 [10.41.21.177]) by netsrv1.ikr.uni-stuttgart.de (Postfix) with ESMTP id 62EED59A8A; Fri, 17 Jun 2011 11:33:09 +0200 (CEST) From: Mirja Kuehlewind Organization: University of Stuttgart (Germany), IKR To: Lisong Xu Date: Fri, 17 Jun 2011 11:33:09 +0200 User-Agent: KMail/1.9.10 (enterprise35 0.20101217.1207316) References: <94D3019D-33B6-4205-8B65-02923DBCA2DE@ifi.uio.no> <201106151507.46768.mkuehle@ikr.uni-stuttgart.de> <4DFA3108.7000201@cse.unl.edu> In-Reply-To: <4DFA3108.7000201@cse.unl.edu> 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: <201106171133.09177.mirja.kuehlewind@ikr.uni-stuttgart.de> Cc: ledbat@ietf.org, iccrg@cs.ucl.ac.uk Subject: Re: [ledbat] [Iccrg] Looking for reviewer for draft-ietf-ledbat-congestion-06 X-BeenThere: ledbat@ietf.org X-Mailman-Version: 2.1.12 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, 17 Jun 2011 09:33:12 -0000 Hi Lisong, you are right, if it is an unsigned this might cause errors but its actuall= y=20 not a problem. If local_timestamp-remote_timestamp is negative but=20 acknowledgement.delay is signed you will get a wrong result (but this doesn= 't=20 matter as this delay does not show a real delay value anyway) but you will= =20 get a result because there simply will be an overflow. If you now calculate queuing_delay =3D current_delay - base_delay. Also thi= s=20 error will cancel out and you get an valid result. Anyway, its in the responsibility of the implementor to get the type and ra= nge=20 right; its not part of the algorithm itself, from my point of view. Do you= =20 have a different opinion here?=20 Mirja On Thursday 16 June 2011 18:36:24 Lisong Xu wrote: > Mirja, > > Thanks for your reply. I have only one question now. > > "it doesn't matter if the delay is positive or negative because its > canceled out in the calculation of the queuing delay and even an > overflow would work here." > > You are right that it does not matter whether acknowledgement.delay is > positive or negative. But variable acknowledgement.delay MUST be a > signed int. If it is implemented as an unsigned int, then sometimes > there will be a problem. > > Thanks > Lisong > > On 6/15/2011 6:07 AM, Mirja K=FChlewind wrote: > > Hi Lisong > > > > thank you very much for your review! Please see comments inline. > > > > Mirja > > > > On Sunday 12 June 2011 08:53:10 Lisong Xu wrote: > >> Hi Michael, > >> > >> Below are my comments after reading the draft. > >> Thanks > >> Lisong > >> > >> > >> **** Section 3.1 **** > >> First sentence: "a loss occurs [RFC5681], which, in the absence of any > >> Active Queue Management (AQM) in the network, occurs only when the que= ue > >> at the bottleneck link on the end-to-end path overflows " > >> > >> Since a loss may occur due to link errors, such as fiber errors and > >> wireless errors, we may change the first sentence to > >> "... (AQM) and link errors in the network,...." > > > > Done. > > > >> **** Section 3.3 **** > >> The data type of each variable is not specified. Since some variables > >> must be signed variables, it is important to specify the type of each > >> variable in order to correctly implement the algorithm. > >> > >> For example, tcp_time_stamp is an unsigned int, so local_timestamp and > >> remote_timestamp are also unsigned int. But variable > >> acknowledgement.delay should be a signed int, since > >> local_timestamp-remote_timestamp may be negative. > > > > I don't want to specify any data type here because that's only pseudo > > code of the algorithm and the range and resolution of a variable are > > implementation specific and might depend on the framing protocol used a= nd > > of course as well on the programming language. > > > > Your example is a quite special case as one would assume that delay is > > always positive but you might get negative values because of the clock > > offset. Issues like clock offset and skew, which can come up in a real > > system, are not regarded as part of the algorithm. Anyway there is some > > discussion in the appendix. Moreover, in fact in this special example it > > doesn't matter if the delay is positive or negative because its canceled > > out in the calculation of the queuing delay and even an overflow would > > work here. > > > > The only case where it is important that a value can/must get negative = is > > the off_target and this is mentioned explicit in 3.4.1. > > > >> **** Section 3.4.2 **** > >> "a LEDBAT sender stores BASE_HISTORY+1 separate minima- one each for t= he > >> last BASE_HISTORY minutes, and one for the running current minute." > >> > >> But the update_current_delay(delay) code maintains only BASE_HISTORY > >> minima. So the above sentence should be changed to > >> "a LEDBAT sender stores BASE_HISTORY separate minima- one each for the > >> last BASE_HISTORY-1 minutes, and one for the running current minute." > > > > Thanks. You are right! Done. > > > >> **** Section 3.5 **** > >> "we recommend that the sender SHOULD use at least 4 samples in each RT= T. > >> Thus, CURRENT_FILTER SHOULD be at least 4, and limited such that no > >> samples in list are older than an RTT in the > >> past." > >> > >> But what if cwnd is less than 4? In this case, there are less than 4 > >> samples in each RTT. > > > > That's why there is a SHOULD and not a MUST. If you have less samples, > > you can, of course, only use whatever you get. But the results might be > > very noisy and if you permanently have less then 4 samples, LEDBAT might > > not work correctly (because of noise in real systems). > > > > Should we make this more explicit? > > > >> **** General ***** > >> > >> It is not clear what the relation between cwnd and flightsize is. Is > >> flightsize always the same as cwnd, or could be less than cwnd? When is > >> flightsize less than cwnd? > > > > flightsize can be less if your transfer is application-limited (and > > ALLOWED_INCREASE is large enough). Thus you don't have enough data to > > fill the cwnd. > > > > In the code you find > > " on acknowledgment: > > # flightsize is the amount of data outstanding before this ack > > # was received and is updated later by update_flightsize(); > > # bytes_newly_acked is the number of bytes that this ack > > # newly acknowledges, and it MAY be set to MSS; and > > # cwnd is in bytes." > > > > I've added the following to 'on initialization:' (eventhough you find t= he > > same explanation in 3.2.) > > " # cwnd is the amount of data that is allowed to send in one RTT and > > # is defined in bytes." > > > > Does this help? > > > >> On 6/5/2011 12:38 AM, Michael Welzl wrote: > >>> Hi, > >>> > >>> We're urgently looking for a volunteer to review > >>> draft-ietf-ledbat-congestion-06: > >>> http://tools.ietf.org/html/draft-ietf-ledbat-congestion-06 > >>> which is currently in Last Call, ending in less than two weeks (15 > >>> June). > >>> > >>> If anyone here is willing to do a review, please drop Murari and me a > >>> note ASAP! > >>> > >>> Thanks, > >>> Michael > >>> > >>> > >>> _______________________________________________ > >>> Iccrg mailing list > >>> Iccrg@cs.ucl.ac.uk > >>> http://oakham.cs.ucl.ac.uk/mailman/listinfo/iccrg =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 dario.rossi@enst.fr Fri Jun 17 02:45:38 2011 Return-Path: X-Original-To: ledbat@ietfa.amsl.com Delivered-To: ledbat@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4984421F84E2 for ; Fri, 17 Jun 2011 02:45:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.598 X-Spam-Level: X-Spam-Status: No, score=-2.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id fsxsIWzdJhos for ; Fri, 17 Jun 2011 02:45:37 -0700 (PDT) Received: from smtp2.enst.fr (revol2.enst.fr [IPv6:2001:660:330f:2::e]) by ietfa.amsl.com (Postfix) with ESMTP id 4C98A21F84DD for ; Fri, 17 Jun 2011 02:45:36 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by smtp2.enst.fr (Postfix) with ESMTP id 471D6B81A3; Fri, 17 Jun 2011 11:45:33 +0200 (CEST) Received: from [IPv6:::1] (infres1.enst.fr [137.194.192.1]) by smtp2.enst.fr (Postfix) with ESMTP id C707DB8033; Fri, 17 Jun 2011 11:45:32 +0200 (CEST) Message-ID: <4DFB223E.3000303@enst.fr> Date: Fri, 17 Jun 2011 11:45:34 +0200 From: Dario Rossi User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.9.2.12) Gecko/20101027 Lightning/1.0b2 Thunderbird/3.1.6 MIME-Version: 1.0 To: Mirja Kuehlewind References: <791AD3077F94194BB2BDD13565B6295D05E6DF22@PALLENE.office.hd> <791AD3077F94194BB2BDD13565B6295D13B54A35@Polydeuces.office.hd> <201106151821.15361.mirja.kuehlewind@ikr.uni-stuttgart.de> In-Reply-To: <201106151821.15361.mirja.kuehlewind@ikr.uni-stuttgart.de> Content-Type: multipart/alternative; boundary="------------010309000509060602020106" Cc: ledbat@ietf.org Subject: Re: [ledbat] 2 week last call for draft-ietf-ledbat-congestion-06 X-BeenThere: ledbat@ietf.org X-Mailman-Version: 2.1.12 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, 17 Jun 2011 09:45:38 -0000 This is a multi-part message in MIME format. --------------010309000509060602020106 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Hi Mirja, all, 1st of all, sorry for not having been able to cope/help with the numerous updates on the draft, and for the after-deadline comment! please see inline On 06/15/2011 06:21 PM, Mirja Kuehlewind wrote: > Hi, > > thanks for the review. Please see my comments inline. > > Mirja > > > On Wednesday 15 June 2011 17:37:47 Rolf Winter wrote: >> Hi, >> >> (chair's hat off. Please treat these comments as any other last call >> comments received.) >> >> A fine document. Some points below. >> >> "update_current_delay() maintains a list of one-way delay measurements, of >> which the minimum is used as an estimate of the current end-to-end delay". >> This is not mentioned when you talk about the implementation of FILTER() >> which actually gives a very different algorithm as an example. > Good catch! We changed MIN() to FILTER() and we forgot to adapt the text here > (there are two more places we have to change). > >> "In limited experiments with Bittorrent nodes, this controller seems to >> work well." Refs would be good. > That's the problem, there are no refs... > Our testbed experiments with the BitTorrent libUTP implementation shown that latecomer unfairness arises also in the real world, in case of /backlogged/ flows ( see Fig1, pag2 in http://arxiv.org/abs/1010.5623 ) Latecomer unfairness may instead vanish in case of /non-backlogged/ connections (see Fig6 pag 9 in http://arxiv.org/abs/1010.5623 ; only ns2 results here though) While I understand (and agree) that fairness may not be the main aspect in ledbat, given the above observations and [1], it seems to me that sec 5.3 of the current version of the draft wrongly states that fairness is reinstated simply by randomness in the inter-packet transmission times exist, as [1] shows this is not the case (and though there is real-world noise in the testbed of Fig1, pag2 in http://arxiv.org/abs/1010.5623 , this is apparently not enough either...) In other words, real-world noise is not enough to break latecomer unfairness, but the use of non-backlogged traffic sources can: notice that non backlogged sources assist in emptying the queues, while a simple jittering cannot (hence, the explanation in sec 5.3 is misleading?). [1] G. Carofiglio, L. Muscariello, D. Rossi and S. Valenti, *The quest for LEDBAT fairness* . In /IEEE Globecom'10/, Miami, FL, USA, December 6-10 2010. Best, D. >> "In the worse case, if the first flow yields at the same rate as the new >> flow increases its sending rate, the new flow will see constant end-to-end >> delay, which it assumes is the base delay, until the first flow backs off >> completely. As a result, by the time the second flow stops increasing its >> cwnd, it would have added twice the target queueing delay to the network." >> Maybe I am misreading this but I believe this is not entirely and >> necessarily correct. The base delay estimation is the minimum of all >> measured delay samples. Assume the first flow backs off completely, the >> second flow should be able to get quite close to the absolute base delay >> with one of its packets and it'll add TARGET on top. > No, its correct. By the time the first flow backs off completely, the second > flow has already increase its sending rate such that TARGET extra delay is on > the link. So every packet that is send out after the back off will still > measure the base_delay + TARGET and there has never been and will never be a > lower sample. So during the time period the first one needed to back off, the > delay was constant (all delay samples have been the same). > > cwnd > ^ > | __________________________________ > | / > | / > | / > | / > | \ / > | \ / > | / \ > | / \ > -------------------------------------------------------------------> time > t1 > > delay > ^ > | __________________________________ > | / > | / > | / > |_________ / > | > | > | > | > -------------------------------------------------------------------> time > t1 > >> s/In other words, A LEDBAT/In other words, a LEDBAT/ >> s/senders's/sender's/ > Done. > > >> 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 Rolf Winter >>> Sent: Mittwoch, 1. Juni 2011 09:17 >>> To: ledbat@ietf.org >>> Subject: [ledbat] 2 week last call for draft-ietf-ledbat-congestion-06 >>> >>> Working Group, >>> >>> this is to start a two week working group last call of draft-ietf- >>> ledbat-congestion-06. >>> >>> Please send all comments you have to ledbat@ietf.org. >>> >>> This WG last call ends on the 15th of June. >>> >>> The chairs. >>> >>> >>> >>> 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 > > -- Oo Associate Professor > TELECOM ParisTech ~ (formerly ENST) mail: dario.rossi@enst.fr phone: +33.1.4581.7563 fax: +33.1.4581.7158 web: http://www.enst.fr/~drossi --------------010309000509060602020106 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Hi Mirja, all,

1st of all, sorry for not having been able to cope/help with the numerous updates on the draft, and for the after-deadline comment!  please see inline

On 06/15/2011 06:21 PM, Mirja Kuehlewind wrote: 
Hi,

thanks for the review. Please see my comments inline.

Mirja


On Wednesday 15 June 2011 17:37:47 Rolf Winter wrote:

Hi,

(chair's hat off. Please treat these comments as any other last call
comments received.)

A fine document. Some points below.

"update_current_delay() maintains a list of one-way delay measurements, of
which the minimum is used as an estimate of the current end-to-end delay".
This is not mentioned when you talk about the implementation of FILTER()
which actually gives a very different algorithm as an example.

Good catch! We changed MIN() to FILTER() and we forgot to adapt the text here 
(there are two more places we have to change).


"In limited experiments with Bittorrent nodes, this controller seems to
work well." Refs would be good.

That's the problem, there are no refs...

Our testbed experiments with the BitTorrent libUTP implementation shown that latecomer unfairness arises also in the real world, in case of /backlogged/ flows ( see Fig1, pag2 in http://arxiv.org/abs/1010.5623 )

Latecomer unfairness may instead vanish in case of /non-backlogged/ connections (see Fig6 pag 9 in http://arxiv.org/abs/1010.5623 ; only ns2 results here though)

While I understand (and agree) that fairness may not be the main aspect in ledbat, given the above observations and [1], it seems to me that  sec 5.3 of the current version of the draft wrongly states that fairness is reinstated simply by
	randomness in the inter-packet transmission times exist,
as [1] shows this is not the case  (and though there is real-world noise in the testbed of Fig1, pag2 in http://arxiv.org/abs/1010.5623 , this is apparently not enough either...)

In other words, real-world noise is not enough to break latecomer unfairness, but the use of non-backlogged traffic sources can: notice that non backlogged sources assist in emptying the queues, while a simple jittering cannot (hence, the explanation in sec 5.3 is misleading?).


[1] G. Carofiglio, L. Muscariello, D. Rossi and S. Valenti, The quest for LEDBAT fairness . In IEEE Globecom'10, Miami, FL, USA, December 6-10 2010.


Best,
D.


      

        
"In the worse case, if the first flow yields at the same rate as the new
flow increases its sending rate, the new flow will see constant end-to-end
delay, which it assumes is the base delay, until the first flow backs off
completely. As a result, by the time the second flow stops increasing its
cwnd, it would have added twice the target queueing delay to the network."
Maybe I am misreading this but I believe this is not entirely and
necessarily correct. The base delay estimation is the minimum of all
measured delay samples. Assume the first flow backs off completely, the
second flow should be able to get quite close to the absolute base delay
with one of its packets and it'll add TARGET on top.


      

      
No, its correct. By the time the first flow backs off completely, the second 
flow has already increase its sending rate such that TARGET extra delay is on 
the link. So every packet that is send out after the back off will still 
measure the base_delay + TARGET and there has never been and will never be a 
lower sample. So during the time period the first one needed to back off, the 
delay was constant (all delay samples have been the same).

cwnd
^
|                        __________________________________
|                      /
|                    /
|                 /
|              /
|  \        /
|     \  / 
|     /  \
|  /        \
-------------------------------------------------------------------> time
              t1

delay
^
|                         __________________________________
|                        /
|                      /
|                   /
|_________ /
| 
|
|
|
-------------------------------------------------------------------> time
                t1



      

        
s/In other words, A LEDBAT/In other words, a LEDBAT/
s/senders's/sender's/


      

      
Done.




      

        
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 Rolf Winter
Sent: Mittwoch, 1. Juni 2011 09:17
To: ledbat@ietf.org
Subject: [ledbat] 2 week last call for draft-ietf-ledbat-congestion-06

Working Group,

this is to start a two week working group last call of draft-ietf-
ledbat-congestion-06.

Please send all comments you have to ledbat@ietf.org.

This WG last call ends on the 15th of June.

The chairs.



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


      

      




    

    

    

    
-- 
 Oo    Associate Professor
  >    TELECOM ParisTech
 ~     (formerly ENST)

mail:  dario.rossi@enst.fr
phone: +33.1.4581.7563
fax:   +33.1.4581.7158
web:   http://www.enst.fr/~drossi


  


--------------010309000509060602020106--

From dario.rossi@enst.fr  Fri Jun 17 05:42:39 2011
Return-Path: 
X-Original-To: ledbat@ietfa.amsl.com
Delivered-To: ledbat@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D6FA211E809B for ; Fri, 17 Jun 2011 05:42:39 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.598
X-Spam-Level: 
X-Spam-Status: No, score=-2.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001]
Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id BwFOXigwHz64 for ; Fri, 17 Jun 2011 05:42:38 -0700 (PDT)
Received: from smtp2.enst.fr (revol2.enst.fr [IPv6:2001:660:330f:2::e]) by ietfa.amsl.com (Postfix) with ESMTP id AFCFB11E8091 for ; Fri, 17 Jun 2011 05:42:37 -0700 (PDT)
Received: from localhost (localhost [127.0.0.1]) by smtp2.enst.fr (Postfix) with ESMTP id C0089B8A24; Fri, 17 Jun 2011 14:42:36 +0200 (CEST)
Received: from [IPv6:::1] (infres1.enst.fr [137.194.192.1]) by smtp2.enst.fr (Postfix) with ESMTP id 55300B8942; Fri, 17 Jun 2011 14:42:36 +0200 (CEST)
Message-ID: <4DFB4BBF.9080701@enst.fr>
Date: Fri, 17 Jun 2011 14:42:39 +0200
From: Dario Rossi 
User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.9.2.12) Gecko/20101027 Lightning/1.0b2 Thunderbird/3.1.6
MIME-Version: 1.0
To: ledbat@ietf.org
Content-Type: multipart/alternative; boundary="------------090908090608010207000506"
Cc: Claudio Testa 
Subject: [ledbat] Impact of Ledbat on BitTorrent completion time
X-BeenThere: ledbat@ietf.org
X-Mailman-Version: 2.1.12
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, 17 Jun 2011 12:42:39 -0000

This is a multi-part message in MIME format.
--------------090908090608010207000506
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 8bit

Dear all,

we want to share on the list some recent results (though not necessarily 
useful to finalize the draft, hence in a separate mail)

we have been doing some ns2 simulation on  swarm scenarios, where peers 
implementing the BitTorrent protocol are running Ledbat (or TCP) 
congestion control, focusing on the completion time of individual peers 
-- instead of fairness, for once ;)

we used the ns2 BitTorrent implementation provided in [1] and our own 
ns2 Ledbat implementation (which is not uptodate with the latest draft 
specification), emulating reasonable settings of the 
bt.transp_disposition flag (i.e., peer accept both incoming TCP and 
Ledbat for downlink, but only use TCP xor Ledbat in uplink)

results of our investigation are available in [2], shortly:
*  no difference can be seen in homogeneous swarm (i.e., all peers run 
TCP,  or all peers run Ledbat)
*  in heterogeneous swarm (i.e., half TCP, half Ledbat), peers running 
Ledbat in their uplink have a shorter completion time.
    We argue  this to be due to a shorter queuing delay in the Ledbat 
case w.r.t TCP, so that signaling of Ledbat peers is
    faster and they can opportunistically "steal" download slots (by 
hitting earlier the  request queue of other peers)  to
    self-congested peers using TCP in uplink.

We hope these findings are of interest for the wg;  if you have any 
comment, or are aware of similar studies, please do not hesitate to 
share them on the list

Best regards,
D.


[1] K. Eger, T. Hoßfeld, A. Binzenhofer, and G. Kunzmann,
"Efficient simulation of large-scale p2p networks: packet-level vs. 
flow-level simulations,"
in ACM UPGRADE-CN, Monterey, CA, Jun 2007.

[2] C. Testa and D. Rossi,
*The impact of uTP on BitTorrent completion time* 
 .
In /IEEE Peer to Peer (P2P'11)/, Kyoto, Japan, September 2011.





-- 
  Oo    Associate Professor
   >     TELECOM ParisTech
  ~     (formerly ENST)

mail:  dario.rossi@enst.fr
phone: +33.1.4581.7563
fax:   +33.1.4581.7158
web:   http://www.enst.fr/~drossi


--------------090908090608010207000506
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit



  

    
  
  
    Dear all,

    

    we want to share on the list some recent results (though not
    necessarily useful to finalize the draft, hence in a separate mail)

    

    we have been doing some ns2 simulation on  swarm scenarios, where
    peers implementing the BitTorrent protocol are running Ledbat (or
    TCP) congestion control, focusing on the completion time of
    individual peers -- instead of fairness, for once ;)

    

    we used the ns2 BitTorrent implementation provided in [1] and our
    own ns2 Ledbat implementation (which is not uptodate with the latest
    draft specification), emulating reasonable settings of the
    bt.transp_disposition flag (i.e., peer accept both incoming TCP and
    Ledbat for downlink, but only use TCP xor Ledbat in uplink)

    

    results of our investigation are available in [2], shortly:

    *  no difference can be seen in homogeneous swarm (i.e., all peers
    run TCP,  or all peers run Ledbat)

    *  in heterogeneous swarm (i.e., half TCP, half Ledbat), peers
    running Ledbat in their uplink have a shorter completion time.

       We argue  this to be due to a shorter queuing delay in the Ledbat
    case w.r.t TCP, so that signaling of Ledbat peers is 

       faster and they can opportunistically "steal" download slots (by
    hitting earlier the  request queue of other peers)  to

       self-congested peers using TCP in uplink.

    

    We hope these findings are of interest for the wg;  if you have any
    comment, or are aware of similar studies, please do not hesitate to
    share them on the list 

    

    Best regards, 

    D.

    

    

    [1] K. Eger, T. Hoßfeld, A. Binzenhofer, and G. Kunzmann, 

    “Efficient simulation of large-scale p2p networks: packet-level vs.
    flow-level simulations,” 

    in ACM UPGRADE-CN, Monterey, CA, Jun 2007.

    

    [2] C. Testa and D. Rossi, 

    The impact of uTP on BitTorrent completion
        time . 

    In IEEE Peer to Peer (P2P'11), Kyoto, Japan, September
    2011.

    

    




-- 
 Oo    Associate Professor
  >    TELECOM ParisTech
 ~     (formerly ENST)

mail:  dario.rossi@enst.fr
phone: +33.1.4581.7563
fax:   +33.1.4581.7158
web:   http://www.enst.fr/~drossi


  


--------------090908090608010207000506--

From mirja.kuehlewind@ikr.uni-stuttgart.de  Sat Jun 18 01:29:01 2011
Return-Path: 
X-Original-To: ledbat@ietfa.amsl.com
Delivered-To: ledbat@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E816111E80A1 for ; Sat, 18 Jun 2011 01:29:01 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.155
X-Spam-Level: 
X-Spam-Status: No, score=-2.155 tagged_above=-999 required=5 tests=[AWL=0.094,  BAYES_00=-2.599, HELO_EQ_DE=0.35]
Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 4INuUPQn3P6L for ; Sat, 18 Jun 2011 01:29:01 -0700 (PDT)
Received: from mailsrv.ikr.uni-stuttgart.de (mailsrv.ikr.uni-stuttgart.de [129.69.170.2]) by ietfa.amsl.com (Postfix) with ESMTP id A35A711E8082 for ; Sat, 18 Jun 2011 01:28:59 -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 B0EC1633B1; Sat, 18 Jun 2011 10:28:57 +0200 (CEST)
Received: from vpn-2-cl177 (vpn-2-cl177 [10.41.21.177]) by netsrv1.ikr.uni-stuttgart.de (Postfix) with ESMTP id 87BF659A8A; Sat, 18 Jun 2011 10:28:57 +0200 (CEST)
From: Mirja Kuehlewind 
Organization: University of Stuttgart (Germany), IKR
To: Lisong Xu 
Date: Sat, 18 Jun 2011 10:28:56 +0200
User-Agent: KMail/1.9.10 (enterprise35 0.20101217.1207316)
References: <94D3019D-33B6-4205-8B65-02923DBCA2DE@ifi.uio.no> <201106171133.09177.mirja.kuehlewind@ikr.uni-stuttgart.de> <4DFBF553.4000103@cse.unl.edu>
In-Reply-To: <4DFBF553.4000103@cse.unl.edu>
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: <201106181028.56604.mirja.kuehlewind@ikr.uni-stuttgart.de>
Cc: ledbat@ietf.org, iccrg@cs.ucl.ac.uk
Subject: Re: [ledbat] [Iccrg] Looking for reviewer for draft-ietf-ledbat-congestion-06
X-BeenThere: ledbat@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Mailing list of the LEDBAT WG 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Sat, 18 Jun 2011 08:29:02 -0000

Hi Lisong,

> A scientific paper is meant for a researcher, but an RFC is for a
> programmer who wants to implement the protocol. This is why I want to
> specify the data type of acknowledgement.delay (possible others too).
Other than many RFCs this document is NOT specifying a protocol. It 'only'=
=20
documents the algorithm. There is anyway some work for the implementor  to=
=20
transfer the algorithm based on the used framing protocol and programming=20
language. E.g. if you want to implement LEDBAT on a small low-energy device=
=20
with limited memory and you only have unsigned short, you have to scope wit=
h=20
it...
And even protocol specifications, which are even more implementor guides, t=
ry=20
to specify a protocol deliberately without any implementation specify=20
assumptions such that a protocol can be implemented in many different=20
devices.
We are actually still thinking about a document to define LEDBAT for TCP=20
(which would be more like a implementation guide then).

>
> OK, here is an example to illustrate the problem of unsigned variables.
>
> assume all variables are unsigned short.
>
> at some time (low queueing delay):
>    local_timestamp =3D 3, and remote_timestamp =3D 5
>    then acknowledgement.delay =3D 65534
>    then base_delay =3D 65534
>
> at some time later (high queueing delay):
>    local_timestamp =3D 7, and remote_timestamp =3D 6
>    then acknowledgement.delay =3D 1
>    then base_delay =3D 1
>    then queueing_delay =3D 0
In this example there is a very strong clock skew. You would need some cloc=
k=20
correction, otherwise the result are incorrect anyway.

Mirja

>
> Thanks
> Lisong
>
> On 6/17/2011 2:33 AM, Mirja Kuehlewind wrote:
> > Hi Lisong,
> >
> > you are right, if it is an unsigned this might cause errors but its
> > actually not a problem. If local_timestamp-remote_timestamp is negative
> > but acknowledgement.delay is signed you will get a wrong result (but th=
is
> > doesn't matter as this delay does not show a real delay value anyway) b=
ut
> > you will get a result because there simply will be an overflow.
> > If you now calculate queuing_delay =3D current_delay - base_delay. Also
> > this error will cancel out and you get an valid result.
> >
> > Anyway, its in the responsibility of the implementor to get the type and
> > range right; its not part of the algorithm itself, from my point of vie=
w.
> > Do you have a different opinion here?
> >
> > Mirja
> >
> > On Thursday 16 June 2011 18:36:24 Lisong Xu wrote:
> >> Mirja,
> >>
> >> Thanks for your reply. I have only one question now.
> >>
> >> "it doesn't matter if the delay is positive or negative because its
> >> canceled out in the calculation of the queuing delay and even an
> >> overflow would work here."
> >>
> >> You are right that it does not matter whether acknowledgement.delay is
> >> positive or negative. But variable acknowledgement.delay MUST be a
> >> signed int. If it is implemented as an unsigned int, then sometimes
> >> there will be a problem.
> >>
> >> Thanks
> >> Lisong
> >>
> >> On 6/15/2011 6:07 AM, Mirja K=FChlewind wrote:
> >>> Hi Lisong
> >>>
> >>> thank you very much for your review! Please see comments inline.
> >>>
> >>> Mirja
> >>>
> >>> On Sunday 12 June 2011 08:53:10 Lisong Xu wrote:
> >>>> Hi Michael,
> >>>>
> >>>> Below are my comments after reading the draft.
> >>>> Thanks
> >>>> Lisong
> >>>>
> >>>>
> >>>> **** Section 3.1 ****
> >>>> First sentence: "a loss occurs [RFC5681], which, in the absence of a=
ny
> >>>> Active Queue Management (AQM) in the network, occurs only when the
> >>>> queue at the bottleneck link on the end-to-end path overflows "
> >>>>
> >>>> Since a loss may occur due to link errors, such as fiber errors and
> >>>> wireless errors, we may change the first sentence to
> >>>> "... (AQM) and link errors in the network,...."
> >>>
> >>> Done.
> >>>
> >>>> **** Section 3.3 ****
> >>>> The data type of each variable is not specified. Since some variables
> >>>> must be signed variables, it is important to specify the type of each
> >>>> variable in order to correctly implement the algorithm.
> >>>>
> >>>> For example, tcp_time_stamp is an unsigned int, so local_timestamp a=
nd
> >>>> remote_timestamp are also unsigned int.  But variable
> >>>> acknowledgement.delay should be a signed int, since
> >>>> local_timestamp-remote_timestamp may be negative.
> >>>
> >>> I don't want to specify any data type here because that's only pseudo
> >>> code of the algorithm and the range and resolution of a variable are
> >>> implementation specific and might depend on the framing protocol used
> >>> and of course as well on the programming language.
> >>>
> >>> Your example is a quite special case as one would assume that delay is
> >>> always positive but you might get negative values because of the clock
> >>> offset. Issues like clock offset and skew, which can come up in a real
> >>> system, are not regarded as part of the algorithm. Anyway there is so=
me
> >>> discussion in the appendix. Moreover, in fact in this special example
> >>> it doesn't matter if the delay is positive or negative because its
> >>> canceled out in the calculation of the queuing delay and even an
> >>> overflow would work here.
> >>>
> >>> The only case where it is important that a value can/must get negative
> >>> is the off_target and this is mentioned explicit in 3.4.1.
> >>>
> >>>> **** Section 3.4.2 ****
> >>>> "a LEDBAT sender stores BASE_HISTORY+1 separate minima- one each for
> >>>> the last BASE_HISTORY minutes, and one for the running current
> >>>> minute."
> >>>>
> >>>> But the update_current_delay(delay) code maintains only BASE_HISTORY
> >>>> minima. So the above sentence should be changed to
> >>>> "a LEDBAT sender stores BASE_HISTORY separate minima- one each for t=
he
> >>>> last BASE_HISTORY-1 minutes, and one for the running current minute."
> >>>
> >>> Thanks. You are right! Done.
> >>>
> >>>> **** Section 3.5 ****
> >>>> "we recommend that the sender SHOULD use at least 4 samples in each
> >>>> RTT. Thus, CURRENT_FILTER SHOULD be at least 4, and limited such that
> >>>> no samples in list are older than an RTT in the
> >>>> past."
> >>>>
> >>>> But what if cwnd is less than 4? In this case, there are less than 4
> >>>> samples in each RTT.
> >>>
> >>> That's why there is a SHOULD and not a MUST. If you have less samples,
> >>> you can, of course, only use whatever you get. But the results might =
be
> >>> very noisy and if you permanently have less then 4 samples, LEDBAT
> >>> might not work correctly (because of noise in real systems).
> >>>
> >>> Should we make this more explicit?
> >>>
> >>>> **** General *****
> >>>>
> >>>> It is not clear what the relation between cwnd and flightsize is. Is
> >>>> flightsize always the same as cwnd, or could be less than cwnd? When
> >>>> is flightsize less than cwnd?
> >>>
> >>> flightsize can be less if your transfer is application-limited (and
> >>> ALLOWED_INCREASE is large enough). Thus you don't have enough data to
> >>> fill the cwnd.
> >>>
> >>> In the code you find
> >>> " on acknowledgment:
> >>>       # flightsize is the amount of data outstanding before this ack
> >>>       #    was received and is updated later by update_flightsize();
> >>>       # bytes_newly_acked is the number of bytes that this ack
> >>>       #    newly acknowledges, and it MAY be set to MSS; and
> >>>       # cwnd is in bytes."
> >>>
> >>> I've added the following to 'on initialization:' (eventhough you find
> >>> the same explanation in 3.2.)
> >>> "   # cwnd is the amount of data that is allowed to send in one RTT a=
nd
> >>>       # is defined in bytes."
> >>>
> >>> Does this help?
> >>>
> >>>> On 6/5/2011 12:38 AM, Michael Welzl wrote:
> >>>>> Hi,
> >>>>>
> >>>>> We're urgently looking for a volunteer to review
> >>>>> draft-ietf-ledbat-congestion-06:
> >>>>> http://tools.ietf.org/html/draft-ietf-ledbat-congestion-06
> >>>>> which is currently in Last Call, ending in less than two weeks (15
> >>>>> June).
> >>>>>
> >>>>> If anyone here is willing to do a review, please drop Murari and me=
 a
> >>>>> note ASAP!
> >>>>>
> >>>>> Thanks,
> >>>>> Michael
> >>>>>
> >>>>>
> >>>>> _______________________________________________
> >>>>> Iccrg mailing list
> >>>>> Iccrg@cs.ucl.ac.uk
> >>>>> http://oakham.cs.ucl.ac.uk/mailman/listinfo/iccrg



=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 Rolf.Winter@neclab.eu  Sat Jun 25 11:34:56 2011
Return-Path: 
X-Original-To: ledbat@ietfa.amsl.com
Delivered-To: ledbat@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2B7D311E80A2 for ; Sat, 25 Jun 2011 11:34:56 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -102.123
X-Spam-Level: 
X-Spam-Status: No, score=-102.123 tagged_above=-999 required=5 tests=[AWL=0.126, BAYES_00=-2.599, HELO_EQ_DE=0.35, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 3qebFTVNYW5O for ; Sat, 25 Jun 2011 11:34:55 -0700 (PDT)
Received: from smtp0.netlab.nec.de (smtp0.netlab.nec.de [195.37.70.40]) by ietfa.amsl.com (Postfix) with ESMTP id 0A1D211E809B for ; Sat, 25 Jun 2011 11:34:55 -0700 (PDT)
Received: from localhost (localhost.localdomain [127.0.0.1]) by smtp0.netlab.nec.de (Postfix) with ESMTP id 2414028000227 for ; Sat, 25 Jun 2011 20:34:54 +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 2TGKhP++7tSI for ; Sat, 25 Jun 2011 20:34:54 +0200 (CEST)
Received: from ENCELADUS.office.hd (ENCELADUS.office.hd [192.168.24.52]) by smtp0.netlab.nec.de (Postfix) with ESMTP id 09493280001AA for ; Sat, 25 Jun 2011 20:34:49 +0200 (CEST)
Received: from Polydeuces.office.hd ([169.254.3.115]) by ENCELADUS.office.hd ([192.168.24.52]) with mapi id 14.01.0270.001; Sat, 25 Jun 2011 20:43:12 +0200
From: Rolf Winter 
To: "ledbat@ietf.org" 
Thread-Topic: Nomcom 2011-2012: Second Call for Volunteers 
Thread-Index: AQHMMpviRkAFCfqMK0SQtz3lhLe/0ZTOaZJA
Date: Sat, 25 Jun 2011 18:43:11 +0000
Message-ID: <791AD3077F94194BB2BDD13565B6295D13B68F5C@Polydeuces.office.hd>
Accept-Language: en-US, de-DE
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
x-originating-ip: [10.7.0.204]
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
Subject: [ledbat] FW: Nomcom 2011-2012: Second Call for Volunteers
X-BeenThere: ledbat@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Mailing list of the LEDBAT WG 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Sat, 25 Jun 2011 18:34:56 -0000

Please consider volunteering. I did it myself last year and it has been a v=
ery valuable experience.

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


> -----Original Message-----
> From: ietf-announce-bounces@ietf.org [mailto:ietf-announce-
> bounces@ietf.org] On Behalf Of NomCom Chair
> Sent: Freitag, 24. Juni 2011 20:14
> To: IETF Announcement list
> Subject: Nomcom 2011-2012: Second Call for Volunteers
>=20
> This is the Second call for Volunteers for the 2011-12 Nomcom.  We are
> just about halfway through the volunteer period so if you are
> considering
> volunteering, please do so very soon.
>=20
> We have had a very good response to the initial call for volunteers and
> I am pleased to report that we have 50 volunteers thus far whose
> qualifications have been confirmed by the secretariat. I have notified
> each of these volunteers by email.
>=20
> However, we would like to have many more volunteers. The more
> volunteers,
> the better chance we have of choosing a random yet representative cross
> section of the IETF population. You have until 11:59 pm EDT July 10,
> 2011
> to volunteer for Nomcom but it would be much better if you can
> volunteer
> as early as possible.
>=20
> If you volunteered before 21:00 EDT on June 21 to serve as a voting
> member
> and have not received a confirmation email from me, please re-submit
> and
> bring to my attention right away!
>=20
> Details about the process for volunteering for the Nomcom and the list
> of open positions for which the nominating committee is responsible are
> summarized in the initial announcement:
>=20
> https://datatracker.ietf.org/ann/nomcom/2938/
>=20
> The 50 volunteers who have thus far been qualified by the secretariat
> are:
>=20
> Alia Atlas , Juniper Networks
> Lixia Zhang , UCLA
> Wassim Haddad  , Ericsson
> Glen Zorn , Network Zen
> Richard Barnes , BBN Technologies
> Stephen Kent , BBN Technologies
> Scott Mansfield , Ericsson
> Tina TSOU , FutureWei Technologies
> Fernando Gont , UTN/FRH
> Karen Seo , BBN Technologies
> Jie Dong , Huawei Technologies
> Mach Chen , Huawei Technologies Co.
> Sheng Jiang , Huawei Technologies Co. Ltd.
> Dimitri Papadimitriou , Alcatel-Lucent
> Thomas D. Nadeau , CA Technologies
> David Meyer , Cisco Systems/University of Oregon
> Wesley George , Time Warner Cable
> Cullen Jennings , Cisco
> Stephen Hanna , Juniper Networks
> Stephan Wenger , Bidyo
> Keyur Patel , Cisco Systems
> Michael Hamilton , BreakingPoint Systems
> Behcet Sarikaya , Huawei USA
> Mark Townsley , Cisco Systems
> Fred Baker , Cisco Systems
> Brian Trammell , ETH Zurich
> Sam Hartman , Painless Security
> Chris Griffiths , Comcast
> George Michaelson , APNIC
> Jiankang Yao , CNNIC
> Sohel Khan , Comcast
> Dacheng Zhang , Huawei
> Lianshu Zheng , Huawei Technologies
> Hui Deng , China Mobile
> Gang Chen , China Mobile
> Mirja Kuhlewind , University of Stuttgart
> John E Drake , Juniper Networks
> Matt Lepinski , BBN Technologies
> Subir Das , Telcordia Technologies Inc
> Yi Zhao , Huawei
> John Scudder , Juniper Networks
> Christer Holmberg , LM Ericsson
> Teemu Savolainen , Nokia
> Samita Chakrabarti , Ericsson
> Jaap Akkerhuis , NLnet labs
> Jason Weil , Time Warner Cable
> Randy Bush , Internet Initiative Japan
> Christian Schmidt , Nokia Siemens Networks
> Sean Shen , CNNIC
> Lou Berger , LabN Consulting
>=20
> The primary activity for this nomcom will begin during IETF-81 in
> Quebec City and should be completed by January 2012. The nomcom will
> be collecting requirements from the community, as well as talking to
> candidates and to community members about candidates. There will be
> regularly scheduled conference calls to ensure progress. Thus, being a
> nomcom member does require some time commitment.
>=20
> Please volunteer by sending an email to me before
> 11:59 pm EDT July 10, 2011 as follows:
>=20
> To: suresh.krishnan@ericsson.com
> Subject: Nomcom 2011-12 Volunteer
>=20
> Please include the following information in the body of the mail:
>=20
> Full Name:  // As you enter in the IETF Registration Form,
>             // First/Given name followed by Last/Family Name
>=20
> Current Primary Affiliation: // typically what goes in the Company
>                              // field in the IETF Registration Form
>=20
> Email Address(es): // all email addresses used to Register for the
>                    // past 5 IETF meetings
> 		   // Please designate a Preferred email address for
>                    // contact if there is more than one email address
>=20
> Telephone number:  // With country code (for confirmation if selected)
>=20
> Please expect an email response from me within 3 business days stating
> whether or not you are qualified.  If you do not receive a response in
> this timeframe, please re-send your email with the tag "RESEND:" added
> to the subject line.
>=20
> If you are not yet sure you would like to volunteer, please consider
> that Nomcom members play a very important role in shaping the
> leadership of the IETF.  Ensuring the leadership of the IETF is fair
> and balanced and comprised of those who can lead the IETF in the right
> direction is an important responsibility that rests on the IETF
> participants at large. Volunteering for the Nomcom is a good way of
> contributing in that direction.
>=20
> I will be publishing a more detailed target timetable, as well as
> details of the randomness seeds to be used for the RFC 3797 selection
> process within the next few days.
>=20
> Thank you in advance for your participation.
>=20
> Suresh Krishnan
> Nomcom Chair 2011-2012
> Email: nomcom-chair@ietf.org, suresh.krishnan@ericsson.com
>=20
> _______________________________________________
> IETF-Announce mailing list
> IETF-Announce@ietf.org
> https://www.ietf.org/mailman/listinfo/ietf-announce

From mirja.kuehlewind@ikr.uni-stuttgart.de  Tue Jun 28 11:07:45 2011
Return-Path: 
X-Original-To: ledbat@ietfa.amsl.com
Delivered-To: ledbat@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D292911E8128 for ; Tue, 28 Jun 2011 11:07:45 -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.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id CEQvNXJ8aSvD for ; Tue, 28 Jun 2011 11:07:45 -0700 (PDT)
Received: from mailsrv.ikr.uni-stuttgart.de (mailsrv.ikr.uni-stuttgart.de [129.69.170.2]) by ietfa.amsl.com (Postfix) with ESMTP id 10BD811E8131 for ; Tue, 28 Jun 2011 11:07:44 -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 46839633B1; Tue, 28 Jun 2011 20:07:42 +0200 (CEST)
Received: from vpn-2-cl177 (vpn-2-cl177 [10.41.21.177]) by netsrv1.ikr.uni-stuttgart.de (Postfix) with ESMTP id 3498F59A8A; Tue, 28 Jun 2011 20:07:41 +0200 (CEST)
From: Mirja Kuehlewind 
Organization: University of Stuttgart (Germany), IKR
To: Dario Rossi 
Date: Tue, 28 Jun 2011 20:07:40 +0200
User-Agent: KMail/1.9.10 (enterprise35 0.20101217.1207316)
References: <791AD3077F94194BB2BDD13565B6295D05E6DF22@PALLENE.office.hd> <201106151821.15361.mirja.kuehlewind@ikr.uni-stuttgart.de> <4DFB223E.3000303@enst.fr>
In-Reply-To: <4DFB223E.3000303@enst.fr>
X-KMail-QuotePrefix: > 
MIME-Version: 1.0
Content-Type: Text/Plain; charset="iso-8859-1"
Content-Transfer-Encoding: 7bit
Content-Disposition: inline
Message-Id: <201106282007.40987.mirja.kuehlewind@ikr.uni-stuttgart.de>
Cc: ledbat@ietf.org
Subject: Re: [ledbat] 2 week last call for draft-ietf-ledbat-congestion-06
X-BeenThere: ledbat@ietf.org
X-Mailman-Version: 2.1.12
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, 28 Jun 2011 18:07:45 -0000

Hi Dario,

sorry for the late response.  First of all thanks for your feedback. I'm not 
sure if I exactly got your point. I believe our statement about randomness is 
still not wrong because it's very general. Of course the idea is that the 
queue has to get empty from time to time (to measure the real base delay). 
Maybe we can state that more explicit?

But back to your result. Can you define what you exactly mean by 'backlogged' 
flows? I'm not sure if I fully got you right here...

Mirja


> Our testbed experiments with the BitTorrent libUTP implementation shown
> that latecomer unfairness arises also in the real world, in case of
> /backlogged/ flows ( see Fig1, pag2 in http://arxiv.org/abs/1010.5623 )
>
> Latecomer unfairness may instead vanish in case of /non-backlogged/
> connections (see Fig6 pag 9 in http://arxiv.org/abs/1010.5623 ; only ns2
> results here though)
>
> While I understand (and agree) that fairness may not be the main aspect
> in ledbat, given the above observations and [1], it seems to me that
> sec 5.3 of the current version of the draft wrongly states that fairness
> is reinstated simply by
>
> 	randomness in the inter-packet transmission times exist,
>
> as [1] shows this is not the case  (and though there is real-world noise
> in the testbed of Fig1, pag2 in http://arxiv.org/abs/1010.5623 , this is
> apparently not enough either...)
>
> In other words, real-world noise is not enough to break latecomer
> unfairness, but the use of non-backlogged traffic sources can: notice
> that non backlogged sources assist in emptying the queues, while a
> simple jittering cannot (hence, the explanation in sec 5.3 is misleading?).
>
>
> [1] G. Carofiglio, L. Muscariello, D. Rossi and S. Valenti, *The quest
> for LEDBAT fairness*
>  . In /IEEE
> Globecom'10/, Miami, FL, USA, December 6-10 2010.
>
>
> Best,
> D.
>

From mirja.kuehlewind@ikr.uni-stuttgart.de  Tue Jun 28 11:25:57 2011
Return-Path: 
X-Original-To: ledbat@ietfa.amsl.com
Delivered-To: ledbat@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6634311E8103 for ; Tue, 28 Jun 2011 11:25:57 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.136
X-Spam-Level: 
X-Spam-Status: No, score=-2.136 tagged_above=-999 required=5 tests=[AWL=-0.114, BAYES_00=-2.599, HELO_EQ_DE=0.35, SARE_SUB_OBFU_Q1=0.227]
Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 5Fgm1Mt7uzgr for ; Tue, 28 Jun 2011 11:25:57 -0700 (PDT)
Received: from mailsrv.ikr.uni-stuttgart.de (mailsrv.ikr.uni-stuttgart.de [129.69.170.2]) by ietfa.amsl.com (Postfix) with ESMTP id DB99F11E80EE for ; Tue, 28 Jun 2011 11:25:56 -0700 (PDT)
Received: from netsrv1.ikr.uni-stuttgart.de (netsrv1-c [10.11.12.12]) by mailsrv.ikr.uni-stuttgart.de (Postfix) with ESMTP id 01D48633B1; Tue, 28 Jun 2011 20:25:56 +0200 (CEST)
Received: from vpn-2-cl177 (vpn-2-cl177 [10.41.21.177]) by netsrv1.ikr.uni-stuttgart.de (Postfix) with ESMTP id E63A559A8A; Tue, 28 Jun 2011 20:25:55 +0200 (CEST)
From: Mirja Kuehlewind 
Organization: University of Stuttgart (Germany), IKR
To: gorry@erg.abdn.ac.uk
Date: Tue, 28 Jun 2011 20:25:54 +0200
User-Agent: KMail/1.9.10 (enterprise35 0.20101217.1207316)
References: <791AD3077F94194BB2BDD13565B6295D05E6DF22@PALLENE.office.hd> <4DF90477.4080906@mti-systems.com> <4DFA4101.9000306@erg.abdn.ac.uk>
In-Reply-To: <4DFA4101.9000306@erg.abdn.ac.uk>
X-KMail-QuotePrefix: > 
MIME-Version: 1.0
Content-Type: Text/Plain; charset="iso-8859-1"
Content-Transfer-Encoding: 7bit
Content-Disposition: inline
Message-Id: <201106282025.54990.mirja.kuehlewind@ikr.uni-stuttgart.de>
Cc: ledbat@ietf.org
Subject: Re: [ledbat] ECN/AQM, was:  2 week last call for draft-ietf-ledbat-congestion-06
X-BeenThere: ledbat@ietf.org
X-Mailman-Version: 2.1.12
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, 28 Jun 2011 18:25:57 -0000

Hi Gorry.

> Mirja seems to raise a valid point...
>
> I think it would be extremely good to encourage the use of ECN for such
> applications, by saying explicitly that ECN could offer benefit when the
> infrastructure supports this. To allow this, a LEDBAT session needs to
> send packets with ECT(x), and then MUST include appropriate control
> functions.
I don't think we should recommend for LEBDAT to be ECN-capable because the 
selection of a congestion control mechanism is, from my point of view, not 
related to the question to support ECN or not.
Moreover, ECN is an TCP/IP mechanism and LEDBAT is specified independent of 
any framing protocol (e.g. BitTorrent uses UDP).
And when LEDBAT is working correctly, there shouldn't occur any ECN marking 
(and of course no losses neither) as LEDBAT will reduce it's sending rate to 
basically zero before any queues overflow.

> - whatever, I think reception of an ECN mark MUST cause the
> corresponding sender to perform a congestion response - i.e. can not be
> ignored.
My only question was: Should we mention _explicit_ that LEDBAT has to halve 
its window on an ECN mark or is it enough if RCF3168 is defining this 
_implicit_ by saying (every) congestion control should react in the same way 
to ECN marks as it would to loss.
In both cases a LEDBAT flow has to halve this window on an ECN mark (as on 
loss). 

So in general, I'm not sure if we should talk about an TCP/IP mechanism (ECN) 
in this draft when we only specify the algorithm and not talking about 
anything TCP specific...?

Mirja

From arjuna.sathiaseelan@gmail.com  Tue Jun 28 12:28:22 2011
Return-Path: 
X-Original-To: ledbat@ietfa.amsl.com
Delivered-To: ledbat@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4F3CA11E8199 for ; Tue, 28 Jun 2011 12:28:22 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.75
X-Spam-Level: 
X-Spam-Status: No, score=-2.75 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_LOW=-1, SARE_SUB_OBFU_Q1=0.227]
Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 5717IY5z54Xi for ; Tue, 28 Jun 2011 12:28:17 -0700 (PDT)
Received: from mail-qy0-f179.google.com (mail-qy0-f179.google.com [209.85.216.179]) by ietfa.amsl.com (Postfix) with ESMTP id 3075711E8195 for ; Tue, 28 Jun 2011 12:28:17 -0700 (PDT)
Received: by qyk29 with SMTP id 29so387159qyk.10 for ; Tue, 28 Jun 2011 12:28:12 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:cc:content-type; bh=AYarfiAonZiabYKO/EwFuqbp7JTEVLjKXkKdvAID9Rc=; b=B/zd3xJY4hKP36anpGOxVJZ1ypThmCdeBM+kXALjZP+VyHkeeXGYj7H3cVHgirsQhr XiY7DBUKa3HLNpIab3jGy4/8g76SVcNpwG14J5rahfgHzcn/aBpJk1XX0WLG1VHQQJLJ OpkPH+e+XXCrExOBUXmDdgdA6ElssEIY+uodI=
MIME-Version: 1.0
Received: by 10.224.27.129 with SMTP id i1mr3738346qac.312.1309289292249; Tue, 28 Jun 2011 12:28:12 -0700 (PDT)
Sender: arjuna.sathiaseelan@gmail.com
Received: by 10.229.87.8 with HTTP; Tue, 28 Jun 2011 12:28:12 -0700 (PDT)
In-Reply-To: <201106282025.54990.mirja.kuehlewind@ikr.uni-stuttgart.de>
References: <791AD3077F94194BB2BDD13565B6295D05E6DF22@PALLENE.office.hd> <4DF90477.4080906@mti-systems.com> <4DFA4101.9000306@erg.abdn.ac.uk> <201106282025.54990.mirja.kuehlewind@ikr.uni-stuttgart.de>
Date: Tue, 28 Jun 2011 20:28:12 +0100
X-Google-Sender-Auth: 8GxKwabIpDyEGXolt3ov5FCCPMg
Message-ID: 
From: Arjuna Sathiaseelan 
To: Mirja Kuehlewind 
Content-Type: text/plain; charset=ISO-8859-1
Cc: ledbat@ietf.org
Subject: Re: [ledbat] ECN/AQM, was: 2 week last call for draft-ietf-ledbat-congestion-06
X-BeenThere: ledbat@ietf.org
X-Mailman-Version: 2.1.12
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, 28 Jun 2011 19:28:22 -0000

Dear Mirja,
  Sorry- I am a newcomer to LEDBAT - and I am trying to understand
this. So when you say LEDBAT reduces the sending rate to zero - does
that mean LEDBAT doesnt have the notion of timers/timeouts? So if
LEDBAT knows that the queues are being utilised could it wait for any
amount of time without sending data?

> And when LEDBAT is working correctly, there shouldn't occur any ECN marking
> (and of course no losses neither) as LEDBAT will reduce it's sending rate to
> basically zero before any queues overflow.

Regards
Arjuna

From wwwrun@rfc-editor.org  Tue Jun 28 15:51:38 2011
Return-Path: 
X-Original-To: ledbat@ietfa.amsl.com
Delivered-To: ledbat@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5347411E8205; Tue, 28 Jun 2011 15:51:38 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -102.389
X-Spam-Level: 
X-Spam-Status: No, score=-102.389 tagged_above=-999 required=5 tests=[AWL=0.211, BAYES_00=-2.599, NO_RELAYS=-0.001, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Stchv6z3jnQc; Tue, 28 Jun 2011 15:51:37 -0700 (PDT)
Received: from rfc-editor.org (rfc-editor.org [IPv6:2001:1890:1112:1::2f]) by ietfa.amsl.com (Postfix) with ESMTP id B8CDF11E81BB; Tue, 28 Jun 2011 15:51:37 -0700 (PDT)
Received: by rfc-editor.org (Postfix, from userid 30) id 0CB8298C55B; Tue, 28 Jun 2011 15:37:27 -0700 (PDT)
To: ietf-announce@ietf.org, rfc-dist@rfc-editor.org
From: rfc-editor@rfc-editor.org
Message-Id: <20110628223727.0CB8298C55B@rfc-editor.org>
Date: Tue, 28 Jun 2011 15:37:27 -0700 (PDT)
Cc: ledbat@ietf.org, rfc-editor@rfc-editor.org
Subject: [ledbat] RFC 6297 on A Survey of Lower-than-Best-Effort Transport Protocols
X-BeenThere: ledbat@ietf.org
X-Mailman-Version: 2.1.12
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, 28 Jun 2011 22:51:38 -0000

A new Request for Comments is now available in online RFC libraries.

        
        RFC 6297

        Title:      A Survey of Lower-than-Best-Effort Transport 
                    Protocols 
        Author:     M. Welzl, D. Ros
        Status:     Informational
        Stream:     IETF
        Date:       June 2011
        Mailbox:    michawe@ifi.uio.no, 
                    david.ros@telecom-bretagne.eu
        Pages:      18
        Characters: 46532
        Updates/Obsoletes/SeeAlso:   None

        I-D Tag:    draft-ietf-ledbat-survey-07.txt

        URL:        http://www.rfc-editor.org/rfc/rfc6297.txt

This document provides a survey of transport protocols that are
designed to have a smaller bandwidth and/or delay impact on standard
TCP than standard TCP itself when they share a bottleneck with it.
Such protocols could be used for delay-insensitive "background"
traffic, as they provide what is sometimes called a "less than" (or
"lower than") best-effort service.  This document is not an 
Internet Standards Track specification; it is published 
for informational purposes.

This document is a product of the Low Extra Delay Background Transport Working Group of the IETF.


INFORMATIONAL: This memo provides information for the Internet community.
It does not specify an Internet standard of any kind. Distribution of
this memo is unlimited.

This announcement is sent to the IETF-Announce and rfc-dist lists.
To subscribe or unsubscribe, see
  http://www.ietf.org/mailman/listinfo/ietf-announce
  http://mailman.rfc-editor.org/mailman/listinfo/rfc-dist

For searching the RFC series, see http://www.rfc-editor.org/rfcsearch.html.
For downloading RFCs, see http://www.rfc-editor.org/rfc.html.

Requests for special distribution should be addressed to either the
author of the RFC in question, or to rfc-editor@rfc-editor.org.  Unless
specifically noted otherwise on the RFC itself, all RFCs are for
unlimited distribution.


The RFC Editor Team
Association Management Solutions, LLC



From ingemar.s.johansson@ericsson.com  Tue Jun 28 22:30:20 2011
Return-Path: 
X-Original-To: ledbat@ietfa.amsl.com
Delivered-To: ledbat@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D1F209E8004 for ; Tue, 28 Jun 2011 22:30:20 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.299
X-Spam-Level: 
X-Spam-Status: No, score=-6.299 tagged_above=-999 required=5 tests=[AWL=-0.300, BAYES_00=-2.599, J_CHICKENPOX_56=0.6, RCVD_IN_DNSWL_MED=-4]
Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 4lacOEryq5pg for ; Tue, 28 Jun 2011 22:30:20 -0700 (PDT)
Received: from mailgw10.se.ericsson.net (mailgw10.se.ericsson.net [193.180.251.61]) by ietfa.amsl.com (Postfix) with ESMTP id D7C229E8018 for ; Tue, 28 Jun 2011 22:30:19 -0700 (PDT)
X-AuditID: c1b4fb3d-b7c17ae00000262e-36-4e0ab869e977
Received: from esessmw0184.eemea.ericsson.se (Unknown_Domain [153.88.253.124]) by mailgw10.se.ericsson.net (Symantec Mail Security) with SMTP id 9E.E4.09774.968BA0E4; Wed, 29 Jun 2011 07:30:18 +0200 (CEST)
Received: from ESESSCMS0366.eemea.ericsson.se ([169.254.1.23]) by esessmw0184.eemea.ericsson.se ([153.88.115.81]) with mapi; Wed, 29 Jun 2011 07:30:17 +0200
From: Ingemar Johansson S 
To: "ledbat@ietf.org" 
Date: Wed, 29 Jun 2011 07:30:13 +0200
Thread-Topic: ledbat Digest, Vol 30, Issue 10
Thread-Index: Acw1xgWYqwY8s29kTWme9/M35wrvfAAVNBUQ
Message-ID: 
References: 
In-Reply-To: 
Accept-Language: sv-SE, en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
acceptlanguage: sv-SE, en-US
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
X-Brightmail-Tracker: AAAAAA==
Subject: Re: [ledbat] ledbat Digest, Vol 30, Issue 10
X-BeenThere: ledbat@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Mailing list of the LEDBAT WG 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Wed, 29 Jun 2011 05:30:20 -0000

Hi

I believe it is OK to say that LEDBAT should work in a 3168-ish way to ECN =
marks. i.e in the same way that it reacts to loss and possibly just referen=
ce to RFC3168.

I don't fully agree with the sentence "there shouldn't occur any ECN markin=
g (and of course no losses neither) as LEDBAT will reduce it's sending rate=
 to basically zero before any queues overflow".=20
For certain wireless access it is possible to tune ECN marking algorithm su=
ch that they trigger just at the bend on the hockey stick. Means that packe=
ts are ECN-CE marked even though the delay+jitter is quite moderate.
Of course this is pretty much dependent on the design of the ECN marking bu=
t I wouldn't rule out that packets are "LEDBAT packets" are ECN marked.

Regards
Ingemar =20

>=20
> Hi Gorry.
>=20
> > Mirja seems to raise a valid point...
> >
> > I think it would be extremely good to encourage the use of ECN for=20
> > such applications, by saying explicitly that ECN could=20
> offer benefit=20
> > when the infrastructure supports this. To allow this, a=20
> LEDBAT session=20
> > needs to send packets with ECT(x), and then MUST include=20
> appropriate=20
> > control functions.
> I don't think we should recommend for LEBDAT to be=20
> ECN-capable because the selection of a congestion control=20
> mechanism is, from my point of view, not related to the=20
> question to support ECN or not.
> Moreover, ECN is an TCP/IP mechanism and LEDBAT is specified=20
> independent of any framing protocol (e.g. BitTorrent uses UDP).
> And when LEDBAT is working correctly, there shouldn't occur=20
> any ECN marking (and of course no losses neither) as LEDBAT=20
> will reduce it's sending rate to basically zero before any=20
> queues overflow.
>=20
> > - whatever, I think reception of an ECN mark MUST cause the=20
> > corresponding sender to perform a congestion response -=20
> i.e. can not=20
> > be ignored.
> My only question was: Should we mention _explicit_ that=20
> LEDBAT has to halve its window on an ECN mark or is it enough=20
> if RCF3168 is defining this _implicit_ by saying (every)=20
> congestion control should react in the same way to ECN marks=20
> as it would to loss.
> In both cases a LEDBAT flow has to halve this window on an=20
> ECN mark (as on loss).=20
>=20
> So in general, I'm not sure if we should talk about an TCP/IP=20
> mechanism (ECN) in this draft when we only specify the=20
> algorithm and not talking about anything TCP specific...?
>=20
> Mirja
>=20
>=20
> ------------------------------
>=20
> _______________________________________________
> ledbat mailing list
> ledbat@ietf.org
> https://www.ietf.org/mailman/listinfo/ledbat
>=20
>=20
> End of ledbat Digest, Vol 30, Issue 10
> **************************************
> =

From Rolf.Winter@neclab.eu  Tue Jun 28 23:57:19 2011
Return-Path: 
X-Original-To: ledbat@ietfa.amsl.com
Delivered-To: ledbat@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3EC189E8035 for ; Tue, 28 Jun 2011 23:57:19 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -102.063
X-Spam-Level: 
X-Spam-Status: No, score=-102.063 tagged_above=-999 required=5 tests=[AWL=0.186, BAYES_00=-2.599, HELO_EQ_DE=0.35, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id nzLI0srSFwZ4 for ; Tue, 28 Jun 2011 23:57:18 -0700 (PDT)
Received: from smtp0.netlab.nec.de (smtp0.netlab.nec.de [195.37.70.40]) by ietfa.amsl.com (Postfix) with ESMTP id 789A99E802D for ; Tue, 28 Jun 2011 23:57:18 -0700 (PDT)
Received: from localhost (localhost.localdomain [127.0.0.1]) by smtp0.netlab.nec.de (Postfix) with ESMTP id DB09E280001DB for ; Wed, 29 Jun 2011 08:57:17 +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 UEOBfh-MQgG2 for ; Wed, 29 Jun 2011 08:57:17 +0200 (CEST)
Received: from ENCELADUS.office.hd (ENCELADUS.office.hd [192.168.24.52]) by smtp0.netlab.nec.de (Postfix) with ESMTP id BCAC128000189 for ; Wed, 29 Jun 2011 08:57:12 +0200 (CEST)
Received: from PALLENE.office.hd ([169.254.1.100]) by ENCELADUS.office.hd ([192.168.24.52]) with mapi id 14.01.0270.001; Wed, 29 Jun 2011 08:57:12 +0200
From: Rolf Winter 
To: "ledbat@ietf.org" 
Thread-Topic: [ledbat] RFC 6297 on A Survey of Lower-than-Best-Effort Transport	Protocols
Thread-Index: AQHMNebi/4sRjYxVJUGfnQDgbsrRSZTT51zQ
Date: Wed, 29 Jun 2011 06:57:12 +0000
Message-ID: <791AD3077F94194BB2BDD13565B6295D1C737F89@PALLENE.office.hd>
References: <20110628223727.0CB8298C55B@rfc-editor.org>
In-Reply-To: <20110628223727.0CB8298C55B@rfc-editor.org>
Accept-Language: en-US, de-DE
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
x-originating-ip: [10.1.6.28]
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
Subject: Re: [ledbat] RFC 6297 on A Survey of Lower-than-Best-Effort Transport	Protocols
X-BeenThere: ledbat@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Mailing list of the LEDBAT WG 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Wed, 29 Jun 2011 06:57:19 -0000

Congratulations to the authors and many thanks to them and to the WG for al=
l your effort!

The chairs.

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


> -----Original Message-----
> From: ledbat-bounces@ietf.org [mailto:ledbat-bounces@ietf.org] On
> Behalf Of rfc-editor@rfc-editor.org
> Sent: Mittwoch, 29. Juni 2011 00:37
> To: ietf-announce@ietf.org; rfc-dist@rfc-editor.org
> Cc: ledbat@ietf.org; rfc-editor@rfc-editor.org
> Subject: [ledbat] RFC 6297 on A Survey of Lower-than-Best-Effort
> Transport Protocols
>=20
>=20
> A new Request for Comments is now available in online RFC libraries.
>=20
>=20
>         RFC 6297
>=20
>         Title:      A Survey of Lower-than-Best-Effort Transport
>                     Protocols
>         Author:     M. Welzl, D. Ros
>         Status:     Informational
>         Stream:     IETF
>         Date:       June 2011
>         Mailbox:    michawe@ifi.uio.no,
>                     david.ros@telecom-bretagne.eu
>         Pages:      18
>         Characters: 46532
>         Updates/Obsoletes/SeeAlso:   None
>=20
>         I-D Tag:    draft-ietf-ledbat-survey-07.txt
>=20
>         URL:        http://www.rfc-editor.org/rfc/rfc6297.txt
>=20
> This document provides a survey of transport protocols that are
> designed to have a smaller bandwidth and/or delay impact on standard
> TCP than standard TCP itself when they share a bottleneck with it.
> Such protocols could be used for delay-insensitive "background"
> traffic, as they provide what is sometimes called a "less than" (or
> "lower than") best-effort service.  This document is not an
> Internet Standards Track specification; it is published
> for informational purposes.
>=20
> This document is a product of the Low Extra Delay Background Transport
> Working Group of the IETF.
>=20
>=20
> INFORMATIONAL: This memo provides information for the Internet
> community.
> It does not specify an Internet standard of any kind. Distribution of
> this memo is unlimited.
>=20
> This announcement is sent to the IETF-Announce and rfc-dist lists.
> To subscribe or unsubscribe, see
>   http://www.ietf.org/mailman/listinfo/ietf-announce
>   http://mailman.rfc-editor.org/mailman/listinfo/rfc-dist
>=20
> For searching the RFC series, see http://www.rfc-
> editor.org/rfcsearch.html.
> For downloading RFCs, see http://www.rfc-editor.org/rfc.html.
>=20
> Requests for special distribution should be addressed to either the
> author of the RFC in question, or to rfc-editor@rfc-editor.org.  Unless
> specifically noted otherwise on the RFC itself, all RFCs are for
> unlimited distribution.
>=20
>=20
> The RFC Editor Team
> Association Management Solutions, LLC
>=20
>=20
> _______________________________________________
> ledbat mailing list
> ledbat@ietf.org
> https://www.ietf.org/mailman/listinfo/ledbat

From ingemar.s.johansson@ericsson.com  Wed Jun 29 00:35:21 2011
Return-Path: 
X-Original-To: ledbat@ietfa.amsl.com
Delivered-To: ledbat@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 53E6321F85A9 for ; Wed, 29 Jun 2011 00:35:21 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.449
X-Spam-Level: 
X-Spam-Status: No, score=-6.449 tagged_above=-999 required=5 tests=[AWL=0.149,  BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4]
Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id OCqqSMmggVZ2 for ; Wed, 29 Jun 2011 00:35:20 -0700 (PDT)
Received: from mailgw10.se.ericsson.net (mailgw10.se.ericsson.net [193.180.251.61]) by ietfa.amsl.com (Postfix) with ESMTP id 0319C21F85AA for ; Wed, 29 Jun 2011 00:35:19 -0700 (PDT)
X-AuditID: c1b4fb3d-b7c17ae00000262e-87-4e0ad5b6623c
Received: from esessmw0237.eemea.ericsson.se (Unknown_Domain [153.88.253.124]) by mailgw10.se.ericsson.net (Symantec Mail Security) with SMTP id AE.05.09774.6B5DA0E4; Wed, 29 Jun 2011 09:35:18 +0200 (CEST)
Received: from ESESSCMS0366.eemea.ericsson.se ([169.254.1.23]) by esessmw0237.eemea.ericsson.se ([153.88.115.90]) with mapi; Wed, 29 Jun 2011 09:35:18 +0200
From: Ingemar Johansson S 
To: "ledbat@ietf.org" 
Date: Wed, 29 Jun 2011 09:35:17 +0200
Thread-Topic: C-code of ledbat
Thread-Index: Acw2Lxe2oCxmQqp6Q4WCQyaaYZAjRA==
Message-ID: 
Accept-Language: sv-SE, en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
acceptlanguage: sv-SE, en-US
Content-Type: multipart/alternative; boundary="_000_DBB1DC060375D147AC43F310AD987DCC2EAF2DEF96ESESSCMS0366e_"
MIME-Version: 1.0
X-Brightmail-Tracker: AAAAAA==
Subject: [ledbat] C-code of ledbat
X-BeenThere: ledbat@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Mailing list of the LEDBAT WG 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Wed, 29 Jun 2011 07:35:21 -0000

--_000_DBB1DC060375D147AC43F310AD987DCC2EAF2DEF96ESESSCMS0366e_
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable

Hi

Is there any c-code for LEDBAT available ?
I may be interested to make a model for our proprietary wireless (LTE/HSPA)=
 modeling software.
I guess the pseudo code in the draft should do but c-code may be easier to =
copy-paste

/Ingemar

=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D
INGEMAR JOHANSSON  M.Sc.
Senior Researcher

Ericsson AB
Wireless Area Networks
Labratoriegr=E4nd 11
971 28, Lule=E5, Sweden
Phone +46-1071 43042
SMS/MMS +46-73 078 3289
ingemar.s.johansson@ericsson.com
www.ericsson.com
Visit http://labs.ericsson.com !
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D




--_000_DBB1DC060375D147AC43F310AD987DCC2EAF2DEF96ESESSCMS0366e_
Content-Type: text/html; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable











Hi


 


Is there any c-code for LEDBAT available ? 


I may be interested to make a model for our proprietary wireless (LTE/=
HSPA) modeling software.


I guess the pseudo code in the draft should do but c-code may be easie=
r to copy-paste


 


/Ingemar


 


=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D


INGEMAR JOHANSSON  M.Sc. 


Senior Researcher


 


Ericsson AB


Wireless Area Networks

Labratoriegr=E4nd 11

971 28, Lule=E5, Sweden

Phone +46-1071 43042<=
/div>

SMS/MMS +46-73 078 3289


ingemar.s.johansson@ericsson.com=





=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D


 


 


 





--_000_DBB1DC060375D147AC43F310AD987DCC2EAF2DEF96ESESSCMS0366e_--

From dario.rossi@enst.fr  Wed Jun 29 01:15:53 2011
Return-Path: 
X-Original-To: ledbat@ietfa.amsl.com
Delivered-To: ledbat@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A9BCF21F8604 for ; Wed, 29 Jun 2011 01:15:53 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.598
X-Spam-Level: 
X-Spam-Status: No, score=-2.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001]
Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id k4Ej2vX8vCTc for ; Wed, 29 Jun 2011 01:15:52 -0700 (PDT)
Received: from smtp2.enst.fr (revol2.enst.fr [IPv6:2001:660:330f:2::e]) by ietfa.amsl.com (Postfix) with ESMTP id E430121F8619 for ; Wed, 29 Jun 2011 01:15:51 -0700 (PDT)
Received: from localhost (localhost [127.0.0.1]) by smtp2.enst.fr (Postfix) with ESMTP id 9F159B8ADF for ; Wed, 29 Jun 2011 09:48:49 +0200 (CEST)
Received: from [IPv6:::1] (infres1.enst.fr [137.194.192.1]) by smtp2.enst.fr (Postfix) with ESMTP id 476FFB8AFD for ; Wed, 29 Jun 2011 09:48:49 +0200 (CEST)
Message-ID: <4E0AD8E0.7050707@enst.fr>
Date: Wed, 29 Jun 2011 09:48:48 +0200
From: Dario Rossi 
User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.9.2.12) Gecko/20101027 Lightning/1.0b2 Thunderbird/3.1.6
MIME-Version: 1.0
To: ledbat@ietf.org
References: 
In-Reply-To: 
Content-Type: multipart/alternative; boundary="------------040308010900060706050603"
Subject: Re: [ledbat] C-code of ledbat
X-BeenThere: ledbat@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Mailing list of the LEDBAT WG 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Wed, 29 Jun 2011 08:15:53 -0000

This is a multi-part message in MIME format.
--------------040308010900060706050603
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 8bit

Hi Ingemar,

you basically have two options: our open source OpenLedbat [OL] 
implementation and the BitTorrent [BT] one:

     [BT] G. Hazel. uTorrent Transport Protocol library. 
http://github.com/bittorrent/libutp, May 2010.

     [OL] 
http://perso.infres.enst.fr/~drossi/index.php?n=Software.LEDBAT 



there are a few differences that may let you choose one or the other:

OL replaces /TCP/ congestion control with Ledbat (i.e., is based on TCP 
framing, not uTP one) so it is not compatible with uTP headers unlike BT.

BT implementantion works at the application layer, OL at kernel layer: 
so, OL is transparent w.r.t the application (ie., you can revert to TCP 
later without modyfing the app)

OL not only works as a Linux kernel module, but also as  an ns2 
simulation module, so it may be good for controlled evaluation before 
deployment  (note: though we have checked that the module loads in linux 
and have made limited experiments where it works as expected (e..g., 
yield to tcp, etc.) we have mostly used our code in simulation during 
our research).

I guess you know that both implementation are affected by a latecomer 
issue (we verified it happens in BT http://arxiv.org/pdf/1006.3018v1 in 
a testbed and in OL by n2 simulation)


hope it helps,
D.


On 06/29/2011 09:35 AM, Ingemar Johansson S wrote:
> Hi
> Is there any c-code for LEDBAT available ?
> I may be interested to make a model for our proprietary wireless 
> (LTE/HSPA) modeling software.
> I guess the pseudo code in the draft should do but c-code may be 
> easier to copy-paste
> /Ingemar
> =================================
> INGEMAR JOHANSSON  M.Sc.
> Senior Researcher
> Ericsson AB
> Wireless Area Networks
> Labratoriegränd 11
> 971 28, Luleċ, Sweden
> Phone +46-1071 43042
> SMS/MMS +46-73 078 3289
> ingemar.s.johansson@ericsson.com
> _www.ericsson.com_
> Visit _http://labs.ericsson.com_ !
> =================================
>
>
> _______________________________________________
> ledbat mailing list
> ledbat@ietf.org
> https://www.ietf.org/mailman/listinfo/ledbat


-- 
  Oo    Associate Professor
   >     TELECOM ParisTech
  ~     (formerly ENST)

mail:  dario.rossi@enst.fr
phone: +33.1.4581.7563
fax:   +33.1.4581.7158
web:   http://www.enst.fr/~drossi


--------------040308010900060706050603
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit



  
    
  
  
    Hi Ingemar,

    

    you basically have two options: our open source OpenLedbat [OL]
    implementation and the BitTorrent [BT] one:

    

        [BT]
    G. Hazel. uTorrent Transport Protocol library. http://github.com/bittorrent/libutp,
    May 2010.
    
    [OL] http://perso.infres.enst.fr/~drossi/index.php?n=Software.LEDBAT
    

    

    there are a few differences that may let you choose one or the
    other:

    

    OL replaces /TCP/ congestion control with Ledbat (i.e., is based on
    TCP framing, not uTP one) so it is not compatible with uTP headers
    unlike BT.

    

    BT implementantion works at the application layer, OL at kernel
    layer: so, OL is transparent w.r.t the application (ie., you can
    revert to TCP later without modyfing the app)

    

    OL not only works as a Linux kernel module, but also as  an ns2
    simulation module, so it may be good for controlled evaluation
    before deployment  (note: though we have checked that the module
    loads in linux and have made limited experiments where it works as
    expected (e..g., yield to tcp, etc.) we have mostly used our code in
    simulation during our research).

    

    I guess you know that both implementation are affected by a
    latecomer issue (we verified it happens in BT
    http://arxiv.org/pdf/1006.3018v1 in a testbed and in OL by n2
    simulation)

    

    

    hope it helps,

    D.

    

    

    On 06/29/2011 09:35 AM, Ingemar Johansson S wrote:
    

      
      
      
      
      
        
Hi

        
 

        
Is there any c-code for LEDBAT available ? 

        
I may be interested to make a model for our proprietary
          wireless (LTE/HSPA) modeling software.

        
I guess the pseudo code in the draft should do but c-code
          may be easier to copy-paste

        
 

        
/Ingemar

        
 

        
=================================

        
INGEMAR JOHANSSON 
            M.Sc. 

        
Senior Researcher

        
 

        
Ericsson AB

        
Wireless Area Networks

        
Labratoriegränd 11

        
971 28, Luleå, Sweden

        
Phone +46-1071 43042

        
SMS/MMS +46-73 078 3289

        
        
        
        
=================================

        
 

        
 

        
 

      
      

_______________________________________________
ledbat mailing list
ledbat@ietf.org
https://www.ietf.org/mailman/listinfo/ledbat


    

    

    

    
-- 
 Oo    Associate Professor
  >    TELECOM ParisTech
 ~     (formerly ENST)

mail:  dario.rossi@enst.fr
phone: +33.1.4581.7563
fax:   +33.1.4581.7158
web:   http://www.enst.fr/~drossi


  


--------------040308010900060706050603--

From dario.rossi@enst.fr  Wed Jun 29 01:20:14 2011
Return-Path: 
X-Original-To: ledbat@ietfa.amsl.com
Delivered-To: ledbat@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6B85B21F84FE for ; Wed, 29 Jun 2011 01:20:14 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.598
X-Spam-Level: 
X-Spam-Status: No, score=-2.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001]
Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id c58btUc1MSA5 for ; Wed, 29 Jun 2011 01:20:13 -0700 (PDT)
Received: from smtp2.enst.fr (revol2.enst.fr [IPv6:2001:660:330f:2::e]) by ietfa.amsl.com (Postfix) with ESMTP id 602A121F846A for ; Wed, 29 Jun 2011 01:20:12 -0700 (PDT)
Received: from localhost (localhost [127.0.0.1]) by smtp2.enst.fr (Postfix) with ESMTP id 36B96B8BAC; Wed, 29 Jun 2011 10:20:11 +0200 (CEST)
Received: from [IPv6:::1] (infres1.enst.fr [137.194.192.1]) by smtp2.enst.fr (Postfix) with ESMTP id 7B932B8A7A; Wed, 29 Jun 2011 10:20:08 +0200 (CEST)
Message-ID: <4E0AE037.8050709@enst.fr>
Date: Wed, 29 Jun 2011 10:20:07 +0200
From: Dario Rossi 
User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.9.2.12) Gecko/20101027 Lightning/1.0b2 Thunderbird/3.1.6
MIME-Version: 1.0
To: Mirja Kuehlewind 
References: <791AD3077F94194BB2BDD13565B6295D05E6DF22@PALLENE.office.hd> <201106151821.15361.mirja.kuehlewind@ikr.uni-stuttgart.de> <4DFB223E.3000303@enst.fr> <201106282007.40987.mirja.kuehlewind@ikr.uni-stuttgart.de>
In-Reply-To: <201106282007.40987.mirja.kuehlewind@ikr.uni-stuttgart.de>
Content-Type: multipart/alternative; boundary="------------020100040106090600020504"
Cc: ledbat@ietf.org
Subject: Re: [ledbat] 2 week last call for draft-ietf-ledbat-congestion-06
X-BeenThere: ledbat@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Mailing list of the LEDBAT WG 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Wed, 29 Jun 2011 08:20:14 -0000

This is a multi-part message in MIME format.
--------------020100040106090600020504
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit

Hi Mirja, all,

both questions are deeply related,  I reformulate the explanation with 
more details -- so, sorry for the long mail,

imo, a /random jitter between two consecutive packets/  is not enough to 
trigger changes that avoid latecomer issue (which is what the draft 
suggests)

/backlogged/ means that application have /always/ data to send, so that 
the congestion control  happens on an infinite stream of packets that 
queue at application level (this is the usual case of FTP application). 
In case you have backlogged transfers, latecomer happens in practice  
(eg even with  libUTP implementation [ARXIV] ), and irrespectively of 
random jittering [1]

now, if the source is non-backlogged but /talks in spurts/ (e.g., 
BitTorrent chunks, short HTTP transfers) with some random idle time in 
between the spurts, this amount of randomness can assist flows in 
reaching a (more) fair share of the link.

more generally, I believe that /non-backlogged/ data arrival at the 
congestion control is likely the reason why  BitTorrent never observed 
the latecomer stuff , because now the link is not fully utilised. If the 
link utilization is on average <100% , then the queue seldom empties, in 
agreement with the original motivation for having a non-null target in 
ledbat for efficiency matters

in other words,  the  BitTorrent statement (sorry, rephrased with my own 
words, so do not quoted exactly)  that in practice randomness in real 
world happens due to e.g. "hiccups reading from disks" actually 
translate imo into /non-backlogged/ data transmission. Reason for non 
backlogged transmission (ie. <100% link utilization) was also observed 
in real swarm experiments** by Legout et al. [2,3] **due to /P2P 
protocol dynamics/, more than to disk bottlenecks

now, in *real BitTorrent swarms*, due to non-backlogged transmission, 
latecomer may not happen in practice and LEDBAT can actually translate 
into an advantage (see one of my last mails on the list about the impact 
of LEBDAT on BitTorrent completion time [4]).     However, from a 
*protocol perspective* the issue with latecomer still remains in 
LEDBAT,  as the first of two FTP-like backlogged transfers would face 
the latecomer starvation problem.

hope this clarifies my thoughts,
D.


[1]
G. Carofiglio, L. Muscariello, D. Rossi and S. Valenti, *The quest for 
LEDBAT fairness* 
 . In /IEEE 
Globecom'10/, Miami, FL, USA, December 6-10 2010.

[2] A. Legout, N. Liogkas, E. Kohler, and L. Zhang. *Clustering and 
Sharing Incentives in BitTorrent Systems*. In /Proceedings of ACM 
SIGMETRICS'2007/, June 12--16, 2007, San Diego, CA, USA. [.ps 
, .pdf 
, .tex 
].

[3] A. Legout, G. Urvoy-Keller, and P. Michiardi. *Rarest First and 
Choke Algorithms Are Enough*. In /Proceedings of ACM SIGCOMM/USENIX 
IMC'2006/, October 25--27, 2006, Rio de Janeiro, Brazil. [.ps 
, .pdf 
, .tex 
].

[4]
C. Testa and D. Rossi, *The impact of uTP on BitTorrent completion time* 
 . In /IEEE Peer to 
Peer (P2P'11)/, Kyoto, Japan, September 2011.

[ARXIV] G. Carofiglio, L. Muscariello, D. Rossi and S. Valenti, 
"Rethinking low extra delay background transport protocols" 
http://arxiv.org/abs/1010.5623


On 06/28/2011 08:07 PM, Mirja Kuehlewind wrote:
> Hi Dario,
>
> sorry for the late response.  First of all thanks for your feedback. I'm not
> sure if I exactly got your point. I believe our statement about randomness is
> still not wrong because it's very general. Of course the idea is that the
> queue has to get empty from time to time (to measure the real base delay).
> Maybe we can state that more explicit?
>
> But back to your result. Can you define what you exactly mean by 'backlogged'
> flows? I'm not sure if I fully got you right here...
>
> Mirja
>
>
>> Our testbed experiments with the BitTorrent libUTP implementation shown
>> that latecomer unfairness arises also in the real world, in case of
>> /backlogged/ flows ( see Fig1, pag2 in http://arxiv.org/abs/1010.5623 )
>>
>> Latecomer unfairness may instead vanish in case of /non-backlogged/
>> connections (see Fig6 pag 9 in http://arxiv.org/abs/1010.5623 ; only ns2
>> results here though)
>>
>> While I understand (and agree) that fairness may not be the main aspect
>> in ledbat, given the above observations and [1], it seems to me that
>> sec 5.3 of the current version of the draft wrongly states that fairness
>> is reinstated simply by
>>
>> 	randomness in the inter-packet transmission times exist,
>>
>> as [1] shows this is not the case  (and though there is real-world noise
>> in the testbed of Fig1, pag2 in http://arxiv.org/abs/1010.5623 , this is
>> apparently not enough either...)
>>
>> In other words, real-world noise is not enough to break latecomer
>> unfairness, but the use of non-backlogged traffic sources can: notice
>> that non backlogged sources assist in emptying the queues, while a
>> simple jittering cannot (hence, the explanation in sec 5.3 is misleading?).
>>
>>
>> [1] G. Carofiglio, L. Muscariello, D. Rossi and S. Valenti, *The quest
>> for LEDBAT fairness*
>>   . In /IEEE
>> Globecom'10/, Miami, FL, USA, December 6-10 2010.
>>
>>
>> Best,
>> D.
>>


-- 
  Oo    Associate Professor
   >     TELECOM ParisTech
  ~     (formerly ENST)

mail:  dario.rossi@enst.fr
phone: +33.1.4581.7563
fax:   +33.1.4581.7158
web:   http://www.enst.fr/~drossi


--------------020100040106090600020504
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit



  
    
  
  
    Hi Mirja, all,

    

    both questions are deeply related,  I reformulate the explanation
    with more details -- so, sorry for the long mail, 

    

    imo, a /random jitter between two consecutive packets/  is not
    enough to trigger changes that avoid latecomer issue (which is what
    the draft suggests)

    

    /backlogged/ means that application have /always/ data to send, so
    that the congestion control  happens on an infinite stream of
    packets that queue at application level (this is the usual case of
    FTP application). In case you have backlogged transfers, latecomer
    happens in practice  (eg even with  libUTP implementation [ARXIV] ),
    and irrespectively of random jittering [1]

    

    now, if the source is non-backlogged but /talks in spurts/ (e.g.,
    BitTorrent chunks, short HTTP transfers) with some random idle time
    in between the spurts, this amount of randomness can assist flows in
    reaching a (more) fair share of the link.

    

    more generally, I believe that /non-backlogged/ data arrival at the
    congestion control is likely the reason why  BitTorrent never
    observed the latecomer stuff , because now the link is not fully
    utilised. If the link utilization is on average <100% , then the
    queue seldom empties, in agreement with the original motivation for
    having a non-null target in ledbat for efficiency matters

    

    in other words,  the  BitTorrent statement (sorry, rephrased with my
    own words, so do not quoted exactly)  that in practice randomness in
    real world happens due to e.g. "hiccups reading from disks" actually
    translate imo into /non-backlogged/ data transmission. Reason for
    non backlogged transmission (ie. <100% link utilization) was also
    observed in real swarm experiments  by Legout et al. [2,3] due
    to /P2P protocol dynamics/, more than to disk bottlenecks

    

    now, in *real BitTorrent swarms*, due to non-backlogged
    transmission, latecomer may not happen in practice and LEDBAT can
    actually translate into an advantage (see one of my last mails on
    the list about the impact of LEBDAT on BitTorrent completion time
    [4]).     However, from a *protocol perspective* the issue with
    latecomer still remains in LEDBAT,  as the first of two FTP-like
    backlogged transfers would face the latecomer starvation problem.

    

    hope this clarifies my thoughts,

    D.

    

     
    

    [1]

    G. Carofiglio, L. Muscariello, D. Rossi and S. Valenti, The quest for LEDBAT fairness
    . In IEEE Globecom'10, Miami, FL, USA, December 6-10 2010.
    

    

    [2] A. Legout, N. Liogkas, E. Kohler, and L. Zhang. Clustering
      and Sharing Incentives in BitTorrent Systems. In Proceedings
      of ACM SIGMETRICS'2007, June 12--16, 2007, San Diego, CA, USA.
    [.ps, .pdf, .tex]. 

    

    [3] A. Legout, G. Urvoy-Keller, and P. Michiardi. Rarest First
      and Choke Algorithms Are Enough. In Proceedings of ACM
      SIGCOMM/USENIX
      IMC'2006, October 25--27, 2006, Rio de Janeiro, Brazil. [.ps, .pdf, .tex]. 

    

    [4]

    C. Testa and D. Rossi, The impact of uTP on BitTorrent completion
        time . In IEEE Peer to Peer (P2P'11),
    Kyoto, Japan, September 2011.
    

    

    [ARXIV] G. Carofiglio, L. Muscariello, D. Rossi and S. Valenti,
    "Rethinking low extra delay background transport protocols"
    http://arxiv.org/abs/1010.5623

    

    

    On 06/28/2011 08:07 PM, Mirja Kuehlewind wrote:
    

      
Hi Dario,

sorry for the late response.  First of all thanks for your feedback. I'm not 
sure if I exactly got your point. I believe our statement about randomness is 
still not wrong because it's very general. Of course the idea is that the 
queue has to get empty from time to time (to measure the real base delay). 
Maybe we can state that more explicit?

But back to your result. Can you define what you exactly mean by 'backlogged' 
flows? I'm not sure if I fully got you right here...

Mirja




      

        
Our testbed experiments with the BitTorrent libUTP implementation shown
that latecomer unfairness arises also in the real world, in case of
/backlogged/ flows ( see Fig1, pag2 in http://arxiv.org/abs/1010.5623 )

Latecomer unfairness may instead vanish in case of /non-backlogged/
connections (see Fig6 pag 9 in http://arxiv.org/abs/1010.5623 ; only ns2
results here though)

While I understand (and agree) that fairness may not be the main aspect
in ledbat, given the above observations and [1], it seems to me that
sec 5.3 of the current version of the draft wrongly states that fairness
is reinstated simply by

	randomness in the inter-packet transmission times exist,

as [1] shows this is not the case  (and though there is real-world noise
in the testbed of Fig1, pag2 in http://arxiv.org/abs/1010.5623 , this is
apparently not enough either...)

In other words, real-world noise is not enough to break latecomer
unfairness, but the use of non-backlogged traffic sources can: notice
that non backlogged sources assist in emptying the queues, while a
simple jittering cannot (hence, the explanation in sec 5.3 is misleading?).


[1] G. Carofiglio, L. Muscariello, D. Rossi and S. Valenti, *The quest
for LEDBAT fairness*
<http://www.enst.fr/%7Edrossi/paper/rossi10globecom-a.pdf> . In /IEEE
Globecom'10/, Miami, FL, USA, December 6-10 2010.


Best,
D.



      

    

    

    

    
-- 
 Oo    Associate Professor
  >    TELECOM ParisTech
 ~     (formerly ENST)

mail:  dario.rossi@enst.fr
phone: +33.1.4581.7563
fax:   +33.1.4581.7158
web:   http://www.enst.fr/~drossi


  


--------------020100040106090600020504--

From mirja.kuehlewind@ikr.uni-stuttgart.de  Wed Jun 29 04:39:07 2011
Return-Path: 
X-Original-To: ledbat@ietfa.amsl.com
Delivered-To: ledbat@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 567BA21F85B9 for ; Wed, 29 Jun 2011 04:39:07 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.079
X-Spam-Level: 
X-Spam-Status: No, score=-2.079 tagged_above=-999 required=5 tests=[AWL=-0.057, BAYES_00=-2.599, HELO_EQ_DE=0.35, SARE_SUB_OBFU_Q1=0.227]
Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 11OH00ldUfMs for ; Wed, 29 Jun 2011 04:39:06 -0700 (PDT)
Received: from mailsrv.ikr.uni-stuttgart.de (mailsrv.ikr.uni-stuttgart.de [129.69.170.2]) by ietfa.amsl.com (Postfix) with ESMTP id 0756B21F85B4 for ; Wed, 29 Jun 2011 04:39:05 -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 2B624633B1; Wed, 29 Jun 2011 13:39:04 +0200 (CEST)
Received: from vpn-2-cl177 (vpn-2-cl177 [10.41.21.177]) by netsrv1.ikr.uni-stuttgart.de (Postfix) with ESMTP id 19E1859A8A; Wed, 29 Jun 2011 13:39:04 +0200 (CEST)
From: Mirja Kuehlewind 
Organization: University of Stuttgart (Germany), IKR
To: Arjuna Sathiaseelan 
Date: Wed, 29 Jun 2011 13:39:03 +0200
User-Agent: KMail/1.9.10 (enterprise35 0.20101217.1207316)
References: <791AD3077F94194BB2BDD13565B6295D05E6DF22@PALLENE.office.hd> <201106282025.54990.mirja.kuehlewind@ikr.uni-stuttgart.de> 
In-Reply-To: 
X-KMail-QuotePrefix: > 
MIME-Version: 1.0
Content-Type: Text/Plain; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
Content-Disposition: inline
Message-Id: <201106291339.03755.mirja.kuehlewind@ikr.uni-stuttgart.de>
Cc: ledbat@ietf.org
Subject: Re: [ledbat] ECN/AQM, was: 2 week last call for draft-ietf-ledbat-congestion-06
X-BeenThere: ledbat@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Mailing list of the LEDBAT WG 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Wed, 29 Jun 2011 11:39:07 -0000

Hi Arjuna,

the minimum cwnd windows is 2 (MIN_CWND). That means LEDBAT will send at le=
ast=20
two 2 packets per RTT (which is 'basically' zero). LEDBAT will not wait for=
=20
any timers here but send continuously data with a very, very slow rate.

Mirja


On Tuesday 28 June 2011 21:28:12 Arjuna Sathiaseelan wrote:
> Dear Mirja,
>   Sorry- I am a newcomer to LEDBAT - and I am trying to understand
> this. So when you say LEDBAT reduces the sending rate to zero - does
> that mean LEDBAT doesnt have the notion of timers/timeouts? So if
> LEDBAT knows that the queues are being utilised could it wait for any
> amount of time without sending data?
>
> > And when LEDBAT is working correctly, there shouldn't occur any ECN
> > marking (and of course no losses neither) as LEDBAT will reduce it's
> > sending rate to basically zero before any queues overflow.
>
> Regards
> Arjuna



=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 mirja.kuehlewind@ikr.uni-stuttgart.de  Wed Jun 29 05:24:07 2011
Return-Path: 
X-Original-To: ledbat@ietfa.amsl.com
Delivered-To: ledbat@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AD60711E8075 for ; Wed, 29 Jun 2011 05:24:07 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.873
X-Spam-Level: 
X-Spam-Status: No, score=-1.873 tagged_above=-999 required=5 tests=[AWL=-0.224, BAYES_00=-2.599, HELO_EQ_DE=0.35, J_CHICKENPOX_56=0.6]
Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id EdBnAhYF9OT8 for ; Wed, 29 Jun 2011 05:24:07 -0700 (PDT)
Received: from mailsrv.ikr.uni-stuttgart.de (mailsrv.ikr.uni-stuttgart.de [129.69.170.2]) by ietfa.amsl.com (Postfix) with ESMTP id A212B11E8070 for ; Wed, 29 Jun 2011 05:24:06 -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 55F12633B1; Wed, 29 Jun 2011 14:24:05 +0200 (CEST)
Received: from vpn-2-cl177 (vpn-2-cl177 [10.41.21.177]) by netsrv1.ikr.uni-stuttgart.de (Postfix) with ESMTP id 4131959A8A; Wed, 29 Jun 2011 14:24:05 +0200 (CEST)
From: Mirja Kuehlewind 
Organization: University of Stuttgart (Germany), IKR
To: Ingemar Johansson S 
Date: Wed, 29 Jun 2011 14:24:04 +0200
User-Agent: KMail/1.9.10 (enterprise35 0.20101217.1207316)
References:  
In-Reply-To: 
X-KMail-QuotePrefix: > 
MIME-Version: 1.0
Content-Type: Text/Plain; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
Content-Disposition: inline
Message-Id: <201106291424.04753.mirja.kuehlewind@ikr.uni-stuttgart.de>
Cc: ledbat@ietf.org
Subject: Re: [ledbat] ledbat Digest, Vol 30, Issue 10
X-BeenThere: ledbat@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Mailing list of the LEDBAT WG 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Wed, 29 Jun 2011 12:24:07 -0000

Hi Ingemar,

I did not very much investigations about LEDBAT in a wireless scenario. But=
=20
LEDBAT is supposed to keep the extra delay at TARGET ms. Even if there is=20
some other extra delay e.g. introduced by the wireless network, LEDBAT will=
=20
try to keep TARGET ms extra delay on the link. I guess in a wireless scenar=
io=20
TARGET has to be chosen large enough thus.

But regarding marking or dropping: I guess you assume a scenario, where TAR=
GET=20
is chosen very large and the marking/dropping threshold is very small, and=
=20
thus LEDBAT will get quite frequent marks/losses. In this scenario LEDBAT=20
will fall back to normal TCP behavior (with a little slower increase). I do=
=20
not consider this case as regular LEDBAT behavior, as you don't have the=20
LEDBAT advantage anymore.

Mirja



On Wednesday 29 June 2011 07:30:13 Ingemar Johansson S wrote:
> Hi
>
> I believe it is OK to say that LEDBAT should work in a 3168-ish way to ECN
> marks. i.e in the same way that it reacts to loss and possibly just
> reference to RFC3168.
>
> I don't fully agree with the sentence "there shouldn't occur any ECN
> marking (and of course no losses neither) as LEDBAT will reduce it's
> sending rate to basically zero before any queues overflow". For certain
> wireless access it is possible to tune ECN marking algorithm such that th=
ey
> trigger just at the bend on the hockey stick. Means that packets are ECN-=
CE
> marked even though the delay+jitter is quite moderate. Of course this is
> pretty much dependent on the design of the ECN marking but I wouldn't rule
> out that packets are "LEDBAT packets" are ECN marked.
>
> Regards
> Ingemar
>
> > Hi Gorry.
> >
> > > Mirja seems to raise a valid point...
> > >
> > > I think it would be extremely good to encourage the use of ECN for
> > > such applications, by saying explicitly that ECN could
> >
> > offer benefit
> >
> > > when the infrastructure supports this. To allow this, a
> >
> > LEDBAT session
> >
> > > needs to send packets with ECT(x), and then MUST include
> >
> > appropriate
> >
> > > control functions.
> >
> > I don't think we should recommend for LEBDAT to be
> > ECN-capable because the selection of a congestion control
> > mechanism is, from my point of view, not related to the
> > question to support ECN or not.
> > Moreover, ECN is an TCP/IP mechanism and LEDBAT is specified
> > independent of any framing protocol (e.g. BitTorrent uses UDP).
> > And when LEDBAT is working correctly, there shouldn't occur
> > any ECN marking (and of course no losses neither) as LEDBAT
> > will reduce it's sending rate to basically zero before any
> > queues overflow.
> >
> > > - whatever, I think reception of an ECN mark MUST cause the
> > > corresponding sender to perform a congestion response -
> >
> > i.e. can not
> >
> > > be ignored.
> >
> > My only question was: Should we mention _explicit_ that
> > LEDBAT has to halve its window on an ECN mark or is it enough
> > if RCF3168 is defining this _implicit_ by saying (every)
> > congestion control should react in the same way to ECN marks
> > as it would to loss.
> > In both cases a LEDBAT flow has to halve this window on an
> > ECN mark (as on loss).
> >
> > So in general, I'm not sure if we should talk about an TCP/IP
> > mechanism (ECN) in this draft when we only specify the
> > algorithm and not talking about anything TCP specific...?
> >
> > Mirja
> >
> >
> > ------------------------------
> >
> > _______________________________________________
> > ledbat mailing list
> > ledbat@ietf.org
> > https://www.ietf.org/mailman/listinfo/ledbat
> >
> >
> > End of ledbat Digest, Vol 30, Issue 10
> > **************************************



=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 gorry@erg.abdn.ac.uk  Wed Jun 29 09:09:26 2011
Return-Path: 
X-Original-To: ledbat@ietfa.amsl.com
Delivered-To: ledbat@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D412B21F847D for ; Wed, 29 Jun 2011 09:09:26 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -102.372
X-Spam-Level: 
X-Spam-Status: No, score=-102.372 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, SARE_SUB_OBFU_Q1=0.227, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id MhrC6TNnbIuq for ; Wed, 29 Jun 2011 09:09:26 -0700 (PDT)
Received: from erg.abdn.ac.uk (dee.erg.abdn.ac.uk [IPv6:2001:630:241:204:203:baff:fe9a:8c9b]) by ietfa.amsl.com (Postfix) with ESMTP id 394D221F84A5 for ; Wed, 29 Jun 2011 09:09:23 -0700 (PDT)
Received: from gorry-mac.erg.abdn.ac.uk (gorry-mac.erg.abdn.ac.uk [139.133.207.5]) (authenticated bits=0) by erg.abdn.ac.uk (8.13.4/8.13.4) with ESMTP id p5TG9GiP020065 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NOT); Wed, 29 Jun 2011 17:09:16 +0100 (BST)
Message-ID: <4E0B4E2C.8070303@erg.abdn.ac.uk>
Date: Wed, 29 Jun 2011 17:09:16 +0100
From: Gorry Fairhurst 
Organization: The University of Aberdeen is a charity registered in Scotland,  No SC013683. 
User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.6; en-US; rv:1.9.2.17) Gecko/20110414 Thunderbird/3.1.10
MIME-Version: 1.0
To: Mirja Kuehlewind 
References: <791AD3077F94194BB2BDD13565B6295D05E6DF22@PALLENE.office.hd>	<201106282025.54990.mirja.kuehlewind@ikr.uni-stuttgart.de>	 <201106291339.03755.mirja.kuehlewind@ikr.uni-stuttgart.de>
In-Reply-To: <201106291339.03755.mirja.kuehlewind@ikr.uni-stuttgart.de>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
X-ERG-MailScanner: Found to be clean
X-ERG-MailScanner-From: gorry@erg.abdn.ac.uk
Cc: ledbat@ietf.org
Subject: Re: [ledbat] ECN/AQM, was: 2 week last call for draft-ietf-ledbat-congestion-06
X-BeenThere: ledbat@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
Reply-To: gorry@erg.abdn.ac.uk
List-Id: Mailing list of the LEDBAT WG 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Wed, 29 Jun 2011 16:09:26 -0000

I think Arjuna has a point, this is MUCH more aggressive than TCP under 
some conditions. Also if this is implemented as UDP, it does not adhere 
to the "worst case" rate described in the BCP for UDP usage, RFC 5405 
(see section 3.1.2).

Why is LEDBAT more aggressive than TCP or that recommended for UDP-based 
applications over severely constrained paths?

Gorry


On 29/06/2011 12:39, Mirja Kuehlewind wrote:
> Hi Arjuna,
>
> the minimum cwnd windows is 2 (MIN_CWND). That means LEDBAT will send at least
> two 2 packets per RTT (which is 'basically' zero). LEDBAT will not wait for
> any timers here but send continuously data with a very, very slow rate.
>
> Mirja
>
>
> On Tuesday 28 June 2011 21:28:12 Arjuna Sathiaseelan wrote:
>> Dear Mirja,
>>    Sorry- I am a newcomer to LEDBAT - and I am trying to understand
>> this. So when you say LEDBAT reduces the sending rate to zero - does
>> that mean LEDBAT doesnt have the notion of timers/timeouts? So if
>> LEDBAT knows that the queues are being utilised could it wait for any
>> amount of time without sending data?
>>
>>> And when LEDBAT is working correctly, there shouldn't occur any ECN
>>> marking (and of course no losses neither) as LEDBAT will reduce it's
>>> sending rate to basically zero before any queues overflow.
>>
>> Regards
>> Arjuna
>
>
>


From bob.briscoe@bt.com  Wed Jun 29 09:44:44 2011
Return-Path: 
X-Original-To: ledbat@ietfa.amsl.com
Delivered-To: ledbat@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3140221F8663 for ; Wed, 29 Jun 2011 09:44:44 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.052
X-Spam-Level: 
X-Spam-Status: No, score=-3.052 tagged_above=-999 required=5 tests=[AWL=0.320,  BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1, SARE_SUB_OBFU_Q1=0.227]
Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id wwqwtVI+RKov for ; Wed, 29 Jun 2011 09:44:39 -0700 (PDT)
Received: from smtp1.smtp.bt.com (smtp1.smtp.bt.com [217.32.164.137]) by ietfa.amsl.com (Postfix) with ESMTP id 6679B21F8666 for ; Wed, 29 Jun 2011 09:44:39 -0700 (PDT)
Received: from i2kc06-ukbr.domain1.systemhost.net ([193.113.197.70]) by smtp1.smtp.bt.com with Microsoft SMTPSVC(6.0.3790.4675);  Wed, 29 Jun 2011 17:44:36 +0100
Received: from cbibipnt05.iuser.iroot.adidom.com ([147.149.196.177]) by i2kc06-ukbr.domain1.systemhost.net with Microsoft SMTPSVC(6.0.3790.4675); Wed, 29 Jun 2011 17:44:36 +0100
Received: From bagheera.jungle.bt.co.uk ([132.146.168.158]) by cbibipnt05.iuser.iroot.adidom.com (WebShield SMTP v4.5 MR1a P0803.399); id 1309365875292; Wed, 29 Jun 2011 17:44:35 +0100
Received: from MUT.jungle.bt.co.uk ([10.215.131.97]) by bagheera.jungle.bt.co.uk (8.13.5/8.12.8) with ESMTP id p5TGiYhs009504; Wed, 29 Jun 2011 17:44:34 +0100
Message-Id: <201106291644.p5TGiYhs009504@bagheera.jungle.bt.co.uk>
X-Mailer: QUALCOMM Windows Eudora Version 7.1.0.9
Date: Wed, 29 Jun 2011 17:44:32 +0100
To: Mirja Kuehlewind 
From: Bob Briscoe 
In-Reply-To: <201106291339.03755.mirja.kuehlewind@ikr.uni-stuttgart.de>
References: <791AD3077F94194BB2BDD13565B6295D05E6DF22@PALLENE.office.hd> <201106282025.54990.mirja.kuehlewind@ikr.uni-stuttgart.de>  <201106291339.03755.mirja.kuehlewind@ikr.uni-stuttgart.de>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"; format=flowed
X-Scanned-By: MIMEDefang 2.56 on 132.146.168.158
X-OriginalArrivalTime: 29 Jun 2011 16:44:36.0747 (UTC) FILETIME=[D4E3ADB0:01CC367B]
Cc: ledbat@ietf.org
Subject: Re: [ledbat] ECN/AQM, was: 2 week last call for  draft-ietf-ledbat-congestion-06
X-BeenThere: ledbat@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Mailing list of the LEDBAT WG 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Wed, 29 Jun 2011 16:44:44 -0000

Mirja,

Going back to your original question, I hope the thoughts below will 
help. They argue against some of the things you said earlier, and 
justify what Gorry concluded.

ECN was never intended to be TCP-only. The IETF debated whether to 
define ECN-IP in a separate RFC to ECN-TCP and decided the TCP part 
should go in the same RFC as the IP part. But RFC3168 encourages 
addition of ECN to other transports, which is happening (SCTP, DCCP, RTP).

However, we shouldn't just follow the RFCs blindly on this issue, 
because I don't think responding to ECN was ever considered in the 
context of a delay-sensing transport like LEDBAT. We have to think 
from scratch...

For those of you on the list who have given up thinking from scratch, 
because it hurts, you don't need to read through the logic in points 
1-5 below. The summary is:

* Sending ECN-capable packets ought to be recommended for LEDBAT, so 
that if ever ECN is deployed in the network, LEDBAT can take advantage of it.
* If LEDBAT sends ECN-capable packets, it should respond to ECN marks 
just like it responds to losses - reverting to TCP-like behaviour.
* However, LEDBAT will probably need the same sort of code as RTP 
needs to detect black-holing of ECN-capable UDP packets.




1/ LEDBAT is designed to fall-back to TCP behaviour on loss, so that 
it doesn't lose out to other long-running TCPs, which are assumed to 
be a more likely cause of a loss.

2/ Whether an AQM (or tail-drop) signals loss before or after the 
queue reaches the LEDBAT target (100ms) depends on the speed of the 
line. If a fast line is the bottleneck in the path, it will signal 
loss to LEDBAT before it reaches 100ms delay. Therefore LEDBAT will 
always respond to congestion of this fast queue like TCP, not LEDBAT.

I believe using a fixed target delay was a deliberate design choice 
in LEDBAT so that it is more likely to yield to congestion in the 
(slow) upstream queue of your own home gateway, and less likely to 
yield to other people's traffic in the fast queues of a carrier or a LAN.

Put another way, LEDBAT does not assume loss always occurs after 
100ms. But LEDBAT protects itself first, then tries to be 
super-friendly second. Therefore LEDBAT works to the rule "trying to 
be super-friendly in response to a loss is more likely to receive a 
slap for your troubles, so don't bother".

3/ RFC3168 very strongly requires that an AQM signals ECN to 
ECN-capable transports only when it would signal loss to 
non-ECN-capable transports. Beware, there be monsters if you break 
this rule on the public Internet! If an operator places the ECN 
threshold shallower than drop in a public Internet queue, then 
non-ECN-capable traffic would always starve out ECN-capable traffic.

BTW, DCTCP could only have a shallower ECN threshold than drop 
because it could be deployed in a data centre where ECN was turned on 
in every host, and there were no significant non-ECN transports (open 
loop datagram transactions still work fine too).

4/ Combining points 2 & 3, if LEDBAT sends ECN-capable packets, an 
ECN queue would signal congestion at exactly the same queue length as 
it would signal drop for non-ECN-capable packets. Just as with drop, 
this could be before or after the queue reaches LEDBATs 100ms target delay.

So, on the public Internet, LEDBAT should assume "trying to be 
super-friendly in response to an ECN mark is more likely to receive a 
slap for your troubles, so don't bother".

Therefore, on the public Internet, LEDBAT should respond to ECN just 
as it would respond to a loss, ie. revert to TCP-like behaviour. 
Therefore adding ECN to LEDBAT should involve the same code changes 
at user-level as adding ECN to TCP in the kernel.

5/ The only reason not to add ECN to LEDBAT would be if some 
middlebox black-holes ECN-capable UDP packets (or worse we've seen 
ECN-TCP negotiation crash a broken home gateway with widespread 
deployment a few years ago). Otherwise, adding ECN can either do 
nothing or improve matters.

LEDBAT is over UDP, so it won't trigger the particular crash that 
prevented ECN deployment in TCP for so many years (it happened while 
the buggy gateway was looking at the ECN negotiation bits in the TCP 
header of the SYN).

However, more recent buggy routers have been found to discard UDP 
datagrams that are ECN-capable at the IP layer (discovered when 
adding ECN to RTP). These buggy routers are being fixed. It is 
possible to detect this bug and fall-back to non-ECN. But that needs 
a new thread to discuss it.




Bob

At 12:39 29/06/2011, Mirja Kuehlewind wrote:


________________________________________________________________
Bob Briscoe,                                BT Innovate & Design 


From gorry@erg.abdn.ac.uk  Wed Jun 29 09:45:02 2011
Return-Path: 
X-Original-To: ledbat@ietfa.amsl.com
Delivered-To: ledbat@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 55EB721F8673 for ; Wed, 29 Jun 2011 09:45:02 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -102.372
X-Spam-Level: 
X-Spam-Status: No, score=-102.372 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, SARE_SUB_OBFU_Q1=0.227, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id RHePKKSkO0ZL for ; Wed, 29 Jun 2011 09:45:01 -0700 (PDT)
Received: from erg.abdn.ac.uk (dee.erg.abdn.ac.uk [IPv6:2001:630:241:204:203:baff:fe9a:8c9b]) by ietfa.amsl.com (Postfix) with ESMTP id CB6F821F85E4 for ; Wed, 29 Jun 2011 09:45:00 -0700 (PDT)
Received: from gorry-mac.erg.abdn.ac.uk (gorry-mac.erg.abdn.ac.uk [139.133.207.5]) (authenticated bits=0) by erg.abdn.ac.uk (8.13.4/8.13.4) with ESMTP id p5TGinC9020944 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NOT); Wed, 29 Jun 2011 17:44:49 +0100 (BST)
Message-ID: <4E0B5682.9080905@erg.abdn.ac.uk>
Date: Wed, 29 Jun 2011 17:44:50 +0100
From: Gorry Fairhurst 
Organization: The University of Aberdeen is a charity registered in Scotland,  No SC013683. 
User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.6; en-US; rv:1.9.2.17) Gecko/20110414 Thunderbird/3.1.10
MIME-Version: 1.0
To: Mirja Kuehlewind 
References: <791AD3077F94194BB2BDD13565B6295D05E6DF22@PALLENE.office.hd> <4DF90477.4080906@mti-systems.com> <4DFA4101.9000306@erg.abdn.ac.uk> <201106282025.54990.mirja.kuehlewind@ikr.uni-stuttgart.de>
In-Reply-To: <201106282025.54990.mirja.kuehlewind@ikr.uni-stuttgart.de>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
X-ERG-MailScanner: Found to be clean
X-ERG-MailScanner-From: gorry@erg.abdn.ac.uk
Cc: ledbat@ietf.org
Subject: Re: [ledbat] ECN/AQM, was:  2 week last call for draft-ietf-ledbat-congestion-06
X-BeenThere: ledbat@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
Reply-To: gorry@erg.abdn.ac.uk
List-Id: Mailing list of the LEDBAT WG 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Wed, 29 Jun 2011 16:45:02 -0000

On 28/06/2011 19:25, Mirja Kuehlewind wrote:
> Hi Gorry.
>
>> Mirja seems to raise a valid point...
>>
>> I think it would be extremely good to encourage the use of ECN for such
>> applications, by saying explicitly that ECN could offer benefit when the
>> infrastructure supports this. To allow this, a LEDBAT session needs to
>> send packets with ECT(x), and then MUST include appropriate control
>> functions.
 >
> I don't think we should recommend for LEBDAT to be ECN-capable because the
> selection of a congestion control mechanism is, from my point of view, not
> related to the question to support ECN or not.
 >
I'm not sure I understand.

> Moreover, ECN is an TCP/IP mechanism and LEDBAT is specified independent of
> any framing protocol (e.g. BitTorrent uses UDP).
 >
ECN is an IP mechanism that relies on a congestion-responsive transport. 
There is defined support for it in TCP, DCCP and soon  emerging in RTP 
over UDP (and perhaps SCTP).

There is no reason why a congestion-responsive LEDBAT flow over UDP can 
not use ECN, if it provides the functions.

> And when LEDBAT is working correctly, there shouldn't occur any ECN marking
> (and of course no losses neither) as LEDBAT will reduce it's sending rate to
> basically zero before any queues overflow.
>
I am not easily persuaded the function will always reduced LEDBAT 
throughput below all sharing TCP flows before queue overflow. Where I 
work, I see many types of dynamic layer 2 system in use, not all of 
which are easily mapped to layer 3 buffer - wide-area wireless access 
for instance, which can impose significant variation in RTT.

>> - whatever, I think reception of an ECN mark MUST cause the
>> corresponding sender to perform a congestion response - i.e. can not be
>> ignored.
> My only question was: Should we mention _explicit_ that LEDBAT has to halve
> its window on an ECN mark or is it enough if RCF3168 is defining this
> _implicit_ by saying (every) congestion control should react in the same way
> to ECN marks as it would to loss.
 >
> In both cases a LEDBAT flow has to halve this window on an ECN mark (as on
> loss).
>
> So in general, I'm not sure if we should talk about an TCP/IP mechanism (ECN)
> in this draft when we only specify the algorithm and not talking about
> anything TCP specific...?
>
I'm not saying the group should define the mechanism, but I am saying 
that from my point of view, it would be wise that ECN is ignored, and 
that what matters is proper response to "congestion indications", not to 
loss.

> Mirja
>
Gorry



From gorry@erg.abdn.ac.uk  Wed Jun 29 09:46:43 2011
Return-Path: 
X-Original-To: ledbat@ietfa.amsl.com
Delivered-To: ledbat@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5CA5121F8652 for ; Wed, 29 Jun 2011 09:46:43 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -102.186
X-Spam-Level: 
X-Spam-Status: No, score=-102.186 tagged_above=-999 required=5 tests=[AWL=-0.186, BAYES_00=-2.599, J_CHICKENPOX_56=0.6, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id HJwhPGdgN-QV for ; Wed, 29 Jun 2011 09:46:42 -0700 (PDT)
Received: from erg.abdn.ac.uk (dee.erg.abdn.ac.uk [IPv6:2001:630:241:204:203:baff:fe9a:8c9b]) by ietfa.amsl.com (Postfix) with ESMTP id 1109021F86BB for ; Wed, 29 Jun 2011 09:46:38 -0700 (PDT)
Received: from gorry-mac.erg.abdn.ac.uk (gorry-mac.erg.abdn.ac.uk [139.133.207.5]) (authenticated bits=0) by erg.abdn.ac.uk (8.13.4/8.13.4) with ESMTP id p5TGkTgp021039 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NOT); Wed, 29 Jun 2011 17:46:30 +0100 (BST)
Message-ID: <4E0B56E6.2020307@erg.abdn.ac.uk>
Date: Wed, 29 Jun 2011 17:46:30 +0100
From: Gorry Fairhurst 
Organization: The University of Aberdeen is a charity registered in Scotland,  No SC013683. 
User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.6; en-US; rv:1.9.2.17) Gecko/20110414 Thunderbird/3.1.10
MIME-Version: 1.0
To: Ingemar Johansson S 
References:  
In-Reply-To: 
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
X-ERG-MailScanner: Found to be clean
X-ERG-MailScanner-From: gorry@erg.abdn.ac.uk
Cc: "ledbat@ietf.org" 
Subject: Re: [ledbat] ledbat Digest, Vol 30, Issue 10
X-BeenThere: ledbat@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
Reply-To: gorry@erg.abdn.ac.uk
List-Id: Mailing list of the LEDBAT WG 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Wed, 29 Jun 2011 16:46:43 -0000

Agree (see my email response).

Gorry

On 29/06/2011 06:30, Ingemar Johansson S wrote:
> Hi
>
> I believe it is OK to say that LEDBAT should work in a 3168-ish way to ECN marks. i.e in the same way that it reacts to loss and possibly just reference to RFC3168.
>
> I don't fully agree with the sentence "there shouldn't occur any ECN marking (and of course no losses neither) as LEDBAT will reduce it's sending rate to basically zero before any queues overflow".
> For certain wireless access it is possible to tune ECN marking algorithm such that they trigger just at the bend on the hockey stick. Means that packets are ECN-CE marked even though the delay+jitter is quite moderate.
> Of course this is pretty much dependent on the design of the ECN marking but I wouldn't rule out that packets are "LEDBAT packets" are ECN marked.
>
> Regards
> Ingemar
>
>>
>> Hi Gorry.
>>
>>> Mirja seems to raise a valid point...
>>>
>>> I think it would be extremely good to encourage the use of ECN for
>>> such applications, by saying explicitly that ECN could
>> offer benefit
>>> when the infrastructure supports this. To allow this, a
>> LEDBAT session
>>> needs to send packets with ECT(x), and then MUST include
>> appropriate
>>> control functions.
>> I don't think we should recommend for LEBDAT to be
>> ECN-capable because the selection of a congestion control
>> mechanism is, from my point of view, not related to the
>> question to support ECN or not.
>> Moreover, ECN is an TCP/IP mechanism and LEDBAT is specified
>> independent of any framing protocol (e.g. BitTorrent uses UDP).
>> And when LEDBAT is working correctly, there shouldn't occur
>> any ECN marking (and of course no losses neither) as LEDBAT
>> will reduce it's sending rate to basically zero before any
>> queues overflow.
>>
>>> - whatever, I think reception of an ECN mark MUST cause the
>>> corresponding sender to perform a congestion response -
>> i.e. can not
>>> be ignored.
>> My only question was: Should we mention _explicit_ that
>> LEDBAT has to halve its window on an ECN mark or is it enough
>> if RCF3168 is defining this _implicit_ by saying (every)
>> congestion control should react in the same way to ECN marks
>> as it would to loss.
>> In both cases a LEDBAT flow has to halve this window on an
>> ECN mark (as on loss).
>>
>> So in general, I'm not sure if we should talk about an TCP/IP
>> mechanism (ECN) in this draft when we only specify the
>> algorithm and not talking about anything TCP specific...?
>>
>> Mirja
>>
>>
>> ------------------------------
>>
>> _______________________________________________
>> ledbat mailing list
>> ledbat@ietf.org
>> https://www.ietf.org/mailman/listinfo/ledbat
>>
>>
>> End of ledbat Digest, Vol 30, Issue 10
>> **************************************
>>
>
>


From arjuna.sathiaseelan@gmail.com  Wed Jun 29 11:36:44 2011
Return-Path: 
X-Original-To: ledbat@ietfa.amsl.com
Delivered-To: ledbat@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 996E011E8079 for ; Wed, 29 Jun 2011 11:36:44 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.75
X-Spam-Level: 
X-Spam-Status: No, score=-2.75 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_LOW=-1, SARE_SUB_OBFU_Q1=0.227]
Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id I5veR8Sg0rsd for ; Wed, 29 Jun 2011 11:36:44 -0700 (PDT)
Received: from mail-qw0-f44.google.com (mail-qw0-f44.google.com [209.85.216.44]) by ietfa.amsl.com (Postfix) with ESMTP id CEB9E9E8056 for ; Wed, 29 Jun 2011 11:36:43 -0700 (PDT)
Received: by qwc23 with SMTP id 23so1226518qwc.31 for ; Wed, 29 Jun 2011 11:36:43 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:cc:content-type :content-transfer-encoding; bh=FiOoM0y9ot8WjR7HHv9Xoscjwzu3rEJmzBY1yhp9lMg=; b=tpjrfPfGWdhBbPpJ0CFA28Fuwdv45jIZE7tVPH51if1zm6F6omEtVsJKtm843oB6Dz +5EAFk7NhqEiCUMfxI99YQNu6pY6t2MEQP/7DbpiBSSfgJYv1EDIinI2LScxC9WsvE71 UcMk5US293wVzgubfsIkGEncqehj15gsoWbJU=
MIME-Version: 1.0
Received: by 10.229.131.66 with SMTP id w2mr812868qcs.254.1309372602239; Wed, 29 Jun 2011 11:36:42 -0700 (PDT)
Sender: arjuna.sathiaseelan@gmail.com
Received: by 10.229.87.8 with HTTP; Wed, 29 Jun 2011 11:36:42 -0700 (PDT)
In-Reply-To: <201106291339.03755.mirja.kuehlewind@ikr.uni-stuttgart.de>
References: <791AD3077F94194BB2BDD13565B6295D05E6DF22@PALLENE.office.hd> <201106282025.54990.mirja.kuehlewind@ikr.uni-stuttgart.de>  <201106291339.03755.mirja.kuehlewind@ikr.uni-stuttgart.de>
Date: Wed, 29 Jun 2011 19:36:42 +0100
X-Google-Sender-Auth: v_rdtXZjfuqwXI-Lem6Q6RGscMQ
Message-ID: 
From: Arjuna Sathiaseelan 
To: Mirja Kuehlewind 
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable
Cc: ledbat@ietf.org
Subject: Re: [ledbat] ECN/AQM, was: 2 week last call for draft-ietf-ledbat-congestion-06
X-BeenThere: ledbat@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Mailing list of the LEDBAT WG 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Wed, 29 Jun 2011 18:36:44 -0000

Dear Mirja,
  I am not sure whether cwnd of 2 packets/RTT during periods of heavy
congestion is a good response - because other methods support lower
rates for e.g TFRC would end up at a rate of 1 packet every 64 seconds
or so. So I am wondering whether its possible to reduce the cwnd to a
more lower rate as a response to sustained congestion.


I agree with Bob and Gorry that allowing LEDBAT to support ECN is not
going to hurt.

Regards
Arjuna

On 29 June 2011 12:39, Mirja Kuehlewind
 wrote:
> Hi Arjuna,
>
> the minimum cwnd windows is 2 (MIN_CWND). That means LEDBAT will send at =
least
> two 2 packets per RTT (which is 'basically' zero). LEDBAT will not wait f=
or
> any timers here but send continuously data with a very, very slow rate.
>
> Mirja
>
>
> On Tuesday 28 June 2011 21:28:12 Arjuna Sathiaseelan wrote:
>> Dear Mirja,
>> =A0 Sorry- I am a newcomer to LEDBAT - and I am trying to understand
>> this. So when you say LEDBAT reduces the sending rate to zero - does
>> that mean LEDBAT doesnt have the notion of timers/timeouts? So if
>> LEDBAT knows that the queues are being utilised could it wait for any
>> amount of time without sending data?
>>
>> > And when LEDBAT is working correctly, there shouldn't occur any ECN
>> > marking (and of course no losses neither) as LEDBAT will reduce it's
>> > sending rate to basically zero before any queues overflow.
>>
>> Regards
>> Arjuna
>
>
>
> --
> -------------------------------------------------------------------
> 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
> -------------------------------------------------------------------
>

From bob.briscoe@bt.com  Wed Jun 29 12:02:46 2011
Return-Path: 
X-Original-To: ledbat@ietfa.amsl.com
Delivered-To: ledbat@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4358611E80AD for ; Wed, 29 Jun 2011 12:02:46 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.132
X-Spam-Level: 
X-Spam-Status: No, score=-3.132 tagged_above=-999 required=5 tests=[AWL=0.240,  BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1, SARE_SUB_OBFU_Q1=0.227]
Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id AaR-8QSInptU for ; Wed, 29 Jun 2011 12:02:45 -0700 (PDT)
Received: from smtp1.smtp.bt.com (smtp1.smtp.bt.com [217.32.164.137]) by ietfa.amsl.com (Postfix) with ESMTP id C062711E80E7 for ; Wed, 29 Jun 2011 12:02:16 -0700 (PDT)
Received: from i2kc06-ukbr.domain1.systemhost.net ([193.113.197.70]) by smtp1.smtp.bt.com with Microsoft SMTPSVC(6.0.3790.4675);  Wed, 29 Jun 2011 20:02:15 +0100
Received: from cbibipnt05.iuser.iroot.adidom.com ([147.149.196.177]) by i2kc06-ukbr.domain1.systemhost.net with Microsoft SMTPSVC(6.0.3790.4675); Wed, 29 Jun 2011 20:02:15 +0100
Received: From bagheera.jungle.bt.co.uk ([132.146.168.158]) by cbibipnt05.iuser.iroot.adidom.com (WebShield SMTP v4.5 MR1a P0803.399); id 1309374133809; Wed, 29 Jun 2011 20:02:13 +0100
Received: from MUT.jungle.bt.co.uk ([10.215.131.97]) by bagheera.jungle.bt.co.uk (8.13.5/8.12.8) with ESMTP id p5TJ2C03010090; Wed, 29 Jun 2011 20:02:12 +0100
Message-Id: <201106291902.p5TJ2C03010090@bagheera.jungle.bt.co.uk>
X-Mailer: QUALCOMM Windows Eudora Version 7.1.0.9
Date: Wed, 29 Jun 2011 20:02:11 +0100
To: 
From: Bob Briscoe 
In-Reply-To: <4E0B5682.9080905@erg.abdn.ac.uk>
References: <791AD3077F94194BB2BDD13565B6295D05E6DF22@PALLENE.office.hd> <4DF90477.4080906@mti-systems.com> <4DFA4101.9000306@erg.abdn.ac.uk> <201106282025.54990.mirja.kuehlewind@ikr.uni-stuttgart.de> <4E0B5682.9080905@erg.abdn.ac.uk>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"; format=flowed
X-Scanned-By: MIMEDefang 2.56 on 132.146.168.158
X-OriginalArrivalTime: 29 Jun 2011 19:02:15.0276 (UTC) FILETIME=[0F5B32C0:01CC368F]
Cc: ledbat@ietf.org
Subject: Re: [ledbat] ECN/AQM, was:  2 week last call for  draft-ietf-ledbat-congestion-06
X-BeenThere: ledbat@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Mailing list of the LEDBAT WG 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Wed, 29 Jun 2011 19:02:46 -0000

Gorry,

At 17:44 29/06/2011, Gorry Fairhurst wrote:
>On 28/06/2011 19:25, Mirja Kuehlewind wrote:
>>So in general, I'm not sure if we should talk about an TCP/IP mechanism (ECN)
>>in this draft when we only specify the algorithm and not talking about
>>anything TCP specific...?
>I'm not saying the group should define the mechanism, but I am 
>saying that from my point of view, it would be wise that ECN is 
>ignored, and that what matters is proper response to "congestion 
>indications", not to loss.

Did you miss a 'not' in the sentence?
"it would be wise that ECN is NOT ignored"


Bob


>>Mirja
>Gorry
>

________________________________________________________________
Bob Briscoe,                                BT Innovate & Design 


From gorry@erg.abdn.ac.uk  Thu Jun 30 01:40:27 2011
Return-Path: 
X-Original-To: ledbat@ietfa.amsl.com
Delivered-To: ledbat@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 04BBB21F86A0 for ; Thu, 30 Jun 2011 01:40:27 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -102.31
X-Spam-Level: 
X-Spam-Status: No, score=-102.31 tagged_above=-999 required=5 tests=[AWL=0.062, BAYES_00=-2.599, SARE_SUB_OBFU_Q1=0.227, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id xD3yOwIyV4CI for ; Thu, 30 Jun 2011 01:40:26 -0700 (PDT)
Received: from erg.abdn.ac.uk (dee.erg.abdn.ac.uk [IPv6:2001:630:241:204:203:baff:fe9a:8c9b]) by ietfa.amsl.com (Postfix) with ESMTP id 368D421F869F for ; Thu, 30 Jun 2011 01:40:25 -0700 (PDT)
Received: from gorry-mac.erg.abdn.ac.uk (gorry-mac.erg.abdn.ac.uk [139.133.207.5]) (authenticated bits=0) by erg.abdn.ac.uk (8.13.4/8.13.4) with ESMTP id p5U8eL6e005544 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NOT); Thu, 30 Jun 2011 09:40:21 +0100 (BST)
Message-ID: <4E0C3675.6080700@erg.abdn.ac.uk>
Date: Thu, 30 Jun 2011 09:40:21 +0100
From: Gorry Fairhurst 
Organization: The University of Aberdeen is a charity registered in Scotland,  No SC013683. 
User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.6; en-US; rv:1.9.2.17) Gecko/20110414 Thunderbird/3.1.10
MIME-Version: 1.0
To: Bob Briscoe 
References: <791AD3077F94194BB2BDD13565B6295D05E6DF22@PALLENE.office.hd> <4DF90477.4080906@mti-systems.com> <4DFA4101.9000306@erg.abdn.ac.uk> <201106282025.54990.mirja.kuehlewind@ikr.uni-stuttgart.de> <4E0B5682.9080905@erg.abdn.ac.uk> <201106291902.p5TJ2C03010090@bagheera.jungle.bt.co.uk>
In-Reply-To: <201106291902.p5TJ2C03010090@bagheera.jungle.bt.co.uk>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
X-ERG-MailScanner: Found to be clean
X-ERG-MailScanner-From: gorry@erg.abdn.ac.uk
Cc: ledbat@ietf.org
Subject: Re: [ledbat] ECN/AQM, was:  2 week last call for  draft-ietf-ledbat-congestion-06
X-BeenThere: ledbat@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
Reply-To: gorry@erg.abdn.ac.uk
List-Id: Mailing list of the LEDBAT WG 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Thu, 30 Jun 2011 08:40:27 -0000

Indeed I missed a "NOT".

To be clear, I think LEDBAT should indicate that ECN is a useful 
mechanism for congestion control, and that instantiations of the LEDBAT 
method in transports should be encouraged to support ECN functionality.

Gorry

On 29/06/2011 20:02, Bob Briscoe wrote:
> Gorry,
>
> At 17:44 29/06/2011, Gorry Fairhurst wrote:
>> On 28/06/2011 19:25, Mirja Kuehlewind wrote:
>>> So in general, I'm not sure if we should talk about an TCP/IP
>>> mechanism (ECN)
>>> in this draft when we only specify the algorithm and not talking about
>>> anything TCP specific...?
>> I'm not saying the group should define the mechanism, but I am saying
>> that from my point of view, it would be wise that ECN is ignored, and
>> that what matters is proper response to "congestion indications", not
>> to loss.
>
> Did you miss a 'not' in the sentence?
> "it would be wise that ECN is NOT ignored"
>
>
> Bob
>
>
>>> Mirja
>> Gorry
>>
>
> ________________________________________________________________
> Bob Briscoe, BT Innovate & Design
>


From mirja.kuehlewind@ikr.uni-stuttgart.de  Thu Jun 30 04:17:39 2011
Return-Path: 
X-Original-To: ledbat@ietfa.amsl.com
Delivered-To: ledbat@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 997BD21F8807 for ; Thu, 30 Jun 2011 04:17:39 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.004
X-Spam-Level: 
X-Spam-Status: No, score=-2.004 tagged_above=-999 required=5 tests=[AWL=0.018,  BAYES_00=-2.599, HELO_EQ_DE=0.35, SARE_SUB_OBFU_Q1=0.227]
Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Uh++MBRMSiki for ; Thu, 30 Jun 2011 04:17:39 -0700 (PDT)
Received: from mailsrv.ikr.uni-stuttgart.de (mailsrv.ikr.uni-stuttgart.de [129.69.170.2]) by ietfa.amsl.com (Postfix) with ESMTP id 95E2921F87EA for ; Thu, 30 Jun 2011 04:17:37 -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 7C6A1633B1; Thu, 30 Jun 2011 13:17:36 +0200 (CEST)
Received: from vpn-2-cl177 (vpn-2-cl177 [10.41.21.177]) by netsrv1.ikr.uni-stuttgart.de (Postfix) with ESMTP id 5706059A8A; Thu, 30 Jun 2011 13:17:36 +0200 (CEST)
From: Mirja Kuehlewind 
Organization: University of Stuttgart (Germany), IKR
To: Arjuna Sathiaseelan 
Date: Thu, 30 Jun 2011 13:17:35 +0200
User-Agent: KMail/1.9.10 (enterprise35 0.20101217.1207316)
References: <791AD3077F94194BB2BDD13565B6295D05E6DF22@PALLENE.office.hd> <201106291339.03755.mirja.kuehlewind@ikr.uni-stuttgart.de> 
In-Reply-To: 
X-KMail-QuotePrefix: > 
MIME-Version: 1.0
Content-Type: Text/Plain; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
Content-Disposition: inline
Message-Id: <201106301317.35684.mirja.kuehlewind@ikr.uni-stuttgart.de>
Cc: ledbat@ietf.org
Subject: [ledbat] MIN_CWND, was: ECN/AQM, was: 2 week last call for draft-ietf-ledbat-congestion-06
X-BeenThere: ledbat@ietf.org
X-Mailman-Version: 2.1.12
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, 30 Jun 2011 11:17:39 -0000

Hi Arjuna, hi Gorry,

I was not aware that there is any recommendation to send only one packet pe=
r=20
(up to) 64 sec. That seems a very high value for me. It actually means you=
=20
are not sending any data for 64sec no matter what is happening in this 64 s=
ec=20
(the link might be empty already after one second)...?

The recommendation of 2 packet per RTT was because we need to monitor chang=
es=20
in one-way delay with LEDBAT. That's why we though there should be at least=
 =20
two samples per RTT.=20

Thinking about it now, you can even get measurement samples by sending pack=
ets=20
without any data. But that makes the description more complicated.

One more remark: The draft says "MIN_CWND SHOULD be 2". That means if there=
 is=20
a good reason (in certain scenarios or with a certain framing protocol),=20
another value can be used. In case of allowing a CWND of 0, there has to so=
me=20
mechanism to restart the transmission. We did not regard such as mechanism =
as=20
part of the LEDBAT algorithm (so far).

How should be proceed here now?

Mirja=20


On Wednesday 29 June 2011 20:36:42 Arjuna Sathiaseelan wrote:
> Dear Mirja,
>   I am not sure whether cwnd of 2 packets/RTT during periods of heavy
> congestion is a good response - because other methods support lower
> rates for e.g TFRC would end up at a rate of 1 packet every 64 seconds
> or so. So I am wondering whether its possible to reduce the cwnd to a
> more lower rate as a response to sustained congestion.
>
>
> I agree with Bob and Gorry that allowing LEDBAT to support ECN is not
> going to hurt.
>
> Regards
> Arjuna
>
> On 29 June 2011 12:39, Mirja Kuehlewind
>
>  wrote:
> > Hi Arjuna,
> >
> > the minimum cwnd windows is 2 (MIN_CWND). That means LEDBAT will send at
> > least two 2 packets per RTT (which is 'basically' zero). LEDBAT will not
> > wait for any timers here but send continuously data with a very, very
> > slow rate.
> >
> > Mirja
> >
> > On Tuesday 28 June 2011 21:28:12 Arjuna Sathiaseelan wrote:
> >> Dear Mirja,
> >> =A0 Sorry- I am a newcomer to LEDBAT - and I am trying to understand
> >> this. So when you say LEDBAT reduces the sending rate to zero - does
> >> that mean LEDBAT doesnt have the notion of timers/timeouts? So if
> >> LEDBAT knows that the queues are being utilised could it wait for any
> >> amount of time without sending data?
> >>
> >> > And when LEDBAT is working correctly, there shouldn't occur any ECN
> >> > marking (and of course no losses neither) as LEDBAT will reduce it's
> >> > sending rate to basically zero before any queues overflow.
> >>
> >> Regards
> >> Arjuna
> >
> > --
> > -------------------------------------------------------------------
> > 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-=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 mirja.kuehlewind@ikr.uni-stuttgart.de  Thu Jun 30 04:41:33 2011
Return-Path: 
X-Original-To: ledbat@ietfa.amsl.com
Delivered-To: ledbat@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1455321F8662 for ; Thu, 30 Jun 2011 04:41:33 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.007
X-Spam-Level: 
X-Spam-Status: No, score=-2.007 tagged_above=-999 required=5 tests=[AWL=0.015,  BAYES_00=-2.599, HELO_EQ_DE=0.35, SARE_SUB_OBFU_Q1=0.227]
Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ZqsZA+uguPxI for ; Thu, 30 Jun 2011 04:41:32 -0700 (PDT)
Received: from mailsrv.ikr.uni-stuttgart.de (mailsrv.ikr.uni-stuttgart.de [129.69.170.2]) by ietfa.amsl.com (Postfix) with ESMTP id 27DCE21F865C for ; Thu, 30 Jun 2011 04:41:32 -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 EE806633B1; Thu, 30 Jun 2011 13:41:30 +0200 (CEST)
Received: from vpn-2-cl177 (vpn-2-cl177 [10.41.21.177]) by netsrv1.ikr.uni-stuttgart.de (Postfix) with ESMTP id E171B59A8A; Thu, 30 Jun 2011 13:41:30 +0200 (CEST)
From: Mirja Kuehlewind 
Organization: University of Stuttgart (Germany), IKR
To: gorry@erg.abdn.ac.uk
Date: Thu, 30 Jun 2011 13:41:29 +0200
User-Agent: KMail/1.9.10 (enterprise35 0.20101217.1207316)
References: <791AD3077F94194BB2BDD13565B6295D05E6DF22@PALLENE.office.hd> <201106291902.p5TJ2C03010090@bagheera.jungle.bt.co.uk> <4E0C3675.6080700@erg.abdn.ac.uk>
In-Reply-To: <4E0C3675.6080700@erg.abdn.ac.uk>
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: <201106301341.29881.mirja.kuehlewind@ikr.uni-stuttgart.de>
Cc: ledbat@ietf.org
Subject: Re: [ledbat] ECN/AQM
X-BeenThere: ledbat@ietf.org
X-Mailman-Version: 2.1.12
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, 30 Jun 2011 11:41:33 -0000

Hi everybody,

I try to recap now on the ECN issue to see which action is actually needed =
for=20
the draft. (Btw. I believe we DO have the same opinion):

There are two question:

1. Should LEDBAT react on ECN marks as it would on loss?

A very clear YES here! Nobody wants to ignore ECN marks. The reaction to EC=
N=20
is already specified in RFC3168 to be the same than to loss (for every=20
congestion control). This was not mention explicit in the current draft=20
version. I've been adding the following sentence for the next version (in=20
2.2. Applicability):

"If LEDBAT is used with a framing protocol that is
	 ECN-capable, it should react to ECN marks as it would to losses=20
	 as specified in RFC3168."


2. Should we recommend that transports using LEDBAT should use/enable ECN
as well?

Here are the responses of everybody:

Bob:
"Sending ECN-capable packets ought to be recommended for LEDBAT, so=20
that if ever ECN is deployed in the network, LEDBAT can take advantage of i=
t."

Gorry:
"To be clear, I think LEDBAT should indicate that ECN is a useful=20
mechanism for congestion control, and that instantiations of the LEDBAT=20
method in transports should be encouraged to support ECN functionality."

Arjuna:
"I agree with Bob and Gorry that allowing LEDBAT to support ECN is not
going to hurt."
Agree, ECN does not hurt...

I (Mirja):
=2D> I was saying that this question does not need to be answered in this d=
raft,=20
as this draft is not talking about ANY framing protocol issues (beside some=
=20
hard requirement on the framing protocol e.g. any kind of feedback is need)=
=2E=20
It only documents the LEDBAT algorithm for informational purpose (its not a=
=20
protocol spec nor an implementation guide).=20

How should we continue here? Should we add some text? If yes, where should =
we=20
add the text? Somebody wants to make a proposal for text?

Mirja


On Thursday 30 June 2011 10:40:21 Gorry Fairhurst wrote:
> Indeed I missed a "NOT".
>
> To be clear, I think LEDBAT should indicate that ECN is a useful
> mechanism for congestion control, and that instantiations of the LEDBAT
> method in transports should be encouraged to support ECN functionality.
>
> Gorry
>
> On 29/06/2011 20:02, Bob Briscoe wrote:
> > Gorry,
> >
> > At 17:44 29/06/2011, Gorry Fairhurst wrote:
> >> On 28/06/2011 19:25, Mirja Kuehlewind wrote:
> >>> So in general, I'm not sure if we should talk about an TCP/IP
> >>> mechanism (ECN)
> >>> in this draft when we only specify the algorithm and not talking about
> >>> anything TCP specific...?
> >>
> >> I'm not saying the group should define the mechanism, but I am saying
> >> that from my point of view, it would be wise that ECN is ignored, and
> >> that what matters is proper response to "congestion indications", not
> >> to loss.
> >
> > Did you miss a 'not' in the sentence?
> > "it would be wise that ECN is NOT ignored"
> >
> >
> > Bob
> >
> >>> Mirja
> >>
> >> Gorry
> >
> > ________________________________________________________________
> > Bob Briscoe, BT Innovate & Design



=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 jana.iyengar@gmail.com  Thu Jun 30 08:43:16 2011
Return-Path: 
X-Original-To: ledbat@ietfa.amsl.com
Delivered-To: ledbat@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7DCB111E81B5 for ; Thu, 30 Jun 2011 08:43:16 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.372
X-Spam-Level: 
X-Spam-Status: No, score=-3.372 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1, SARE_SUB_OBFU_Q1=0.227]
Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id lfrgrVeMJ9aB for ; Thu, 30 Jun 2011 08:43:15 -0700 (PDT)
Received: from mail-qw0-f44.google.com (mail-qw0-f44.google.com [209.85.216.44]) by ietfa.amsl.com (Postfix) with ESMTP id 6B05B11E8185 for ; Thu, 30 Jun 2011 08:43:11 -0700 (PDT)
Received: by qwc23 with SMTP id 23so1938874qwc.31 for ; Thu, 30 Jun 2011 08:43:10 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=message-id:date:from:reply-to:organization:user-agent:mime-version :to:cc:subject:references:in-reply-to:content-type :content-transfer-encoding; bh=wSTF/Rf7Sdh3S+M0dnSps3lS3EcXCrD2um6WJ27Z9zE=; b=XI70B6xgb9TXePB3SJcLTQ5e2TOQ7aaJkmeu5zcnTRUPiDma7sNd7gD64igdXn8G7S v4P8UdiPi/YigRHmgVT1VM1x9puwuKu7O/c1wNjUZ8cmWmLDoQdeAWDVbcWM81l9hupq 4j4kEMyExXuTIjBwrMx3mgf/6pHTrYVU7144s=
Received: by 10.224.63.222 with SMTP id c30mr1784929qai.108.1309448589063; Thu, 30 Jun 2011 08:43:09 -0700 (PDT)
Received: from surutti.fandm.edu (c-174-59-61-31.hsd1.pa.comcast.net [174.59.61.31]) by mx.google.com with ESMTPS id e18sm1812137qcs.5.2011.06.30.08.43.07 (version=TLSv1/SSLv3 cipher=OTHER); Thu, 30 Jun 2011 08:43:08 -0700 (PDT)
Message-ID: <4E0C9989.5040505@fandm.edu>
Date: Thu, 30 Jun 2011 11:43:05 -0400
From: Janardhan Iyengar 
Organization: Franklin & Marshall College
User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.6; en-US; rv:1.9.2.18) Gecko/20110616 Lightning/1.0b2 Thunderbird/3.1.11
MIME-Version: 1.0
To: Mirja Kuehlewind 
References: <791AD3077F94194BB2BDD13565B6295D05E6DF22@PALLENE.office.hd>	<201106291902.p5TJ2C03010090@bagheera.jungle.bt.co.uk>	<4E0C3675.6080700@erg.abdn.ac.uk> <201106301341.29881.mirja.kuehlewind@ikr.uni-stuttgart.de>
In-Reply-To: <201106301341.29881.mirja.kuehlewind@ikr.uni-stuttgart.de>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
Cc: Bob Briscoe , ledbat@ietf.org
Subject: Re: [ledbat] ECN/AQM
X-BeenThere: ledbat@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
Reply-To: janardhan.iyengar@fandm.edu
List-Id: Mailing list of the LEDBAT WG 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Thu, 30 Jun 2011 15:43:16 -0000

Dear all,

There is no question that LEDBAT flows will experience loss in the wild, especially, as Bob so eloquently pointed out, when congestion is deeper in the core.

It seems to me that we are all in agreement that ECN marks must be respected.  I don't think that the LEDBAT draft can do more than state what a LEDBAT flow does in the presence of an ECN mark, as Mirja has already included in the Applicability Section.  After all, LEDBAT does not get into protocol mechanisms per se, and cannot really _specify_ anything more with ECN.

For LEDBAT to actively "encourage" ECN adoption, there should be some explicit benefit to the ECN-capable LEDBAT flows over the non-ECN capable ones. And within the scope of the draft, I don't see that we can point to any such benefits.  However, perhaps we could say something in the applicability section about how ECN and AQM can benefit the applications that we expect to use LEDBAT.  Any suggestions?

- jana

On 6/30/11 7:41 AM, Mirja Kuehlewind wrote:
> Hi everybody,
>
> I try to recap now on the ECN issue to see which action is actually needed for
> the draft. (Btw. I believe we DO have the same opinion):
>
> There are two question:
>
> 1. Should LEDBAT react on ECN marks as it would on loss?
>
> A very clear YES here! Nobody wants to ignore ECN marks. The reaction to ECN
> is already specified in RFC3168 to be the same than to loss (for every
> congestion control). This was not mention explicit in the current draft
> version. I've been adding the following sentence for the next version (in
> 2.2. Applicability):
>
> "If LEDBAT is used with a framing protocol that is
> 	 ECN-capable, it should react to ECN marks as it would to losses
> 	 as specified in RFC3168."
>
>
> 2. Should we recommend that transports using LEDBAT should use/enable ECN
> as well?
>
> Here are the responses of everybody:
>
> Bob:
> "Sending ECN-capable packets ought to be recommended for LEDBAT, so
> that if ever ECN is deployed in the network, LEDBAT can take advantage of it."
>
> Gorry:
> "To be clear, I think LEDBAT should indicate that ECN is a useful
> mechanism for congestion control, and that instantiations of the LEDBAT
> method in transports should be encouraged to support ECN functionality."
>
> Arjuna:
> "I agree with Bob and Gorry that allowing LEDBAT to support ECN is not
> going to hurt."
> Agree, ECN does not hurt...
>
> I (Mirja):
> ->  I was saying that this question does not need to be answered in this draft,
> as this draft is not talking about ANY framing protocol issues (beside some
> hard requirement on the framing protocol e.g. any kind of feedback is need).
> It only documents the LEDBAT algorithm for informational purpose (its not a
> protocol spec nor an implementation guide).
>
> How should we continue here? Should we add some text? If yes, where should we
> add the text? Somebody wants to make a proposal for text?
>
> Mirja
>
>
> On Thursday 30 June 2011 10:40:21 Gorry Fairhurst wrote:
>> Indeed I missed a "NOT".
>>
>> To be clear, I think LEDBAT should indicate that ECN is a useful
>> mechanism for congestion control, and that instantiations of the LEDBAT
>> method in transports should be encouraged to support ECN functionality.
>>
>> Gorry
>>
>> On 29/06/2011 20:02, Bob Briscoe wrote:
>>> Gorry,
>>>
>>> At 17:44 29/06/2011, Gorry Fairhurst wrote:
>>>> On 28/06/2011 19:25, Mirja Kuehlewind wrote:
>>>>> So in general, I'm not sure if we should talk about an TCP/IP
>>>>> mechanism (ECN)
>>>>> in this draft when we only specify the algorithm and not talking about
>>>>> anything TCP specific...?
>>>>
>>>> I'm not saying the group should define the mechanism, but I am saying
>>>> that from my point of view, it would be wise that ECN is ignored, and
>>>> that what matters is proper response to "congestion indications", not
>>>> to loss.
>>>
>>> Did you miss a 'not' in the sentence?
>>> "it would be wise that ECN is NOT ignored"
>>>
>>>
>>> Bob
>>>
>>>>> Mirja
>>>>
>>>> Gorry
>>>
>>> ________________________________________________________________
>>> Bob Briscoe, BT Innovate&  Design
>
>
>

-- 
Janardhan Iyengar
Assistant Professor, Computer Science
Franklin & Marshall College
http://www.fandm.edu/jiyengar

From arjuna.sathiaseelan@gmail.com  Thu Jun 30 10:24:01 2011
Return-Path: 
X-Original-To: ledbat@ietfa.amsl.com
Delivered-To: ledbat@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F0A1D11E8285 for ; Thu, 30 Jun 2011 10:24:01 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.75
X-Spam-Level: 
X-Spam-Status: No, score=-2.75 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_LOW=-1, SARE_SUB_OBFU_Q1=0.227]
Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 8DJAqVDlbju7 for ; Thu, 30 Jun 2011 10:24:00 -0700 (PDT)
Received: from mail-qy0-f172.google.com (mail-qy0-f172.google.com [209.85.216.172]) by ietfa.amsl.com (Postfix) with ESMTP id 0E47F11E8282 for ; Thu, 30 Jun 2011 10:23:59 -0700 (PDT)
Received: by qyk9 with SMTP id 9so208846qyk.10 for ; Thu, 30 Jun 2011 10:23:59 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:cc:content-type :content-transfer-encoding; bh=+7uQAGbjpyDZXcrqPgFeahsiiUB4MK3n3l27zDxg2bc=; b=SFikieBafIt298nf7jqfH/S+1EB0ajsn4/YoZFRy1tkms4xKIGscCu/YX6AJcrZdD0 DcsP6FWMVeFf1Cj7jkrz5J2YFIxp/sGR/5U/NfK5VsaFvh7z710227kQTgNBCeVoDdu1 2mniQSb3WGn3svjLH6XnoVQ37SS91lA1ka3EE=
MIME-Version: 1.0
Received: by 10.229.98.20 with SMTP id o20mr1692565qcn.216.1309454639406; Thu, 30 Jun 2011 10:23:59 -0700 (PDT)
Sender: arjuna.sathiaseelan@gmail.com
Received: by 10.229.87.8 with HTTP; Thu, 30 Jun 2011 10:23:59 -0700 (PDT)
In-Reply-To: <201106301317.35684.mirja.kuehlewind@ikr.uni-stuttgart.de>
References: <791AD3077F94194BB2BDD13565B6295D05E6DF22@PALLENE.office.hd> <201106291339.03755.mirja.kuehlewind@ikr.uni-stuttgart.de>  <201106301317.35684.mirja.kuehlewind@ikr.uni-stuttgart.de>
Date: Thu, 30 Jun 2011 18:23:59 +0100
X-Google-Sender-Auth: PQGKxiVo6H5cvr50EXA_VCG3bGo
Message-ID: 
From: Arjuna Sathiaseelan 
To: Mirja Kuehlewind 
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable
Cc: ledbat@ietf.org
Subject: Re: [ledbat] MIN_CWND, was: ECN/AQM, was: 2 week last call for draft-ietf-ledbat-congestion-06
X-BeenThere: ledbat@ietf.org
X-Mailman-Version: 2.1.12
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, 30 Jun 2011 17:24:02 -0000

Dear Mirja,
  We need to think about this..The current nature of transport
protocols seem to be overly conservative to me - for e.g. in the
presence of a RTO, the ssthresh can reduce to a very low value and it
can take ages for a cwnd to grow - so it would be better to stop and
start a new TCP connection! So based on such a theory, we could say
why not use two packets/RTT during severe congestion - because this is
no worse than a LEDBAT starting a new connection with two packets/RTT.
However, the problem here is the lower than best effort nature of
these methods and I dont think we can go in the direction of ICCRG. So
probably we need to stick to conservative methods.

IMHO - I think the best option for LEDBAT during severe congestion is
not to send any data (thats the reason why I asked you the question
about timers and timeouts in my earlier email). However I also agree
that if we dont that we have no way of figuring out the necessary
metrics for LEDTBAT without sending any data.

So howabout a restart mechanism - when the cwnd becomes 0 - can LEDBAT
be allowed to try transmitting one or two packets every second  - and
if this is successful (noting the feedback indicates there is no
congestion - based on the observed delay samples) then it can follow
the normal slow-start procedure? If it still notices congestion, it
stops sending for another second and restarts again..and so on..

Just thoughts..

Regards
Arjuna



On 30 June 2011 12:17, Mirja Kuehlewind
 wrote:
> Hi Arjuna, hi Gorry,
>
> I was not aware that there is any recommendation to send only one packet =
per
> (up to) 64 sec. That seems a very high value for me. It actually means yo=
u
> are not sending any data for 64sec no matter what is happening in this 64=
 sec
> (the link might be empty already after one second)...?
>
> The recommendation of 2 packet per RTT was because we need to monitor cha=
nges
> in one-way delay with LEDBAT. That's why we though there should be at lea=
st
> two samples per RTT.
>
> Thinking about it now, you can even get measurement samples by sending pa=
ckets
> without any data. But that makes the description more complicated.
>
> One more remark: The draft says "MIN_CWND SHOULD be 2". That means if the=
re is
> a good reason (in certain scenarios or with a certain framing protocol),
> another value can be used. In case of allowing a CWND of 0, there has to =
some
> mechanism to restart the transmission. We did not regard such as mechanis=
m as
> part of the LEDBAT algorithm (so far).
>
> How should be proceed here now?
>
> Mirja
>
>
> On Wednesday 29 June 2011 20:36:42 Arjuna Sathiaseelan wrote:
>> Dear Mirja,
>> =A0 I am not sure whether cwnd of 2 packets/RTT during periods of heavy
>> congestion is a good response - because other methods support lower
>> rates for e.g TFRC would end up at a rate of 1 packet every 64 seconds
>> or so. So I am wondering whether its possible to reduce the cwnd to a
>> more lower rate as a response to sustained congestion.
>>
>>
>> I agree with Bob and Gorry that allowing LEDBAT to support ECN is not
>> going to hurt.
>>
>> Regards
>> Arjuna
>>
>> On 29 June 2011 12:39, Mirja Kuehlewind
>>
>>  wrote:
>> > Hi Arjuna,
>> >
>> > the minimum cwnd windows is 2 (MIN_CWND). That means LEDBAT will send =
at
>> > least two 2 packets per RTT (which is 'basically' zero). LEDBAT will n=
ot
>> > wait for any timers here but send continuously data with a very, very
>> > slow rate.
>> >
>> > Mirja
>> >
>> > On Tuesday 28 June 2011 21:28:12 Arjuna Sathiaseelan wrote:
>> >> Dear Mirja,
>> >> =A0 Sorry- I am a newcomer to LEDBAT - and I am trying to understand
>> >> this. So when you say LEDBAT reduces the sending rate to zero - does
>> >> that mean LEDBAT doesnt have the notion of timers/timeouts? So if
>> >> LEDBAT knows that the queues are being utilised could it wait for any
>> >> amount of time without sending data?
>> >>
>> >> > And when LEDBAT is working correctly, there shouldn't occur any ECN
>> >> > marking (and of course no losses neither) as LEDBAT will reduce it'=
s
>> >> > sending rate to basically zero before any queues overflow.
>> >>
>> >> Regards
>> >> Arjuna
>> >
>> > --
>> > -------------------------------------------------------------------
>> > 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
>> > -------------------------------------------------------------------
>
>
>
> --
> -------------------------------------------------------------------
> 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
> -------------------------------------------------------------------
>

From jana.iyengar@gmail.com  Thu Jun 30 15:32:21 2011
Return-Path: 
X-Original-To: ledbat@ietfa.amsl.com
Delivered-To: ledbat@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 21FDD11E80D8 for ; Thu, 30 Jun 2011 15:32:21 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.372
X-Spam-Level: 
X-Spam-Status: No, score=-3.372 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1, SARE_SUB_OBFU_Q1=0.227]
Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id zYGxK7TyB7PL for ; Thu, 30 Jun 2011 15:32:20 -0700 (PDT)
Received: from mail-vx0-f172.google.com (mail-vx0-f172.google.com [209.85.220.172]) by ietfa.amsl.com (Postfix) with ESMTP id 1B11111E807E for ; Thu, 30 Jun 2011 15:32:19 -0700 (PDT)
Received: by vxi40 with SMTP id 40so2428443vxi.31 for ; Thu, 30 Jun 2011 15:32:19 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=message-id:date:from:reply-to:organization:user-agent:mime-version :to:cc:subject:references:in-reply-to:content-type :content-transfer-encoding; bh=U0ZJIiWDyj/TwT1uf9zCTEOJqpTdlgOJZYbwZS2DA/4=; b=gGKmv9vqgJCF3EBrjI4gAEcnc6dLsXtgjl0URWzcTP+BiKgDgcXCLhjT4aU7VY0F4W 0OMbqM4hMjXoRALQ2aqcjy35oOdepvFg61/7h1CUrRMl6q2cb9D8CXEHwp6cDCGO9pc+ BRA3QwQ0NNVyGq9/t526obHyfMcIuDsKkNt8U=
Received: by 10.220.5.207 with SMTP id 15mr669107vcw.226.1309473137190; Thu, 30 Jun 2011 15:32:17 -0700 (PDT)
Received: from surutti.fandm.edu (dhcp-155-68-162-85.fandm.edu [155.68.162.85]) by mx.google.com with ESMTPS id q15sm247354vch.17.2011.06.30.15.32.15 (version=TLSv1/SSLv3 cipher=OTHER); Thu, 30 Jun 2011 15:32:16 -0700 (PDT)
Message-ID: <4E0CF96E.90105@fandm.edu>
Date: Thu, 30 Jun 2011 18:32:14 -0400
From: Janardhan Iyengar 
Organization: Franklin & Marshall College
User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.6; en-US; rv:1.9.2.18) Gecko/20110616 Lightning/1.0b2 Thunderbird/3.1.11
MIME-Version: 1.0
To: Arjuna Sathiaseelan 
References: <791AD3077F94194BB2BDD13565B6295D05E6DF22@PALLENE.office.hd>	<201106291339.03755.mirja.kuehlewind@ikr.uni-stuttgart.de>		<201106301317.35684.mirja.kuehlewind@ikr.uni-stuttgart.de> 
In-Reply-To: 
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 8bit
Cc: ledbat@ietf.org
Subject: Re: [ledbat] MIN_CWND, was: ECN/AQM, was: 2 week last call for draft-ietf-ledbat-congestion-06
X-BeenThere: ledbat@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
Reply-To: janardhan.iyengar@fandm.edu
List-Id: Mailing list of the LEDBAT WG 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Thu, 30 Jun 2011 22:32:21 -0000

Arjuna,

Thank you for raising this question --- it is an important one that we missed but, IMHO, need to resolve.  LEDBAT does not currently account for rate reduction in the case of extreme congestion, as both TFRC and TCP do.  A couple of thoughts offhand:

-  Under extreme congestion where TCP would have timed-out and TFRC would have backed-down significantly, LEDBAT will only halve its sending rate.  If LEDBAT gets a good delay measurement, then the sender _could_ set its congestion window to 0, but what do we do when the congestion is extreme and detection is loss-based?

-  There is no notion of a timer in LEDBAT so far.  If we decide to introduce a timer, we could use the current RTT estimate to seed it, or go with a fixed 1 second as the initial seed time, with a backoff of the timer on a subsequent loss.  We could then use the timer to decide how long to go idle before sending out the next packet.

I'll try to hash this out some more and come up with something useful tonight.
- jana


On 6/30/11 1:23 PM, Arjuna Sathiaseelan wrote:
> Dear Mirja,
>    We need to think about this..The current nature of transport
> protocols seem to be overly conservative to me - for e.g. in the
> presence of a RTO, the ssthresh can reduce to a very low value and it
> can take ages for a cwnd to grow - so it would be better to stop and
> start a new TCP connection! So based on such a theory, we could say
> why not use two packets/RTT during severe congestion - because this is
> no worse than a LEDBAT starting a new connection with two packets/RTT.
> However, the problem here is the lower than best effort nature of
> these methods and I dont think we can go in the direction of ICCRG. So
> probably we need to stick to conservative methods.
>
> IMHO - I think the best option for LEDBAT during severe congestion is
> not to send any data (thats the reason why I asked you the question
> about timers and timeouts in my earlier email). However I also agree
> that if we dont that we have no way of figuring out the necessary
> metrics for LEDTBAT without sending any data.
>
> So howabout a restart mechanism - when the cwnd becomes 0 - can LEDBAT
> be allowed to try transmitting one or two packets every second  - and
> if this is successful (noting the feedback indicates there is no
> congestion - based on the observed delay samples) then it can follow
> the normal slow-start procedure? If it still notices congestion, it
> stops sending for another second and restarts again..and so on..
>
> Just thoughts..
>
> Regards
> Arjuna
>
>
>
> On 30 June 2011 12:17, Mirja Kuehlewind
>   wrote:
>> Hi Arjuna, hi Gorry,
>>
>> I was not aware that there is any recommendation to send only one packet per
>> (up to) 64 sec. That seems a very high value for me. It actually means you
>> are not sending any data for 64sec no matter what is happening in this 64 sec
>> (the link might be empty already after one second)...?
>>
>> The recommendation of 2 packet per RTT was because we need to monitor changes
>> in one-way delay with LEDBAT. That's why we though there should be at least
>> two samples per RTT.
>>
>> Thinking about it now, you can even get measurement samples by sending packets
>> without any data. But that makes the description more complicated.
>>
>> One more remark: The draft says "MIN_CWND SHOULD be 2". That means if there is
>> a good reason (in certain scenarios or with a certain framing protocol),
>> another value can be used. In case of allowing a CWND of 0, there has to some
>> mechanism to restart the transmission. We did not regard such as mechanism as
>> part of the LEDBAT algorithm (so far).
>>
>> How should be proceed here now?
>>
>> Mirja
>>
>>
>> On Wednesday 29 June 2011 20:36:42 Arjuna Sathiaseelan wrote:
>>> Dear Mirja,
>>>    I am not sure whether cwnd of 2 packets/RTT during periods of heavy
>>> congestion is a good response - because other methods support lower
>>> rates for e.g TFRC would end up at a rate of 1 packet every 64 seconds
>>> or so. So I am wondering whether its possible to reduce the cwnd to a
>>> more lower rate as a response to sustained congestion.
>>>
>>>
>>> I agree with Bob and Gorry that allowing LEDBAT to support ECN is not
>>> going to hurt.
>>>
>>> Regards
>>> Arjuna
>>>
>>> On 29 June 2011 12:39, Mirja Kuehlewind
>>>
>>>   wrote:
>>>> Hi Arjuna,
>>>>
>>>> the minimum cwnd windows is 2 (MIN_CWND). That means LEDBAT will send at
>>>> least two 2 packets per RTT (which is 'basically' zero). LEDBAT will not
>>>> wait for any timers here but send continuously data with a very, very
>>>> slow rate.
>>>>
>>>> Mirja
>>>>
>>>> On Tuesday 28 June 2011 21:28:12 Arjuna Sathiaseelan wrote:
>>>>> Dear Mirja,
>>>>>    Sorry- I am a newcomer to LEDBAT - and I am trying to understand
>>>>> this. So when you say LEDBAT reduces the sending rate to zero - does
>>>>> that mean LEDBAT doesnt have the notion of timers/timeouts? So if
>>>>> LEDBAT knows that the queues are being utilised could it wait for any
>>>>> amount of time without sending data?
>>>>>
>>>>>> And when LEDBAT is working correctly, there shouldn't occur any ECN
>>>>>> marking (and of course no losses neither) as LEDBAT will reduce it's
>>>>>> sending rate to basically zero before any queues overflow.
>>>>>
>>>>> Regards
>>>>> Arjuna
>>>>
>>>> --
>>>> -------------------------------------------------------------------
>>>> Dipl.-Ing. Mirja Kühlewind
>>>> 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
>>>> -------------------------------------------------------------------
>>
>>
>>
>> --
>> -------------------------------------------------------------------
>> Dipl.-Ing. Mirja Kühlewind
>> 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

-- 
Janardhan Iyengar
Assistant Professor, Computer Science
Franklin & Marshall College
http://www.fandm.edu/jiyengar

From lachlan.andrew@gmail.com  Thu Jun 30 15:44:45 2011
Return-Path: 
X-Original-To: ledbat@ietfa.amsl.com
Delivered-To: ledbat@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6743F11E82DF for ; Thu, 30 Jun 2011 15:44:45 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -103.372
X-Spam-Level: 
X-Spam-Status: No, score=-103.372 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1, SARE_SUB_OBFU_Q1=0.227, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id T3E63PhveAzw for ; Thu, 30 Jun 2011 15:44:42 -0700 (PDT)
Received: from mail-ww0-f42.google.com (mail-ww0-f42.google.com [74.125.82.42]) by ietfa.amsl.com (Postfix) with ESMTP id 65A1411E822B for ; Thu, 30 Jun 2011 15:44:42 -0700 (PDT)
Received: by wwg11 with SMTP id 11so1212111wwg.1 for ; Thu, 30 Jun 2011 15:44:41 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type:content-transfer-encoding; bh=hPczOgWNU/yzpBJs2f648SId7QqxftodOVqo553LoPo=; b=bDmB7IfRccf1iE+H9WKjLJapt8hh6jk78gmsVPfSZj0QnlCxywvFXTFvkqiK3YZpNk qWdEFEJtBVaq5bETqHVlVABeB4BOWjokuhCY4BemEmXrDBUZYYEmynX6ONaZV7Ta9s5o VqdMO0nIjZbt128ZK4e7gjzMIbGeGl9kRlTE4=
Received: by 10.216.229.222 with SMTP id h72mr2288979weq.34.1309473881085; Thu, 30 Jun 2011 15:44:41 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.216.71.3 with HTTP; Thu, 30 Jun 2011 15:44:21 -0700 (PDT)
In-Reply-To: <4E0C9989.5040505@fandm.edu>
References: <791AD3077F94194BB2BDD13565B6295D05E6DF22@PALLENE.office.hd> <201106291902.p5TJ2C03010090@bagheera.jungle.bt.co.uk> <4E0C3675.6080700@erg.abdn.ac.uk> <201106301341.29881.mirja.kuehlewind@ikr.uni-stuttgart.de> <4E0C9989.5040505@fandm.edu>
From: Lachlan Andrew 
Date: Fri, 1 Jul 2011 08:44:21 +1000
Message-ID: 
To: janardhan.iyengar@fandm.edu, ledbat@ietf.org
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable
Cc: Bob Briscoe 
Subject: Re: [ledbat] ECN/AQM
X-BeenThere: ledbat@ietf.org
X-Mailman-Version: 2.1.12
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, 30 Jun 2011 22:44:45 -0000

On 1 July 2011 01:43, Janardhan Iyengar  wrote:
>
> It seems to me that we are all in agreement that ECN marks must be
> respected.
>
> For LEDBAT to actively "encourage" ECN adoption, there should be some
> explicit benefit to the ECN-capable LEDBAT flows over the non-ECN capable
> ones. And within the scope of the draft, I don't see that we can point to
> any such benefits.

Greetings Jana / all,

I haven't been following Letbat, and this proposal may be heretical,
but it is easy to give a Letbat flow an incentive to be ECN capable,
by specifying that it should back off more when it sees loss than when
it sees ECN.

As long as it backs off at least as much as Reno does on loss, then
this does not violate the spirit of RFC 3168.  It does violate the
requirement that response to ECN be the same as loss, but that was
written at a time when loss was considered synonymous with congestion;
really ECN should be treated more like extra delay for a delay-based
algorithm.

$0.02,
Lachlan

--=20
Lachlan Andrew=A0 Centre for Advanced Internet Architectures (CAIA)
Swinburne University of Technology, Melbourne, Australia

Ph +61 3 9214 4837

From lachlan.andrew@gmail.com  Thu Jun 30 15:54:32 2011
Return-Path: 
X-Original-To: ledbat@ietfa.amsl.com
Delivered-To: ledbat@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0706211E807E for ; Thu, 30 Jun 2011 15:54:32 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -103.372
X-Spam-Level: 
X-Spam-Status: No, score=-103.372 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1, SARE_SUB_OBFU_Q1=0.227, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 1W1E11MdPbue for ; Thu, 30 Jun 2011 15:54:31 -0700 (PDT)
Received: from mail-wy0-f172.google.com (mail-wy0-f172.google.com [74.125.82.172]) by ietfa.amsl.com (Postfix) with ESMTP id 23FA411E8075 for ; Thu, 30 Jun 2011 15:54:30 -0700 (PDT)
Received: by wyj26 with SMTP id 26so2142181wyj.31 for ; Thu, 30 Jun 2011 15:54:30 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :content-type:content-transfer-encoding; bh=x/QyQA0Ob5yG8NkKqAbSNZFr/jvAvKH1kokLsJQpY8k=; b=GcmH9FA/yPvCIiWf6GDCqzfnJvwmkNc1SI8/93NRU7X8hVcWHMVpLg7MVrLkx+qfPI FmKEYaFr+2ZXroyvRp53Pa+Cz6RrzxNB12/AoeBBMt+stNN9Rm1bhqkQB9jRccWNPhU4 TA3cXDmOmzPvEwWt8r2ahadMm6/WhXKYBrXzs=
Received: by 10.216.229.222 with SMTP id h72mr2294823weq.34.1309474469067; Thu, 30 Jun 2011 15:54:29 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.216.71.3 with HTTP; Thu, 30 Jun 2011 15:54:09 -0700 (PDT)
In-Reply-To: 
References: <791AD3077F94194BB2BDD13565B6295D05E6DF22@PALLENE.office.hd> <201106291339.03755.mirja.kuehlewind@ikr.uni-stuttgart.de>  <201106301317.35684.mirja.kuehlewind@ikr.uni-stuttgart.de> 
From: Lachlan Andrew 
Date: Fri, 1 Jul 2011 08:54:09 +1000
Message-ID: 
To: Arjuna Sathiaseelan , ledbat@ietf.org
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable
Subject: Re: [ledbat] MIN_CWND, was: ECN/AQM, was: 2 week last call for draft-ietf-ledbat-congestion-06
X-BeenThere: ledbat@ietf.org
X-Mailman-Version: 2.1.12
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, 30 Jun 2011 22:54:32 -0000

Greetings Arjuna,

I agree with your main point, that Ledbat must sensibly and
conservatively handle high congestion.

On 1 July 2011 03:23, Arjuna Sathiaseelan  wrote:
> The current nature of transport
> protocols seem to be overly conservative to me - for e.g. in the
> presence of a RTO, the ssthresh can reduce to a very low value and it
> can take ages for a cwnd to grow - so it would be better to stop and
> start a new TCP connection!

No.  This confuses "better" with "gives a higher throughput to this
user".  The whole point of congestion control is to do what is good
for the network rather than maximizing the flow's own throughput.
Throwing away information that the network is currently congested is
not a *better* response.

Cheers,
Lachlan

--=20
Lachlan Andrew=A0 Centre for Advanced Internet Architectures (CAIA)
Swinburne University of Technology, Melbourne, Australia

Ph +61 3 9214 4837

From bob.briscoe@bt.com  Thu Jun 30 17:08:39 2011
Return-Path: 
X-Original-To: ledbat@ietfa.amsl.com
Delivered-To: ledbat@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E58D311E80E9 for ; Thu, 30 Jun 2011 17:08:39 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.18
X-Spam-Level: 
X-Spam-Status: No, score=-3.18 tagged_above=-999 required=5 tests=[AWL=0.192,  BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1, SARE_SUB_OBFU_Q1=0.227]
Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id g2kT+PjLoxFL for ; Thu, 30 Jun 2011 17:08:38 -0700 (PDT)
Received: from smtp2.smtp.bt.com (smtp2.smtp.bt.com [217.32.164.150]) by ietfa.amsl.com (Postfix) with ESMTP id 6652011E80C7 for ; Thu, 30 Jun 2011 17:08:38 -0700 (PDT)
Received: from i2kc08-ukbr.domain1.systemhost.net ([193.113.197.71]) by smtp2.smtp.bt.com with Microsoft SMTPSVC(6.0.3790.4675);  Fri, 1 Jul 2011 01:08:35 +0100
Received: from cbibipnt08.iuser.iroot.adidom.com ([147.149.100.81]) by i2kc08-ukbr.domain1.systemhost.net with Microsoft SMTPSVC(6.0.3790.4675); Fri, 1 Jul 2011 01:08:35 +0100
Received: From bagheera.jungle.bt.co.uk ([132.146.168.158]) by cbibipnt08.iuser.iroot.adidom.com (WebShield SMTP v4.5 MR1a P0803.399); id 1309478914784; Fri, 1 Jul 2011 01:08:34 +0100
Received: from MUT.jungle.bt.co.uk ([10.73.64.46]) by bagheera.jungle.bt.co.uk (8.13.5/8.12.8) with ESMTP id p6108VZe017272; Fri, 1 Jul 2011 01:08:31 +0100
Message-Id: <201107010008.p6108VZe017272@bagheera.jungle.bt.co.uk>
X-Mailer: QUALCOMM Windows Eudora Version 7.1.0.9
Date: Fri, 01 Jul 2011 01:08:30 +0100
To: 
From: Bob Briscoe 
In-Reply-To: <4E0C9989.5040505@fandm.edu>
References: <791AD3077F94194BB2BDD13565B6295D05E6DF22@PALLENE.office.hd> <201106291902.p5TJ2C03010090@bagheera.jungle.bt.co.uk> <4E0C3675.6080700@erg.abdn.ac.uk> <201106301341.29881.mirja.kuehlewind@ikr.uni-stuttgart.de> <4E0C9989.5040505@fandm.edu>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"; format=flowed
X-Scanned-By: MIMEDefang 2.56 on 132.146.168.158
X-OriginalArrivalTime: 01 Jul 2011 00:08:35.0560 (UTC) FILETIME=[0545B680:01CC3783]
Cc: ledbat@ietf.org
Subject: Re: [ledbat] ECN/AQM
X-BeenThere: ledbat@ietf.org
X-Mailman-Version: 2.1.12
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, 01 Jul 2011 00:08:40 -0000

Janar,

I take Mirja's point that this isn't the right doc to recommend that 
the LEDBAT transport uses ECN, it's solely appropriate to say how 
LEDBAT should respond to ECN CE.

Earlier revs of this draft said a design goal was to use ECN, but 
that got removed. The applicability section currently says:
"
    LEDBAT seeks to operate in networks with FIFO queues and with tail-
    drop queue management.  Further study is required to understand the
    implications of Active Queue Management (AQM) schemes on LEDBAT
    mechanisms.
"
Thinking about this, it's rather oddly worded. LEDBAT doesn't know 
what sort of queues there will be where it "seeks to operate".

How about saying something like the following:

"LEDBAT has been designed so that long-running flows should not build 
a standing queue that would persistently delay TCP flows that share a 
relatively slow FIFO queue using tail drop.

If active queue management (AQM) is configured to start dropping or 
ECN-marking packets before the averaged queue has reached LEDBAT's 
target delay, it will make LEDBAT revert to TCP behaviour, rather 
than yield to other TCP flows. However the AQM will keep the queuing 
delay low, which achieves an outcome similar to that LEDBAT was 
aiming for. Additionally, if the LEDBAT transport supports ECN, it 
will enjoy the same minor advantages that an ECN-TCP enjoys over a 
non-ECN-TCP; avoiding losses and the consequent timeouts.

Fair queuing will prevent LEDBAT yielding to other TCP flows. 
Nonetheless, fair queueing isolates brief TCP flows from any standing 
queue caused by concurrent long-running flows, which again achieves 
an outcome that is not much worse than that LEDBAT was aiming for 
[Schneider10].

Further study is required to better fully understand the behaviour of 
LEDBAT with non-drop-tail non-FIFO queues.
"


[Schneider10] Joscha Schneider. Joerg Wagner, Rolf Winter , 
Hans-Joerg Kolbe, "Out of my Way -- Evaluating Low Extra Delay 
Background Transport in an ADSL Access Network" . In Proceedings of 
the 22nd International Teletraffic Congress (ITC22), Amsterdam, The 
Netherlands, September 7 - 9 2010.



At 16:43 30/06/2011, Janardhan Iyengar wrote:
>Dear all,
>
>There is no question that LEDBAT flows will experience loss in the 
>wild, especially, as Bob so eloquently pointed out, when congestion 
>is deeper in the core.
>
>It seems to me that we are all in agreement that ECN marks must be 
>respected.  I don't think that the LEDBAT draft can do more than 
>state what a LEDBAT flow does in the presence of an ECN mark, as 
>Mirja has already included in the Applicability Section.  After all, 
>LEDBAT does not get into protocol mechanisms per se, and cannot 
>really _specify_ anything more with ECN.
>
>For LEDBAT to actively "encourage" ECN adoption, there should be 
>some explicit benefit to the ECN-capable LEDBAT flows over the 
>non-ECN capable ones. And within the scope of the draft, I don't see 
>that we can point to any such benefits.  However, perhaps we could 
>say something in the applicability section about how ECN and AQM can 
>benefit the applications that we expect to use LEDBAT.  Any suggestions?
>
>- jana
>
>On 6/30/11 7:41 AM, Mirja Kuehlewind wrote:
>>Hi everybody,
>>
>>I try to recap now on the ECN issue to see which action is actually 
>>needed for
>>the draft. (Btw. I believe we DO have the same opinion):
>>
>>There are two question:
>>
>>1. Should LEDBAT react on ECN marks as it would on loss?
>>
>>A very clear YES here! Nobody wants to ignore ECN marks. The reaction to ECN
>>is already specified in RFC3168 to be the same than to loss (for every
>>congestion control). This was not mention explicit in the current draft
>>version. I've been adding the following sentence for the next version (in
>>2.2. Applicability):
>>
>>"If LEDBAT is used with a framing protocol that is
>>         ECN-capable, it should react to ECN marks as it would to losses
>>         as specified in RFC3168."
>>
>>
>>2. Should we recommend that transports using LEDBAT should use/enable ECN
>>as well?
>>
>>Here are the responses of everybody:
>>
>>Bob:
>>"Sending ECN-capable packets ought to be recommended for LEDBAT, so
>>that if ever ECN is deployed in the network, LEDBAT can take 
>>advantage of it."
>>
>>Gorry:
>>"To be clear, I think LEDBAT should indicate that ECN is a useful
>>mechanism for congestion control, and that instantiations of the LEDBAT
>>method in transports should be encouraged to support ECN functionality."
>>
>>Arjuna:
>>"I agree with Bob and Gorry that allowing LEDBAT to support ECN is not
>>going to hurt."
>>Agree, ECN does not hurt...
>>
>>I (Mirja):
>>->  I was saying that this question does not need to be answered in 
>>this draft,
>>as this draft is not talking about ANY framing protocol issues (beside some
>>hard requirement on the framing protocol e.g. any kind of feedback is need).
>>It only documents the LEDBAT algorithm for informational purpose (its not a
>>protocol spec nor an implementation guide).
>>
>>How should we continue here? Should we add some text? If yes, where should we
>>add the text? Somebody wants to make a proposal for text?
>>
>>Mirja
>>
>>
>>On Thursday 30 June 2011 10:40:21 Gorry Fairhurst wrote:
>>>Indeed I missed a "NOT".
>>>
>>>To be clear, I think LEDBAT should indicate that ECN is a useful
>>>mechanism for congestion control, and that instantiations of the LEDBAT
>>>method in transports should be encouraged to support ECN functionality.
>>>
>>>Gorry
>>>
>>>On 29/06/2011 20:02, Bob Briscoe wrote:
>>>>Gorry,
>>>>
>>>>At 17:44 29/06/2011, Gorry Fairhurst wrote:
>>>>>On 28/06/2011 19:25, Mirja Kuehlewind wrote:
>>>>>>So in general, I'm not sure if we should talk about an TCP/IP
>>>>>>mechanism (ECN)
>>>>>>in this draft when we only specify the algorithm and not talking about
>>>>>>anything TCP specific...?
>>>>>
>>>>>I'm not saying the group should define the mechanism, but I am saying
>>>>>that from my point of view, it would be wise that ECN is ignored, and
>>>>>that what matters is proper response to "congestion indications", not
>>>>>to loss.
>>>>
>>>>Did you miss a 'not' in the sentence?
>>>>"it would be wise that ECN is NOT ignored"
>>>>
>>>>
>>>>Bob
>>>>
>>>>>>Mirja
>>>>>
>>>>>Gorry
>>>>
>>>>________________________________________________________________
>>>>Bob Briscoe, BT Innovate&  Design
>>
>>
>
>--
>Janardhan Iyengar
>Assistant Professor, Computer Science
>Franklin & Marshall College
>http://www.fandm.edu/jiyengar
>_______________________________________________
>ledbat mailing list
>ledbat@ietf.org
>https://www.ietf.org/mailman/listinfo/ledbat

________________________________________________________________
Bob Briscoe,                                BT Innovate & Design 


From jana.iyengar@gmail.com  Thu Jun 30 21:00:29 2011
Return-Path: 
X-Original-To: ledbat@ietfa.amsl.com
Delivered-To: ledbat@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 73C8A1F0C65 for ; Thu, 30 Jun 2011 21:00:29 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.372
X-Spam-Level: 
X-Spam-Status: No, score=-3.372 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1, SARE_SUB_OBFU_Q1=0.227]
Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id OLAxGN4X77az for ; Thu, 30 Jun 2011 21:00:28 -0700 (PDT)
Received: from mail-vw0-f44.google.com (mail-vw0-f44.google.com [209.85.212.44]) by ietfa.amsl.com (Postfix) with ESMTP id 883F21F0C62 for ; Thu, 30 Jun 2011 21:00:28 -0700 (PDT)
Received: by vws12 with SMTP id 12so2575464vws.31 for ; Thu, 30 Jun 2011 21:00:27 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=message-id:date:from:reply-to:organization:user-agent:mime-version :to:cc:subject:references:in-reply-to:content-type :content-transfer-encoding; bh=8K76FevOiEEFXE+8N5Ox+FbEsEXhTm21f77/puIBGYw=; b=fa0Z6Hv54XooizbGeFhGV0rhRN4j2s0EbNfmZ8Eh6d+kbLmNdnhUAazCZsaPg1Gb7h FfTK0kuYVaVK32wKYBqCjsyqH/avl2Axq0+ImNT9b4xSpkif0oqLifgEccIdKU/EsDpb 968xmgAfjUPwwOIAltsPR/jN4o9znNtISNV5U=
Received: by 10.220.109.234 with SMTP id k42mr1108977vcp.65.1309492826985; Thu, 30 Jun 2011 21:00:26 -0700 (PDT)
Received: from surutti.fandm.edu (c-174-54-204-34.hsd1.pa.comcast.net [174.54.204.34]) by mx.google.com with ESMTPS id m4sm594029vcc.38.2011.06.30.21.00.24 (version=TLSv1/SSLv3 cipher=OTHER); Thu, 30 Jun 2011 21:00:25 -0700 (PDT)
Message-ID: <4E0D4657.9050906@fandm.edu>
Date: Fri, 01 Jul 2011 00:00:23 -0400
From: Janardhan Iyengar 
Organization: Franklin & Marshall College
User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.6; en-US; rv:1.9.2.18) Gecko/20110616 Lightning/1.0b2 Thunderbird/3.1.11
MIME-Version: 1.0
To: Lachlan Andrew 
References: <791AD3077F94194BB2BDD13565B6295D05E6DF22@PALLENE.office.hd> <201106291902.p5TJ2C03010090@bagheera.jungle.bt.co.uk> <4E0C3675.6080700@erg.abdn.ac.uk> <201106301341.29881.mirja.kuehlewind@ikr.uni-stuttgart.de> <4E0C9989.5040505@fandm.edu> 
In-Reply-To: 
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
Cc: Bob Briscoe , ledbat@ietf.org
Subject: Re: [ledbat] ECN/AQM
X-BeenThere: ledbat@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
Reply-To: janardhan.iyengar@fandm.edu
List-Id: Mailing list of the LEDBAT WG 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Fri, 01 Jul 2011 04:00:29 -0000

Hi Lachlan,

> I haven't been following Letbat, and this proposal may be heretical,
> but it is easy to give a Letbat flow an incentive to be ECN capable,
> by specifying that it should back off more when it sees loss than when
> it sees ECN.

That seems like an artificial incentive.  Why should a LEDBAT flow reduce its rate more than what TCP does on loss?

> As long as it backs off at least as much as Reno does on loss, then
> this does not violate the spirit of RFC 3168.  It does violate the
> requirement that response to ECN be the same as loss, but that was
> written at a time when loss was considered synonymous with congestion;
> really ECN should be treated more like extra delay for a delay-based
> algorithm.

So, if I understand you correctly, your suggestion is not so much to _reduce more_ on loss, but to _reduce lesser_ on CE.  While the idea seems intriguing, what you are suggesting seems to be a rewrite of RFC 3168.  The receipt of CE signal is an event that may not be accompanied by any clear delay increase;  it is not clear to me how a CE received in the absence of a clear delay signal can be interpreted as extra delay and not loss.  In other words, how do you translate a CE signal to delay?

Isn't the equivalent argument for TCP-like flows to reduce their windows by lesser than than 1/2 on CE marks and by 1/2 on loss  (or am I missing something)?

- jana

-- 
Janardhan Iyengar
Assistant Professor, Computer Science
Franklin & Marshall College
http://www.fandm.edu/jiyengar

From lachlan.andrew@gmail.com  Thu Jun 30 21:48:06 2011
Return-Path: 
X-Original-To: ledbat@ietfa.amsl.com
Delivered-To: ledbat@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6E9FB11E80E2 for ; Thu, 30 Jun 2011 21:48:06 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -103.372
X-Spam-Level: 
X-Spam-Status: No, score=-103.372 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1, SARE_SUB_OBFU_Q1=0.227, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id zASLBhrfLna3 for ; Thu, 30 Jun 2011 21:48:05 -0700 (PDT)
Received: from mail-ww0-f44.google.com (mail-ww0-f44.google.com [74.125.82.44]) by ietfa.amsl.com (Postfix) with ESMTP id 22D2311E80D7 for ; Thu, 30 Jun 2011 21:48:04 -0700 (PDT)
Received: by wwe5 with SMTP id 5so1941997wwe.13 for ; Thu, 30 Jun 2011 21:48:04 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type:content-transfer-encoding; bh=ZwGkJIaETTD9P7xXIts4O293qX9bTuJ+reBhV/bg2Ow=; b=sG4h3D4n7PYSQgOUuA8y06ZybwVKWvdc3XlcoLmMKkOFSn5RoObByLL/1AK9QjI4aC 5WVkcEpjHnlwQZqu5ScSSzO7DSzDBlXu4w2aBwG18njh2ICJGaNnxPsv1Il1ZyrvaGRu jmkrFn2ytZCFZnRFYFFVS8eIpAKN4k8UpEqn4=
Received: by 10.216.58.132 with SMTP id q4mr2534202wec.19.1309495682277; Thu, 30 Jun 2011 21:48:02 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.216.71.3 with HTTP; Thu, 30 Jun 2011 21:47:42 -0700 (PDT)
In-Reply-To: <4E0D4657.9050906@fandm.edu>
References: <791AD3077F94194BB2BDD13565B6295D05E6DF22@PALLENE.office.hd> <201106291902.p5TJ2C03010090@bagheera.jungle.bt.co.uk> <4E0C3675.6080700@erg.abdn.ac.uk> <201106301341.29881.mirja.kuehlewind@ikr.uni-stuttgart.de> <4E0C9989.5040505@fandm.edu>  <4E0D4657.9050906@fandm.edu>
From: Lachlan Andrew 
Date: Fri, 1 Jul 2011 14:47:42 +1000
Message-ID: 
To: janardhan.iyengar@fandm.edu
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable
Cc: ledbat@ietf.org
Subject: Re: [ledbat] ECN/AQM
X-BeenThere: ledbat@ietf.org
X-Mailman-Version: 2.1.12
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, 01 Jul 2011 04:48:06 -0000

Greetings

On 1 July 2011 14:00, Janardhan Iyengar  wrote:
>
>> I haven't been following Letbat, and this proposal may be heretical,
>> but it is easy to give a Letbat flow an incentive to be ECN capable,
>> by specifying that it should back off more when it sees loss than when
>> it sees ECN.
>
> That seems like an artificial incentive. =A0Why should a LEDBAT flow redu=
ce
> its rate more than what TCP does on loss?

No -- I suggested there could/should be a difference between how we
respond to loss and to ECN.  I didn't mention TCP.

>> As long as it backs off at least as much as Reno does on loss, then
>> this does not violate the spirit of RFC 3168. =A0It does violate the
>> requirement that response to ECN be the same as loss, but that was
>> written at a time when loss was considered synonymous with congestion;
>> really ECN should be treated more like extra delay for a delay-based
>> algorithm.
>
> So, if I understand you correctly, your suggestion is not so much to _red=
uce
> more_ on loss, but to _reduce lesser_ on CE.

Yes, they're equivalent.

> While the idea seems
> intriguing, what you are suggesting seems to be a rewrite of RFC 3168.

Not at all.  Most of 3168 is about the mechanism.  That doesn't need
to change.  I'd only challenge the "congestion is equivalent to loss"
prescription.

> The
> receipt of CE signal is an event that may not be accompanied by any clear
> delay increase; =A0it is not clear to me how a CE received in the absence=
 of a
> clear delay signal can be interpreted as extra delay and not loss.
> In other words, how do you translate a CE signal to delay?

You don't need to "translate a CE signal to delay".  My point was just
that you can treat it as another congestion signal whose severity is
less than loss.

> Isn't the equivalent argument for TCP-like flows to reduce their windows =
by
> lesser than than 1/2 on CE marks and by 1/2 on loss =A0(or am I missing
> something)?

No.  It is more equivalent to the argument that it should be *OK* for
TCP-like flows to reduce their windows by 1/2 on CE marks, and by
*more* than 1/2 on loss (if they choose to).

The requirement that CE marks be treated as loss was (presumably) to
prevent flows from using it as a way to be more aggressive than
standard TCP / TFRC.  Ledbat flows are already being much less
aggressive than Reno.  There is no logical reason that something that
backs of more timidly on loss should also back off more timidly on CE
(although there is a logical reason that something should back off on
CE by at least as much as "the universal congestion control when ECN
was introduced" backed off on "the universal congestion signal before
ECN was introduced").

The primary argument in RFC 3168 for making the response to ECN
essentially the same as that to a loss was to allow incremental
deployment of 3168.  If making the response identical actually
*stifles* the deployment of ECN by prohibiting the correct incentives,
then perhaps the wording of 3168 should be fixed...

Cheers,
Lachlan

--=20
Lachlan Andrew=A0 Centre for Advanced Internet Architectures (CAIA)
Swinburne University of Technology, Melbourne, Australia

Ph +61 3 9214 4837