diff options
author | Gerrit Renker <gerrit@erg.abdn.ac.uk> | 2008-06-11 11:19:09 +0100 |
---|---|---|
committer | Gerrit Renker <gerrit@erg.abdn.ac.uk> | 2008-06-11 11:19:09 +0100 |
commit | 3294f202dc1acd82223e83ef59f272bd87bb06b2 (patch) | |
tree | b3841a093322afbc7cd608ccc6ae60debe8c015a /net/dccp/ackvec.c | |
parent | 513fd370e6832f81ab717df4645f5ce679e44f14 (diff) | |
download | linux-3294f202dc1acd82223e83ef59f272bd87bb06b2.tar.gz linux-3294f202dc1acd82223e83ef59f272bd87bb06b2.tar.bz2 linux-3294f202dc1acd82223e83ef59f272bd87bb06b2.zip |
dccp ccid-3: Bug-Fix - Zero RTT is possible
In commit $(825de27d9e40b3117b29a79d412b7a4b78c5d815) (from 27th May, commit
message `dccp ccid-3: Fix "t_ipi explosion" bug'), the CCID-3 window counter
computation was fixed to cope with RTTs < 4 microseconds.
Such RTTs can be found e.g. when running CCID-3 over loopback. The fix removed
a check against RTT < 4, but introduced a divide-by-zero bug.
All steady-state RTTs in DCCP are filtered using dccp_sample_rtt(), which
ensures non-zero samples. However, a zero RTT is possible on initialisation,
when there is no RTT sample from the Request/Response exchange.
The fix is to use the fallback-RTT from RFC 4340, 3.4.
This is also better than just fixing update_win_count() since it allows other
parts of the code to always assume that the RTT is non-zero during the time
that the CCID is used.
Signed-off-by: Gerrit Renker <gerrit@erg.abdn.ac.uk>
Diffstat (limited to 'net/dccp/ackvec.c')
0 files changed, 0 insertions, 0 deletions