From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-wi0-f175.google.com (mail-wi0-f175.google.com [209.85.212.175]) (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 1C9CF20012F for ; Mon, 25 Jun 2012 11:25:14 -0700 (PDT) Received: by wibhm2 with SMTP id hm2so1118389wib.10 for ; Mon, 25 Jun 2012 11:25:13 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; bh=HUvjlVCiAkpTUUiFjhI+Q5y9pKkku8JghlxF3oROgR8=; b=bI6x6vSwusAks+f2cr19t5cZT1l9XRgZ65ktF6VbCsOEpROB5JE1MlfHK3TYmgdFN/ 6wSgszBf3Og0EGrLFfWOtbmX20Q3OP3lTFEaJGTayiv0SYNnsSm5YwFkpwpS61jFqnmJ 2uudE4ksJoA4a01c8OEHzs3ZBUOMZecMPlVVjQR9EROhnYMSSdguKV4FQeAv6MV2soXl m16SynRZeT4PXX3qbphyxGIWLbJz+e6CGG5N6+ZusQgcaTNHfs2wKguGFfycPGdODuN1 VekDcInSXKUhmfb6RKaitlscUr6CNfmnb6C7gs6RBgi6gnYmBulEwQ8QJvNdZU1TjFFU aXMA== MIME-Version: 1.0 Received: by 10.216.202.22 with SMTP id c22mr6424352weo.10.1340648713127; Mon, 25 Jun 2012 11:25:13 -0700 (PDT) Received: by 10.223.103.199 with HTTP; Mon, 25 Jun 2012 11:25:13 -0700 (PDT) In-Reply-To: <5AD96B37-CDEE-44B6-83CC-449C27FCBA76@gmail.com> References: <1340600422-1806-1-git-send-email-dave.taht@bufferbloat.net> <1340600422-1806-2-git-send-email-dave.taht@bufferbloat.net> <1340601724.23933.16.camel@edumazet-glaptop> <1340637617.10893.56.camel@edumazet-glaptop> <1340639151.10893.79.camel@edumazet-glaptop> <5AD96B37-CDEE-44B6-83CC-449C27FCBA76@gmail.com> Date: Mon, 25 Jun 2012 11:25:13 -0700 Message-ID: From: Dave Taht To: Jonathan Morton Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: "codel@lists.bufferbloat.net" , =?ISO-8859-1?Q?Dave_T=E4ht?= Subject: Re: [Codel] [RFCv2 PATCH] codel: add ecn_target for when to drop rather than mark ecn packets X-BeenThere: codel@lists.bufferbloat.net X-Mailman-Version: 2.1.13 Precedence: list List-Id: CoDel AQM discussions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 25 Jun 2012 18:25:15 -0000 On Mon, Jun 25, 2012 at 10:48 AM, Jonathan Morton w= rote: > My impression is that ECN ignorant flows do exist, because of stupid rout= ers rather than malice, and that Dave considers this a problem worth tackli= ng in codel. Malice will exist. It is easy to create a set of flows that will overwhelm either codel or fq_codel, with ecn enabled. fq_codel does respond well to udp flooding, I note, far better than pfifo_f= ast. > > However I would disagree that the problem needs tackling here, at least f= or fq_codel which already segregates non-responsive flows from others. The = ignorant flows will experience higher latency if this link is a bottleneck = for them, that is all. the first version of fq_codel had a separate codel queue per flow, which would behave as you say. The lastest version uses the global drop probability, which makes more sense in the general case. I continue to prototype with qfq+codel which has the first behavior, presently. I like the idea of a more perfect fluid model, especially at the bandwidths I operate at (2-30Mbit), with the cpu horsepower available to make more better choices than fq_codel can. > Plain codel might need a more robust defence, but I have a different sugg= estion for that. Determine whether a prolonged bout of marking is being cau= sed by ECN ignorant flows, and if so disable ECN marking (just drop) until = the ignorant flows have clearly gone away. Well, an example algo for that would be helpful. SFB tried to do this. I note that codel operates independently of RTT and I am thinking hard that RTT related issues need to be explored overall. > The key to knowledge is not to rely on others to teach you it. I am an experimenter first and foremost. My inspirations are more from edison than tesla. Queue behavior is rarely intuitive, and the only way to build intuition, for me, at least, is to design an experiment and observe what happens. Kelly Johnson could "see air". Perhaps van and kathie can "see packets". Me, on the other hand... > > On 25 Jun 2012, at 18:45, Eric Dumazet wrote: > >> On Mon, 2012-06-25 at 08:30 -0700, Dave Taht wrote: >> >>> It was the way I was leaning until I observed me dropping ecn enabled >>> mosh, ssh, and babel packets , which tend to be small, so I started >>> thinking in terms of dropping ecn packets on a graduated packet size >>> scale after exceeding target. ESPECIALLY in case of overload you want >>> command and control packets to get through. >>> >> >> Don't try to add in CoDel things that should be done at another layer. >> There is no classification in CoDel : Its a FIFO. >> >> Only way is to prioritize control packets if you need to, and use >> several queues. >> >> I dont understand... Are you saying that you feel the need to drop >> packets instead of marking them in a 'good citizen world' (none of your >> flow pretends to use ECN to avoid drops) ? >> >> >> >> _______________________________________________ >> Codel mailing list >> Codel@lists.bufferbloat.net >> https://lists.bufferbloat.net/listinfo/codel --=20 Dave T=E4ht http://www.bufferbloat.net/projects/cerowrt/wiki - "3.3.8-6 is out with fq_codel!"