diff options
author | Gerrit Renker <gerrit@erg.abdn.ac.uk> | 2007-11-24 21:40:24 -0200 |
---|---|---|
committer | David S. Miller <davem@davemloft.net> | 2008-01-28 14:54:53 -0800 |
commit | d50ad163e6db2dcc365b8d02b30350220f86df04 (patch) | |
tree | 56998d89dcf4b748c09b4f5fe82bd2b7742ea3cb /drivers/block/ub.c | |
parent | df054e1d00fdafa2e2920319df326ddb3f0d0413 (diff) |
[CCID2]: Deadlock and spurious timeouts when Ack Ratio > cwnd
This patch removes a bug in the current code. I agree with Andrea's comment
that there is a problem here but the way it is treated does not fix it.
The problem is that whenever Ack Ratio > cwnd, starvation/deadlock occurs:
* the receiver will not send an Ack until (Ack Ratio - cwnd) data packets
have arrived;
* the sender will not send any data packet before the receipt of an Ack
advances the send window.
The only way that the connection then progresses was via RTO timeout. In one
extreme case (bulk transfer), it was observed that this happened for every single
packet; i.e. hundreds of packets, each a RTO timeout of 1..3 seconds apart:
a transfer which normally would take a fraction of a second thus grew to
several minutes.
The solution taken by this approach is to observe the relation
"Ack Ratio <= cwnd"
by using the constraint (1) from RFC 4341, 6.1.2; i.e. set
Ack Ratio = ceil(cwnd / 2)
and update it whenever either Ack Ratio or cwnd change. This ensures that
the deadlock problem can not arise.
Signed-off-by: Gerrit Renker <gerrit@erg.abdn.ac.uk>
Acked-by: Ian McDonald <ian.mcdonald@jandi.co.nz>
Signed-off-by: Arnaldo Carvalho de Melo <acme@redhat.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
Diffstat (limited to 'drivers/block/ub.c')
0 files changed, 0 insertions, 0 deletions