From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-bw0-f43.google.com (mail-bw0-f43.google.com [209.85.214.43]) (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 12E46201A3B for ; Tue, 11 Oct 2011 05:18:13 -0700 (PDT) Received: by bkas6 with SMTP id s6so13956499bka.16 for ; Tue, 11 Oct 2011 05:18:12 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=message-id:subject:from:to:cc:date:in-reply-to:references :content-type:x-mailer:content-transfer-encoding:mime-version; bh=A/Q022HMHMUMCUXwhN/S03Q+FUgbRg4tgKy/tDjPidI=; b=jCqx5QfJtqm1nrK1IB5f5Rf+iGQY8aReB6IjDw8l5vnqskO8JspQXVHQnU3fiCZ0A8 vXwx9vuwQl7QyH3OfwVPlKynPZCpfoyPCzzlIudve3xdXZ9gbyUMcUEz5lJn+WvUvW/d 4V34JXysjLZoEEv25mJJPYiEll5SdOGwq2fFQ= Received: by 10.204.7.156 with SMTP id d28mr9299539bkd.40.1318335492056; Tue, 11 Oct 2011 05:18:12 -0700 (PDT) Received: from [10.150.51.213] (gw0.net.jmsp.net. [212.23.165.14]) by mx.google.com with ESMTPS id z9sm20982697bkn.7.2011.10.11.05.18.10 (version=SSLv3 cipher=OTHER); Tue, 11 Oct 2011 05:18:10 -0700 (PDT) Message-ID: <1318335509.2538.11.camel@edumazet-HP-Compaq-6005-Pro-SFF-PC> From: Eric Dumazet To: "Steinar H. Gunderson" Date: Tue, 11 Oct 2011 14:18:29 +0200 In-Reply-To: <1318335234.2538.9.camel@edumazet-HP-Compaq-6005-Pro-SFF-PC> References: <4E941A05.2050705@gmail.com> <20111011115816.GA24956@uio.no> <1318335234.2538.9.camel@edumazet-HP-Compaq-6005-Pro-SFF-PC> Content-Type: text/plain; charset="UTF-8" X-Mailer: Evolution 3.2.0- Content-Transfer-Encoding: 8bit Mime-Version: 1.0 Cc: bloat@lists.bufferbloat.net Subject: Re: [Bloat] a flood of Bufferbloat-related papers 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: Tue, 11 Oct 2011 12:18:14 -0000 Le mardi 11 octobre 2011 à 14:13 +0200, Eric Dumazet a écrit : > Le mardi 11 octobre 2011 à 13:58 +0200, Steinar H. Gunderson a écrit : > > On Tue, Oct 11, 2011 at 12:27:17PM +0200, David Täht wrote: > > > On my list already would be "an analysis of the effects of broken sack > > > processing on linux 2.4.24-3.1", of which I *think* I've captured > > > multiple examples of in the raw traces I've been collecting for > > > months... (so if anyone is interested in the raw data, I can provide) > > > > Do you have any more information? The only thing I could find online was that > > there were SACK issues that were supposed to be fixed by 2.6.16; nothing > > about a fix in 3.1 or post-3.1. > > > > Of course, instead of discussing all linux stuff privately, it would be > good to discuss with linux network maintainers. > > Or is the goal is to provide nice papers only ? > > commit f779b2d60ab95c17f1e025778ed0df3ec2f05d75 > Author: Zheng Yan > Date: Sun Sep 18 22:37:34 2011 -0400 Another fix (scheduled for linux-3.2 available in net-next tree :) [ And some work is currently in progress to support RFC 5562 ] commit 7a269ffad72f3604b8982fa09c387670e0d2ee14 Author: Eric Dumazet Date: Thu Sep 22 20:02:19 2011 +0000 tcp: ECN blackhole should not force quickack mode While playing with a new ADSL box at home, I discovered that ECN blackhole can trigger suboptimal quickack mode on linux : We send one ACK for each incoming data frame, without any delay and eventual piggyback. This is because TCP_ECN_check_ce() considers that if no ECT is seen on a segment, this is because this segment was a retransmit. Refine this heuristic and apply it only if we seen ECT in a previous segment, to detect ECN blackhole at IP level. Signed-off-by: Eric Dumazet CC: Jamal Hadi Salim CC: Jerry Chu CC: Ilpo Järvinen CC: Jim Gettys CC: Dave Taht Acked-by: Ilpo Järvinen Signed-off-by: David S. Miller diff --git a/include/net/tcp.h b/include/net/tcp.h index f357bef..702aefc 100644 --- a/include/net/tcp.h +++ b/include/net/tcp.h @@ -356,6 +356,7 @@ static inline void tcp_dec_quickack_mode(struct sock *sk, #define TCP_ECN_OK 1 #define TCP_ECN_QUEUE_CWR 2 #define TCP_ECN_DEMAND_CWR 4 +#define TCP_ECN_SEEN 8 static __inline__ void TCP_ECN_create_request(struct request_sock *req, struct tcphdr *th) diff --git a/net/ipv4/tcp_input.c b/net/ipv4/tcp_input.c index a5d01b1..5a4408c 100644 --- a/net/ipv4/tcp_input.c +++ b/net/ipv4/tcp_input.c @@ -217,16 +217,25 @@ static inline void TCP_ECN_withdraw_cwr(struct tcp_sock *tp) tp->ecn_flags &= ~TCP_ECN_DEMAND_CWR; } -static inline void TCP_ECN_check_ce(struct tcp_sock *tp, struct sk_buff *skb) +static inline void TCP_ECN_check_ce(struct tcp_sock *tp, const struct sk_buff *skb) { - if (tp->ecn_flags & TCP_ECN_OK) { - if (INET_ECN_is_ce(TCP_SKB_CB(skb)->flags)) - tp->ecn_flags |= TCP_ECN_DEMAND_CWR; + if (!(tp->ecn_flags & TCP_ECN_OK)) + return; + + switch (TCP_SKB_CB(skb)->flags & INET_ECN_MASK) { + case INET_ECN_NOT_ECT: /* Funny extension: if ECT is not set on a segment, - * it is surely retransmit. It is not in ECN RFC, - * but Linux follows this rule. */ - else if (INET_ECN_is_not_ect((TCP_SKB_CB(skb)->flags))) + * and we already seen ECT on a previous segment, + * it is probably a retransmit. + */ + if (tp->ecn_flags & TCP_ECN_SEEN) tcp_enter_quickack_mode((struct sock *)tp); + break; + case INET_ECN_CE: + tp->ecn_flags |= TCP_ECN_DEMAND_CWR; + /* fallinto */ + default: + tp->ecn_flags |= TCP_ECN_SEEN; } }