> This trace is done from the receiver (the acker).
>
> 15:55:34.444225 141.76.20.99.20 > 195.223.140.39.1042: . 9729:9985(256) ack 1 win 32512 [tos 0x8]
> 15:55:34.904244 141.76.20.99.20 > 195.223.140.39.1042: . 9985:10241(256) ack 1 win 32512 [tos 0x8]
> 15:55:34.904325 195.223.140.39.1042 > 141.76.20.99.20: . ack 10241 win 31744 (DF)
> 15:55:35.414288 141.76.20.99.20 > 195.223.140.39.1042: . 10241:10497(256) ack 1 win 32512 [tos 0x8]
> ^^^^^^
> 15:55:35.914321 195.223.140.39.1042 > 141.76.20.99.20: . ack 10497 win 32512 (DF)
> ^^^^^^ delayed ack timeout due a missed packet
> 15:55:36.384302 141.76.20.99.20 > 195.223.140.39.1042: . 10753:11009(256) ack 1 win 32512 [tos 0x8]
> 15:55:36.384411 195.223.140.39.1042 > 141.76.20.99.20: . ack 10497 win 32512 (DF)
> ^^^^^ lost
>
> If I would be the TCP engine I would have understood that at time
> ~"(15:55:34.904244-15:55:34.444225) + 15:55:35.414288" the packet
> 10497:.... got lost from the network. I don' t think that setting the
I'm not sure what you mean, but it sound wrong. How do you know that the
packet is lost? The only way you know that a packet is lost is if you get
one that is out of sequence---and even then, it's possible that packets
have been reordered.
Just because you have been receiving segments are regular intervals,
and there is a sudden lapse, doesn't mean that a packet has been lost.
There is no way to tell the difference between that and a sender that has
stopped sending because it has no more data in its window.
> delayed ack timeout to 0.5sec is a good idea. The max timeout should be
> calculated in a smoothed way in function of previous received packet.
The purpose of a delayed ack is to give TCP a chance to piggyback its own reply
with a segment containing an application-level reply, or to ack another
segment that may arrive within a short period.
If a delayed ack is in effect and another segment arrives on the same
connection, the timer is cancelled and an ack is sent immediately.
Thus you want a reasonably large delay, but not too large---timely acks are
important in situations like slow-start or under Nagle conditions.
> This is not specified by RFCs AFIK, maybe because they are lazy or to
No, it is behavior copied from the BSD implementation. Not all BSD behaviors
are specified by RFC's. Delayed acks are simply something that is allowed
within the requirements of the protocol.
> suggest people to fix broken networks... But since I can' t fix the
> network I think that delayed acks should be at least removable via
> sysctl.
You will then be contributing to congestion. Delayed acks are a good idea.
Without delayed acks, you could be reducing the opportunity for an
implementation to piggy back acks. Look at some examples in the Stevens
book.
For example, consider the exchange of packets when a telnet user types
a character (and assume that there is no outstanding delayed ack timer on the
other end, and the transmission buffer is empty on the local side, so Nagle
doesn't come into effect).
The character is turned into a 40 byte segment which is received by
the remote host. The remote host starts its delayed ack timer and passes
the data to the telnet daemon. The remote software echoes the typed character
before the delayed ack timer goes off. Seeing that there is an outstanding
ack, the kernel cancels the timer and sends off the echoed character with
the acknowledgement piggy-backed.
> I seen that there is a #define TCP_DELAY_ACKS in sysctl_net_ipv4
> but is never used. I don' t think that a congestioned network can be
> improved by sending delayed info to the sender when the network lose one
> packet every 4/5 packet as here.
But that's not the prime motivation behind delayed acks. TCP has other
mechanisms for congestion control. Delayed acks do lessen network traffic, and
so can lower congestion, but they aren't a congestion control mechanism per se.
I don't see how a network that loses 20-25% packets will perform better if you
remove delayed acks. Could you explain the rationale?
If the ack is lost, does it matter whether or not it had been delayed?
It sounds like you are trying to garner more peformance for yourself at the
expense of the congested network. Imagine if *every* user of that network
implemented similar hacks; the overall condition would worsen!
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.rutgers.edu
Please read the FAQ at http://www.tux.org/lkml/