- Hi out there!
I'm working on a SACK implementation in SDL and came across something
me a little confused. My main sources are the following papers:
(1) RFC 2018 (SACK)
(2) "Simulation-based Comparisons of Tahoe, Reno and SACK TCP" by
(2) "A Conservative SACK-based Loss Recovery Algorithm for TCP" by
(1) and (2) state that adding SACK to TCP does not change the basic
congestion control algorithms.
My concern is about the CWND variable (congestion window). On entering
the loss recovery phase (after receiving 3 dupAcks), the Reno TCP halves
SSTHRESH, retransmits the lost packet and then halves CWND and adds
3*MSS (I'm not taking into account the advertised window here). More
incoming dupAcks will increase CWND by one MSS (fast recovery).
From my understanding of (2) and (3), on entering loss recovery phase in
SACK, the CWND is first halved but then frozen and *not* increased
afterwards (as in fast recovery in Reno), because incoming dupAcks are
now handled by the PIPE variable. When SACK leaves
loss recovery, CWND is handled as in Reno, e.g. congestion avoidance
Is my view on this correct ?
Thank you, Olli