From arjuna.sathiaseelan@gmail.com Fri Jul 1 03:03:04 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 9BD3F21F86EA for ; Fri, 1 Jul 2011 03:03:04 -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 MrmEhOqYkKuM for ; Fri, 1 Jul 2011 03:03:04 -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 13E7221F86E9 for ; Fri, 1 Jul 2011 03:03:03 -0700 (PDT) Received: by qwc23 with SMTP id 23so2528123qwc.31 for ; Fri, 01 Jul 2011 03:03:03 -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=PjgOBqGQQpfG4DJPZsGNjN1D991WYmyKMZ+bzgv3lMU=; b=P4morvtdisA1024QWKM4GNE0+M3uP8Qa/Xokq25W1h3Fs4ZkafxBa62FAESXYhTH6L phB5WTj4PVJJXCiK+G4r4QT7LaYpKg5/wfLPstAdfCewPL4u3TxYL+dY/XFhUNr+LUtr VIy2WnRG4ZmsWy/aqZsslejWztUZSSs/VKjMo= MIME-Version: 1.0 Received: by 10.229.51.204 with SMTP id e12mr2394648qcg.178.1309514583375; Fri, 01 Jul 2011 03:03:03 -0700 (PDT) Sender: arjuna.sathiaseelan@gmail.com Received: by 10.229.87.8 with HTTP; Fri, 1 Jul 2011 03:03:03 -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> Date: Fri, 1 Jul 2011 11:03:03 +0100 X-Google-Sender-Auth: LQ55YwHEYHmZxX10P98T1tnk8fQ Message-ID: From: Arjuna Sathiaseelan To: Lachlan Andrew 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: Fri, 01 Jul 2011 10:03:04 -0000 Dear Lachlan - thanks for your reply.. > No. =A0This confuses "better" with "gives a higher throughput to this > user". =A0The 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. Ofcourse I agree with you - that was the whole point of CC..However we still have the liberty to perform actions (for e.g. opening multiple TCP connections, or stopping and starting a new connection when we find the Internet is too slow in responding etc)..And they all seem to be legitimate actions although not good for the network..App designers want better performance for their apps - so they end up thinking of new ways of circumventing the law of the Internet CC..and their actions sound legitimate within the realm. Bob and others have been trying to say this for the past few years - that there is no real notion of fairness in the Internet today and Matt Mathis (who came out with the notion of TCP-friendliness) agrees with it now. So my belief is that next generation TCP could have a more aggressive approach providing incentive for app designers but at the same time being more reactive to congestion. Coupled with mechanisms such as ECN, CONEX etc they could be effective.. But when it comes to LEDBAT, we cannot take this approach. We need to be more conservative.. Regards Arjuna From arjuna.sathiaseelan@gmail.com Fri Jul 1 03:06:50 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 F0C1D11E80F6 for ; Fri, 1 Jul 2011 03:06:49 -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 PI14bsvA42LB for ; Fri, 1 Jul 2011 03:06:49 -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 6216D11E80BB for ; Fri, 1 Jul 2011 03:06:44 -0700 (PDT) Received: by qwc23 with SMTP id 23so2530340qwc.31 for ; Fri, 01 Jul 2011 03:06: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=EpCkAVYuGkImKRS3sHSrkFSNzdSdF5Pf7r+2hhfqaKs=; b=Hx5iyTcU5l3UAHlVNFaCttuyshNAM4hPggfFrHFzV2T9DV1zmIZJodB395zHcIOsMs AYmX16LxuYK4+1NdPto7gI7Xfa8ZCC4kNnh1Ke525RDj/ToTbtZ1ydjmxcA5PMVOWyqh Q0wgTgMS1XIqIBOOmWmiR9iNIC+28PxKFnXYo= MIME-Version: 1.0 Received: by 10.229.98.20 with SMTP id o20mr2316822qcn.216.1309514803785; Fri, 01 Jul 2011 03:06:43 -0700 (PDT) Sender: arjuna.sathiaseelan@gmail.com Received: by 10.229.87.8 with HTTP; Fri, 1 Jul 2011 03:06:43 -0700 (PDT) In-Reply-To: <4E0CF96E.90105@fandm.edu> References: <791AD3077F94194BB2BDD13565B6295D05E6DF22@PALLENE.office.hd> <201106291339.03755.mirja.kuehlewind@ikr.uni-stuttgart.de> <201106301317.35684.mirja.kuehlewind@ikr.uni-stuttgart.de> <4E0CF96E.90105@fandm.edu> Date: Fri, 1 Jul 2011 11:06:43 +0100 X-Google-Sender-Auth: u5Rxut7yEW2U74l4-1u0j_dpOoI Message-ID: From: Arjuna Sathiaseelan 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] 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: Fri, 01 Jul 2011 10:06:50 -0000 Dear Jana, I really think introducing the notion of a timer would be a great idea to mitigate some of the problems..I am happy to discuss this. Regards Arjuna On 30 June 2011 23:32, Janardhan Iyengar wrote: > Arjuna, > > Thank you for raising this question --- it is an important one that we > missed but, IMHO, need to resolve. =A0LEDBAT does not currently account f= or > rate reduction in the case of extreme congestion, as both TFRC and TCP do= . > =A0A couple of thoughts offhand: > > - =A0Under extreme congestion where TCP would have timed-out and TFRC wou= ld > have backed-down significantly, LEDBAT will only halve its sending rate. = =A0If > 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? > > - =A0There is no notion of a timer in LEDBAT so far. =A0If we decide to > introduce a timer, we could use the current RTT estimate to seed it, or g= o > with a fixed 1 second as the initial seed time, with a backoff of the tim= er > on a subsequent loss. =A0We could then use the timer to decide how long t= o 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, >> =A0 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 =A0- 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 >> =A0wrote: >>> >>> Hi Arjuna, hi Gorry, >>> >>> I was not aware that there is any recommendation to send only one packe= t >>> 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 t= o >>> 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, >>>> =A0 I am not sure whether cwnd of 2 packets/RTT during periods of heav= y >>>> 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 >>>> >>>> =A0wrote: >>>>> >>>>> 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 an= y >>>>>> 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 >>> ------------------------------------------------------------------- >>> >> _______________________________________________ >> 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 bob.briscoe@bt.com Fri Jul 1 04:30:40 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 8C69F21F862C for ; Fri, 1 Jul 2011 04:30:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.212 X-Spam-Level: X-Spam-Status: No, score=-3.212 tagged_above=-999 required=5 tests=[AWL=0.160, 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 vhLAocRXoMqq for ; Fri, 1 Jul 2011 04:30:39 -0700 (PDT) Received: from smtp3.smtp.bt.com (smtp3.smtp.bt.com [217.32.164.138]) by ietfa.amsl.com (Postfix) with ESMTP id 3376E21F861A for ; Fri, 1 Jul 2011 04:30:38 -0700 (PDT) Received: from i2kc08-ukbr.domain1.systemhost.net ([193.113.197.71]) by smtp3.smtp.bt.com with Microsoft SMTPSVC(6.0.3790.4675); Fri, 1 Jul 2011 12:30:37 +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 12:30:37 +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 1309519836713; Fri, 1 Jul 2011 12:30:36 +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 p61BUZ79020490; Fri, 1 Jul 2011 12:30:35 +0100 Message-Id: <201107011130.p61BUZ79020490@bagheera.jungle.bt.co.uk> X-Mailer: QUALCOMM Windows Eudora Version 7.1.0.9 Date: Fri, 01 Jul 2011 12:30:34 +0100 To: Lachlan Andrew From: Bob Briscoe In-Reply-To: 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> 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 11:30:37.0317 (UTC) FILETIME=[4C8A4B50:01CC37E2] 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 11:30:40 -0000 Lachlan, I'm trying to work out the mental model you have that leads to this conclusion. Perhaps you are thinking ECN happens at a shallower point in the queue than loss? I was also thinking the response to ECN could be less - until I thought it through a couple of days ago. I posted the logical progression on this list which concluded that LEDBAT has to respond the same to ECN and to loss. See within As you are proposing otherwise, if you say where you disagree with that logical progression we might be able to get to the bottom of this? Bob At 05:47 01/07/2011, Lachlan Andrew wrote: >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. Why should a LEDBAT flow reduce > > 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. 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. > >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; 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? > >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 (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 > >-- >Lachlan Andrew Centre for Advanced Internet Architectures (CAIA) >Swinburne University of Technology, Melbourne, Australia > >Ph +61 3 9214 4837 >_______________________________________________ >ledbat mailing list >ledbat@ietf.org >https://www.ietf.org/mailman/listinfo/ledbat ________________________________________________________________ Bob Briscoe, BT Innovate & Design From jana.iyengar@gmail.com Fri Jul 1 15:40:17 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 7CE2311E81F7 for ; Fri, 1 Jul 2011 15:40:17 -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 w12kvmvV4Sni for ; Fri, 1 Jul 2011 15:40:16 -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 18FFD11E81EB for ; Fri, 1 Jul 2011 15:40:16 -0700 (PDT) Received: by vws12 with SMTP id 12so3274951vws.31 for ; Fri, 01 Jul 2011 15:40:15 -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=XLJZt0E6GebeZj6nWoHkdxJyuAoH7CVpgCK/QKEs6Pw=; b=dnUulFZk576vkJjopKAn0jc/GWV/2wZR2H6Hk0FzUcXlOmfH4PQH4y4r84mrn2lCuw aW+YEX2R+AqLSeROXXTaF2+jy6j/lflEafw0EoS5aC3TaV4eTXrzUHY5/Q6ZutWLxW4C aofhQyEBWtqxzf4vOROQcQFSZizQ3qvA5rzss= Received: by 10.52.180.194 with SMTP id dq2mr1177809vdc.105.1309560015492; Fri, 01 Jul 2011 15:40:15 -0700 (PDT) Received: from surutti.fandm.edu ([155.68.120.206]) by mx.google.com with ESMTPS id c9sm1427578vdv.16.2011.07.01.15.40.13 (version=TLSv1/SSLv3 cipher=OTHER); Fri, 01 Jul 2011 15:40:14 -0700 (PDT) Message-ID: <4E0E4CCC.2050309@fandm.edu> Date: Fri, 01 Jul 2011 18:40:12 -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: Bob Briscoe 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> <201107010008.p6108VZe017272@bagheera.jungle.bt.co.uk> In-Reply-To: <201107010008.p6108VZe017272@bagheera.jungle.bt.co.uk> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: 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 22:40:17 -0000 Bob, Here's what I'm adding in the Applicability Section; please let me know what you think. " When used with an ECN-capable framing protocol, LEDBAT should react to an ECN mark as it would to a loss, as specified in [RFC3168]. LEDBAT is designed to reduce build-up of a standing queue by long- lived LEDBAT flows at a link with a tail-drop FIFO queue, so as to avoid persistently delaying other flows sharing the queue. If Active Queue Management (AQM) is configured to drop or ECN-mark packets before the LEDBAT starts reacting to persistent queue build-up, LEDBAT reverts to TCP behavior, rather than yield to other TCP flows. However, such an AQM is still desirable since it keeps queuing delay low, achieving an outcome that is in line with LEDBAT's goals. Additionally, a LEDBAT transport that supports ECN enjoys the advantages that an ECN-capable TCP enjoys over an ECN-agnostic TCP; avoiding losses and possible retransmissions. Weighted Fair Queuing (WFQ), as employed by some home gateways [Schneider10], seeks to isolate and protect delay-sensitive flows from delays due to standing queues built up by concurrent long-lived flows. Consequently, while it prevents LEDBAT from yielding to other flows, it again achieves an outcome that is in line with LEDBAT's goals [Schneider10]. Further study is required to fully understand the behaviour of LEDBAT with non-drop-tail, non-FIFO queues. " Thanks, - jana On 6/30/11 8:08 PM, Bob Briscoe wrote: > 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 -- Janardhan Iyengar Assistant Professor, Computer Science Franklin & Marshall College http://www.fandm.edu/jiyengar From jana.iyengar@gmail.com Fri Jul 1 17:48: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 0C0AF11E80BD for ; Fri, 1 Jul 2011 17:48: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 7Jb5YK-ToC5j for ; Fri, 1 Jul 2011 17:48:15 -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 13CF411E8092 for ; Fri, 1 Jul 2011 17:48:14 -0700 (PDT) Received: by qyk9 with SMTP id 9so265571qyk.10 for ; Fri, 01 Jul 2011 17:48:14 -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=/7QFU6L54h73fFRBCjz7TQw/sN+bfnCqTnvWKZFpnew=; b=fXK6RGyrGzr1KNZVzWAKnZCICNpChqLfiVNe9HG4SgeJUqktsQFZsmpxckO5uQlehB OUDKyxBJYcGSU2mfdZjmUpEGO8htkzTeftqnfnxZ2lUGPC0UM4L7TAQ2zjsjDJJr9lZF XinvTZkukTQOhCK79ow0vcI0+KjP4GdYTtB50= Received: by 10.229.43.95 with SMTP id v31mr3057741qce.120.1309567674262; Fri, 01 Jul 2011 17:47:54 -0700 (PDT) Received: from surutti.fandm.edu ([155.68.120.206]) by mx.google.com with ESMTPS id l36sm2973299qck.7.2011.07.01.17.47.52 (version=TLSv1/SSLv3 cipher=OTHER); Fri, 01 Jul 2011 17:47:53 -0700 (PDT) Message-ID: <4E0E6AB7.9060808@fandm.edu> Date: Fri, 01 Jul 2011 20:47:51 -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> <4E0D4657.9050906@fandm.edu> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: 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: Sat, 02 Jul 2011 00:48:16 -0000 Hi Lachlan, I think I understand (and am sympathetic to) your general point -- having a weaker congestion response to an ECN mark than to a loss seems intriguing. That said ... >> 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)? > > 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). .. this part I don't understand. This seems like an artificial incentive. Why should TCP-like flows choose to reduce by more than 1/2 on loss, when there's no way of knowing whether ECN marking is turned ON at the point of congestion? > 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 LEDBAT does not back off more timidly on loss. It currently behaves as TCP (i.e., reduce rate by 1/2) when loss is experienced. Caveat: It is possible that the LEDBAT reduction is ultimately more than TCP's under the same circumstances due to cumulative reduction with delay and loss *if the LEDBAT sender witnesses a delay increase first*; with a rate reduction due to the increasing queue, and then a cutting-back by 1/2 when loss is experienced. > 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... I think I see how have different reactions might set up the right incentives for deployment of network-wide ECN... however, endpoints cannot start with the assumption of ECN in the network. Expecting endpoints to reduce by more than 1/2 on loss seems like an artificial incentive that might get easily ignored in implementations. But then again, that seems like an update to 3168, and not just to LEDBAT. - jana -- Janardhan Iyengar Assistant Professor, Computer Science Franklin & Marshall College http://www.fandm.edu/jiyengar From lachlan.andrew@gmail.com Fri Jul 1 17:55:50 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 1561511E80D4 for ; Fri, 1 Jul 2011 17:55:50 -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 ZMEI0EKVvQ0q for ; Fri, 1 Jul 2011 17:55:45 -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 43C5E11E80A7 for ; Fri, 1 Jul 2011 17:55:45 -0700 (PDT) Received: by wwe5 with SMTP id 5so2487835wwe.13 for ; Fri, 01 Jul 2011 17:55:44 -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=aqJ5xEOnooPouIi68js6HFSGjSLkqQbB+ZEhbHUUy9A=; b=pkVyqHKededj/X1ofyrZBYirCVvMctrmVwaoM87k1bZypghXZNszZmSIF39AKMko3y Q2V2JqgxmUpAvnFr83l59wIsXgnOjXGri+iWKcbxPgqpGOZX1veH67mWne9xdLu4ibNs VJFiBi4Yzx8fTE+VJM5eOzfpK//bnuGe3ro4A= Received: by 10.216.18.72 with SMTP id k50mr3412765wek.49.1309568144178; Fri, 01 Jul 2011 17:55:44 -0700 (PDT) MIME-Version: 1.0 Received: by 10.216.71.3 with HTTP; Fri, 1 Jul 2011 17:55:24 -0700 (PDT) In-Reply-To: <201107011130.p61BUZ79020490@bagheera.jungle.bt.co.uk> 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> <201107011130.p61BUZ79020490@bagheera.jungle.bt.co.uk> From: Lachlan Andrew Date: Sat, 2 Jul 2011 10:55:24 +1000 Message-ID: To: Bob Briscoe 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: Sat, 02 Jul 2011 00:55:50 -0000 Greetings Bob, Our point of divergence is probably step 1 in your argument. I was still thinking of LEDBAT as less than best effort. If it (permanently) reverts to standard TCP on loss, then it is not longer less than best effort, since LEDBAT flows will typically be long and experience at least one loss before most of the transfer is complete. However, if it only *temporarily* reverts to standard TCP, then step 1 of the argument is misleading. ECN and loss can differ in how long they cause the LEDBAT flow to remain aggressive. If ECN causes it to remain aggressive longer than loss does, then there is an incentive to enable ECN (if throughput gives an incentive). If higher throughput is not an incentive (that's why we're not using TCP), then smoothness may be an incentive; ECN could cause a more mild immediate backoff but revert more quickly to non-TCP behaviour. You may say that these alternatives are too complex to be worthwhile. If so, I'd probably agree. However, I'm arguing that it is *possible* to give an incentive to use ECN without breaking other design goals. Cheers, Lachlan On 1 July 2011 21:30, Bob Briscoe wrote: > Lachlan, > > I'm trying to work out the mental model you have that leads to this > conclusion. Perhaps you are thinking ECN happens at a shallower point in = the > queue than loss? > > I was also thinking the response to ECN could be less - until I thought i= t > through a couple of days ago. I posted the logical progression on this li= st > which concluded that LEDBAT has to respond the same to ECN and to loss. > > See within > > > As you are proposing otherwise, if you say where you disagree with that > logical progression we might be able to get to the bottom of this? --=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 Fri Jul 1 18:22: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 989B821F84EE for ; Fri, 1 Jul 2011 18:22:44 -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 pGFcBYpyXNsh for ; Fri, 1 Jul 2011 18:22:43 -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 E4FEC21F8578 for ; Fri, 1 Jul 2011 18:21:36 -0700 (PDT) Received: by wyj26 with SMTP id 26so2891097wyj.31 for ; Fri, 01 Jul 2011 18:21:36 -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=o9pulX2egTlC3WYR3WoCItZzPdEnjJFYCzb+2XT7jms=; b=Ji7jnc6Ml7J7gJnl1a383JzQOiuaxj7avDoPXmmBdVfL57DGkr1QhXT+9foowA0HyR fPVStiseCI1f6/L6ggGfaSPImmOuZZZM4N5qm2F6FN4cDXM+yz8M57GvEsyvHVzjUB22 oUkkv7qQ5wOPTDi1I6zRtyjE6dgvdo9MW/Nzs= Received: by 10.216.69.65 with SMTP id m43mr1750775wed.4.1309569694196; Fri, 01 Jul 2011 18:21:34 -0700 (PDT) MIME-Version: 1.0 Received: by 10.216.71.3 with HTTP; Fri, 1 Jul 2011 18:21:14 -0700 (PDT) In-Reply-To: <4E0E6AB7.9060808@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> <4E0E6AB7.9060808@fandm.edu> From: Lachlan Andrew Date: Sat, 2 Jul 2011 11:21:14 +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: Sat, 02 Jul 2011 01:22:44 -0000 Greetings Jana, On 2 July 2011 10:47, Janardhan Iyengar wrote: >> >> 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). > > .. this part I don't understand. =A0This seems like an artificial incenti= ve. > =A0Why should TCP-like flows choose to reduce by more than 1/2 on loss, w= hen > there's no way of knowing whether ECN marking is turned ON at the point o= f > congestion? The reason would be to be less-than-best-effort. >> There is no logical reason that something that >> backs of more timidly on loss should also back off more timidly on CE > > LEDBAT does not back off more timidly on loss. =A0It currently behaves as= TCP > (i.e., reduce rate by 1/2) when loss is experienced. =A0Caveat: It is pos= sible > that the LEDBAT reduction is ultimately more than TCP's under the same > circumstances due to cumulative reduction with delay and loss *if the LED= BAT > sender witnesses a delay increase first*; with a rate reduction due to th= e > increasing queue, and then a cutting-back by 1/2 when loss is experienced= . Yes. I would argue that the Caveat should be the "usual" case when a TCP flow happens to use the same low-capacity bottleneck. Treating ECN differently in that single case is enough to give an incentive to enable it, even if the response to a loss in the core/distribution network is the same. >> 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. =A0If making the response identical actually >> *stifles* the deployment of ECN by prohibiting the correct incentives, >> then perhaps the wording of 3168 should be fixed... > > I think I see how have different reactions might set up the right incenti= ves > for deployment of network-wide ECN... however, endpoints cannot start wit= h > the assumption of ECN in the network. =A0Expecting endpoints to reduce by= more > than 1/2 on loss seems like an artificial incentive that might get easily > ignored in implementations. If the RFC says to do it, then an implementer who wants to be RFC-compliant will do it. An implementer who doesn't want to be RFC compliant could choose to ignore any other part of the spec too. If you mean it might be *overlooked* in an implementation, then that depends on how the text is written. The point is that, as long as the response to ECN is not more aggressive than TCP's, then you are free to specify whatever response to loss you like. (Even if the immediate response is halving the window, the whole response includes when to become more timid again. That can differ for loss and ECN, as I said in my reply to Bob.) > But then again, that seems like an update to 3168, and not just to LEDBAT= . True. A requirement that ECN be treated *identically* to loss basically prohibits incentives to use ECN. Perhaps I'm arguing for a 3168-compatible spec, rather than a 3168-compliant one. As long as LEDBAT remains no more aggressive than TCP, we know it won't cause the Internet to melt down. Cheers, Lachlan --=20 Lachlan Andrew=A0 Centre for Advanced Internet Architectures (CAIA) Swinburne University of Technology, Melbourne, Australia Ph +61 3 9214 4837 From jana.iyengar@gmail.com Fri Jul 1 18:37: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 52EAE11E80C7 for ; Fri, 1 Jul 2011 18:37:45 -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 jLG2ge860aM5 for ; Fri, 1 Jul 2011 18:37:44 -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 5735011E80A2 for ; Fri, 1 Jul 2011 18:37:44 -0700 (PDT) Received: by vws12 with SMTP id 12so3341279vws.31 for ; Fri, 01 Jul 2011 18:37:43 -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=AVhEqrS83mdmo9JaCQUdInmNfZe3uem2cXNvc+OjHgw=; b=WoOnt47PIDhBR5IEQtxkBO//al+XIWTj0HKXIQTYjeyM15rfUUcWYL45s8NT4xl8fM MJmQAn2dTxk3nFBcEymMSwvL9LXitY6amvAJ7M1E+OFFuh4FstNxOPesTU9OrvAmGzLN xURtCBU+HHq3QnfFBWw0ycy+scqj5qtyc6gIY= Received: by 10.52.181.234 with SMTP id dz10mr5520032vdc.190.1309570662064; Fri, 01 Jul 2011 18:37:42 -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 c1sm1467565vdu.29.2011.07.01.18.37.40 (version=TLSv1/SSLv3 cipher=OTHER); Fri, 01 Jul 2011 18:37:41 -0700 (PDT) Message-ID: <4E0E7662.8000003@fandm.edu> Date: Fri, 01 Jul 2011 21:37:38 -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: Bob Briscoe 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> <201107011130.p61BUZ79020490@bagheera.jungle.bt.co.uk> In-Reply-To: <201107011130.p61BUZ79020490@bagheera.jungle.bt.co.uk> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: 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: Sat, 02 Jul 2011 01:37:45 -0000 Bob, Lachlan, (Lachlan, I'd like to hear what you have to say too) Even if the ECN happened at a shallower point in the queue than loss, wouldn't a lesser reduction imply that the LEDBAT flow backs off lesser than a competing ECN-capable TCP, in the absence of a delay signal? So, a question that I pointed out in my earlier email (and I wonder, Lachlan, if this is what you had in mind) -- how should a LEDBAT flow reduce its rate on ECN or loss, if it does observe a queueing delay increase preceding that event? The current LEDBAT mechanism would be more aggressive in its reaction to the congestion "event" than TCP. We could simply say that LEDBAT ought to be more conservative anyways.... that would be simplest. But can we do better? - jana On 7/1/11 7:30 AM, Bob Briscoe wrote: > Lachlan, > > I'm trying to work out the mental model you have that leads to this conclusion. Perhaps you are thinking ECN happens at a shallower point in the queue than loss? > > I was also thinking the response to ECN could be less - until I thought it through a couple of days ago. I posted the logical progression on this list which concluded that LEDBAT has to respond the same to ECN and to loss. > > See within > > As you are proposing otherwise, if you say where you disagree with that logical progression we might be able to get to the bottom of this? > > > Bob > > At 05:47 01/07/2011, Lachlan Andrew wrote: >> 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. Why should a LEDBAT flow reduce >> > 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. 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. >> >> 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; 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? >> >> 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 (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 >> >> -- >> Lachlan Andrew Centre for Advanced Internet Architectures (CAIA) >> Swinburne University of Technology, Melbourne, Australia >> >> Ph +61 3 9214 4837 >> _______________________________________________ >> ledbat mailing list >> ledbat@ietf.org >> https://www.ietf.org/mailman/listinfo/ledbat > > ________________________________________________________________ > Bob Briscoe, BT Innovate & Design -- Janardhan Iyengar Assistant Professor, Computer Science Franklin & Marshall College http://www.fandm.edu/jiyengar From jana.iyengar@gmail.com Fri Jul 1 20:10: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 B1BF821F8DD4 for ; Fri, 1 Jul 2011 20:10:48 -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 PO4syr338JMd for ; Fri, 1 Jul 2011 20:10:48 -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 BF79C21F8D4B for ; Fri, 1 Jul 2011 20:10:47 -0700 (PDT) Received: by vws12 with SMTP id 12so3373865vws.31 for ; Fri, 01 Jul 2011 20:10:47 -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=kybtsxa1VW/J57JNvaiQRCU6bywczJpVG/bnbLX/054=; b=CnfwOklww24MkCL1dGyhXNSOW6f4YQj4nRYS4e6G1ak6Z+TI1sFbEvAopdRxyA1OLG PTDhVd/eRx+YQ5zH02Ipes/+mHcIKqqhc30Pk34iSX50JEtGBpnEP4ZYy4awhSmbTfbJ aaXLSPg983T8WoEnEKtyW15FBPr8fVrhTTRok= Received: by 10.220.82.67 with SMTP id a3mr1419242vcl.235.1309576246843; Fri, 01 Jul 2011 20:10:46 -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 q15sm430244vch.41.2011.07.01.20.10.44 (version=TLSv1/SSLv3 cipher=OTHER); Fri, 01 Jul 2011 20:10:45 -0700 (PDT) Message-ID: <4E0E8C32.1050601@fandm.edu> Date: Fri, 01 Jul 2011 23:10:42 -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> <4E0D4657.9050906@fandm.edu> <201107011130.p61BUZ79020490@bagheera.jungle.bt.co.uk> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: 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: Sat, 02 Jul 2011 03:10:49 -0000 Hi Lachlan, I understand now what your proposal is. More inline. > I was still thinking of LEDBAT as less than best effort. If it > (permanently) reverts to standard TCP on loss, then it is not longer > less than best effort, since LEDBAT flows will typically be long and > experience at least one loss before most of the transfer is complete. No, LEDBAT does not revert to TCP per se, it only reduces its rate by 1/2 on loss. That is, a "temporary revert". > However, if it only *temporarily* reverts to standard TCP, then step 1 > of the argument is misleading. ECN and loss can differ in how long > they cause the LEDBAT flow to remain aggressive. If ECN causes it to > remain aggressive longer than loss does, then there is an incentive to > enable ECN (if throughput gives an incentive). If higher throughput > is not an incentive (that's why we're not using TCP), then smoothness > may be an incentive; ECN could cause a more mild immediate backoff but > revert more quickly to non-TCP behaviour. So, this is interesting, and it certainly warrants considering ideas that may not be too complex. One that comes to mind immediately relates to a point I made earlier: currently, LEDBAT will end up getting a cumulative reduction from increasing delay and ECN/loss when both are observed from the same congestion event. We could consider leaving it as such with loss---that is our pathological case after all---but we could be a bit more careful with ECN. Since LEDBAT's cwnd decreases with increasing queueing delay, a LEDBAT sender could track the highest cwnd within the past RTT (high_cwnd). On loss: the sender simply reduces its cwnd to curr_cwnd/2. On ECN: the sender reduces its window to min(curr_cwnd, high_cwnd/2). This makes it so that if there is no delay increase observed (as Bob suggests, in the core), the new cwnd should be roughly equivalent for both loss and ECN. If there is a delay increase, however, LEDBAT behaves conservatively under loss and a bit more experimentally with ECN. This seems safe enough, does not seem too complex, and certainly provides the incentive we're looking for. What do others think? Is this an avenue worth pursuing? - jana -- Janardhan Iyengar Assistant Professor, Computer Science Franklin & Marshall College http://www.fandm.edu/jiyengar From muraris@microsoft.com Sat Jul 2 02:47:24 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 697ED1F0C53 for ; Sat, 2 Jul 2011 02:47:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -110.372 X-Spam-Level: X-Spam-Status: No, score=-110.372 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8, 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 xn66Bmx9Oc-M for ; Sat, 2 Jul 2011 02:47:23 -0700 (PDT) Received: from smtp.microsoft.com (mail3.microsoft.com [131.107.115.214]) by ietfa.amsl.com (Postfix) with ESMTP id 927521F0C4B for ; Sat, 2 Jul 2011 02:47:23 -0700 (PDT) Received: from TK5EX14MLTC103.redmond.corp.microsoft.com (157.54.79.174) by TK5-EXGWY-E803.partners.extranet.microsoft.com (10.251.56.169) with Microsoft SMTP Server (TLS) id 8.2.176.0; Sat, 2 Jul 2011 02:47:23 -0700 Received: from TK5EX14MBXC298.redmond.corp.microsoft.com ([169.254.1.48]) by TK5EX14MLTC103.redmond.corp.microsoft.com ([157.54.79.174]) with mapi id 14.01.0289.008; Sat, 2 Jul 2011 02:47:23 -0700 From: Murari Sridharan To: "janardhan.iyengar@fandm.edu" , "Lachlan Andrew" Thread-Topic: [ledbat] ECN/AQM Thread-Index: AQHMNxqrykIrP0/nWEyNTFNqAJo2l5TWf/GAgAB1s4CAAFhMgIAADTkAgABwjwCAAODeAIAAJc4A///13XA= Date: Sat, 2 Jul 2011 09:47:22 +0000 Message-ID: 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> <201107011130.p61BUZ79020490@bagheera.jungle.bt.co.uk> <4E0E8C32.1050601@fandm.edu> In-Reply-To: <4E0E8C32.1050601@fandm.edu> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [157.54.51.36] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 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: Sat, 02 Jul 2011 09:47:24 -0000 Just caught up on the thread after my vacation. I think it's a bad idea to = fudge modified responses to ECN this late in the game into Ledbat. It is la= rgely speculative and clearly lacks experimentation and data to justify our= decisions.=20 There are several cases here as discussed by others that we need to be care= ful about. Depending on how low the marking threshold is ledbat may never o= bserve queue build ups that are reaching its target. If other on the bottle= neck are reacting but ledbat doesn't that could be an issue, however switch= es when they are congested (per marking threshold) tend to drop packets th= at dont have the ECT code point set, especially for IP traffic (meaning it = may allow ARP etc). It may very well be that ledbat encounters more packet = loss compared to ECN capable transports that are "protected" as marking can= be done on them without necessarily dropping them. If we think we can't re= ly on such switch behavior then we may have a problem. However I'd go back = to the fact that ledbat isn't a protocol and simply an algorithm on how to = achieve lower than best effort. So my vote is to strongly keep any recommen= dations in text rather than changing the algorithm in any way.=20 Thanks -----Original Message----- From: ledbat-bounces@ietf.org [mailto:ledbat-bounces@ietf.org] On Behalf Of= Janardhan Iyengar Sent: Friday, July 01, 2011 8:11 PM To: Lachlan Andrew Cc: ledbat@ietf.org Subject: Re: [ledbat] ECN/AQM Hi Lachlan, I understand now what your proposal is. More inline. > I was still thinking of LEDBAT as less than best effort. If it > (permanently) reverts to standard TCP on loss, then it is not longer=20 > less than best effort, since LEDBAT flows will typically be long and=20 > experience at least one loss before most of the transfer is complete. No, LEDBAT does not revert to TCP per se, it only reduces its rate by 1/2 o= n loss. That is, a "temporary revert". > However, if it only *temporarily* reverts to standard TCP, then step 1=20 > of the argument is misleading. ECN and loss can differ in how long=20 > they cause the LEDBAT flow to remain aggressive. If ECN causes it to=20 > remain aggressive longer than loss does, then there is an incentive to=20 > enable ECN (if throughput gives an incentive). If higher throughput=20 > is not an incentive (that's why we're not using TCP), then smoothness=20 > may be an incentive; ECN could cause a more mild immediate backoff but=20 > revert more quickly to non-TCP behaviour. So, this is interesting, and it certainly warrants considering ideas that m= ay not be too complex. One that comes to mind immediately relates to a poi= nt I made earlier: currently, LEDBAT will end up getting a cumulative red= uction from increasing delay and ECN/loss when both are observed from the s= ame congestion event. We could consider leaving it as such with loss---tha= t is our pathological case after all---but we could be a bit more careful w= ith ECN. Since LEDBAT's cwnd decreases with increasing queueing delay, a LEDBAT send= er could track the highest cwnd within the past RTT (high_cwnd). On loss: the sender simply reduces its cwnd to curr_cwnd/2. On ECN: the sender reduces its window to min(curr_cwnd, high_cwnd/2). This makes it so that if there is no delay increase observed (as Bob sugges= ts, in the core), the new cwnd should be roughly equivalent for both loss a= nd ECN. If there is a delay increase, however, LEDBAT behaves conservative= ly under loss and a bit more experimentally with ECN. This seems safe enough, does not seem too complex, and certainly provides t= he incentive we're looking for. What do others think? Is this an avenue w= orth pursuing? - jana -- 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 From bob.briscoe@bt.com Sun Jul 3 16:04: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 004861F0C39 for ; Sun, 3 Jul 2011 16:04:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.235 X-Spam-Level: X-Spam-Status: No, score=-3.235 tagged_above=-999 required=5 tests=[AWL=0.137, 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 tC67-KLf5QYS for ; Sun, 3 Jul 2011 16:04:18 -0700 (PDT) Received: from smtp4.smtp.bt.com (smtp4.smtp.bt.com [217.32.164.151]) by ietfa.amsl.com (Postfix) with ESMTP id AF6D41F0C3C for ; Sun, 3 Jul 2011 16:04:17 -0700 (PDT) Received: from i2kc06-ukbr.domain1.systemhost.net ([193.113.197.70]) by smtp4.smtp.bt.com with Microsoft SMTPSVC(6.0.3790.4675); Mon, 4 Jul 2011 00:04:16 +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); Mon, 4 Jul 2011 00:04: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 1309734246459; Mon, 4 Jul 2011 00:04:06 +0100 Received: from MUT.jungle.bt.co.uk ([10.73.128.25]) by bagheera.jungle.bt.co.uk (8.13.5/8.12.8) with ESMTP id p63N4C5j004449; Mon, 4 Jul 2011 00:04:12 +0100 Message-Id: <201107032304.p63N4C5j004449@bagheera.jungle.bt.co.uk> X-Mailer: QUALCOMM Windows Eudora Version 7.1.0.9 Date: Mon, 04 Jul 2011 00:04:12 +0100 To: Murari Sridharan From: Bob Briscoe In-Reply-To: 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> <201107011130.p61BUZ79020490@bagheera.jungle.bt.co.uk> <4E0E8C32.1050601@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: 03 Jul 2011 23:04:15.0723 (UTC) FILETIME=[87DE93B0:01CC39D5] 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: Sun, 03 Jul 2011 23:04:19 -0000 Murari, inline At 10:47 02/07/2011, Murari Sridharan wrote: >Just caught up on the thread after my vacation. I think it's a bad >idea to fudge modified responses to ECN this late in the game into >Ledbat. It is largely speculative and clearly lacks experimentation >and data to justify our decisions. > >There are several cases here as discussed by others that we need to >be careful about. Depending on how low the marking threshold is >ledbat may never observe queue build ups that are reaching its >target. If other on the bottleneck are reacting but ledbat doesn't >that could be an issue, however switches when they are congested >(per marking threshold) tend to drop packets that dont have the ECT >code point set, especially for IP traffic (meaning it may allow ARP >etc). It may very well be that ledbat encounters more packet loss >compared to ECN capable transports that are "protected" as marking >can be done on them without necessarily dropping them. If we think >we can't rely on such switch behavior then we may have a problem. Surely this is not a problem? RFC3168 ECN was designed knowing we can't rely on switches having implemented ECN. The transport gets drop signals instead of ECN from such switches, and responds the same to ECN or drop. No problem. >However I'd go back to the fact that ledbat isn't a protocol and >simply an algorithm on how to achieve lower than best effort. So my >vote is to strongly keep any recommendations in text rather than >changing the algorithm in any way. Sorry, don't understand this last sentence. bob >Thanks > > > >-----Original Message----- >From: ledbat-bounces@ietf.org [mailto:ledbat-bounces@ietf.org] On >Behalf Of Janardhan Iyengar >Sent: Friday, July 01, 2011 8:11 PM >To: Lachlan Andrew >Cc: ledbat@ietf.org >Subject: Re: [ledbat] ECN/AQM > >Hi Lachlan, > >I understand now what your proposal is. More inline. > > > I was still thinking of LEDBAT as less than best effort. If it > > (permanently) reverts to standard TCP on loss, then it is not longer > > less than best effort, since LEDBAT flows will typically be long and > > experience at least one loss before most of the transfer is complete. > >No, LEDBAT does not revert to TCP per se, it only reduces its rate >by 1/2 on loss. That is, a "temporary revert". > > > However, if it only *temporarily* reverts to standard TCP, then step 1 > > of the argument is misleading. ECN and loss can differ in how long > > they cause the LEDBAT flow to remain aggressive. If ECN causes it to > > remain aggressive longer than loss does, then there is an incentive to > > enable ECN (if throughput gives an incentive). If higher throughput > > is not an incentive (that's why we're not using TCP), then smoothness > > may be an incentive; ECN could cause a more mild immediate backoff but > > revert more quickly to non-TCP behaviour. > >So, this is interesting, and it certainly warrants considering ideas >that may not be too complex. One that comes to mind immediately >relates to a point I made earlier: currently, LEDBAT will end up >getting a cumulative reduction from increasing delay and ECN/loss >when both are observed from the same congestion event. We could >consider leaving it as such with loss---that is our pathological >case after all---but we could be a bit more careful with ECN. > >Since LEDBAT's cwnd decreases with increasing queueing delay, a >LEDBAT sender could track the highest cwnd within the past RTT (high_cwnd). >On loss: the sender simply reduces its cwnd to curr_cwnd/2. >On ECN: the sender reduces its window to min(curr_cwnd, high_cwnd/2). > >This makes it so that if there is no delay increase observed (as Bob >suggests, in the core), the new cwnd should be roughly equivalent >for both loss and ECN. If there is a delay increase, however, >LEDBAT behaves conservatively under loss and a bit more >experimentally with ECN. > >This seems safe enough, does not seem too complex, and certainly >provides the incentive we're looking for. What do others think? Is >this an avenue worth pursuing? > >- jana > >-- >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 > >_______________________________________________ >ledbat mailing list >ledbat@ietf.org >https://www.ietf.org/mailman/listinfo/ledbat ________________________________________________________________ Bob Briscoe, BT Innovate & Design From bob.briscoe@bt.com Sun Jul 3 16:24:11 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 C098321F85EB for ; Sun, 3 Jul 2011 16:24:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.252 X-Spam-Level: X-Spam-Status: No, score=-3.252 tagged_above=-999 required=5 tests=[AWL=0.120, 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 qb6i7-Umtfah for ; Sun, 3 Jul 2011 16:24:11 -0700 (PDT) Received: from smtp4.smtp.bt.com (smtp4.smtp.bt.com [217.32.164.151]) by ietfa.amsl.com (Postfix) with ESMTP id BB12521F85EA for ; Sun, 3 Jul 2011 16:24:10 -0700 (PDT) Received: from i2kc08-ukbr.domain1.systemhost.net ([193.113.197.71]) by smtp4.smtp.bt.com with Microsoft SMTPSVC(6.0.3790.4675); Mon, 4 Jul 2011 00:24:10 +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); Mon, 4 Jul 2011 00:24:09 +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 1309735448993; Mon, 4 Jul 2011 00:24:08 +0100 Received: from MUT.jungle.bt.co.uk ([10.73.128.25]) by bagheera.jungle.bt.co.uk (8.13.5/8.12.8) with ESMTP id p63NO4a2004609; Mon, 4 Jul 2011 00:24:05 +0100 Message-Id: <201107032324.p63NO4a2004609@bagheera.jungle.bt.co.uk> X-Mailer: QUALCOMM Windows Eudora Version 7.1.0.9 Date: Mon, 04 Jul 2011 00:24:06 +0100 To: From: Bob Briscoe In-Reply-To: <4E0E8C32.1050601@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> <201107011130.p61BUZ79020490@bagheera.jungle.bt.co.uk> <4E0E8C32.1050601@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: 03 Jul 2011 23:24:09.0606 (UTC) FILETIME=[4F7AAA60:01CC39D8] 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: Sun, 03 Jul 2011 23:24:11 -0000 Janar, There's a wider point against this. I doubt developers of transports and apps will jump to use ECN more because the _IETF_ allows them more leeway. They will (rightly) only care about what leeway networks allow them. The IETF isn't in the equation at run-time. The IETF is however seen as a source of advice on what is OK/safe/stable. If the IETF says it's OK/stable/safe for LEDBAT to respond less to ECN, all that would say to an implementer is that it will also be OK/stable/safe for LEDBAT (or any transport for that matter) to respond less to losses as well. Reason: losses and ECN marks are meant to be identical signs of the condition of a queue. So if the queue can cope with me responding less to ECN, it would have been able to cope with me turning off ECN and responding less to the equivalent loss. Bob At 04:10 02/07/2011, Janardhan Iyengar wrote: >Hi Lachlan, > >I understand now what your proposal is. More inline. > >>I was still thinking of LEDBAT as less than best effort. If it >>(permanently) reverts to standard TCP on loss, then it is not longer >>less than best effort, since LEDBAT flows will typically be long and >>experience at least one loss before most of the transfer is complete. > >No, LEDBAT does not revert to TCP per se, it only reduces its rate >by 1/2 on loss. That is, a "temporary revert". > >>However, if it only *temporarily* reverts to standard TCP, then step 1 >>of the argument is misleading. ECN and loss can differ in how long >>they cause the LEDBAT flow to remain aggressive. If ECN causes it to >>remain aggressive longer than loss does, then there is an incentive to >>enable ECN (if throughput gives an incentive). If higher throughput >>is not an incentive (that's why we're not using TCP), then smoothness >>may be an incentive; ECN could cause a more mild immediate backoff but >>revert more quickly to non-TCP behaviour. > >So, this is interesting, and it certainly warrants considering ideas >that may not be too complex. One that comes to mind immediately >relates to a point I made earlier: currently, LEDBAT will end up >getting a cumulative reduction from increasing delay and ECN/loss >when both are observed from the same congestion event. We could >consider leaving it as such with loss---that is our pathological >case after all---but we could be a bit more careful with ECN. > >Since LEDBAT's cwnd decreases with increasing queueing delay, a >LEDBAT sender could track the highest cwnd within the past RTT (high_cwnd). >On loss: the sender simply reduces its cwnd to curr_cwnd/2. >On ECN: the sender reduces its window to min(curr_cwnd, high_cwnd/2). > >This makes it so that if there is no delay increase observed (as Bob >suggests, in the core), the new cwnd should be roughly equivalent >for both loss and ECN. If there is a delay increase, however, >LEDBAT behaves conservatively under loss and a bit more >experimentally with ECN. > >This seems safe enough, does not seem too complex, and certainly >provides the incentive we're looking for. What do others think? Is >this an avenue worth pursuing? > >- jana > >-- >Janardhan Iyengar >Assistant Professor, Computer Science >Franklin & Marshall College >http://www.fandm.edu/jiyengar ________________________________________________________________ Bob Briscoe, BT Innovate & Design From bob.briscoe@bt.com Sun Jul 3 16:39: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 84DFB1F0C3C for ; Sun, 3 Jul 2011 16:39:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.265 X-Spam-Level: X-Spam-Status: No, score=-3.265 tagged_above=-999 required=5 tests=[AWL=0.107, 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 WiDkGy33BXHE for ; Sun, 3 Jul 2011 16:39:21 -0700 (PDT) Received: from smtp4.smtp.bt.com (smtp4.smtp.bt.com [217.32.164.151]) by ietfa.amsl.com (Postfix) with ESMTP id D4CF61F0C39 for ; Sun, 3 Jul 2011 16:39:20 -0700 (PDT) Received: from i2kc08-ukbr.domain1.systemhost.net ([193.113.197.71]) by smtp4.smtp.bt.com with Microsoft SMTPSVC(6.0.3790.4675); Mon, 4 Jul 2011 00:39:19 +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); Mon, 4 Jul 2011 00:39:19 +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 1309736358169; Mon, 4 Jul 2011 00:39:18 +0100 Received: from MUT.jungle.bt.co.uk ([10.73.128.25]) by bagheera.jungle.bt.co.uk (8.13.5/8.12.8) with ESMTP id p63NdGel004709; Mon, 4 Jul 2011 00:39:16 +0100 Message-Id: <201107032339.p63NdGel004709@bagheera.jungle.bt.co.uk> X-Mailer: QUALCOMM Windows Eudora Version 7.1.0.9 Date: Mon, 04 Jul 2011 00:39:16 +0100 To: From: Bob Briscoe In-Reply-To: <4E0E7662.8000003@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> <201107011130.p61BUZ79020490@bagheera.jungle.bt.co.uk> <4E0E7662.8000003@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: 03 Jul 2011 23:39:19.0154 (UTC) FILETIME=[6D9CAD20:01CC39DA] 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: Sun, 03 Jul 2011 23:39:22 -0000 Jana, I can't get past the first 'if' without choking on it I'm afraid... If ECN happened at a shallower point in the queue than loss, imagine what happens when ECN-capable and non-ECN-capable flows are sharing the queue. When the queue reaches the shallower ECN threshold, an arriving ECN packet will be marked, but an arriving non-ECN packet will be enqueued without marking or loss. WIthout any loss indications yet, the non-ECN flows will be able to drive the queue up to the deeper point where losses start. Now the queue is above the ECN operating point, every time an ECN packet arrives in such a queue, it gets marked with high probability. So the ECN flows get lots of marks and back away. The non-ECN flows get few losses, so they continue to fill the space left by the ECN flows, continually trying to drive the queue to their loss-based operating point. Over time, this continues, ratchetting down all the ECN flows and ratchetting up all the non-ECN flows. ...Starving ECN flows isn't a good way to create incentives to use ECN. Bob At 02:37 02/07/2011, Janardhan Iyengar wrote: >Bob, Lachlan, > >(Lachlan, I'd like to hear what you have to say too) > >Even if the ECN happened at a shallower point in the queue than >loss, wouldn't a lesser reduction imply that the LEDBAT flow backs >off lesser than a competing ECN-capable TCP, in the absence of a delay signal? > >So, a question that I pointed out in my earlier email (and I wonder, >Lachlan, if this is what you had in mind) -- how should a LEDBAT >flow reduce its rate on ECN or loss, if it does observe a queueing >delay increase preceding that event? The current LEDBAT mechanism >would be more aggressive in its reaction to the congestion "event" >than TCP. We could simply say that LEDBAT ought to be more >conservative anyways.... that would be simplest. But can we do better? > >- jana > >On 7/1/11 7:30 AM, Bob Briscoe wrote: >>Lachlan, >> >>I'm trying to work out the mental model you have that leads to this >>conclusion. Perhaps you are thinking ECN happens at a shallower >>point in the queue than loss? >> >>I was also thinking the response to ECN could be less - until I >>thought it through a couple of days ago. I posted the logical >>progression on this list which concluded that LEDBAT has to respond >>the same to ECN and to loss. >> >>See within >> >> >>As you are proposing otherwise, if you say where you disagree with >>that logical progression we might be able to get to the bottom of this? >> >> >>Bob >> >>At 05:47 01/07/2011, Lachlan Andrew wrote: >>>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. Why should a LEDBAT flow reduce >>> > 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. 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. >>> >>>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; 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? >>> >>>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 (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 >>> >>>-- >>>Lachlan Andrew Centre for Advanced Internet Architectures (CAIA) >>>Swinburne University of Technology, Melbourne, Australia >>> >>>Ph +61 3 9214 4837 >>>_______________________________________________ >>>ledbat mailing list >>>ledbat@ietf.org >>>https://www.ietf.org/mailman/listinfo/ledbat >> >>________________________________________________________________ >>Bob Briscoe, BT Innovate & Design > >-- >Janardhan Iyengar >Assistant Professor, Computer Science >Franklin & Marshall College >http://www.fandm.edu/jiyengar ________________________________________________________________ Bob Briscoe, BT Innovate & Design From jana.iyengar@gmail.com Thu Jul 14 09:46:35 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 085D511E8081 for ; Thu, 14 Jul 2011 09:46:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.486 X-Spam-Level: X-Spam-Status: No, score=-3.486 tagged_above=-999 required=5 tests=[AWL=0.114, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] 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 o++sil8zDFTy for ; Thu, 14 Jul 2011 09:46:34 -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 8478B11E8083 for ; Thu, 14 Jul 2011 09:46:22 -0700 (PDT) Received: by vxi40 with SMTP id 40so467216vxi.31 for ; Thu, 14 Jul 2011 09:46:22 -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:subject:content-type:content-transfer-encoding; bh=lbMimnHZt1BOp5sG8CecKSLEhXhK2sD9UFRhXFD+s2w=; b=cUVWCkV7TCvkJYYU1udwbQgUTRE5utDqC6nYlrmG/1+1eEwuryueF2SwPvcPCPRcKD K2obo57prAxVT6oqeRFHsq2IXGQ97gEa7OM/leUNuDifL9cClvzTesgwyXvZ1E5gK2vU QahFuqShtneMcfUPU8tT+81k5z2rW9k0BGOHg= Received: by 10.52.174.113 with SMTP id br17mr2279648vdc.107.1310661981631; Thu, 14 Jul 2011 09:46:21 -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 t14sm88407vcv.5.2011.07.14.09.46.19 (version=TLSv1/SSLv3 cipher=OTHER); Thu, 14 Jul 2011 09:46:20 -0700 (PDT) Message-ID: <4E1F1D5A.6030704@fandm.edu> Date: Thu, 14 Jul 2011 12:46:18 -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: ledbat@ietf.org, Mirja Kuehlewind , Murari Sridharan , "Rolf Winter (Rolf.Winter@neclab.eu)" Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Subject: [ledbat] Fwd: New Version Notification for draft-ietf-ledbat-congestion-07.txt 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, 14 Jul 2011 16:46:35 -0000 Hi all, We've posted a new version of the LEDBAT document that addresses all issues brought up in WGLC but one. Besides some nits, the main changes are: 1. We changed the text in the Fairness section to more accurately reflect possible issues with LEDBAT's fairness. (Dario's comments) 2. The applicability section now has better articulation about LEDBAT's interactions with with ECN and AQM. (Bob's, Gorry's, Arjuna's comments) We haven't yet addressed the MIN_CWND issue under extreme congestion; we hope to resolve this issue at the IETF. We are planning to not discuss the question of incentivizing ECN within this document. It seems like a question that is worth considering in a broader context and needs more discussion; at this late hour (in/after WGLC), it seems like an issue that we may not be able to resolve here. It can certainly be brought to the table if/when LEDBAT goes from experimental to standards-track. - jana -------- Original Message -------- Subject: New Version Notification for draft-ietf-ledbat-congestion-07.txt Date: Mon, 11 Jul 2011 10:57:51 -0700 From: internet-drafts@ietf.org To: mirja.kuehlewind@ikr.uni-stuttgart.de CC: jiyengar@fandm.edu, mirja.kuehlewind@ikr.uni-stuttgart.de, greg@bittorrent.com, shalunov@bittorrent.com A new version of I-D, draft-ietf-ledbat-congestion-07.txt has been successfully submitted by Mirja Kuehlewind and posted to the IETF repository. Filename: draft-ietf-ledbat-congestion Revision: 07 Title: Low Extra Delay Background Transport (LEDBAT) Creation date: 2011-07-11 WG ID: ledbat Number of pages: 18 Abstract: LEDBAT is an experimental delay-based congestion control algorithm that attempts to utilize the available bandwidth on an end-to-end path while limiting the consequent increase in queueing delay on the path. LEDBAT uses changes in one-way delay measurements to limit congestion that the flow itself induces in the network. LEDBAT is designed for use by background bulk-transfer applications; it is designed to be no more aggressive than TCP congestion control and to yield in the presence of any competing flows when latency builds, thus limiting interference with the network performance of the competing flows. The IETF Secretariat From mirja.kuehlewind@ikr.uni-stuttgart.de Thu Jul 14 09:50: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 74EDB21F86C0 for ; Thu, 14 Jul 2011 09:50:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.967 X-Spam-Level: X-Spam-Status: No, score=-1.967 tagged_above=-999 required=5 tests=[AWL=-0.018, 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 zrgCiKr2PAq1 for ; Thu, 14 Jul 2011 09:50:44 -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 CF19E21F85C5 for ; Thu, 14 Jul 2011 09:50:43 -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 5AFB0633B1; Thu, 14 Jul 2011 18:50:41 +0200 (CEST) Received: from vpn-2-cl177 (vpn-2-cl177 [10.41.21.177]) by netsrv1.ikr.uni-stuttgart.de (Postfix) with ESMTP id 4AC2459A8A; Thu, 14 Jul 2011 18:50:41 +0200 (CEST) From: Mirja =?iso-8859-1?q?K=FChlewind?= To: ledbat@ietf.org Date: Thu, 14 Jul 2011 18:50:40 +0200 User-Agent: KMail/1.9.10 (enterprise35 0.20101217.1207316) MIME-Version: 1.0 Content-Type: Text/Plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-Id: <201107141850.40695.mkuehle@ikr.uni-stuttgart.de> Cc: Janardhan Iyengar Subject: [ledbat] Fwd: New Version Notification for draft-ietf-ledbat-congestion-07.txt 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, 14 Jul 2011 16:50:44 -0000 Hi everybody, we submitted a new version of the LEDBAT congestion control draft last Monday. Sorry for the late announcement. We addressed all issues of the reviews incl. the AQM/ECN and randomness/fairness discussions. The only issue which is unsolved is the value of MIN_CWND. We did not change anything about the MIN_CWND in this version. We will address this issue and lower the value in a next version. But as we need some additional mechanism to handle a value of '0', we couldn't solve this issue yet. Thanks again to all reviewers for their comments. Please have a look at the document if your comments have been addressed adequately. Thanks! Jana &Mirja ---------- Forwarded Message ---------- Subject: New Version Notification for draft-ietf-ledbat-congestion-07.txt Date: Monday 11 July 2011, 19:57:51 From: internet-drafts@ietf.org To: mirja.kuehlewind@ikr.uni-stuttgart.de CC: jiyengar@fandm.edu, mirja.kuehlewind@ikr.uni-stuttgart.de, greg@bittorrent.com, shalunov@bittorrent.com A new version of I-D, draft-ietf-ledbat-congestion-07.txt has been successfully submitted by Mirja Kuehlewind and posted to the IETF repository. Filename: draft-ietf-ledbat-congestion Revision: 07 Title: Low Extra Delay Background Transport (LEDBAT) Creation date: 2011-07-11 WG ID: ledbat Number of pages: 18 Abstract: LEDBAT is an experimental delay-based congestion control algorithm that attempts to utilize the available bandwidth on an end-to-end path while limiting the consequent increase in queueing delay on the path. LEDBAT uses changes in one-way delay measurements to limit congestion that the flow itself induces in the network. LEDBAT is designed for use by background bulk-transfer applications; it is designed to be no more aggressive than TCP congestion control and to yield in the presence of any competing flows when latency builds, thus limiting interference with the network performance of the competing flows. The IETF Secretariat ------------------------------------------------------- From Rolf.Winter@neclab.eu Wed Jul 20 01:23: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 C1F0821F8745 for ; Wed, 20 Jul 2011 01:23:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.173 X-Spam-Level: X-Spam-Status: No, score=-102.173 tagged_above=-999 required=5 tests=[AWL=0.077, 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 JfzC9z+FWCmm for ; Wed, 20 Jul 2011 01:23: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 00EC221F8593 for ; Wed, 20 Jul 2011 01:23:52 -0700 (PDT) Received: from localhost (localhost.localdomain [127.0.0.1]) by smtp0.netlab.nec.de (Postfix) with ESMTP id BF0E128000326; Wed, 20 Jul 2011 10:23:51 +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 VCtTtfnDhROT; Wed, 20 Jul 2011 10:23:51 +0200 (CEST) Received: from ENCELADUS.office.hd (ENCELADUS.office.hd [192.168.24.52]) by smtp0.netlab.nec.de (Postfix) with ESMTP id A1B6328000198; Wed, 20 Jul 2011 10:23:31 +0200 (CEST) Received: from DAPHNIS.office.hd ([169.254.2.188]) by ENCELADUS.office.hd ([192.168.24.52]) with mapi id 14.01.0270.001; Wed, 20 Jul 2011 10:23:31 +0200 From: Rolf Winter To: "janardhan.iyengar@fandm.edu" , "ledbat@ietf.org" , Mirja Kuehlewind , Murari Sridharan Thread-Topic: New Version Notification for draft-ietf-ledbat-congestion-07.txt Thread-Index: AQHMQkWWN90Zt3RWoU+Ah+/lv0LJDpT057nw Date: Wed, 20 Jul 2011 08:23:30 +0000 Message-ID: <791AD3077F94194BB2BDD13565B6295D1CFE9B50@DAPHNIS.office.hd> References: <4E1F1D5A.6030704@fandm.edu> In-Reply-To: <4E1F1D5A.6030704@fandm.edu> Accept-Language: en-US, de-DE Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.1.6.28] Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 Subject: Re: [ledbat] New Version Notification for draft-ietf-ledbat-congestion-07.txt 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, 20 Jul 2011 08:23:56 -0000 SGVsbG8sDQoNCmNvdWxkIERhcmlvLCBCb2IsIEdvcnJ5IGFuZCBBcmp1bmEgcGxlYXNlIGNoZWNr IHdoZXRoZXIgeW91ciBjb21tZW50cyBhcmUgcmVzb2x2ZWQuIFRoaXMgd291bGQgaGVscCB1cyBt YWtlIHByb2dyZXNzLg0KDQpUaGFua3MsDQoNCg0KUm9sZg0KDQoNCg0KTkVDIEV1cm9wZSBMaW1p dGVkIHwgUmVnaXN0ZXJlZCBPZmZpY2U6IE5FQyBIb3VzZSwgMSBWaWN0b3JpYSBSb2FkLCBMb25k b24gVzMgNkJMIHwgUmVnaXN0ZXJlZCBpbiBFbmdsYW5kIDI4MzIwMTQgDQoNCg0KPiAtLS0tLU9y aWdpbmFsIE1lc3NhZ2UtLS0tLQ0KPiBGcm9tOiBKYW5hcmRoYW4gSXllbmdhciBbbWFpbHRvOmph bmEuaXllbmdhckBnbWFpbC5jb21dDQo+IFNlbnQ6IERvbm5lcnN0YWcsIDE0LiBKdWxpIDIwMTEg MTg6NDYNCj4gVG86IGxlZGJhdEBpZXRmLm9yZzsgTWlyamEgS3VlaGxld2luZDsgTXVyYXJpIFNy aWRoYXJhbjsgUm9sZiBXaW50ZXINCj4gU3ViamVjdDogRndkOiBOZXcgVmVyc2lvbiBOb3RpZmlj YXRpb24gZm9yIGRyYWZ0LWlldGYtbGVkYmF0LQ0KPiBjb25nZXN0aW9uLTA3LnR4dA0KPiANCj4g SGkgYWxsLA0KPiANCj4gV2UndmUgcG9zdGVkIGEgbmV3IHZlcnNpb24gb2YgdGhlIExFREJBVCBk b2N1bWVudCB0aGF0IGFkZHJlc3NlcyBhbGwNCj4gaXNzdWVzIGJyb3VnaHQgdXAgaW4gV0dMQyBi dXQgb25lLiAgQmVzaWRlcyBzb21lIG5pdHMsIHRoZSBtYWluIGNoYW5nZXMNCj4gYXJlOg0KPiAx LiBXZSBjaGFuZ2VkIHRoZSB0ZXh0IGluIHRoZSBGYWlybmVzcyBzZWN0aW9uIHRvIG1vcmUgYWNj dXJhdGVseQ0KPiByZWZsZWN0IHBvc3NpYmxlIGlzc3VlcyB3aXRoIExFREJBVCdzIGZhaXJuZXNz LiAoRGFyaW8ncyBjb21tZW50cykNCj4gMi4gVGhlIGFwcGxpY2FiaWxpdHkgc2VjdGlvbiBub3cg aGFzIGJldHRlciBhcnRpY3VsYXRpb24gYWJvdXQgTEVEQkFUJ3MNCj4gaW50ZXJhY3Rpb25zIHdp dGggd2l0aCBFQ04gYW5kIEFRTS4gKEJvYidzLCBHb3JyeSdzLCBBcmp1bmEncyBjb21tZW50cykN Cj4gDQo+IFdlIGhhdmVuJ3QgeWV0IGFkZHJlc3NlZCB0aGUgTUlOX0NXTkQgaXNzdWUgdW5kZXIg ZXh0cmVtZSBjb25nZXN0aW9uOw0KPiB3ZSBob3BlIHRvIHJlc29sdmUgdGhpcyBpc3N1ZSBhdCB0 aGUgSUVURi4gIFdlIGFyZSBwbGFubmluZyB0byBub3QNCj4gZGlzY3VzcyB0aGUgcXVlc3Rpb24g b2YgaW5jZW50aXZpemluZyBFQ04gd2l0aGluIHRoaXMgZG9jdW1lbnQuICBJdA0KPiBzZWVtcyBs aWtlIGEgcXVlc3Rpb24gdGhhdCBpcyB3b3J0aCBjb25zaWRlcmluZyBpbiBhIGJyb2FkZXIgY29u dGV4dA0KPiBhbmQgbmVlZHMgbW9yZSBkaXNjdXNzaW9uOyAgYXQgdGhpcyBsYXRlIGhvdXIgKGlu L2FmdGVyIFdHTEMpLCBpdCBzZWVtcw0KPiBsaWtlIGFuIGlzc3VlIHRoYXQgd2UgbWF5IG5vdCBi ZSBhYmxlIHRvIHJlc29sdmUgaGVyZS4gIEl0IGNhbg0KPiBjZXJ0YWlubHkgYmUgYnJvdWdodCB0 byB0aGUgdGFibGUgaWYvd2hlbiBMRURCQVQgZ29lcyBmcm9tIGV4cGVyaW1lbnRhbA0KPiB0byBz dGFuZGFyZHMtdHJhY2suDQo+IA0KPiAtIGphbmENCj4gDQo+IC0tLS0tLS0tIE9yaWdpbmFsIE1l c3NhZ2UgLS0tLS0tLS0NCj4gU3ViamVjdDogTmV3IFZlcnNpb24gTm90aWZpY2F0aW9uIGZvciBk cmFmdC1pZXRmLWxlZGJhdC1jb25nZXN0aW9uLQ0KPiAwNy50eHQNCj4gRGF0ZTogTW9uLCAxMSBK dWwgMjAxMSAxMDo1Nzo1MSAtMDcwMA0KPiBGcm9tOiBpbnRlcm5ldC1kcmFmdHNAaWV0Zi5vcmcN Cj4gVG86IG1pcmphLmt1ZWhsZXdpbmRAaWtyLnVuaS1zdHV0dGdhcnQuZGUNCj4gQ0M6IGppeWVu Z2FyQGZhbmRtLmVkdSwgbWlyamEua3VlaGxld2luZEBpa3IudW5pLXN0dXR0Z2FydC5kZSwNCj4g CWdyZWdAYml0dG9ycmVudC5jb20sIHNoYWx1bm92QGJpdHRvcnJlbnQuY29tDQo+IA0KPiBBIG5l dyB2ZXJzaW9uIG9mIEktRCwgZHJhZnQtaWV0Zi1sZWRiYXQtY29uZ2VzdGlvbi0wNy50eHQgaGFz IGJlZW4NCj4gc3VjY2Vzc2Z1bGx5IHN1Ym1pdHRlZCBieSBNaXJqYSBLdWVobGV3aW5kIGFuZCBw b3N0ZWQgdG8gdGhlIElFVEYNCj4gcmVwb3NpdG9yeS4NCj4gDQo+IEZpbGVuYW1lOgkgZHJhZnQt aWV0Zi1sZWRiYXQtY29uZ2VzdGlvbg0KPiBSZXZpc2lvbjoJIDA3DQo+IFRpdGxlOgkJIExvdyBF eHRyYSBEZWxheSBCYWNrZ3JvdW5kIFRyYW5zcG9ydCAoTEVEQkFUKQ0KPiBDcmVhdGlvbiBkYXRl OgkgMjAxMS0wNy0xMQ0KPiBXRyBJRDoJCSBsZWRiYXQNCj4gTnVtYmVyIG9mIHBhZ2VzOiAxOA0K PiANCj4gQWJzdHJhY3Q6DQo+ICAgICBMRURCQVQgaXMgYW4gZXhwZXJpbWVudGFsIGRlbGF5LWJh c2VkIGNvbmdlc3Rpb24gY29udHJvbCBhbGdvcml0aG0NCj4gICAgIHRoYXQgYXR0ZW1wdHMgdG8g dXRpbGl6ZSB0aGUgYXZhaWxhYmxlIGJhbmR3aWR0aCBvbiBhbiBlbmQtdG8tZW5kDQo+ICAgICBw YXRoIHdoaWxlIGxpbWl0aW5nIHRoZSBjb25zZXF1ZW50IGluY3JlYXNlIGluIHF1ZXVlaW5nIGRl bGF5IG9uDQo+IHRoZQ0KPiAgICAgcGF0aC4gIExFREJBVCB1c2VzIGNoYW5nZXMgaW4gb25lLXdh eSBkZWxheSBtZWFzdXJlbWVudHMgdG8gbGltaXQNCj4gICAgIGNvbmdlc3Rpb24gdGhhdCB0aGUg ZmxvdyBpdHNlbGYgaW5kdWNlcyBpbiB0aGUgbmV0d29yay4gIExFREJBVCBpcw0KPiAgICAgZGVz aWduZWQgZm9yIHVzZSBieSBiYWNrZ3JvdW5kIGJ1bGstdHJhbnNmZXIgYXBwbGljYXRpb25zOyBp dCBpcw0KPiAgICAgZGVzaWduZWQgdG8gYmUgbm8gbW9yZSBhZ2dyZXNzaXZlIHRoYW4gVENQIGNv bmdlc3Rpb24gY29udHJvbCBhbmQNCj4gdG8NCj4gICAgIHlpZWxkIGluIHRoZSBwcmVzZW5jZSBv ZiBhbnkgY29tcGV0aW5nIGZsb3dzIHdoZW4gbGF0ZW5jeSBidWlsZHMsDQo+ICAgICB0aHVzIGxp bWl0aW5nIGludGVyZmVyZW5jZSB3aXRoIHRoZSBuZXR3b3JrIHBlcmZvcm1hbmNlIG9mIHRoZQ0K PiAgICAgY29tcGV0aW5nIGZsb3dzLg0KPiANCj4gDQo+IA0KPiANCj4gVGhlIElFVEYgU2VjcmV0 YXJpYXQNCg== From dario.rossi@enst.fr Wed Jul 20 10:47: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 A84BC21F861E for ; Wed, 20 Jul 2011 10:47:25 -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 UN7Lg732JYW5 for ; Wed, 20 Jul 2011 10:47:21 -0700 (PDT) Received: from smtp2.enst.fr (revol2.enst.fr [IPv6:2001:660:330f:2::e]) by ietfa.amsl.com (Postfix) with ESMTP id B26D221F85F5 for ; Wed, 20 Jul 2011 10:47:20 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by smtp2.enst.fr (Postfix) with ESMTP id 0D55DB8453 for ; Wed, 20 Jul 2011 19:47:19 +0200 (CEST) Received: from [IPv6:::1] (ares.enst.fr [137.194.34.9]) by smtp2.enst.fr (Postfix) with ESMTP id 9FDA5B83DA for ; Wed, 20 Jul 2011 19:47:18 +0200 (CEST) Message-ID: <4E27149D.9030901@enst.fr> Date: Wed, 20 Jul 2011 19:47:09 +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: <4E1F1D5A.6030704@fandm.edu> <791AD3077F94194BB2BDD13565B6295D1CFE9B50@DAPHNIS.office.hd> In-Reply-To: <791AD3077F94194BB2BDD13565B6295D1CFE9B50@DAPHNIS.office.hd> Content-Type: multipart/alternative; boundary="------------040907020105060100010404" Subject: Re: [ledbat] New Version Notification for draft-ietf-ledbat-congestion-07.txt 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, 20 Jul 2011 17:47:25 -0000 This is a multi-part message in MIME format. --------------040907020105060100010404 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Hello all, I have gone only through section 5.3. Fairness Among LEDBAT Flows: I can say I *almost* entirely agree with 5.3 except that in real life fairness issue remains with *backlogged* flows, while the drafts mislead the reader into believing this is not the case once again, Fig1, pag2 in [ARXIV] has been gathered on a *real testbed with libUTP code* https://github.com/bittorrent/libutp -- basically, that figure it confirms what we early saw via ns2 simulation in Fig3 pag5 in [ICCCN]. I am not saying this is *the default settings for BitTorrent* where we expect may short flows due to chunk based transmission (called otherwise in the draft but I am perfectly fine with the draft wording) to lessen latecomer effect at the same time, imo the IETF LEDBAT draft should be applicable to a larger extent, where *possibly LEDBAT is used for backlogged transfers* (eg. as simple as a couple of low priority background FTP transfers over LEDBAT): and in that settings, there is no way imo you can get rid of latecomer with aiad. however, I am not seeing any trace of this in the draft; rather, I see that 5.3 ends with: "With a small number of LEDBAT flows, system noise may sufficiently regulate the late-comer's advantage." If I would be editing the document myself, I would rather write (sorry for being a pain in the neck, but I am technically conviced of that point): "With a small number of LEDBAT flows, system noise may sufficiently regulate the late-comer's advantage provided flows are non backlogged. In case of backlogged connections, latecomer advantage may still arise [ARXIV]." imo, anybody taking the libUTP code and redoing the simple testbed experiment can convice himself latecomer truly holds: i.e., [ARIXV] is right and 5.3 is wrong (I think I cannot make the point more clear than that) however, as I am not an author of the draft, I think that adoption of the above text is a matter of the discussion of the WG: thus, if the WG thinks that nowhere on earth we are ever gonna see backlogged connections again, then no harm will be done and 5.3 can stay as it is regards, D. [ARXIV] G. Carofiglio, L. Muscariello, D. Rossi and S. Valenti, "Rethinking low extra delay background transport protocols" http://arxiv.org/abs/1010.5623 [ICCCN] D. Rossi, C. Testa, S. Valenti and L. Muscariello, *LEDBAT: the new BitTorrent congestion control protocol* . In /International Conference on Computer Communication Networks (ICCCN'10)/, Zurich, Switzerland, August 2-5 2010. On 07/20/2011 10:23 AM, Rolf Winter wrote: > Hello, > > could Dario, Bob, Gorry and Arjuna please check whether your comments are resolved. This would help us make progress. > > Thanks, > > > Rolf > > > > NEC Europe Limited | Registered Office: NEC House, 1 Victoria Road, London W3 6BL | Registered in England 2832014 > > >> -----Original Message----- >> From: Janardhan Iyengar [mailto:jana.iyengar@gmail.com] >> Sent: Donnerstag, 14. Juli 2011 18:46 >> To: ledbat@ietf.org; Mirja Kuehlewind; Murari Sridharan; Rolf Winter >> Subject: Fwd: New Version Notification for draft-ietf-ledbat- >> congestion-07.txt >> >> Hi all, >> >> We've posted a new version of the LEDBAT document that addresses all >> issues brought up in WGLC but one. Besides some nits, the main changes >> are: >> 1. We changed the text in the Fairness section to more accurately >> reflect possible issues with LEDBAT's fairness. (Dario's comments) >> 2. The applicability section now has better articulation about LEDBAT's >> interactions with with ECN and AQM. (Bob's, Gorry's, Arjuna's comments) >> >> We haven't yet addressed the MIN_CWND issue under extreme congestion; >> we hope to resolve this issue at the IETF. We are planning to not >> discuss the question of incentivizing ECN within this document. It >> seems like a question that is worth considering in a broader context >> and needs more discussion; at this late hour (in/after WGLC), it seems >> like an issue that we may not be able to resolve here. It can >> certainly be brought to the table if/when LEDBAT goes from experimental >> to standards-track. >> >> - jana >> >> -------- Original Message -------- >> Subject: New Version Notification for draft-ietf-ledbat-congestion- >> 07.txt >> Date: Mon, 11 Jul 2011 10:57:51 -0700 >> From: internet-drafts@ietf.org >> To: mirja.kuehlewind@ikr.uni-stuttgart.de >> CC: jiyengar@fandm.edu, mirja.kuehlewind@ikr.uni-stuttgart.de, >> greg@bittorrent.com, shalunov@bittorrent.com >> >> A new version of I-D, draft-ietf-ledbat-congestion-07.txt has been >> successfully submitted by Mirja Kuehlewind and posted to the IETF >> repository. >> >> Filename: draft-ietf-ledbat-congestion >> Revision: 07 >> Title: Low Extra Delay Background Transport (LEDBAT) >> Creation date: 2011-07-11 >> WG ID: ledbat >> Number of pages: 18 >> >> Abstract: >> LEDBAT is an experimental delay-based congestion control algorithm >> that attempts to utilize the available bandwidth on an end-to-end >> path while limiting the consequent increase in queueing delay on >> the >> path. LEDBAT uses changes in one-way delay measurements to limit >> congestion that the flow itself induces in the network. LEDBAT is >> designed for use by background bulk-transfer applications; it is >> designed to be no more aggressive than TCP congestion control and >> to >> yield in the presence of any competing flows when latency builds, >> thus limiting interference with the network performance of the >> competing flows. >> >> >> >> >> The IETF Secretariat > _______________________________________________ > 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 --------------040907020105060100010404 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Hello all,

I have gone only through section  5.3. Fairness Among LEDBAT Flows:  I can say I *almost* entirely agree with 5.3 except that in real life fairness issue remains with *backlogged* flows, while the drafts mislead the reader into believing this is not the case

once again,  Fig1, pag2 in [ARXIV] has been gathered on a *real testbed with libUTP code* https://github.com/bittorrent/libutp  --  basically, that figure it confirms what we early saw via ns2 simulation in Fig3 pag5 in [ICCCN].

I am not saying this is *the default settings for BitTorrent* where we expect may short flows due to chunk based transmission (called otherwise in the draft but I am perfectly fine with the draft wording) to lessen latecomer effect

at the same time, imo the IETF LEDBAT draft should be applicable to a larger extent, where *possibly LEDBAT is used for backlogged transfers* (eg. as simple as a couple of low priority background FTP transfers over LEDBAT): and in that settings, there is no way imo you can get rid of latecomer with aiad.

however,  I am not seeing any trace of this in the draft; rather, I see that 5.3 ends with:

        "With a small number of LEDBAT flows, system noise may sufficiently regulate the late-comer's advantage."

If I would be editing the document myself, I would rather write (sorry for being a pain in the neck, but I am technically conviced of that point):

        "With a small number of LEDBAT flows, system noise may sufficiently regulate the late-comer's advantage provided flows are non backlogged. In case of backlogged connections, latecomer advantage may still arise [ARXIV]."


imo, anybody taking the libUTP code and redoing the simple testbed experiment can convice himself latecomer truly holds: i.e., [ARIXV] is right and 5.3 is wrong (I think I cannot make the point more clear than that)

however, as I am not an author of the draft, I think that adoption of the above text is a matter of the discussion of the WG: thus, if the WG thinks that nowhere on earth we are ever gonna see backlogged connections again, then no harm will be done and 5.3 can stay as it is


regards,
D.



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

[ICCCN] D. Rossi, C. Testa, S. Valenti and L. Muscariello, LEDBAT: the new BitTorrent congestion control protocol . In International Conference on Computer Communication Networks (ICCCN'10), Zurich, Switzerland, August 2-5 2010.



On 07/20/2011 10:23 AM, Rolf Winter wrote: 
Hello,

could Dario, Bob, Gorry and Arjuna please check whether your comments are resolved. This would help us make progress.

Thanks,


Rolf



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



-----Original Message-----
From: Janardhan Iyengar [mailto:jana.iyengar@gmail.com]
Sent: Donnerstag, 14. Juli 2011 18:46
To: ledbat@ietf.org; Mirja Kuehlewind; Murari Sridharan; Rolf Winter
Subject: Fwd: New Version Notification for draft-ietf-ledbat-
congestion-07.txt

Hi all,

We've posted a new version of the LEDBAT document that addresses all
issues brought up in WGLC but one.  Besides some nits, the main changes
are:
1. We changed the text in the Fairness section to more accurately
reflect possible issues with LEDBAT's fairness. (Dario's comments)
2. The applicability section now has better articulation about LEDBAT's
interactions with with ECN and AQM. (Bob's, Gorry's, Arjuna's comments)

We haven't yet addressed the MIN_CWND issue under extreme congestion;
we hope to resolve this issue at the IETF.  We are planning to not
discuss the question of incentivizing ECN within this document.  It
seems like a question that is worth considering in a broader context
and needs more discussion;  at this late hour (in/after WGLC), it seems
like an issue that we may not be able to resolve here.  It can
certainly be brought to the table if/when LEDBAT goes from experimental
to standards-track.

- jana

-------- Original Message --------
Subject: New Version Notification for draft-ietf-ledbat-congestion-
07.txt
Date: Mon, 11 Jul 2011 10:57:51 -0700
From: internet-drafts@ietf.org
To: mirja.kuehlewind@ikr.uni-stuttgart.de
CC: jiyengar@fandm.edu, mirja.kuehlewind@ikr.uni-stuttgart.de,
	greg@bittorrent.com, shalunov@bittorrent.com

A new version of I-D, draft-ietf-ledbat-congestion-07.txt has been
successfully submitted by Mirja Kuehlewind and posted to the IETF
repository.

Filename:	 draft-ietf-ledbat-congestion
Revision:	 07
Title:		 Low Extra Delay Background Transport (LEDBAT)
Creation date:	 2011-07-11
WG ID:		 ledbat
Number of pages: 18

Abstract:
    LEDBAT is an experimental delay-based congestion control algorithm
    that attempts to utilize the available bandwidth on an end-to-end
    path while limiting the consequent increase in queueing delay on
the
    path.  LEDBAT uses changes in one-way delay measurements to limit
    congestion that the flow itself induces in the network.  LEDBAT is
    designed for use by background bulk-transfer applications; it is
    designed to be no more aggressive than TCP congestion control and
to
    yield in the presence of any competing flows when latency builds,
    thus limiting interference with the network performance of the
    competing flows.




The IETF Secretariat

_______________________________________________
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
--------------040907020105060100010404-- From bob.briscoe@bt.com Thu Jul 28 16:19: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 F30EA21F8B7B for ; Thu, 28 Jul 2011 16:19:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.938 X-Spam-Level: X-Spam-Status: No, score=-2.938 tagged_above=-999 required=5 tests=[AWL=-0.408, BAYES_00=-2.599, DATE_IN_PAST_06_12=1.069, RCVD_IN_DNSWL_LOW=-1] 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 KH8ueHrlL9NZ for ; Thu, 28 Jul 2011 16:19: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 530FA11E811E for ; Thu, 28 Jul 2011 16:19:45 -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); Fri, 29 Jul 2011 00:19:43 +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); Fri, 29 Jul 2011 00:19:43 +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 131189518219; Fri, 29 Jul 2011 00:19:42 +0100 Received: from MUT.jungle.bt.co.uk ([10.73.64.22]) by bagheera.jungle.bt.co.uk (8.13.5/8.12.8) with ESMTP id p6SNJd8F022546; Fri, 29 Jul 2011 00:19:40 +0100 Message-Id: <201107282319.p6SNJd8F022546@bagheera.jungle.bt.co.uk> X-Mailer: QUALCOMM Windows Eudora Version 7.1.0.9 Date: Thu, 28 Jul 2011 11:23:44 -0400 To: Janardhan Iyengar From: Bob Briscoe 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: 28 Jul 2011 23:19:43.0474 (UTC) FILETIME=[D52DE520:01CC4D7C] Cc: "ledbat@ietf.org" , tsv-area IETF list Subject: [ledbat] LEDBAT doesn't help sharing network beyond home gateway 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, 28 Jul 2011 23:19:46 -0000 Jana, You asked the basis of what I just said in TSVAREA. I said in a residential network, LEDBAT won't yield to traffic sharing any queue upstream of your own home gateway queue. LEDBAT's target delay is 150ms. A typical shared link in such a network will be 1Gb/s. 150ms of queuing into a 1Gb/s link is 12,500 packets of queue (if 1500B per pkt). The buffer will not be this big (unless there's more bloat than anyone would expect)! Therefore LEDBAT will drive the queue off the end of its tail, just like TCP does. Therefore LEDAT is not designed to yield to others in such a queue into a higher speed link. The root cause is the fixed 150ms target delay. Nonetheless, I believe this design choice makes sense for LEDBAT _today_: you only yield to others in your own home. You don't yield to others in other homes. If LEDBAT yielded to others, users would reject it. Evidence is on the Bittorrent community postings when uTP was 'imposed' on BitTorrent users - it was only accepted because it was shown that performance didn't suffer unless it was yielding to self. We could design a LEDBAT-like protocol that yields to others in any queue. But no-one would want it (yet). Incidentally, a goal of ConEx is to incentivise deployment of LEDBAT-like protocols. The suffix '-like' means that they would benefit from yielding to anyone, not just your family in your home. Bob ________________________________________________________________ Bob Briscoe, BT Innovate & Design From Rolf.Winter@neclab.eu Thu Jul 28 16:30: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 0F18C11E80C8; Thu, 28 Jul 2011 16:30:14 -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.210, BAYES_00=-2.599, 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 av11jIyuQEmc; Thu, 28 Jul 2011 16:30:13 -0700 (PDT) Received: from mailer1.neclab.eu (mailer1.neclab.eu [195.37.70.40]) by ietfa.amsl.com (Postfix) with ESMTP id C746211E80A2; Thu, 28 Jul 2011 16:30:12 -0700 (PDT) Received: from localhost (localhost.localdomain [127.0.0.1]) by mailer1.neclab.eu (Postfix) with ESMTP id 8C5C828000329; Fri, 29 Jul 2011 01:30:11 +0200 (CEST) X-Virus-Scanned: Amavisd on Debian GNU/Linux (atlas1.office.hd) Received: from mailer1.neclab.eu ([127.0.0.1]) by localhost (atlas1.office.hd [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id CqFgvU4MLIuo; Fri, 29 Jul 2011 01:30:11 +0200 (CEST) Received: from ENCELADUS.office.hd (ENCELADUS.office.hd [192.168.24.52]) by mailer1.neclab.eu (Postfix) with ESMTP id 66BF628000198; Fri, 29 Jul 2011 01:29:51 +0200 (CEST) Received: from DAPHNIS.office.hd ([169.254.2.20]) by ENCELADUS.office.hd ([192.168.24.52]) with mapi id 14.01.0270.001; Fri, 29 Jul 2011 01:29:30 +0200 From: Rolf Winter To: Bob Briscoe , Janardhan Iyengar Thread-Topic: [ledbat] LEDBAT doesn't help sharing network beyond home gateway Thread-Index: AQHMTXzjahdOl9p7WUmuqzdg87JclZUCYPrg Date: Thu, 28 Jul 2011 23:29:29 +0000 Message-ID: <791AD3077F94194BB2BDD13565B6295D1D034AF5@DAPHNIS.office.hd> References: <201107282319.p6SNJd8F022546@bagheera.jungle.bt.co.uk> In-Reply-To: <201107282319.p6SNJd8F022546@bagheera.jungle.bt.co.uk> Accept-Language: en-US, de-DE Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.7.0.197] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "ledbat@ietf.org" , tsv-area IETF list Subject: Re: [ledbat] LEDBAT doesn't help sharing network beyond home gateway 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, 28 Jul 2011 23:30:14 -0000 One clarification. The target is 100ms, can be less, but not more. The "can= be less" part is to cater for the future. The cannot be more is to make su= re you cannot be unfair unless you chose to be non-standards compliant. 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 Bob Briscoe > Sent: Donnerstag, 28. Juli 2011 17:24 > To: Janardhan Iyengar > Cc: ledbat@ietf.org; tsv-area IETF list > Subject: [ledbat] LEDBAT doesn't help sharing network beyond home > gateway >=20 > Jana, >=20 > You asked the basis of what I just said in TSVAREA. I said in a > residential network, LEDBAT won't yield to traffic sharing any queue > upstream of your own home gateway queue. >=20 > LEDBAT's target delay is 150ms. >=20 > A typical shared link in such a network will be 1Gb/s. >=20 > 150ms of queuing into a 1Gb/s link is 12,500 packets of queue (if > 1500B per pkt). >=20 > The buffer will not be this big (unless there's more bloat than > anyone would expect)! Therefore LEDBAT will drive the queue off the > end of its tail, just like TCP does. Therefore LEDAT is not designed > to yield to others in such a queue into a higher speed link. >=20 > The root cause is the fixed 150ms target delay. >=20 > Nonetheless, I believe this design choice makes sense for LEDBAT > _today_: you only yield to others in your own home. You don't yield > to others in other homes. >=20 > If LEDBAT yielded to others, users would reject it. Evidence is on > the Bittorrent community postings when uTP was 'imposed' on > BitTorrent users - it was only accepted because it was shown that > performance didn't suffer unless it was yielding to self. >=20 > We could design a LEDBAT-like protocol that yields to others in any > queue. But no-one would want it (yet). Incidentally, a goal of ConEx > is to incentivise deployment of LEDBAT-like protocols. The suffix > '-like' means that they would benefit from yielding to anyone, not > just your family in your home. >=20 >=20 > Bob >=20 >=20 >=20 > ________________________________________________________________ > Bob Briscoe, BT Innovate & Design >=20 > _______________________________________________ > ledbat mailing list > ledbat@ietf.org > https://www.ietf.org/mailman/listinfo/ledbat From muraris@microsoft.com Thu Jul 28 16:59:28 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 EE05711E80C8; Thu, 28 Jul 2011 16:59:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -110.343 X-Spam-Level: X-Spam-Status: No, score=-110.343 tagged_above=-999 required=5 tests=[AWL=0.256, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8, 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 tv2vXNfW3+S4; Thu, 28 Jul 2011 16:59:28 -0700 (PDT) Received: from smtp.microsoft.com (mailc.microsoft.com [131.107.115.214]) by ietfa.amsl.com (Postfix) with ESMTP id 7234621F8A23; Thu, 28 Jul 2011 16:59:28 -0700 (PDT) Received: from TK5EX14HUBC101.redmond.corp.microsoft.com (157.54.7.153) by TK5-EXGWY-E803.partners.extranet.microsoft.com (10.251.56.169) with Microsoft SMTP Server (TLS) id 8.2.176.0; Thu, 28 Jul 2011 16:59:28 -0700 Received: from TK5EX14MBXC298.redmond.corp.microsoft.com ([169.254.1.177]) by TK5EX14HUBC101.redmond.corp.microsoft.com ([157.54.7.153]) with mapi id 14.01.0323.002; Thu, 28 Jul 2011 16:59:27 -0700 From: Murari Sridharan To: Bob Briscoe , Janardhan Iyengar Thread-Topic: LEDBAT doesn't help sharing network beyond home gateway Thread-Index: AQHMTXzgQ/cdPh1c+kS+bY60FnzEqpUCaZYQ Date: Thu, 28 Jul 2011 23:59:26 +0000 Message-ID: References: <201107282319.p6SNJd8F022546@bagheera.jungle.bt.co.uk> In-Reply-To: <201107282319.p6SNJd8F022546@bagheera.jungle.bt.co.uk> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [157.54.51.76] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "ledbat@ietf.org" , tsv-area IETF list Subject: Re: [ledbat] LEDBAT doesn't help sharing network beyond home gateway 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, 28 Jul 2011 23:59:29 -0000 Bob, agree & great point.=20 -----Original Message----- From: tsv-area-bounces@ietf.org [mailto:tsv-area-bounces@ietf.org] On Behal= f Of Bob Briscoe Sent: Thursday, July 28, 2011 8:24 AM To: Janardhan Iyengar Cc: ledbat@ietf.org; tsv-area IETF list Subject: LEDBAT doesn't help sharing network beyond home gateway Jana, You asked the basis of what I just said in TSVAREA. I said in a residential= network, LEDBAT won't yield to traffic sharing any queue upstream of your = own home gateway queue. LEDBAT's target delay is 150ms. A typical shared link in such a network will be 1Gb/s. 150ms of queuing into a 1Gb/s link is 12,500 packets of queue (if 1500B per= pkt). The buffer will not be this big (unless there's more bloat than anyone woul= d expect)! Therefore LEDBAT will drive the queue off the end of its tail, j= ust like TCP does. Therefore LEDAT is not designed to yield to others in su= ch a queue into a higher speed link. The root cause is the fixed 150ms target delay. Nonetheless, I believe this design choice makes sense for LEDBAT _today_: you only yield to others in your own home. You don't yield to othe= rs in other homes. If LEDBAT yielded to others, users would reject it. Evidence is on the Bitt= orrent community postings when uTP was 'imposed' on BitTorrent users - it w= as only accepted because it was shown that performance didn't suffer unless= it was yielding to self. We could design a LEDBAT-like protocol that yields to others in any queue. = But no-one would want it (yet). Incidentally, a goal of ConEx is to incenti= vise deployment of LEDBAT-like protocols. The suffix '-like' means that the= y would benefit from yielding to anyone, not just your family in your home. Bob ________________________________________________________________ Bob Briscoe, BT Innovate & Design=20 From decoy@iki.fi Thu Jul 28 18:20:08 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 CE52011E810E; Thu, 28 Jul 2011 18:20:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.6 X-Spam-Level: X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, NO_RELAYS=-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 oC8nLsnfIFxT; Thu, 28 Jul 2011 18:20:08 -0700 (PDT) Received: from mail.kapsi.fi (mx1.kapsi.fi [IPv6:2001:1bc8:1004::1:25]) by ietfa.amsl.com (Postfix) with ESMTP id B8C6911E8092; Thu, 28 Jul 2011 18:20:07 -0700 (PDT) Received: from lakka.kapsi.fi ([2001:1bc8:1004::1] ident=Debian-exim) by mail.kapsi.fi with esmtps (TLS1.0:RSA_AES_256_CBC_SHA1:32) (Exim 4.69) (envelope-from ) id 1Qmbk6-0001mp-9Q; Fri, 29 Jul 2011 04:19:58 +0300 Received: from decoy (helo=localhost) by lakka.kapsi.fi with local-esmtp (Exim 4.72) (envelope-from ) id 1Qmbk6-0001Ii-5s; Fri, 29 Jul 2011 04:19:58 +0300 Date: Fri, 29 Jul 2011 04:19:57 +0300 (EEST) From: Sampo Syreeni Sender: decoy@kapsi.fi To: Bob Briscoe In-Reply-To: <201107282319.p6SNJd8F022546@bagheera.jungle.bt.co.uk> Message-ID: References: <201107282319.p6SNJd8F022546@bagheera.jungle.bt.co.uk> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed X-SA-Exim-Connect-IP: 2001:1bc8:1004::1 X-SA-Exim-Mail-From: decoy@iki.fi X-SA-Exim-Scanned: No (on mail.kapsi.fi); SAEximRunCond expanded to false Cc: Janardhan Iyengar , "ledbat@ietf.org" , tsv-area IETF list Subject: Re: [ledbat] LEDBAT doesn't help sharing network beyond home gateway 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, 29 Jul 2011 01:20:08 -0000 On 2011-07-28, Bob Briscoe wrote: > I said in a residential network, LEDBAT won't yield to traffic sharing > any queue upstream of your own home gateway queue. > > LEDBAT's target delay is 150ms. Target delay, but also a one designed to mimic the minimum delay over the whole path? No? A users's upstream cable modem being the most typical and biggest part of that, but still, isn't the protocol about the whole? Shouldn't it then in theory be that LEDBAT quenches towards the minimum total delay, regardless of where the bottleneck might be? Any higher up, faster, less congested buffers ought to be totally neglected in the process because the lower, more filled up dominate the e2e delay calculation? If not, then the quenching ought to happen because of the more congested link/filled up buffer, that is *now* causing the extra delay beoynd the minimum sensed. > The root cause is the fixed 150ms target delay. So what I (we?) am missing is that with very fast networks the protocol should be able to asymptotically go to zero latency, while staying nice and crowd-stable? Are there other, statistical considerations beyond this? > If LEDBAT yielded to others, users would reject it. They absolutely would not. In fact, they don't: it's in current use and is rapidly being adopted by the numbers, as uTP, within uTorrent (and others). > We could design a LEDBAT-like protocol that yields to others in any > queue. But no-one would want it (yet). Incidentally, a goal of ConEx > is to incentivise deployment of LEDBAT-like protocols. The suffix > '-like' means that they would benefit from yielding to anyone, not > just your family in your home. Yes. So I at least am missing something. I'm sorry to ask for looking a bit stupid, but... What *am* I missing, really? -- Sampo Syreeni, aka decoy - decoy@iki.fi, http://decoy.iki.fi/front +358-50-5756111, 025E D175 ABE5 027C 9494 EEB0 E090 8BA9 0509 85C2 From arvid@cs.umu.se Thu Jul 28 19:35:47 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 516B521F8666; Thu, 28 Jul 2011 19:35:47 -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_SE=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 nQq1aT1NUWWE; Thu, 28 Jul 2011 19:35:46 -0700 (PDT) Received: from mail.acc.umu.se (mail.acc.umu.se [IPv6:2001:6b0:e:2018::156]) by ietfa.amsl.com (Postfix) with ESMTP id E427521F85DE; Thu, 28 Jul 2011 19:35:44 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by amavisd-new (Postfix) with ESMTP id 433F189F; Fri, 29 Jul 2011 04:35:42 +0200 (MEST) X-Virus-Scanned: amavisd-new at acc.umu.se Received: from mao.acc.umu.se (mao.acc.umu.se [130.239.18.154]) by mail.acc.umu.se (Postfix) with ESMTP id 3C29D89E; Fri, 29 Jul 2011 04:35:41 +0200 (MEST) Received: by mao.acc.umu.se (Postfix, from userid 3027) id 38E781009B; Fri, 29 Jul 2011 04:34:40 +0200 (CEST) Received: from 38.99.42.130 ([38.99.42.130]) by puss.acc.umu.se (IMP) with HTTP for ; Fri, 29 Jul 2011 04:34:40 +0200 Message-ID: <1311906880.4e321c4026475@puss.acc.umu.se> Date: Fri, 29 Jul 2011 04:34:40 +0200 From: arvid@cs.umu.se To: Sampo Syreeni References: <201107282319.p6SNJd8F022546@bagheera.jungle.bt.co.uk> In-Reply-To: MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit User-Agent: Internet Messaging Program (IMP) 3.2.2 Cc: Janardhan Iyengar , "ledbat@ietf.org" , tsv-area IETF list Subject: Re: [ledbat] LEDBAT doesn't help sharing network beyond home gateway 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, 29 Jul 2011 02:35:47 -0000 Quoting Sampo Syreeni : > On 2011-07-28, Bob Briscoe wrote: > > > I said in a residential network, LEDBAT won't yield to traffic sharing > > any queue upstream of your own home gateway queue. > > > > LEDBAT's target delay is 150ms. I thought the LEDBAT target delay was 25 ms, but I might have missed some update. In BitTorrent's uTP it's 100 ms right now. > Target delay, but also a one designed to mimic the minimum delay over > the whole path? No? A users's upstream cable modem being the most > typical and biggest part of that, but still, isn't the protocol about > the whole? It's important to understand what "target delay" means. In LEDBAT, it refers to the delay on top of the lowest ever seen one-way latency from the source to the destination. It does not include any fixed latency (such as the fixed latency you have in routers for handling packets in each hop nor the speed of light), the variable in the one-way latency is essentially entirely the time a packet spends sitting in buffers. LEDBAT does not care about which buffer or where the buffer is (whether it's your router, your modem, your ISP's router or your destination's ISPs router etc.). > Shouldn't it then in theory be that LEDBAT quenches towards the minimum > total delay, regardless of where the bottleneck might be? Any higher up, > faster, less congested buffers ought to be totally neglected in the > process because the lower, more filled up dominate the e2e delay > calculation? That sounds like a correct statement. > If not, then the quenching ought to happen because of the more congested > link/filled up buffer, that is *now* causing the extra delay beoynd the > minimum sensed. > > > The root cause is the fixed 150ms target delay. > > So what I (we?) am missing is that with very fast networks the protocol > should be able to asymptotically go to zero latency, while staying nice > and crowd-stable? Are there other, statistical considerations beyond > this? If no buffer along the path can fit the target-delay amount of bytes, LEDBAT would essentially behave like TCP, and (essentially) be just as fair as TCP is. > > If LEDBAT yielded to others, users would reject it. > > They absolutely would not. In fact, they don't: it's in current use and > is rapidly being adopted by the numbers, as uTP, within uTorrent (and > others). Right. It just happens to be people's modems that are the bottlenecks (unsurprisingly). -- Arvid Norberg From richard_woundy@cable.comcast.com Thu Jul 28 20:57:11 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 DAD2F21F8639; Thu, 28 Jul 2011 20:57:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.399 X-Spam-Level: X-Spam-Status: No, score=-106.399 tagged_above=-999 required=5 tests=[AWL=2.064, BAYES_00=-2.599, HELO_EQ_MODEMCABLE=0.768, HOST_EQ_MODEMCABLE=1.368, RCVD_IN_DNSWL_HI=-8, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 8yhS1-BSjeS9; Thu, 28 Jul 2011 20:57:11 -0700 (PDT) Received: from pacdcimo01.cable.comcast.com (PacdcIMO01.cable.comcast.com [24.40.8.145]) by ietfa.amsl.com (Postfix) with ESMTP id 844F021F85B9; Thu, 28 Jul 2011 20:57:09 -0700 (PDT) Received: from ([24.40.55.40]) by pacdcimo01.cable.comcast.com with ESMTP with TLS id 5503620.135534643; Thu, 28 Jul 2011 23:57:03 -0400 Received: from PACDCEXMB05.cable.comcast.com ([fe80::a5b0:e5c4:df1b:2367]) by pacdcexhub03.cable.comcast.com ([fe80::d1dd:b302:b617:3755%11]) with mapi id 14.01.0289.001; Thu, 28 Jul 2011 23:57:03 -0400 From: "Woundy, Richard" To: "arvid@cs.umu.se" , Sampo Syreeni Thread-Topic: [ledbat] LEDBAT doesn't help sharing network beyond home gateway Thread-Index: AQHMTXzcinrsN+47UUa+u48s5QEF65UCw1WAgAAU4QD//9N3YA== Date: Fri, 29 Jul 2011 03:57:02 +0000 Message-ID: <1CA25301D2219F40B3AA37201F0EACD1135DF0C7@PACDCEXMB05.cable.comcast.com> References: <201107282319.p6SNJd8F022546@bagheera.jungle.bt.co.uk> <1311906880.4e321c4026475@puss.acc.umu.se> In-Reply-To: <1311906880.4e321c4026475@puss.acc.umu.se> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [76.96.111.6] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: Janardhan Iyengar , "ledbat@ietf.org" , tsv-area IETF list Subject: Re: [ledbat] LEDBAT doesn't help sharing network beyond home gateway 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, 29 Jul 2011 03:57:12 -0000 > I thought the LEDBAT target delay was 25 ms, but I might have missed some= update. In BitTorrent's uTP it's 100 ms right now. The LEDBAT target delay was increased from 25 msec to 100 msec in version -= 02, to match the uTP implementation. -----Original Message----- From: ledbat-bounces@ietf.org [mailto:ledbat-bounces@ietf.org] On Behalf Of= arvid@cs.umu.se Sent: Thursday, July 28, 2011 10:35 PM To: Sampo Syreeni Cc: Janardhan Iyengar; ledbat@ietf.org; tsv-area IETF list Subject: Re: [ledbat] LEDBAT doesn't help sharing network beyond home gatew= ay Quoting Sampo Syreeni : > On 2011-07-28, Bob Briscoe wrote: >=20 > > I said in a residential network, LEDBAT won't yield to traffic sharing= =20 > > any queue upstream of your own home gateway queue. > > > > LEDBAT's target delay is 150ms. I thought the LEDBAT target delay was 25 ms, but I might have missed some update. In BitTorrent's uTP it's 100 ms right now. > Target delay, but also a one designed to mimic the minimum delay over=20 > the whole path? No? A users's upstream cable modem being the most=20 > typical and biggest part of that, but still, isn't the protocol about=20 > the whole? It's important to understand what "target delay" means. In LEDBAT, it refer= s to the delay on top of the lowest ever seen one-way latency from the source to= the destination. It does not include any fixed latency (such as the fixed laten= cy you have in routers for handling packets in each hop nor the speed of light= ), the variable in the one-way latency is essentially entirely the time a pack= et spends sitting in buffers. LEDBAT does not care about which buffer or where= the buffer is (whether it's your router, your modem, your ISP's router or your destination's ISPs router etc.). > Shouldn't it then in theory be that LEDBAT quenches towards the minimum=20 > total delay, regardless of where the bottleneck might be? Any higher up,= =20 > faster, less congested buffers ought to be totally neglected in the=20 > process because the lower, more filled up dominate the e2e delay=20 > calculation? That sounds like a correct statement. > If not, then the quenching ought to happen because of the more congested= =20 > link/filled up buffer, that is *now* causing the extra delay beoynd the=20 > minimum sensed. >=20 > > The root cause is the fixed 150ms target delay. >=20 > So what I (we?) am missing is that with very fast networks the protocol=20 > should be able to asymptotically go to zero latency, while staying nice=20 > and crowd-stable? Are there other, statistical considerations beyond=20 > this? If no buffer along the path can fit the target-delay amount of bytes, LEDBA= T would essentially behave like TCP, and (essentially) be just as fair as TCP= is. > > If LEDBAT yielded to others, users would reject it. >=20 > They absolutely would not. In fact, they don't: it's in current use and=20 > is rapidly being adopted by the numbers, as uTP, within uTorrent (and=20 > others). Right. It just happens to be people's modems that are the bottlenecks (unsurprisingly). --=20 Arvid Norberg _______________________________________________ ledbat mailing list ledbat@ietf.org https://www.ietf.org/mailman/listinfo/ledbat