DCTCP congestion control flavour not working as intended.

[Avian688]

The DCTCP congestion control flavour does not work as intended due to the following lines in the TcpConnectionUtil.cc file (which was updated after the release of the DCTCP flavour).
// ECN if (state->ect && state->sndCwr) { tcpHeader->setCwrBit(true); EV_INFO << "\nDCTCPInfo - sending TCP segment. Set CWR bit. Setting sndCwr to false\n"; state->sndCwr = false; }

DCTCP should only update the congestion window once every RTT. After receiving a marked packed, causing a congestion window update, state->sndCwr is set to true. This indicates that the congestion window has changed, which makes sure the congestion window is not again updated if another marked packed arrives. The code snipped above is in the TcpConnection::sendSegment(uint32_t bytes) method, meaning that, when ecn is used, the state-sndCwr will be reset to false for every sent segment. This breaks the behaviour of DCTCP.

[kalsasdf]

The ECE bit of the ACK in DCTCP is not affected by the CWR bit of received packets because DCTCP has its own state machine, which is one cumulative ACK(marked with ECE bit) for every m consecutively received packets, where m is 2 typically. And this algorithm has also been overrided in INET4.4. The following code is in the DcTcp.cc file.
bool DcTcp::shouldMarkAck()
{
// RFC 8257 3.2 page 6
// When sending an ACK, the ECE flag MUST be set if and only if DCTCP.CE is true.
return state->dctcp_ce;
}
So I think DCTCP will behave normally under this version.