Subject: Selective ACKs

From: Jan-Oliver Rock <[email-masked]>
Date: Wed, 18 Apr 2001 23:28:19 +0200

Hi out there!
I'm working on a SACK implementation in SDL and came across something
that has
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
Fall/Floyd
(2) "A Conservative SACK-based Loss Recovery Algorithm for TCP" by
Allman

(1) and (2) state that adding SACK to TCP does not change the basic
underlying
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
takes over. 
Is my view on this correct ?
Thank you, Olli

---

From: Mark Allman <[email-masked]>
Date: Mon, 23 Apr 2001 05:01:06 -0400

> (2) "A Conservative SACK-based Loss Recovery Algorithm for TCP" by

(Actually most of the credit goes to Ethan Blanton, but anyway...)

> (1) and (2) state that adding SACK to TCP does not change the
> basic underlying 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 takes over.  Is my view on this
> correct ?  

Right.  Immediatly after recovery is finished cwnd should be the
same in both cases.  Fast recovery just sort of overloads cwnd
during recovery to accomplish what pipe does during SACK-based
recovery.

allman

---
Mark Allman -- NASA GRC/BBN -- http://roland.grc.nasa.gov/~mallman/