From muraris@microsoft.com Mon Jun 1 07:29:27 2009 Return-Path: X-Original-To: ledbat@core3.amsl.com Delivered-To: ledbat@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id CC55E3A6A02 for ; Mon, 1 Jun 2009 07:29:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.599 X-Spam-Level: X-Spam-Status: No, score=-10.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id pBLt6LviN9AI for ; Mon, 1 Jun 2009 07:29:26 -0700 (PDT) Received: from smtp.microsoft.com (maila.microsoft.com [131.107.115.212]) by core3.amsl.com (Postfix) with ESMTP id 2E3793A7176 for ; Mon, 1 Jun 2009 07:28:57 -0700 (PDT) Received: from tk5-exmlt-c102.redmond.corp.microsoft.com (157.54.24.67) by TK5-EXGWY-E801.partners.extranet.microsoft.com (10.251.56.50) with Microsoft SMTP Server (TLS) id 8.2.99.4; Mon, 1 Jun 2009 07:28:57 -0700 Received: from NA-EXMSG-C110.redmond.corp.microsoft.com ([157.54.62.162]) by tk5-exmlt-c102.redmond.corp.microsoft.com ([157.54.24.67]) with mapi; Mon, 1 Jun 2009 07:28:57 -0700 From: Murari Sridharan To: Jitu Padhye , Stanislav Shalunov Date: Mon, 1 Jun 2009 07:28:23 -0700 Thread-Topic: LEDBAT over TCP? Thread-Index: Acm5Ec9UpoFPU+T7SCSee6Bm9uGxSwbs6YNgA3/wnSA= Message-ID: References: <200904011045.n31AjtGg008364@bagheera.jungle.bt.co.uk> <6c82d1360904022311k28c5dfa2g160ec6abb92d5190@mail.gmail.com> <200904081803.n38I3N0X029206@bagheera.jungle.bt.co.uk> <200904091250.n39CoNlg018456@bagheera.jungle.bt.co.uk>, In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "ledbat@ietf.org" Subject: Re: [ledbat] LEDBAT over TCP? X-BeenThere: ledbat@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Mailing list of the LEDBAT WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 01 Jun 2009 14:29:27 -0000 Per-Stas from an earlier email.=20 Note that the draft describes the congestion control and not the framing. The congestion control scheme could be applicable in a variety of scenarios: over UDP, as a TCP mod, over TCP, as a CCID for DCCP, as an SCTP mod, etc. Over TCP has some practical disadvantages, such as inability to control packet size to reduce serialization on slow links and very hard to debug interactions between control loops. It's still an option, and you're free to use this technique even if I couldn't get it to work. The framing is out of scope for the WG -- it was dropped from the charter. ________________________________________ From: ledbat-bounces@ietf.org [ledbat-bounces@ietf.org] On Behalf Of Jitu P= adhye [padhye@microsoft.com] Sent: Thursday, May 14, 2009 12:14 PM To: Stanislav Shalunov Cc: ledbat@ietf.org Subject: [ledbat] LEDBAT over TCP? Stas: Is it expected that people will run this solution over TCP, or is it meant = for running over UDP only? Also (and I think someone asked this before) is there an NS simulation mode= l that people can play with? Thanks, - Jitu _______________________________________________ ledbat mailing list ledbat@ietf.org https://www.ietf.org/mailman/listinfo/ledbat= From muraris@microsoft.com Mon Jun 1 08:04:47 2009 Return-Path: X-Original-To: ledbat@core3.amsl.com Delivered-To: ledbat@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 1330A3A6B11 for ; Mon, 1 Jun 2009 08:04:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.599 X-Spam-Level: X-Spam-Status: No, score=-10.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id GdLdowonFqkl for ; Mon, 1 Jun 2009 08:04:45 -0700 (PDT) Received: from smtp.microsoft.com (mail2.microsoft.com [131.107.115.215]) by core3.amsl.com (Postfix) with ESMTP id 835B63A6813 for ; Mon, 1 Jun 2009 08:04:45 -0700 (PDT) Received: from tk5-exhub-c104.redmond.corp.microsoft.com (157.54.88.97) by TK5-EXGWY-E802.partners.extranet.microsoft.com (10.251.56.168) with Microsoft SMTP Server (TLS) id 8.2.99.4; Mon, 1 Jun 2009 08:04:44 -0700 Received: from NA-EXMSG-C110.redmond.corp.microsoft.com ([157.54.62.162]) by tk5-exhub-c104.redmond.corp.microsoft.com ([157.54.88.97]) with mapi; Mon, 1 Jun 2009 08:04:44 -0700 From: Murari Sridharan To: Bob Briscoe , Stanislav Shalunov Date: Mon, 1 Jun 2009 08:04:43 -0700 Thread-Topic: [ledbat] fairness between competing delay flows in draft-shalunov-ledbat-congestion-00.txt Thread-Index: Acm5Ec7gYopJq2ogQS2SatWpTLT3iQptLPtW Message-ID: References: <6c82d1360904022329o34efd701p8b7a0b08730ae65a@mail.gmail.com>, <200904091250.n39CoVKH018460@bagheera.jungle.bt.co.uk> In-Reply-To: <200904091250.n39CoVKH018460@bagheera.jungle.bt.co.uk> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: Douglas Leith , "ledbat@ietf.org" Subject: Re: [ledbat] fairness between competing delay flows in draft-shalunov-ledbat-congestion-00.txt X-BeenThere: ledbat@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Mailing list of the LEDBAT WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 01 Jun 2009 15:04:47 -0000 Bob i think you are raising some very valid points here, Stas would be grea= t if you can respond to his mail, havent seen one yet.=20 Bob, If i understand you correctly CTCP does somethign like this, there is = a seperate window increase process and there is a delay threshold (as measu= red through gamma which is the packets backlogged) which is used simply as = a thresold to decrease if exceeded. Low priority TCP which is "a" ledbat t= ype solution that we are looking at for some of our scenarios. Even though = it doesnt have an explicit delay target it tries to detect change in slope = and adjusts the receive window to throttle the sender. It does aim to maint= ain a lower delay and does so well in our experiments but there is no expli= cit delay target. I am trying out a simple variant where the receiver measu= res the backlog using a vegas style equation with rcvwnd instead of cwnd to= see if we can keep a certain amount of packets backlogged thereby doing so= methign liek what you describe below. Will keep the list posted on the find= ings. The main difference though is that low priority TCP does infact relyo= n RTT and not one-way delay so reverse path congestion could affect this. T= he advantage is it works as an alternative congestion control option on reg= ular TCP and only one end needs to change, both of which are very compellin= g.=20 Regarding getting a good delay measurement that is indeed what we observed = with CTCP over production links. However in the case of CTCP we did a lot o= f testing on high-speed links and there was enough statistical multiplexing= and we almost always got a good base delay measurement. In the case when t= he bottleneck is a home link and there are multiple ledbat flows within the= home the first movers advantage that Doug mentions is indeed possible. In = Stas' experiments I am not sure if he had multiple ledbat flows within the = home from different computers and if he saw this problem or not.=20 At this point it would be great if some folks in the DL can try out a NS ve= rsion of the algorithm, its simple and straightforward to implement and we = can then study different aspects being discussed below. Stas do you have so= me results you can share, would be great to see how some of the dynamics be= low work in practice.=20 Thanks ________________________________________ From: ledbat-bounces@ietf.org [ledbat-bounces@ietf.org] On Behalf Of Bob Br= iscoe [rbriscoe@jungle.bt.co.uk] Sent: Thursday, April 09, 2009 5:50 AM To: Stanislav Shalunov Cc: Douglas Leith; ledbat@ietf.org Subject: Re: [ledbat] fairness between competing delay flows in draft-shalu= nov-ledbat-congestion-00.txt Stas, Point taken about base measurements, but this questions is about the motivation for the core part of the control algo: cwnd +=3D GAIN * off_target / cwnd. (using the draft's terminology: off_target =3D TARGET - queuing_delay) Q. Why should the controller's increase and decrease both depend on the same formula? I think this means the shares that competing flows get depend purely on the minutiae of the dynamics of each competing flow. That means shares depend on arbitrary stuff that sharing shouldn't depend on (e.g. whether disk heads move, how many other interrupts are served, who arrived first), and there's nothing explicit to control what the shares do depend on. However, I assume I must have missed something, as I'm sure you've thought of this. As far as I can work out (haven't had time to work through the non-linear case where the small standing queue might disappear completely), shares don't explicitly depend on RTT or packet size or delayed ack factor (which IMHO they shouldn't). While both the acceleration and deceleration of each flow do depend on these factors in equal measures (which IMHO they should too). So far so good, but... ...taking RTT as one example, altho the steady state shares won't depend directly on RTT, they might depend on second order effects of how differences in RTT interact with other random events. If correct, that's not good. It's random. Put another way, repeating the question in my earlier posting: Q. Why should the controller aim to *increase* delay up to the target? Instead the window *increase* could operate as a separate continuous process (as in AIMD algos). And the threshold only indicates a *decrease* is needed if exceeded. Then bottleneck sharing is explicitly under control. It is the equilibrium when the two decoupled increase & decrease processes balance. 'TARGET' then becomes merely a lower threshold for the decrease process, not a target for both processes. Bob At 07:29 03/04/2009, Stanislav Shalunov wrote: >We have not observed the late-comer's advantage. > >As soon as the first flow has a hiccup (for example, because something >needs to wait for a few disk head moves), there will be a gap in the >first flow's traffic, enabling the second flow to measure accurately. > >During the session Murari mentioned that in their experience, flows >were also always able to get a reasonable base delay measurement. > >Obviously, the more flows, the more uniform the traffic, the more >likely it is that the late comers might be mistaken about the base. >At tens of flows, this is clearly not a problem. At tens of >thousands, which is what most backbones see for bulk connections, I'd >expect it to start showing. The coordination problem at tens of >thousands of connections is hard and almost certain to be emergent, >but then extended congestion on backbone links is infrequent. In the >worst case, it'll all fall back to TCP. > >For a small number of flows, the situation most typically encountered >on congested links, base estimation seems to be reliable. > > >On Tue, Mar 31, 2009 at 5:23 PM, Douglas Leith wrote: > > Can I ask what the expected/desired behaviour will be when two or more > > ledbat flows share a link ? > > For example, say a first flow starts, ramps us cwnd until it hits > the target > > queueing delay and then a second ledbat flow starts a while later. Its= not > > clear to me from the ID how the first flow would alter its cwnd to make > > space for the second ledbat flow (especially if the second flow > does not use > > slow start, or perhaps has an early exit from slow start). > > Also, is there a danger that, similarly the vegas and related algorithm= s, > > the later starting flow will have difficulty getting an accurate > estimate of > > the base RTT since earlier starting flows maintain a standing queue ? > > Doug > > www.hamilton.ie > > > >-- >Stanislav Shalunov >BitTorrent Inc >shalunov@bittorrent.com > >personal: http://shlang.com >_______________________________________________ >ledbat mailing list >ledbat@ietf.org >https://www.ietf.org/mailman/listinfo/ledbat ________________________________________________________________ Bob Briscoe, Networks Research Centre, BT Research _______________________________________________ ledbat mailing list ledbat@ietf.org https://www.ietf.org/mailman/listinfo/ledbat= From michawe@ulrik.uio.no Mon Jun 1 09:28:06 2009 Return-Path: X-Original-To: ledbat@core3.amsl.com Delivered-To: ledbat@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 0485A3A7197 for ; Mon, 1 Jun 2009 09:28:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.126 X-Spam-Level: X-Spam-Status: No, score=-5.126 tagged_above=-999 required=5 tests=[AWL=0.603, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, SARE_MLH_Stock1=0.87] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id je9dp-2XDxkA for ; Mon, 1 Jun 2009 09:28:05 -0700 (PDT) Received: from mail-out2.uio.no (mail-out2.uio.no [129.240.10.58]) by core3.amsl.com (Postfix) with ESMTP id 07F023A6A3C for ; Mon, 1 Jun 2009 09:28:05 -0700 (PDT) Received: from mail-mx5.uio.no ([129.240.10.46]) by mail-out2.uio.no with esmtp (Exim 4.69) (envelope-from ) id 1MBAMm-00045o-30 for ledbat@ietf.org; Mon, 01 Jun 2009 18:28:04 +0200 Received: from w3prod-wm01.uio.no ([129.240.4.214] helo=webmail.uio.no) by mail-mx5.uio.no with esmtpsa (TLSv1:AES256-SHA:256) user michawe (Exim 4.69) (envelope-from ) id 1MBAMl-0002PM-N6 for ledbat@ietf.org; Mon, 01 Jun 2009 18:28:04 +0200 Received: from 80.202.161.222 (SquirrelMail authenticated user michawe) by webmail.uio.no with HTTP; Mon, 1 Jun 2009 18:28:03 +0200 (CEST) Message-ID: <506e37a3fcf2a213d8d84a9fb427b6f1.squirrel@webmail.uio.no> Date: Mon, 1 Jun 2009 18:28:03 +0200 (CEST) From: michawe@ifi.uio.no To: ledbat@ietf.org User-Agent: SquirrelMail/1.4.17 MIME-Version: 1.0 Content-Type: text/plain;charset=iso-8859-1 Content-Transfer-Encoding: 8bit X-UiO-Ratelimit-Test: rcpts/h 6 msgs/h 4 sum rcpts/h 6 sum msgs/h 4 total rcpts 619 max rcpts/h 19 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=_URIID_) X-UiO-Scanned: 7FE8E6EA2762C24D55963D08F1EE8E547EB8ECF5 X-UiO-SPAM-Test: remote_host: 129.240.4.214 spam_score: -49 maxlevel 80 minaction 2 bait 0 mail/h: 61 total 1351401 max/h 678 blacklist 0 greylist 0 ratelimit 0 Subject: [ledbat] Meeting in Stockholm? X-BeenThere: ledbat@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Mailing list of the LEDBAT WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 01 Jun 2009 16:28:06 -0000 Hi all, Does this group plan to meet in Stockholm? If so, I would like to request a slot to present my lower-than-best-effort survey draft, draft-welzl-ledbat-survey-00.txt Cheers, Michael From muraris@microsoft.com Mon Jun 1 18:44:55 2009 Return-Path: X-Original-To: ledbat@core3.amsl.com Delivered-To: ledbat@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 13C943A68EA for ; Mon, 1 Jun 2009 18:44:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.164 X-Spam-Level: X-Spam-Status: No, score=-10.164 tagged_above=-999 required=5 tests=[AWL=-0.435, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8, SARE_MLH_Stock1=0.87] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 6myxeollhuCj for ; Mon, 1 Jun 2009 18:44:54 -0700 (PDT) Received: from smtp.microsoft.com (mail2.microsoft.com [131.107.115.215]) by core3.amsl.com (Postfix) with ESMTP id 5B1A73A67FF for ; Mon, 1 Jun 2009 18:44:54 -0700 (PDT) Received: from tk5-expfs-c106.redmond.corp.microsoft.com (157.54.69.40) by TK5-EXGWY-E802.partners.extranet.microsoft.com (10.251.56.168) with Microsoft SMTP Server (TLS) id 8.2.99.4; Mon, 1 Jun 2009 18:44:54 -0700 Received: from NA-EXMSG-C110.redmond.corp.microsoft.com ([157.54.62.162]) by tk5-expfs-c106.redmond.corp.microsoft.com ([157.54.69.40]) with mapi; Mon, 1 Jun 2009 18:44:54 -0700 From: Murari Sridharan To: "michawe@ifi.uio.no" , "ledbat@ietf.org" Date: Mon, 1 Jun 2009 18:44:41 -0700 Thread-Topic: [ledbat] Meeting in Stockholm? Thread-Index: Acni1iKmPcbEkJ6UTL+9AstoxcSsCwATY/Os Message-ID: References: <506e37a3fcf2a213d8d84a9fb427b6f1.squirrel@webmail.uio.no> In-Reply-To: <506e37a3fcf2a213d8d84a9fb427b6f1.squirrel@webmail.uio.no> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: Re: [ledbat] Meeting in Stockholm? X-BeenThere: ledbat@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Mailing list of the LEDBAT WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 02 Jun 2009 01:44:55 -0000 Yes we do, I'll add you to the agenda.=20 Thanks ________________________________________ From: ledbat-bounces@ietf.org [ledbat-bounces@ietf.org] On Behalf Of michaw= e@ifi.uio.no [michawe@ifi.uio.no] Sent: Monday, June 01, 2009 9:28 AM To: ledbat@ietf.org Subject: [ledbat] Meeting in Stockholm? Hi all, Does this group plan to meet in Stockholm? If so, I would like to request a slot to present my lower-than-best-effort survey draft, draft-welzl-ledbat-survey-00.txt Cheers, Michael _______________________________________________ ledbat mailing list ledbat@ietf.org https://www.ietf.org/mailman/listinfo/ledbat= From rbriscoe@jungle.bt.co.uk Tue Jun 2 01:18:56 2009 Return-Path: X-Original-To: ledbat@core3.amsl.com Delivered-To: ledbat@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id D80D73A6E00 for ; Tue, 2 Jun 2009 01:18:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.117 X-Spam-Level: X-Spam-Status: No, score=-2.117 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, DNS_FROM_RFC_BOGUSMX=1.482, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id tXl5mNX76ND5 for ; Tue, 2 Jun 2009 01:18:50 -0700 (PDT) Received: from smtp4.smtp.bt.com (smtp4.smtp.bt.com [217.32.164.151]) by core3.amsl.com (Postfix) with ESMTP id 23D833A6E47 for ; Tue, 2 Jun 2009 01:18:49 -0700 (PDT) Received: from i2kc06-ukbr.domain1.systemhost.net ([193.113.197.70]) by smtp4.smtp.bt.com with Microsoft SMTPSVC(6.0.3790.3959); Tue, 2 Jun 2009 09:18:49 +0100 Received: from cbibipnt05.iuser.iroot.adidom.com ([147.149.196.177]) by i2kc06-ukbr.domain1.systemhost.net with Microsoft SMTPSVC(6.0.3790.1830); Tue, 2 Jun 2009 09:18:49 +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 1243930729129; Tue, 2 Jun 2009 09:18:49 +0100 Received: from mut.jungle.bt.co.uk ([10.73.210.117]) by bagheera.jungle.bt.co.uk (8.13.5/8.12.8) with ESMTP id n528IgL2021129; Tue, 2 Jun 2009 09:18:43 +0100 Message-Id: <200906020818.n528IgL2021129@bagheera.jungle.bt.co.uk> X-Mailer: QUALCOMM Windows Eudora Version 7.1.0.9 Date: Tue, 02 Jun 2009 08:08:13 +0100 To: Murari Sridharan , Stanislav Shalunov From: Bob Briscoe In-Reply-To: References: <6c82d1360904022329o34efd701p8b7a0b08730ae65a@mail.gmail.com> <200904091250.n39CoVKH018460@bagheera.jungle.bt.co.uk> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-Scanned-By: MIMEDefang 2.56 on 132.146.168.158 X-OriginalArrivalTime: 02 Jun 2009 08:18:49.0687 (UTC) FILETIME=[C1ED0E70:01C9E35A] Cc: Douglas Leith , "ledbat@ietf.org" Subject: Re: [ledbat] fairness between competing delay flows in draft-shalunov-ledbat-congestion-00.txt X-BeenThere: ledbat@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Mailing list of the LEDBAT WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 02 Jun 2009 08:18:56 -0000 Murari, I think one thing in Stas's mind (reading between the lines of a conversation I had with him at the Dublin IETF) was that an AIMD process like we're describing leads delay to increase with no. of LEDBAT flows. Whereas the linear controller in his draft makes sure you get about the same delay however many flows. However, that might be at the expense of some flows randomly getting much less than others. Stas's comments in the SF LEDBAT meeting could be construed as implying that in practice randomness seems to lead to all flows getting some decent share. However, I don't quite see how, as the algorithm seems to have no tendency to make this happen - it seems more likely Doug's first-mover advantage will dominate. Stas? Bob At 16:04 01/06/2009, Murari Sridharan wrote: >Bob i think you are raising some very valid points here, Stas would >be great if you can respond to his mail, havent seen one yet. > >Bob, If i understand you correctly CTCP does somethign like this, >there is a seperate window increase process and there is a delay >threshold (as measured through gamma which is the packets >backlogged) which is used simply as a thresold to decrease if >exceeded. Low priority TCP which is "a" ledbat type solution that >we are looking at for some of our scenarios. Even though it doesnt >have an explicit delay target it tries to detect change in slope and >adjusts the receive window to throttle the sender. It does aim to >maintain a lower delay and does so well in our experiments but there >is no explicit delay target. I am trying out a simple variant where >the receiver measures the backlog using a vegas style equation with >rcvwnd instead of cwnd to see if we can keep a certain amount of >packets backlogged thereby doing somethign liek what you describe >below. Will keep the list posted on the findings. The main >difference though is that low priority TCP does infact relyon RTT >and not one-way delay so reverse path congestion could affect this. >The advantage is it works as an alternative congestion control >option on regular TCP and only one end needs to change, both of >which are very compelling. > >Regarding getting a good delay measurement that is indeed what we >observed with CTCP over production links. However in the case of >CTCP we did a lot of testing on high-speed links and there was >enough statistical multiplexing and we almost always got a good base >delay measurement. In the case when the bottleneck is a home link >and there are multiple ledbat flows within the home the first movers >advantage that Doug mentions is indeed possible. In Stas' >experiments I am not sure if he had multiple ledbat flows within the >home from different computers and if he saw this problem or not. > >At this point it would be great if some folks in the DL can try out >a NS version of the algorithm, its simple and straightforward to >implement and we can then study different aspects being discussed >below. Stas do you have some results you can share, would be great >to see how some of the dynamics below work in practice. > >Thanks >________________________________________ >From: ledbat-bounces@ietf.org [ledbat-bounces@ietf.org] On Behalf Of >Bob Briscoe [rbriscoe@jungle.bt.co.uk] >Sent: Thursday, April 09, 2009 5:50 AM >To: Stanislav Shalunov >Cc: Douglas Leith; ledbat@ietf.org >Subject: Re: [ledbat] fairness between competing delay flows in >draft-shalunov-ledbat-congestion-00.txt > >Stas, > >Point taken about base measurements, but this questions is about the >motivation for the core part of the control algo: > cwnd += GAIN * off_target / cwnd. (using the draft's >terminology: off_target = TARGET - queuing_delay) >Q. Why should the controller's increase and decrease both depend on >the same formula? > >I think this means the shares that competing flows get depend purely >on the minutiae of the dynamics of each competing flow. That means >shares depend on arbitrary stuff that sharing shouldn't depend on >(e.g. whether disk heads move, how many other interrupts are served, >who arrived first), and there's nothing explicit to control what the >shares do depend on. However, I assume I must have missed something, >as I'm sure you've thought of this. > >As far as I can work out (haven't had time to work through the >non-linear case where the small standing queue might disappear >completely), shares don't explicitly depend on RTT or packet size or >delayed ack factor (which IMHO they shouldn't). While both the >acceleration and deceleration of each flow do depend on these factors >in equal measures (which IMHO they should too). So far so good, but... > >...taking RTT as one example, altho the steady state shares won't >depend directly on RTT, they might depend on second order effects of >how differences in RTT interact with other random events. If correct, >that's not good. It's random. > >Put another way, repeating the question in my earlier posting: >Q. Why should the controller aim to *increase* delay up to the target? > >Instead the window *increase* could operate as a separate continuous >process (as in AIMD algos). And the threshold only indicates a >*decrease* is needed if exceeded. Then bottleneck sharing is >explicitly under control. It is the equilibrium when the two >decoupled increase & decrease processes balance. 'TARGET' then >becomes merely a lower threshold for the decrease process, not a >target for both processes. > > >Bob > >At 07:29 03/04/2009, Stanislav Shalunov wrote: > >We have not observed the late-comer's advantage. > > > >As soon as the first flow has a hiccup (for example, because something > >needs to wait for a few disk head moves), there will be a gap in the > >first flow's traffic, enabling the second flow to measure accurately. > > > >During the session Murari mentioned that in their experience, flows > >were also always able to get a reasonable base delay measurement. > > > >Obviously, the more flows, the more uniform the traffic, the more > >likely it is that the late comers might be mistaken about the base. > >At tens of flows, this is clearly not a problem. At tens of > >thousands, which is what most backbones see for bulk connections, I'd > >expect it to start showing. The coordination problem at tens of > >thousands of connections is hard and almost certain to be emergent, > >but then extended congestion on backbone links is infrequent. In the > >worst case, it'll all fall back to TCP. > > > >For a small number of flows, the situation most typically encountered > >on congested links, base estimation seems to be reliable. > > > > > >On Tue, Mar 31, 2009 at 5:23 PM, Douglas Leith wrote: > > > Can I ask what the expected/desired behaviour will be when two or more > > > ledbat flows share a link ? > > > For example, say a first flow starts, ramps us cwnd until it hits > > the target > > > queueing delay and then a second ledbat flow starts a while > later. Its not > > > clear to me from the ID how the first flow would alter its cwnd to make > > > space for the second ledbat flow (especially if the second flow > > does not use > > > slow start, or perhaps has an early exit from slow start). > > > Also, is there a danger that, similarly the vegas and related algorithms, > > > the later starting flow will have difficulty getting an accurate > > estimate of > > > the base RTT since earlier starting flows maintain a standing queue ? > > > Doug > > > www.hamilton.ie > > > > > > > >-- > >Stanislav Shalunov > >BitTorrent Inc > >shalunov@bittorrent.com > > > >personal: http://shlang.com > >_______________________________________________ > >ledbat mailing list > >ledbat@ietf.org > >https://www.ietf.org/mailman/listinfo/ledbat > >________________________________________________________________ >Bob Briscoe, Networks Research Centre, BT Research > >_______________________________________________ >ledbat mailing list >ledbat@ietf.org >https://www.ietf.org/mailman/listinfo/ledbat ________________________________________________________________ Bob Briscoe, Networks Research Centre, BT Research From nweaver@ICSI.Berkeley.EDU Mon Jun 8 11:13:29 2009 Return-Path: X-Original-To: ledbat@core3.amsl.com Delivered-To: ledbat@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 809803A67FD for ; Mon, 8 Jun 2009 11:13:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.996 X-Spam-Level: X-Spam-Status: No, score=-5.996 tagged_above=-999 required=5 tests=[AWL=0.603, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Se6J03mjYeI3 for ; Mon, 8 Jun 2009 11:13:28 -0700 (PDT) Received: from fruitcake.ICSI.Berkeley.EDU (fruitcake.ICSI.Berkeley.EDU [192.150.186.11]) by core3.amsl.com (Postfix) with ESMTP id B8F8D3A6A90 for ; Mon, 8 Jun 2009 11:13:28 -0700 (PDT) Received: from [IPv6:::1] (jack.ICSI.Berkeley.EDU [192.150.186.73]) by fruitcake.ICSI.Berkeley.EDU (8.12.11.20060614/8.12.11) with ESMTP id n58IDYjJ017435; Mon, 8 Jun 2009 11:13:34 -0700 (PDT) Message-Id: <56AA4CC8-D6C4-4CF5-AFAE-6698C22DD3FE@ICSI.Berkeley.EDU> From: Nicholas Weaver To: ledbat@ietf.org Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v935.3) Date: Mon, 8 Jun 2009 11:13:33 -0700 X-Mailer: Apple Mail (2.935.3) Cc: Nicholas Weaver Subject: [ledbat] The ICSI Netalyzr X-BeenThere: ledbat@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Mailing list of the LEDBAT WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 08 Jun 2009 18:13:29 -0000 The public beta of the ICSI Netalyzr is now live at http://netalyzr.icsi.berkeley.edu This Java applet is designed to allow users to probe and discover various properties about their network connection. The many tests include latency, bandwidth, and buffer size measurements. Other, more subtle tests detect port filtering and hidden proxies, the correct operation of in-network HTTP caches, and the general health and behavior of the DNS resolver. In particular, the test includes buffer sizing and bandwidth, which directly relate to this working group. From muraris@microsoft.com Mon Jun 8 11:43:01 2009 Return-Path: X-Original-To: ledbat@core3.amsl.com Delivered-To: ledbat@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 8B9083A6A98 for ; Mon, 8 Jun 2009 11:43:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.454 X-Spam-Level: X-Spam-Status: No, score=-10.454 tagged_above=-999 required=5 tests=[AWL=0.145, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id g-FPgCQe3ibz for ; Mon, 8 Jun 2009 11:43:00 -0700 (PDT) Received: from smtp.microsoft.com (mail2.microsoft.com [131.107.115.215]) by core3.amsl.com (Postfix) with ESMTP id 9200B3A6A90 for ; Mon, 8 Jun 2009 11:43:00 -0700 (PDT) Received: from tk5-expfs-c107.redmond.corp.microsoft.com (157.54.69.47) by TK5-EXGWY-E802.partners.extranet.microsoft.com (10.251.56.168) with Microsoft SMTP Server (TLS) id 8.2.99.4; Mon, 8 Jun 2009 11:43:05 -0700 Received: from NA-EXMSG-C110.redmond.corp.microsoft.com ([157.54.62.162]) by tk5-expfs-c107.redmond.corp.microsoft.com ([157.54.69.47]) with mapi; Mon, 8 Jun 2009 11:43:05 -0700 From: Murari Sridharan To: Nicholas Weaver , "ledbat@ietf.org" Date: Mon, 8 Jun 2009 11:43:03 -0700 Thread-Topic: [ledbat] The ICSI Netalyzr Thread-Index: AcnoZNvVyr5eeRrSQY2tVFUerGP85wABBNqw Message-ID: References: <56AA4CC8-D6C4-4CF5-AFAE-6698C22DD3FE@ICSI.Berkeley.EDU> In-Reply-To: <56AA4CC8-D6C4-4CF5-AFAE-6698C22DD3FE@ICSI.Berkeley.EDU> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: Re: [ledbat] The ICSI Netalyzr X-BeenThere: ledbat@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Mailing list of the LEDBAT WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 08 Jun 2009 18:43:01 -0000 This is great Nick, will try this out and get back to you.=20 -----Original Message----- From: ledbat-bounces@ietf.org [mailto:ledbat-bounces@ietf.org] On Behalf Of= Nicholas Weaver Sent: Monday, June 08, 2009 11:14 AM To: ledbat@ietf.org Cc: Nicholas Weaver Subject: [ledbat] The ICSI Netalyzr The public beta of the ICSI Netalyzr is now live at http://netalyzr.icsi.berkeley.edu This Java applet is designed to allow users to probe and discover various properties about their network connection. The many tests include latency, bandwidth, and buffer size measurements. Other, more subtle tests detect port filtering and hidden proxies, the correct operation of in-network HTTP caches, and the general health and behavior of the DNS resolver. In particular, the test includes buffer sizing and bandwidth, which =20 directly relate to this working group. _______________________________________________ ledbat mailing list ledbat@ietf.org https://www.ietf.org/mailman/listinfo/ledbat From muraris@microsoft.com Tue Jun 16 11:48:31 2009 Return-Path: X-Original-To: ledbat@core3.amsl.com Delivered-To: ledbat@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 65D7B3A6C0C for ; Tue, 16 Jun 2009 11:48:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.512 X-Spam-Level: X-Spam-Status: No, score=-10.512 tagged_above=-999 required=5 tests=[AWL=0.087, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id SBaWh-mTHFJK for ; Tue, 16 Jun 2009 11:48:29 -0700 (PDT) Received: from smtp.microsoft.com (smtp.microsoft.com [131.107.115.212]) by core3.amsl.com (Postfix) with ESMTP id C5D8A3A6BC8 for ; Tue, 16 Jun 2009 11:48:29 -0700 (PDT) Received: from TK5-EXHUB-C102.redmond.corp.microsoft.com (157.54.18.53) by TK5-EXGWY-E801.partners.extranet.microsoft.com (10.251.56.50) with Microsoft SMTP Server (TLS) id 8.2.99.4; Tue, 16 Jun 2009 11:48:40 -0700 Received: from NA-EXMSG-C110.redmond.corp.microsoft.com ([157.54.62.162]) by TK5-EXHUB-C102.redmond.corp.microsoft.com ([157.54.18.53]) with mapi; Tue, 16 Jun 2009 11:48:40 -0700 From: Murari Sridharan To: Murari Sridharan , Bob Briscoe , Stanislav Shalunov Date: Tue, 16 Jun 2009 11:48:39 -0700 Thread-Topic: [ledbat] fairness between competing delay flows in draft-shalunov-ledbat-congestion-00.txt Thread-Index: Acm5Ec7gYopJq2ogQS2SatWpTLT3iQptLPtWAvsYtoA= Message-ID: References: <6c82d1360904022329o34efd701p8b7a0b08730ae65a@mail.gmail.com>, <200904091250.n39CoVKH018460@bagheera.jungle.bt.co.uk> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: Douglas Leith , "ledbat@ietf.org" Subject: Re: [ledbat] fairness between competing delay flows in draft-shalunov-ledbat-congestion-00.txt X-BeenThere: ledbat@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Mailing list of the LEDBAT WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 16 Jun 2009 18:48:31 -0000 Stas, any updates on this? we are getting close and it would be best to add= ress some of the key concerns so we can take a call on the mailing list on = making this a WG item.=20 -----Original Message----- From: ledbat-bounces@ietf.org [mailto:ledbat-bounces@ietf.org] On Behalf Of= Murari Sridharan Sent: Monday, June 01, 2009 8:05 AM To: Bob Briscoe; Stanislav Shalunov Cc: Douglas Leith; ledbat@ietf.org Subject: Re: [ledbat] fairness between competing delay flows in draft-shalu= nov-ledbat-congestion-00.txt Bob i think you are raising some very valid points here, Stas would be grea= t if you can respond to his mail, havent seen one yet.=20 Bob, If i understand you correctly CTCP does somethign like this, there is = a seperate window increase process and there is a delay threshold (as measu= red through gamma which is the packets backlogged) which is used simply as = a thresold to decrease if exceeded. Low priority TCP which is "a" ledbat t= ype solution that we are looking at for some of our scenarios. Even though = it doesnt have an explicit delay target it tries to detect change in slope = and adjusts the receive window to throttle the sender. It does aim to maint= ain a lower delay and does so well in our experiments but there is no expli= cit delay target. I am trying out a simple variant where the receiver measu= res the backlog using a vegas style equation with rcvwnd instead of cwnd to= see if we can keep a certain amount of packets backlogged thereby doing so= methign liek what you describe below. Will keep the list posted on the find= ings. The main difference though is that low priority TCP does infact relyo= n RTT and not o ne-way delay so reverse path congestion could affect this. The advantage i= s it works as an alternative congestion control option on regular TCP and o= nly one end needs to change, both of which are very compelling.=20 Regarding getting a good delay measurement that is indeed what we observed = with CTCP over production links. However in the case of CTCP we did a lot o= f testing on high-speed links and there was enough statistical multiplexing= and we almost always got a good base delay measurement. In the case when t= he bottleneck is a home link and there are multiple ledbat flows within the= home the first movers advantage that Doug mentions is indeed possible. In = Stas' experiments I am not sure if he had multiple ledbat flows within the = home from different computers and if he saw this problem or not.=20 At this point it would be great if some folks in the DL can try out a NS ve= rsion of the algorithm, its simple and straightforward to implement and we = can then study different aspects being discussed below. Stas do you have so= me results you can share, would be great to see how some of the dynamics be= low work in practice.=20 Thanks ________________________________________ From: ledbat-bounces@ietf.org [ledbat-bounces@ietf.org] On Behalf Of Bob Br= iscoe [rbriscoe@jungle.bt.co.uk] Sent: Thursday, April 09, 2009 5:50 AM To: Stanislav Shalunov Cc: Douglas Leith; ledbat@ietf.org Subject: Re: [ledbat] fairness between competing delay flows in draft-shalu= nov-ledbat-congestion-00.txt Stas, Point taken about base measurements, but this questions is about the motivation for the core part of the control algo: cwnd +=3D GAIN * off_target / cwnd. (using the draft's terminology: off_target =3D TARGET - queuing_delay) Q. Why should the controller's increase and decrease both depend on the same formula? I think this means the shares that competing flows get depend purely on the minutiae of the dynamics of each competing flow. That means shares depend on arbitrary stuff that sharing shouldn't depend on (e.g. whether disk heads move, how many other interrupts are served, who arrived first), and there's nothing explicit to control what the shares do depend on. However, I assume I must have missed something, as I'm sure you've thought of this. As far as I can work out (haven't had time to work through the non-linear case where the small standing queue might disappear completely), shares don't explicitly depend on RTT or packet size or delayed ack factor (which IMHO they shouldn't). While both the acceleration and deceleration of each flow do depend on these factors in equal measures (which IMHO they should too). So far so good, but... ...taking RTT as one example, altho the steady state shares won't depend directly on RTT, they might depend on second order effects of how differences in RTT interact with other random events. If correct, that's not good. It's random. Put another way, repeating the question in my earlier posting: Q. Why should the controller aim to *increase* delay up to the target? Instead the window *increase* could operate as a separate continuous process (as in AIMD algos). And the threshold only indicates a *decrease* is needed if exceeded. Then bottleneck sharing is explicitly under control. It is the equilibrium when the two decoupled increase & decrease processes balance. 'TARGET' then becomes merely a lower threshold for the decrease process, not a target for both processes. Bob At 07:29 03/04/2009, Stanislav Shalunov wrote: >We have not observed the late-comer's advantage. > >As soon as the first flow has a hiccup (for example, because something >needs to wait for a few disk head moves), there will be a gap in the >first flow's traffic, enabling the second flow to measure accurately. > >During the session Murari mentioned that in their experience, flows >were also always able to get a reasonable base delay measurement. > >Obviously, the more flows, the more uniform the traffic, the more >likely it is that the late comers might be mistaken about the base. >At tens of flows, this is clearly not a problem. At tens of >thousands, which is what most backbones see for bulk connections, I'd >expect it to start showing. The coordination problem at tens of >thousands of connections is hard and almost certain to be emergent, >but then extended congestion on backbone links is infrequent. In the >worst case, it'll all fall back to TCP. > >For a small number of flows, the situation most typically encountered >on congested links, base estimation seems to be reliable. > > >On Tue, Mar 31, 2009 at 5:23 PM, Douglas Leith wrote: > > Can I ask what the expected/desired behaviour will be when two or more > > ledbat flows share a link ? > > For example, say a first flow starts, ramps us cwnd until it hits > the target > > queueing delay and then a second ledbat flow starts a while later. Its= not > > clear to me from the ID how the first flow would alter its cwnd to make > > space for the second ledbat flow (especially if the second flow > does not use > > slow start, or perhaps has an early exit from slow start). > > Also, is there a danger that, similarly the vegas and related algorithm= s, > > the later starting flow will have difficulty getting an accurate > estimate of > > the base RTT since earlier starting flows maintain a standing queue ? > > Doug > > www.hamilton.ie > > > >-- >Stanislav Shalunov >BitTorrent Inc >shalunov@bittorrent.com > >personal: http://shlang.com >_______________________________________________ >ledbat mailing list >ledbat@ietf.org >https://www.ietf.org/mailman/listinfo/ledbat ________________________________________________________________ Bob Briscoe, Networks Research Centre, BT Research _______________________________________________ ledbat mailing list ledbat@ietf.org https://www.ietf.org/mailman/listinfo/ledbat _______________________________________________ ledbat mailing list ledbat@ietf.org https://www.ietf.org/mailman/listinfo/ledbat From muraris@microsoft.com Thu Jun 25 05:27:25 2009 Return-Path: X-Original-To: ledbat@core3.amsl.com Delivered-To: ledbat@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 0F28828C13A for ; Thu, 25 Jun 2009 05:27:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.526 X-Spam-Level: X-Spam-Status: No, score=-10.526 tagged_above=-999 required=5 tests=[AWL=0.073, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id XznE18fYFVLj for ; Thu, 25 Jun 2009 05:27:23 -0700 (PDT) Received: from smtp.microsoft.com (smtp.microsoft.com [131.107.115.214]) by core3.amsl.com (Postfix) with ESMTP id DDA933A6AF0 for ; Thu, 25 Jun 2009 05:27:23 -0700 (PDT) Received: from TK5-EXHUB-C102.redmond.corp.microsoft.com (157.54.18.53) by TK5-EXGWY-E803.partners.extranet.microsoft.com (10.251.56.169) with Microsoft SMTP Server (TLS) id 8.2.99.4; Thu, 25 Jun 2009 05:26:26 -0700 Received: from NA-EXMSG-C110.redmond.corp.microsoft.com ([157.54.62.150]) by TK5-EXHUB-C102.redmond.corp.microsoft.com ([157.54.18.53]) with mapi; Thu, 25 Jun 2009 05:26:26 -0700 From: Murari Sridharan To: Murari Sridharan , Nicholas Weaver , "ledbat@ietf.org" Date: Thu, 25 Jun 2009 05:26:25 -0700 Thread-Topic: [ledbat] The ICSI Netalyzr Thread-Index: AcnoZNvVyr5eeRrSQY2tVFUerGP85wABBNqwA0m9bEA= Message-ID: References: <56AA4CC8-D6C4-4CF5-AFAE-6698C22DD3FE@ICSI.Berkeley.EDU> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: Re: [ledbat] The ICSI Netalyzr X-BeenThere: ledbat@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Mailing list of the LEDBAT WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 25 Jun 2009 12:27:25 -0000 Nick, do you have details on how you did the buffer measurements? I tried t= his on multiple modems (DSL, WiMAX clearwire) and almost always the bufferi= ng was ~4s. This may very well be the case but iw as a bit surprised to see= the similar numbers across multiple access types. Has ton of useful info s= o I think this is very useful.=20 Thanks Murari=20 -----Original Message----- From: ledbat-bounces@ietf.org [mailto:ledbat-bounces@ietf.org] On Behalf Of= Murari Sridharan Sent: Monday, June 08, 2009 11:43 AM To: Nicholas Weaver; ledbat@ietf.org Subject: Re: [ledbat] The ICSI Netalyzr This is great Nick, will try this out and get back to you.=20 -----Original Message----- From: ledbat-bounces@ietf.org [mailto:ledbat-bounces@ietf.org] On Behalf Of= Nicholas Weaver Sent: Monday, June 08, 2009 11:14 AM To: ledbat@ietf.org Cc: Nicholas Weaver Subject: [ledbat] The ICSI Netalyzr The public beta of the ICSI Netalyzr is now live at http://netalyzr.icsi.berkeley.edu This Java applet is designed to allow users to probe and discover various properties about their network connection. The many tests include latency, bandwidth, and buffer size measurements. Other, more subtle tests detect port filtering and hidden proxies, the correct operation of in-network HTTP caches, and the general health and behavior of the DNS resolver. In particular, the test includes buffer sizing and bandwidth, which =20 directly relate to this working group. _______________________________________________ ledbat mailing list ledbat@ietf.org https://www.ietf.org/mailman/listinfo/ledbat _______________________________________________ ledbat mailing list ledbat@ietf.org https://www.ietf.org/mailman/listinfo/ledbat From nweaver@ICSI.Berkeley.EDU Thu Jun 25 05:47:33 2009 Return-Path: X-Original-To: ledbat@core3.amsl.com Delivered-To: ledbat@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id B8F133A6CC7 for ; Thu, 25 Jun 2009 05:47:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.847 X-Spam-Level: X-Spam-Status: No, score=-5.847 tagged_above=-999 required=5 tests=[AWL=0.752, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id gbVh7lpGNmbY for ; Thu, 25 Jun 2009 05:47:33 -0700 (PDT) Received: from fruitcake.ICSI.Berkeley.EDU (fruitcake.ICSI.Berkeley.EDU [192.150.186.11]) by core3.amsl.com (Postfix) with ESMTP id 0C1DE3A69B9 for ; Thu, 25 Jun 2009 05:47:33 -0700 (PDT) Received: from [IPv6:::1] (jack.ICSI.Berkeley.EDU [192.150.186.73]) by fruitcake.ICSI.Berkeley.EDU (8.12.11.20060614/8.12.11) with ESMTP id n5PChY1B026479; Thu, 25 Jun 2009 05:43:34 -0700 (PDT) Message-Id: <8F3271CA-1464-4026-B661-A85BB2BC8665@ICSI.Berkeley.EDU> From: Nicholas Weaver To: Murari Sridharan In-Reply-To: Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v935.3) Date: Thu, 25 Jun 2009 05:43:34 -0700 References: <56AA4CC8-D6C4-4CF5-AFAE-6698C22DD3FE@ICSI.Berkeley.EDU> X-Mailer: Apple Mail (2.935.3) Cc: "ledbat@ietf.org" , Nicholas Weaver Subject: Re: [ledbat] The ICSI Netalyzr X-BeenThere: ledbat@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Mailing list of the LEDBAT WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 25 Jun 2009 12:47:33 -0000 On Jun 25, 2009, at 5:26 AM, Murari Sridharan wrote: > Nick, do you have details on how you did the buffer measurements? I > tried this on multiple modems (DSL, WiMAX clearwire) and almost > always the buffering was ~4s. This may very well be the case but iw > as a bit surprised to see the similar numbers across multiple access > types. Has ton of useful info so I think this is very useful. Its a very crude test: It simply does a quiet (no traffic) ping to get the baseline RTT. Then in blasts large UDP packets at full rate for 10 seconds. During the 10 second sending interval, the last 5 seconds are used to measure the RTT time for the packets received, and the difference is the estimated buffer size. The packet rate during this 5 second period is used for the bandwidth estimation and reordering tracking. It tends to produce somewhat weird results on wireless links where there is access control, so there may be delays in that case that would not be seen. Or if there is a separate rate limit for UDP as well. From nweaver@ICSI.Berkeley.EDU Thu Jun 25 05:52:06 2009 Return-Path: X-Original-To: ledbat@core3.amsl.com Delivered-To: ledbat@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 155D73A69B9 for ; Thu, 25 Jun 2009 05:52:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.868 X-Spam-Level: X-Spam-Status: No, score=-5.868 tagged_above=-999 required=5 tests=[AWL=0.731, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id o2Ti7yILn6Ag for ; Thu, 25 Jun 2009 05:52:05 -0700 (PDT) Received: from fruitcake.ICSI.Berkeley.EDU (fruitcake.ICSI.Berkeley.EDU [192.150.186.11]) by core3.amsl.com (Postfix) with ESMTP id 6982E3A683F for ; Thu, 25 Jun 2009 05:52:05 -0700 (PDT) Received: from [IPv6:::1] (jack.ICSI.Berkeley.EDU [192.150.186.73]) by fruitcake.ICSI.Berkeley.EDU (8.12.11.20060614/8.12.11) with ESMTP id n5PCnuN1027412; Thu, 25 Jun 2009 05:49:57 -0700 (PDT) Message-Id: From: Nicholas Weaver To: Murari Sridharan In-Reply-To: <8F3271CA-1464-4026-B661-A85BB2BC8665@ICSI.Berkeley.EDU> Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v935.3) Date: Thu, 25 Jun 2009 05:49:56 -0700 References: <56AA4CC8-D6C4-4CF5-AFAE-6698C22DD3FE@ICSI.Berkeley.EDU> <8F3271CA-1464-4026-B661-A85BB2BC8665@ICSI.Berkeley.EDU> X-Mailer: Apple Mail (2.935.3) Cc: ledbat@ietf.org, Nicholas Weaver Subject: Re: [ledbat] The ICSI Netalyzr X-BeenThere: ledbat@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Mailing list of the LEDBAT WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 25 Jun 2009 12:52:06 -0000 On Jun 25, 2009, at 5:43 AM, Nicholas Weaver wrote: > > On Jun 25, 2009, at 5:26 AM, Murari Sridharan wrote: > >> Nick, do you have details on how you did the buffer measurements? I >> tried this on multiple modems (DSL, WiMAX clearwire) and almost >> always the buffering was ~4s. This may very well be the case but iw >> as a bit surprised to see the similar numbers across multiple >> access types. Has ton of useful info so I think this is very useful. > > Its a very crude test: It simply does a quiet (no traffic) ping to > get the baseline RTT. Then in blasts large UDP packets at full rate > for 10 seconds. During the 10 second sending interval, the last 5 > seconds are used to measure the RTT time for the packets received, > and the difference is the estimated buffer size. This also means that there is an effective max measured delay of <5 seconds in practice, so this could easily be the phenomenon you are seeing. Its really only designed to get ballpark-figures/feel: how many have annoying (>500ms) and bad (>1s) buffers. From the point of view of LEDBAT, P2P designers, hardware designers, etc, its not the detailed figure but just the general ballpark thats of concern, because the details can vary so much by current conditions. From muraris@microsoft.com Fri Jun 26 08:28:23 2009 Return-Path: X-Original-To: ledbat@core3.amsl.com Delivered-To: ledbat@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 13D5E3A6AEA for ; Fri, 26 Jun 2009 08:28:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.536 X-Spam-Level: X-Spam-Status: No, score=-10.536 tagged_above=-999 required=5 tests=[AWL=0.062, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id PTAvpZvhMt01 for ; Fri, 26 Jun 2009 08:28:17 -0700 (PDT) Received: from smtp.microsoft.com (mailc.microsoft.com [131.107.115.214]) by core3.amsl.com (Postfix) with ESMTP id E8CCE3A6A6D for ; Fri, 26 Jun 2009 08:28:16 -0700 (PDT) Received: from tk5-exhub-c103.redmond.corp.microsoft.com (157.54.88.96) by TK5-EXGWY-E803.partners.extranet.microsoft.com (10.251.56.169) with Microsoft SMTP Server (TLS) id 8.2.99.4; Fri, 26 Jun 2009 08:28:03 -0700 Received: from NA-EXMSG-C110.redmond.corp.microsoft.com ([157.54.62.150]) by tk5-exhub-c103.redmond.corp.microsoft.com ([157.54.88.96]) with mapi; Fri, 26 Jun 2009 08:28:03 -0700 From: Murari Sridharan To: "ledbat@ietf.org" Date: Fri, 26 Jun 2009 08:28:02 -0700 Thread-Topic: Progress, Agendas and such Thread-Index: Acn2crF8+oXvFLneRJOiAjioodke2A== Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: multipart/alternative; boundary="_000_FCA794787FDE0D4DBE9FFA11053ECEB6231E547ACBNAEXMSGC110re_" MIME-Version: 1.0 Subject: [ledbat] Progress, Agendas and such X-BeenThere: ledbat@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Mailing list of the LEDBAT WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 26 Jun 2009 15:28:23 -0000 --_000_FCA794787FDE0D4DBE9FFA11053ECEB6231E547ACBNAEXMSGC110re_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Folks, we are getting closer to the Stockholm meeting and we need to make q= uite a bit of progress. This mail is a summary of where things stand, what = action items we have and a proposed plan to move things forward. We have the following documents and none of these so far are WG items. For = starters we need to adopt these as WG items and then continue discussions, = here is what we have so far. draft-shalunov-ledbat-congestion There have been some fairness concerns raised regarding the algorithm inclu= ding whether the controller should aim to move delay to a target. Should the target be a fixed value? Is there a first mover advantage, espec= ially inside a home environment where there are not too many flows for ther= e to be effective statistical multiplexing? It would be good to get some folks on the list to do a Greenfield implement= ation. The control algorithm is straightforward and should be easy to study= the dynamics in NS for instance. It would be good to see data on how the algorithm behaves both in simulatio= n and from field trials that Stas performed. Stas do let us know how much o= f this data you can share, you can of course anonymize any user specific in= formation and show us graphs depicting specific behavior. This definitely c= alls for reversion of your document answering/clarifying some of the questi= ons raised in the mailing lists. There is work to do but I think we are ready to adopt this as a WG item and= then continue working on improving the algorithm. Right now there is no al= ternative proposal. We did get a informal (verbal) hum in favor of adopting= this as a WG item in SFO. Unless anybody has specific objections we should= go ahead with this plan. draft-penno-ledbat-app-practices-recommendations There was a ton of feedback on this I am looking forward to seeing a next v= ersion from the authors but I believe this one is also ready to be adopted = as a WG item. Reinaldo please let us know when we can see a revised draft i= ncorporating the comments. draft-welzl-ledbat-survey This is a pretty good summary of the related research but many people hadn'= t read it at the last IETF it would be great if you can send feedback to Mi= chael. Regarding the agenda for Stockholm. Michael asked for a slot. Each draft ab= ove will get one slot. There are a ton of interesting questions/discussions= to be had on the ledbat congestion control front. If somebody did a Greenf= ield implementation or analyzes the algorithm further it would be good to h= ave you come up and present your findings as well. Thanks Murari --_000_FCA794787FDE0D4DBE9FFA11053ECEB6231E547ACBNAEXMSGC110re_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Folks, we are getting closer to the Stockholm meeting = and we need to make quite a bit of progress. This mail is a summary of where thing= s stand, what action items we have and a proposed plan to move things forward= .

 

We have the following documents and none of these so f= ar are WG items. For starters we need to adopt these as WG items and then continue discussions, here is what we have so far.

 

d= raft-shalunov-ledbat-congestion

There have been some fairness concerns raised regardin= g the algorithm including whether the controller should aim to move delay to a target.

Should the target be a fixed value? Is there a first m= over advantage, especially inside a home environment where there are not too man= y flows for there to be effective statistical multiplexing?

 

It would be good to get some folks on the list to do a= Greenfield implementation. The control algorithm is straightforward and should be easy= to study the dynamics in NS for instance.

It would be good to see data on how the algorithm beha= ves both in simulation and from field trials that Stas performed. Stas do let u= s know how much of this data you can share, you can of course anonymize any u= ser specific information and show us graphs depicting specific behavior. This definitely calls for reversion of your document answering/clarifying some of the quest= ions raised in the mailing lists.

 

There is work to do but I think we are ready to adopt = this as a WG item and then continue working on improving the algorithm. Right no= w there is no alternative proposal. We did get a informal (verbal) hum in fav= or of adopting this as a WG item in SFO. Unless anybody has specific objection= s we should go ahead with this plan.

 

draft-penno-ledbat-app-practices-recommendations

There was a ton of feedback on this I am looking forwa= rd to seeing a next version from the authors but I believe this one is also ready= to be adopted as a WG item. Reinaldo please let us know when we can see a revi= sed draft incorporating the comments.

 

draft-we= lzl-ledbat-survey

This is a pretty good summary of the related research = but many people hadn’t read it at the last IETF it would be great if you = can send feedback to Michael.

 

Regarding the agenda for Stockholm. Michael asked for = a slot. Each draft above will get one slot. There are a ton of interesting questions/discussions to be had on the ledbat congestion control front. If somebody did a Greenfield implementation or analyzes the algorithm further = it would be good to have you come up and present your findings as well. <= /o:p>

 

Thanks

Murari

--_000_FCA794787FDE0D4DBE9FFA11053ECEB6231E547ACBNAEXMSGC110re_-- From muraris@microsoft.com Fri Jun 26 08:46:56 2009 Return-Path: X-Original-To: ledbat@core3.amsl.com Delivered-To: ledbat@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 654833A6AC0 for ; Fri, 26 Jun 2009 08:46:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.544 X-Spam-Level: X-Spam-Status: No, score=-10.544 tagged_above=-999 required=5 tests=[AWL=0.054, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id O8Sj3HGQgJkE for ; Fri, 26 Jun 2009 08:46:55 -0700 (PDT) Received: from smtp.microsoft.com (smtp.microsoft.com [131.107.115.212]) by core3.amsl.com (Postfix) with ESMTP id 926973A697E for ; Fri, 26 Jun 2009 08:46:55 -0700 (PDT) Received: from tk5-expfs-c104.redmond.corp.microsoft.com (157.54.88.62) by TK5-EXGWY-E801.partners.extranet.microsoft.com (10.251.56.50) with Microsoft SMTP Server (TLS) id 8.2.99.4; Fri, 26 Jun 2009 08:46:33 -0700 Received: from NA-EXMSG-C110.redmond.corp.microsoft.com ([157.54.62.150]) by tk5-expfs-c104.redmond.corp.microsoft.com ([157.54.88.62]) with mapi; Fri, 26 Jun 2009 08:46:33 -0700 From: Murari Sridharan To: "ledbat@ietf.org" Date: Fri, 26 Jun 2009 08:46:32 -0700 Thread-Topic: Ledbat variants Thread-Index: Acn2dUciHlE+x/bASeGzSY+/P0T4eA== Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: multipart/alternative; boundary="_000_FCA794787FDE0D4DBE9FFA11053ECEB6231E547AE3NAEXMSGC110re_" MIME-Version: 1.0 Subject: [ledbat] Ledbat variants X-BeenThere: ledbat@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Mailing list of the LEDBAT WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 26 Jun 2009 15:46:56 -0000 --_000_FCA794787FDE0D4DBE9FFA11053ECEB6231E547AE3NAEXMSGC110re_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable All, There is a need for ledbat type CC as an alternative congestion control on = TCP. The difference here is that it has to work within TCP as a form of con= gestion control (or flow control). There are several applications (not incl= uding P2P apps) that require this behavior. The main differences are a) the= re is no additional framing other than TCP framing b) it should be incremen= tally deployable, that is only one end (sender or receiver) needs to change= as you may not always have control over both ends c) given it would work w= ithin TCP it would react to RTT (as opposed to one-way delay) and as a resu= lt will be affected by reverse path congestion. Even though one of the ledb= at requirements is to saturate the bottleneck there are applications that a= re perfectly fine without saturating the link as long as some basic guarant= ees on flow completion. In our charter we have text that says applications of this algorithm to exi= sting transport protocols is expected to occur in WGs that maintain those p= rotocols be it TCP, DCCP or SCTP. Does that mean a ledbat variant such as a= bove gets discussed in TCPM or ICCRG or should we take a stab at it here an= d move it to ICCRG at some later point? Thanks --_000_FCA794787FDE0D4DBE9FFA11053ECEB6231E547AE3NAEXMSGC110re_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

All,

 

There is a need for ledbat type CC as an alternative congestion control on TCP. The difference here is that it has to work withi= n TCP as a form of congestion control (or flow control). There are several ap= plications (not including P2P apps) that require this behavior. The main differences a= re a) there is no additional framing other than TCP framing b) it should be in= crementally deployable, that is only one end (sender or receiver) needs to change as yo= u may not always have control over both ends c) given it would work within TC= P it would react to RTT (as opposed to one-way delay) and as a result will be affected by reverse path congestion. Even though one of the ledbat requirem= ents is to saturate the bottleneck there are applications that are perfectly fin= e without saturating the link as long as some basic guarantees on flow comple= tion.

 

