On Mon, 2012-08-06 at 18:22 +0200, Richard Scheffenegger wrote: > Well, as long as the window is large enough, the delayed ACKs shouldn't > matter, even if the ECE is delayed for 1 segment; the argument about delayed > ACKs when cwnd is 1 is also true for non-ECN flows; they would run better > when every segment is acked individually; but can the receiver tell, if the > sender is running at cwnd=1? >
It should just be safe instead than lazy. Frankly what's the deal to send an ACK right now instead of in 40ms ? > Perhaps, if it tracks the RTT of the flow (which has to work without TS, as > they are undefined for pure ACKs), and the number of segments seen during > one RTT... Linux does have an heuristic to _not_ use delayed acks for the first packets received (about 15 MSS), _because_ it assumes sender has a small cwnd. When receiving out of order packets, this logic is restarted, because we want to send SACKS as soon as possible, not after a delayed ack. Every time we suspect sender has a small cwnd, we enter the quickack mode. So when receiving CE segments, we should do the same. Thats a flaw in current linux code to do nothing and expect more packets to come. It just works because RTO triggers. A lot of bugs are hidden because of various timers that take some emergency actions. tcp_enter_quickack_mode() has all the needed tweaks. diff --git a/net/ipv4/tcp_input.c b/net/ipv4/tcp_input.c index 2fd2bc9..2e55337 100644 --- a/net/ipv4/tcp_input.c +++ b/net/ipv4/tcp_input.c @@ -237,6 +237,9 @@ static inline void TCP_ECN_check_ce(struct tcp_sock *tp, const struct sk_buff *s tcp_enter_quickack_mode((struct sock *)tp); break; case INET_ECN_CE: + /* Better not delay acks, sender can have a very low cwnd */ + tcp_enter_quickack_mode((struct sock *)tp); + tp->ecn_flags |= TCP_ECN_DEMAND_CWR; /* fallinto */ default: _______________________________________________ Codel mailing list Codel@lists.bufferbloat.net https://lists.bufferbloat.net/listinfo/codel