From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-iw0-f171.google.com (mail-iw0-f171.google.com [209.85.214.171]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority" (verified OK)) by huchra.bufferbloat.net (Postfix) with ESMTPS id D7F5820016F for ; Fri, 24 Jun 2011 01:42:44 -0700 (PDT) Received: by iwn34 with SMTP id 34so3490681iwn.16 for ; Fri, 24 Jun 2011 02:10:39 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type :content-transfer-encoding; bh=PqdYhqcDqJbp5T2KhmV00oP5C4xZODRVODMmPCO5amA=; b=RDAc+lltlAFEnnh3oVGgiP0vhTNlagwyoNS6xPOk/usTLPDq/ymy2ZuFeVB3PSm5IE jmP/xghStqs6gZTtRHaSsKp+AvCIuLeJHWcmgQ37XCGzc1UZcT9e6le6iJFbSjqaCDsF l9ZY+8tkJjZYCeQ2YdHWQBgxFqtcZ+7tjzgGE= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; b=GkfcQBuvTz7Kt7KAcTyGf2Ge+OFJZE2aIo6rbp6xThPo3XZ5UAOX9U4VuHvB07aCQa MWjK5joB3nQwzT2vcdffxzqPaOOvboH7pmsfgpxrvX091Y6fciHe9suEcOCB+f0rvtA8 StNevlBt8hG4znqSQLTLHHXQw5r1psy2bOWdQ= MIME-Version: 1.0 Received: by 10.42.140.74 with SMTP id j10mr3276599icu.294.1308906638931; Fri, 24 Jun 2011 02:10:38 -0700 (PDT) Received: by 10.231.32.137 with HTTP; Fri, 24 Jun 2011 02:10:38 -0700 (PDT) In-Reply-To: <1308891660.3000.7.camel@edumazet-laptop> References: <7ir56kupy8.fsf@lanthane.pps.jussieu.fr> <1308891660.3000.7.camel@edumazet-laptop> Date: Fri, 24 Jun 2011 03:10:38 -0600 Message-ID: From: Dave Taht To: Eric Dumazet Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: bloat Subject: Re: [Bloat] Some updates on hacking on AQMS X-BeenThere: bloat@lists.bufferbloat.net X-Mailman-Version: 2.1.13 Precedence: list List-Id: General list for discussing Bufferbloat List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 24 Jun 2011 08:42:45 -0000 On Thu, Jun 23, 2011 at 11:01 PM, Eric Dumazet wro= te: > Le jeudi 23 juin 2011 =E0 17:10 -0600, Dave Taht a =E9crit : >> On Thu, Jun 23, 2011 at 4:45 PM, Juliusz Chroboczek = wrote: >> >> It really seems that ECN support could be added generically for all >> >> qdiscs that currently do packet drop. Creating a generic mark_or_drop >> >> function is easy. >> > >> > As hinted in a previous message -- please don't. =A0Every qdisc must b= e >> > examined individually to check if it is suitable for ECN. >> > >> > Consider also the following. =A0If the administrator specifies a maxim= um >> > rate of 100 Mbit/s, he probably doesn't expect the outgoing traffic to >> > exceed that rate under any circumstances. =A0If you start marking inst= ead >> > of dropping, you must make sure that the resulting traffic is still >> > under 100 Mbit/s, including the marked packets. >> >> In designing this particular concept I made sure that was an option, >> in the mildly recorrected: >> >> http://www.bufferbloat.net/projects/bloat/wiki/Save_the_Ants >> >> Try harder to not shoot the ants, but make ecn marking a first class >> option throughout the qdiscs... >> >> if possible.. > > I believe it was done. > > qdisc implementations are not random, but follow extensive research > works. All of which is either invalidated, obsolete, or newly revalidated since the advent of wireless, the increase in using TCP for short transfers, and nat becoming predominant, the increase in traffic volume overall, and the introduction of both voice and video calling on the web, and the introduction of massive amounts of video traffic to the Internet, sadly most of which are unclassifyable and on port 80... ... The workloads have changed, the characteristics of traffic have changed, and experiments need to be re-run. > Before doing a change like that, you must redo all the experiments and > show the pro/cons ;) I'm kind of hoping to be building a platform where others can do that easie= r. > Once qdisc queue is _full_, its too late, you have to drop packets > anyway. And its not because at least one flow is not responsive : > It might be because one thousand flows began their life at the very same > moment :( Painfully aware of that. > > > > --=20 Dave T=E4ht SKYPE: davetaht US Tel: 1-239-829-5608 http://the-edge.blogspot.com