| In doing some DCCP testing, I have identified a bug in the CCID 2
| implementation. Right now, CCID 2 will willingly increase it's
| congestion window (the number of packets it tries to keep in the
| network) greater than the sequence window. This, of course, causes
| acknowledgments from the receiver to be deemed sequence invalid which
| causes a Sync/SyncAck exchange. In at least one test, this has resulted
| in a loss of 1/3rd of the bandwidth because of repeated Sync/SyncAck
| exchanges. I am working on a patch; however, I am interested to know if
| anyone else has seen similar problems and/or is working on a solution...
|
The problem is known and the fix so far is ugly ("simply increase the
value of the seq_window sysctl to an improbably high value").
Limiting the cwnd to the value of seq_window would be one way. With
regard to a recent change I was also thinking whether a per-connection
socket option for seq_window would make sense, which overrides seq_window
(taking u64/u48 values).
The whole thing is complicated since three variables constrain each other:
a) According to RFC 4340, 7.5.2,
seq_window =~ 5 * cwnd
b) ack_ratio must be less than or equal to ceil(cwnd/2) (already done)
If 5 * cwnd >= current_seq_window, we should be sending an NN option to
the remote peer to inform about this change. There is already support for
this signalling in the test tree,
http://eden-feed.erg.abdn.ac.uk/cgi-bin/gitweb.cgi?p=dccp_exp.git;a=commitdiff;h=a39e30e09a9e31ddeadc44d4a2baef4eac4cde25
The same should actually be done for (b), but it is currently disabled, since
it was found to misbehave (re-activating it requires only to disable the
preprocessor conditional).
I think that sending an update would be the right thing to do.
Gerrit
--
To unsubscribe from this list: send the line "unsubscribe dccp" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
