Subject: RE: NewReno and the 2001 Revision

From: "Spencer Dawkins" <[email-masked]>
Date: Fri, 11 Sep 1998 09:35:58 -0400

I would like to see this bug fix (multiple cwnd reductions in a single
window) included. It seems to me that the TCPSAT guys are spending lots of
time and effort trying to keep their pipes full, and backing off by half in
a single window of data (when we built this up at one segment per window of
data) is already aggressive congestion avoidance - agressive enough to avoid
congestion oscillation.

Spencer 

> -----Original Message-----
> From:	Mark Allman [SMTP:[email-masked]]
> Sent:	Friday, September 11, 1998 8:07 AM
> To:	[email-masked]
> Cc:	Vern Paxson
> Subject:	NewReno and the 2001 Revision
> 
> 
> We would like to hear some feedback on what sorts of loss recovery
> mechanisms the working group thinks are appropriate for inclusion in
> the revision of RFC 2001.  As Sally outlined in Chicago, there are
> several improvements we can make to Reno style TCP (i.e., TCP
> without SACK).
> 
> Our current opinion is that some form of the NewReno changes (as was
> obvious in the meeting, there are a number of permutations of
> NewReno) should be included in a seperate experimental document.
> However, as Sally outlined in the meeting and it her note to this
> list shortly after, there is also a seperate issue of fixing a
> fairly well known TCP bug (misfeature?).  The bug occurs when
> multiple fast retransmits happen for multiple lost segments within a
> window of data and consequently cwnd is halved multiple times for
> one ``congestion event''.  We would like to hear comments on whether
> or not such a bug fix should be included in the 2001 revision.
> 
> Thanks,
> Mark and Vern

---

From: Mark Allman <[email-masked]>
Date: Fri, 25 Sep 1998 15:36:52 -0400

> As Sally pointed out in the IETF meeting, we can easily come up
> with scenarioes where NewReno and its variants work badly or too
> aggressively.  But with SACK, we can do better.  

I think no matter what TCP we have, we can always come up with
scenarios where things don't work particularly well.  I have seen
presentations on situations in which SACK based algorithms are
suboptimal, as well.

> As of now, there is no internet draft on how to make good use of
> SACK.  I think in 1 year's time, SACK should be widely deployed.
> So we should focus on how to make good use of SACK info, and also
> how to avoid abusing it.

OK, I am with you on the last statement.  We don't want people to
abuse SACK information and make an inappropriately agressive TCP.
That is why we inserted the statement on SACK in 2001.bis.  The
paragraph essentially says that SACK algorithms must follow the
spirit of the non-SACK congestion control algorithms (see the
statement in the draft for a better (I hope!) description).

But, at this point I am not sure that the research into a SACK-based
algorithm is done, or near a point where it is time to determine
which algorithm is ``the best'' and standardize it.  So, it seems to
me that the appropriate approach is to outline the general
principles that should guide the development of SACK-based
algorithms, in order to prevent such algorithms from hurting the
network and contributing to congestion collapse.  However, it seems
less important to try to decide which SACK-based algorithm is the
best and standardize it (at least at this time).

But, I've been wrong before...

allman