Hi all,
We have been working on an ns-3 implementation of TCP Prague and are currently validating it by running a wider set of bandwidth/delay scenarios beyond what our initial pre-print (
https://arxiv.org/abs/2603.20166) covers, using a physical Linux testbed as reference.
The 4 Mbps / 5 ms scenario produced results very different from the testbed. After investigating, we noticed that in `tcp-socket-base.cc`, when the congestion state transitions from `CA_CWR` to `CA_OPEN`, `m_congState` is updated directly but `CongestionStateSet` is never called:

TCP Prague uses an internal flag `m_inLoss` to block window growth during loss recovery, which is cleared when `CongestionStateSet(CA_OPEN)` is called. Since that callback never fires on this path, the flag stays `true` indefinitely and the congestion window freezes permanently at 2 × MSS.
This is confirmed by our logs: `m_tcb->m_congState` is set to `CA_OPEN` by the socket base, but the congestion control is never notified. Every other state transition in `tcp-socket-base.cc` calls `CongestionStateSet`, this appears to be the only exception.
We are not sure if this is intentional behavior, perhaps congestion controls using HasCongControl() are expected to handle this case differently. When we added the missing CongestionStateSet(CA_OPEN) call, the scenario behaved as expected, so we wanted to check here before considering any changes to TcpSocketBase.
Thanks!