From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-ob0-f171.google.com (mail-ob0-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 14AF4201AEE for ; Thu, 28 Jun 2012 15:57:07 -0700 (PDT) Received: by obbef5 with SMTP id ef5so8562755obb.16 for ; Thu, 28 Jun 2012 15:57:06 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type:x-system-of-record; bh=Vu8GkEO8SWu3jTyJ+u0e51HXiSbqSsb6I5Ga5SDHMt4=; b=d/oiUGrU8GjgDbbAPdmHKJoeA4HiX2AO1T3sFYmVT8RjieKPsTJ7v/NgXDdXHOdF/d gvzHGvg4K+0RiB+LZkVeRih0hogawrg0GJAfVf81S0sMKJSyJF345C4KhPb99IWZCYUr cN622/KhrjoLVAJgsd+kQ/ImJIUc7eeTmQKNJbPJBwW7R+Mn5FMoM8ND4SGxStMYodMH JKt6gi4gLnTC3Qu1jyY+/K1b1w/RTayjZLxOYJasbuwYT4H9pYAT31MTDbYUZUy7rxaF cUem0ecgIIFiOQKcDJQVcnIrgKnzN/ngBJGNniged3gOaTK+R9V25ZMdFZjSjFVTVWDp Xs5Q== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type:x-system-of-record:x-gm-message-state; bh=Vu8GkEO8SWu3jTyJ+u0e51HXiSbqSsb6I5Ga5SDHMt4=; b=kpYTU30hmC3ct7A9YmdWmBqKjNB51dvZ58F4INj5ht0nJTluQLZTeEeRc0GBRO/iBY Rl/nr+dO2W703V5wM+N1AetnpY2I8t2Dck+wpSi5BTNUf1QHe3giCD0ApIGXG1hPDXHK zULy87ehinj+6W3cihkYNCzI1aL4H1to94UY2ZXOqH3fpQwWRk9u+fmaUZzXZ9Jt+I60 ipSoDE9OS54Ckkl3tPBao1WjWq0vWcFqrcTwZv+5KjMTubCCliqzZ3F1gkrBbQROMqKd 1mZLdWApqeETVPMRZOf0j3Isw8B+RJma+dMlrgvxyyakbR/P5shNsb+hl9eIHn9M+Oev IPVg== Received: by 10.182.164.10 with SMTP id ym10mr4636148obb.75.1340924226757; Thu, 28 Jun 2012 15:57:06 -0700 (PDT) Received: by 10.182.164.10 with SMTP id ym10mr4636134obb.75.1340924226601; Thu, 28 Jun 2012 15:57:06 -0700 (PDT) MIME-Version: 1.0 Received: by 10.60.140.164 with HTTP; Thu, 28 Jun 2012 15:56:46 -0700 (PDT) In-Reply-To: <1340907151.13187.169.camel@edumazet-glaptop> References: <1340903237.13187.151.camel@edumazet-glaptop> <1340907151.13187.169.camel@edumazet-glaptop> From: Yuchung Cheng Date: Thu, 28 Jun 2012 15:56:46 -0700 Message-ID: To: Eric Dumazet Content-Type: text/plain; charset=ISO-8859-1 X-System-Of-Record: true X-Gm-Message-State: ALoCoQndtS5wxeouEey8BemI7QqMPpCYlsi6LkyaMJ143dSqJfc5IzKkgyOEYXy+asVHizIlN9f7aqclUvxBq/VPgkmviWZtAwsAEFB90B5dBAJGms1rwXTx6TpV+AsNE8/nwhB+fwDreAamIcPEU5hK+0zGwhc6OTz5zCR7usj6R1HlNLniWQ7fiRcr4QHSiJnqgrjqREWe X-Mailman-Approved-At: Thu, 28 Jun 2012 16:18:52 -0700 Cc: Nandita Dukkipati , netdev , codel@lists.bufferbloat.net, Matt Mathis , Neal Cardwell , David Miller Subject: Re: [Codel] [PATCH net-next] fq_codel: report congestion notification at enqueue time 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: Thu, 28 Jun 2012 22:57:08 -0000 On Thu, Jun 28, 2012 at 11:12 AM, Eric Dumazet wrote: > On Thu, 2012-06-28 at 10:51 -0700, Dave Taht wrote: > >> clever idea. A problem is there are other forms of network traffic on >> a link, and this is punishing a single tcp Dave: it won't just punish a single TCP, all protocols that react to XMIT_CN will share similar fate. >> stream that may not be the source of the problem in the first place, >> and basically putting it into double jeopardy. >> > > Why ? In fact this patch helps the tcp session being signaled (as it > will be anyway) at enqueue time, instead of having to react to packet > losses indications given (after RTT) by receiver. > > Avoiding losses help receiver to consume data without having to buffer > it into Out Of Order queue. > > So its not jeopardy, but early congestion notification without RTT > delay. > > NET_XMIT_CN is a soft signal, far more disruptive than a DROP. I don't read here: you mean far "less" disruptive in terms of performance? > >> I am curious as to how often an enqueue is actually dropping in the >> codel/fq_codel case, the hope was that there would be plenty of >> headroom under far more circumstances on this qdisc. >> > > "tc -s qdisc show dev eth0" can show you all the counts. > > We never drop a packet at enqueue time, unless you hit the emergency > limit (10240 packets for fq_codel). When you reach this limit, you are > under trouble. Another nice feature is to resume TCP xmit operation at when the skb hits the wire. My hutch is that Eric is working on this too. > > >