Messages in this thread |  | | From | kuznet@ms2 ... | Subject | Re: TCP acking too fast | Date | Sun, 14 Oct 2001 22:20:24 +0400 (MSK DST) |
| |
Hello!
> The assumption is that the peer is implemented the way you expect and > that the application doesn't toy with TCP_NODELAY.
Sorry??
It is the most important _exactly_ for TCP_NODELAY, which generates lots of remnants.
> Not really. You could do one of two things: either ack every second > segment
I do not worry about this _at_ _all_. See? "each other", "each two mss" --- all this is red herring.
I do understand your problem, which is not related to rcv_mss. When bandwidth in different directions differ more than 20 times, stretch ACKs are even preferred. Look into tcplw work, using stretch ACKs is even considered as something normal.
I really commiserate and think that removing "final cut" clause will help you. But sending ACK on buffer drain at least for short packets is real demand, which cannot be relaxed. "final cut" is also better not to remove actually, but the case when it is required is probabilistically marginal.
Alexey - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
|  |