In our charter we have text that says applications of = this algorithm to existing transport protocols is expected to occur in WGs that maintain those protocols be it TCP, DCCP or SCTP. Does that mean a ledbat variant such as above gets discussed in TCPM or ICCRG or should we take a s= tab at it here and move it to ICCRG at some later point?

 

Thanks

--_000_FCA794787FDE0D4DBE9FFA11053ECEB6231E547AE3NAEXMSGC110re_-- From lars.eggert@nokia.com Mon Jun 29 00:41:59 2009 Return-Path: X-Original-To: ledbat@core3.amsl.com Delivered-To: ledbat@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 8789D28C169 for ; Mon, 29 Jun 2009 00:41:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.545 X-Spam-Level: X-Spam-Status: No, score=-2.545 tagged_above=-999 required=5 tests=[AWL=0.054, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id XIaHqFDoRJUh for ; Mon, 29 Jun 2009 00:41:58 -0700 (PDT) Received: from mail.fit.nokia.com (mail.fit.nokia.com [195.148.124.195]) by core3.amsl.com (Postfix) with ESMTP id 5A3FF3A6A0D for ; Mon, 29 Jun 2009 00:41:58 -0700 (PDT) Received: from [192.168.0.198] (funet-wlan.fit.nokia.com [195.148.124.254]) (authenticated bits=0) by mail.fit.nokia.com (8.14.3/8.14.3) with ESMTP id n5T7gCkE058799 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NOT); Mon, 29 Jun 2009 10:42:13 +0300 (EEST) (envelope-from lars.eggert@nokia.com) Message-Id: <3C4E2A7B-9634-4E22-BD6B-3AE49D16948C@nokia.com> From: Lars Eggert To: Murari Sridharan In-Reply-To: Content-Type: multipart/signed; boundary=Apple-Mail-11--481328400; micalg=sha1; protocol="application/pkcs7-signature" Mime-Version: 1.0 (Apple Message framework v935.3) Date: Mon, 29 Jun 2009 10:42:07 +0300 References: X-Mailer: Apple Mail (2.935.3) X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.2.2 (mail.fit.nokia.com [195.148.124.194]); Mon, 29 Jun 2009 10:42:13 +0300 (EEST) Cc: "ledbat@ietf.org" Subject: Re: [ledbat] Ledbat variants X-BeenThere: ledbat@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Mailing list of the LEDBAT WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 29 Jun 2009 07:41:59 -0000 --Apple-Mail-11--481328400 Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Hi, On 2009-6-26, at 18:46, Murari Sridharan wrote: > In our charter we have text that says applications of this algorithm > to existing transport protocols is expected to occur in WGs that > maintain those protocols be it TCP, DCCP or SCTP. Does that mean a > ledbat variant such as above gets discussed in TCPM or ICCRG or > should we take a stab at it here and move it to ICCRG at some later > point? the - maybe naive - assumption behind the charter text was that LEDBAT would produce one experimental CC algorithm that could then be applied to different transport protocols in whatever WG maintains those protocols. The issue you raise - what if "the" LEDBAT algorithm requires input or behavior that one of the protocols can't provide? - is interesting, and I don't think we thought about this case at chartering time. My personal preference would be to still try and come up with one simple algorithm that can actually be applied to several of our transport protocols. The reason is that it'll be difficult enough to model, simulate and experimentally vet this one algorithm, and multiplying this effort will require many more cycles. On the other hand, if someone came up with a really good LBE algorithm that for example only worked for DCCP, I don't see why we wouldn't want to publish this in some form (in cooperation with the DCCP WG, in this example case.) But I don't think we should fragment the effort into per-protocol algorithms unless we really need to. On 2009-6-26, at 18:46, Murari Sridharan wrote: > There is a need for ledbat type CC as an alternative congestion > control on TCP. True. I may be naive again, but the draft-shalunov-ledbat-congestion algorithm is adapted from TCP Vegas - do we not believe that it would work when re-applied to TCP? > The difference here is that it has to work within TCP as a form of > congestion control (or flow control). There are several applications > (not including P2P apps) that require this behavior. The main > differences are a) there is no additional framing other than TCP > framing b) it should be incrementally deployable, that is only one > end (sender or receiver) needs to change as you may not always have > control over both ends c) given it would work within TCP it would > react to RTT (as opposed to one-way delay) and as a result will be > affected by reverse path congestion. (b) is a new requirement that during the chartering phase wasn't discussed much. Obviously, it'd be nice if a one-ended algorithm would work, but I'd worry that we're lopping off too much of the design space if we make this a hard requirement. > Even though one of the ledbat requirements is to saturate the > bottleneck there are applications that are perfectly fine without > saturating the link as long as some basic guarantees on flow > completion. This is again diverging a bit from the goals of the charter. I don't think that anyone would be seriously concerned if we came up with an otherwise good algorithm that in some corner cases can't fill the bottleneck, but if we came up with one that'd never saturate the bottleneck, I'd expect the bulk transfer folks to argue a bit. Lars --Apple-Mail-11--481328400 Content-Disposition: attachment; filename=smime.p7s Content-Type: application/pkcs7-signature; name=smime.p7s Content-Transfer-Encoding: base64 MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIGQDCCAvkw ggJioAMCAQICEEi7WbMMKa2GLKFpQDaOBQEwDQYJKoZIhvcNAQEFBQAwYjELMAkGA1UEBhMCWkEx JTAjBgNVBAoTHFRoYXd0ZSBDb25zdWx0aW5nIChQdHkpIEx0ZC4xLDAqBgNVBAMTI1RoYXd0ZSBQ ZXJzb25hbCBGcmVlbWFpbCBJc3N1aW5nIENBMB4XDTA4MDgyMzE3NDMzOVoXDTA5MDgyMzE3NDMz OVowXDEPMA0GA1UEBBMGRWdnZXJ0MQ0wCwYDVQQqEwRMYXJzMRQwEgYDVQQDEwtMYXJzIEVnZ2Vy dDEkMCIGCSqGSIb3DQEJARYVbGFycy5lZ2dlcnRAbm9raWEuY29tMIIBIjANBgkqhkiG9w0BAQEF AAOCAQ8AMIIBCgKCAQEAlwQVktJZCY89iU6jcW1XnZQN+aMgF2utCUT3H3ZKB5Jbet1SDWt0md/W 571bHjxtn9CfEJdochNL3l9f1WiJNdVbJ182557Ltx9SojqthpqtA0jKEqo2gqrf+raUj1demmo0 6ocsLqv046CrwidOp6k0RAfvkKPLhD4PD9Nk3oaZuxqBz1wY4u8Q83iWMArDeXiQxfNZnOBz5cDs VvVjTjitm3VANkbD02tNkwl5AHw7htde4yH8hIwlfzqsAtHBEah3HyOvs9b+gHg2pFz9eS+HuotY ZKycCweRs8NKXoCg+zAkVYi3zvZEH2VOuPlpMQMrB9+fLWg2UBsTeZ864wIDAQABozIwMDAgBgNV HREEGTAXgRVsYXJzLmVnZ2VydEBub2tpYS5jb20wDAYDVR0TAQH/BAIwADANBgkqhkiG9w0BAQUF AAOBgQBMdV2U+ryV5t3nuBFH19XKflodN6Bc60GBYHHY/Z0+Cl08Q75qzTt02IILBg+/YVh/fygb 6pFrOm1sFtLN7fENBfbO2VtpFjP2lGUgbXTVT5xGM6+MtqZiBI6LqexAeY6gsd/taoUfy9fZG42d ciBA9gSGlQjjWQyG8mb5HR8L9jCCAz8wggKooAMCAQICAQ0wDQYJKoZIhvcNAQEFBQAwgdExCzAJ BgNVBAYTAlpBMRUwEwYDVQQIEwxXZXN0ZXJuIENhcGUxEjAQBgNVBAcTCUNhcGUgVG93bjEaMBgG A1UEChMRVGhhd3RlIENvbnN1bHRpbmcxKDAmBgNVBAsTH0NlcnRpZmljYXRpb24gU2VydmljZXMg RGl2aXNpb24xJDAiBgNVBAMTG1RoYXd0ZSBQZXJzb25hbCBGcmVlbWFpbCBDQTErMCkGCSqGSIb3 DQEJARYccGVyc29uYWwtZnJlZW1haWxAdGhhd3RlLmNvbTAeFw0wMzA3MTcwMDAwMDBaFw0xMzA3 MTYyMzU5NTlaMGIxCzAJBgNVBAYTAlpBMSUwIwYDVQQKExxUaGF3dGUgQ29uc3VsdGluZyAoUHR5 KSBMdGQuMSwwKgYDVQQDEyNUaGF3dGUgUGVyc29uYWwgRnJlZW1haWwgSXNzdWluZyBDQTCBnzAN BgkqhkiG9w0BAQEFAAOBjQAwgYkCgYEAxKY8VXNV+065yplaHmjAdQRwnd/p/6Me7L3N9VvyGna9 fww6YfK/Uc4B1OVQCjDXAmNaLIkVcI7dyfArhVqqP3FWy688Cwfn8R+RNiQqE88r1fOCdz0Dviv+ uxg+B79AgAJk16emu59l0cUqVIUPSAR/p7bRPGEEQB5kGXJgt/sCAwEAAaOBlDCBkTASBgNVHRMB Af8ECDAGAQH/AgEAMEMGA1UdHwQ8MDowOKA2oDSGMmh0dHA6Ly9jcmwudGhhd3RlLmNvbS9UaGF3 dGVQZXJzb25hbEZyZWVtYWlsQ0EuY3JsMAsGA1UdDwQEAwIBBjApBgNVHREEIjAgpB4wHDEaMBgG A1UEAxMRUHJpdmF0ZUxhYmVsMi0xMzgwDQYJKoZIhvcNAQEFBQADgYEASIzRUIPqCy7MDaNmrGcP f6+svsIXoUOWlJ1/TCG4+DYfqi2fNi/A9BxQIJNwPP2t4WFiw9k6GX6EsZkbAMUaC4J0niVQlGLH 2ydxVyWN3amcOY6MIE9lX5Xa9/eH1sYITq726jTlEBpbNU1341YheILcIRk13iSx0x1G/11fZU8x ggMQMIIDDAIBATB2MGIxCzAJBgNVBAYTAlpBMSUwIwYDVQQKExxUaGF3dGUgQ29uc3VsdGluZyAo UHR5KSBMdGQuMSwwKgYDVQQDEyNUaGF3dGUgUGVyc29uYWwgRnJlZW1haWwgSXNzdWluZyBDQQIQ SLtZswwprYYsoWlANo4FATAJBgUrDgMCGgUAoIIBbzAYBgkqhkiG9w0BCQMxCwYJKoZIhvcNAQcB MBwGCSqGSIb3DQEJBTEPFw0wOTA2MjkwNzQyMDdaMCMGCSqGSIb3DQEJBDEWBBS9FaR0D7ptOw3G 1lqbiZM9KvXOMTCBhQYJKwYBBAGCNxAEMXgwdjBiMQswCQYDVQQGEwJaQTElMCMGA1UEChMcVGhh d3RlIENvbnN1bHRpbmcgKFB0eSkgTHRkLjEsMCoGA1UEAxMjVGhhd3RlIFBlcnNvbmFsIEZyZWVt YWlsIElzc3VpbmcgQ0ECEEi7WbMMKa2GLKFpQDaOBQEwgYcGCyqGSIb3DQEJEAILMXigdjBiMQsw CQYDVQQGEwJaQTElMCMGA1UEChMcVGhhd3RlIENvbnN1bHRpbmcgKFB0eSkgTHRkLjEsMCoGA1UE AxMjVGhhd3RlIFBlcnNvbmFsIEZyZWVtYWlsIElzc3VpbmcgQ0ECEEi7WbMMKa2GLKFpQDaOBQEw DQYJKoZIhvcNAQEBBQAEggEAiCwVVZM6Nn1M8HFG22qGuAJIKUG/MyinVnn3vD0fs87jb/PS95YB VTBvORs2O0PPBXR0CG1G2HOxg3dXzqRsWylvPEaX9KRlC0GBFq7KSfIHHW/IttRTIiLBr7IYi/cG 2hmCmyIpRxu+s7Fbb3SP7s6cAKF57vcYEEGqNqF+433ib9N6dJgD8hzvXVtvVlN3nPnxGkzvbqZB Esbafa9tP7ecpS1IYVo0dL1Ui7boSBhDzfWYgSPiujWqXiux1m8EK/zoQRpEOVJdlnPPUAANMvYV ZMslHtoJ2GiyjVEn4Kdo9+pLcq2AdVwo1Nduqtox3Gz/bAC6KtltJBVNffRIPAAAAAAAAA== --Apple-Mail-11--481328400--