1325Re: NewReno and the 2001 Revision
- Sep 25, 1998
> As Sally pointed out in the IETF meeting, we can easily come upI think no matter what TCP we have, we can always come up with
> with scenarioes where NewReno and its variants work badly or too
> aggressively. But with SACK, we can do better.
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 ofOK, I am with you on the last statement. We don't want people to
> 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.
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...
- Next post in topic >>