diff options
author | Jon Maloy <jon.maloy@ericsson.com> | 2019-12-10 02:52:45 +0300 |
---|---|---|
committer | David S. Miller <davem@davemloft.net> | 2019-12-11 04:31:15 +0300 |
commit | d3b09995ab930df225929b4153b7187f1bb8a396 (patch) | |
tree | 0b380333afeeafb3b25d42d889e808e02c8e23bd /net/tipc/ib_media.c | |
parent | 02288248b051ae9a9438278148f44bdfb0a4068b (diff) | |
download | linux-d3b09995ab930df225929b4153b7187f1bb8a396.tar.xz |
tipc: eliminate more unnecessary nacks and retransmissions
When we increase the link tranmsit window we often observe the following
scenario:
1) A STATE message bypasses a sequence of traffic packets and arrives
far ahead of those to the receiver. STATE messages contain a
'peers_nxt_snt' field to indicate which was the last packet sent
from the peer. This mechanism is intended as a last resort for the
receiver to detect missing packets, e.g., during very low traffic
when there is no packet flow to help early loss detection.
3) The receiving link compares the 'peer_nxt_snt' field to its own
'rcv_nxt', finds that there is a gap, and immediately sends a
NACK message back to the peer.
4) When this NACKs arrives at the sender, all the requested
retransmissions are performed, since it is a first-time request.
Just like in the scenario described in the previous commit this leads
to many redundant retransmissions, with decreased throughput as a
consequence.
We fix this by adding two more conditions before we send a NACK in
this sitution. First, the deferred queue must be empty, so we cannot
assume that the potential packet loss has already been detected by
other means. Second, we check the 'peers_snd_nxt' field only in probe/
probe_reply messages, thus turning this into a true mechanism of last
resort as it was really meant to be.
Acked-by: Ying Xue <ying.xue@windriver.com>
Signed-off-by: Jon Maloy <jon.maloy@ericsson.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
Diffstat (limited to 'net/tipc/ib_media.c')
0 files changed, 0 insertions, 0 deletions