I'm still reading the latest ID on "standard mechanisms" but regarding
comment 3 by Tom Henderson, we have studied a SACK based algorithm
for loss recovery, in conjunction with ``New-Reno'' and agree the
additional information provided by SACK improves TCP error recovery.
New-Reno ensures the conservativeness of the TCP retransmission and
avoids a needless reduction of the value of cwnd.
Our simulation results are published in the following reference (also
quoted in the ID on "research issues"). We also explored the potential
for retransmission of previously retransmitted segments (retransmission
of retransmitted DATA segments) by noting the time order of received
SACKs at the sender. Premature reduction of cwnd would certainly
impact performance over a LFN which sees any form of loss!!!
[Nihal K. G. Samaraweera and Godred Fairhurst, "Reinforcement of TCP
error Recovery for Wireless Communication", Computer Communication
Review, volume 28, number 2, April 1998.].
Nihal Samaraweera and Gorry Fairhurst
> 3. In section 4.1.2 (Fast Retransmit/Recovery), I think it would help
to
> emphasize the benefits of employing the ``New-Reno'' bug fix that
avoids
> cutting the window multiple times in one RTT. This is particularly
important
> for long transfers over a satellite link. I think that it qualifies
as a
> ``standard mechanism'' because it is really a guide as to how to
better
> implement Reno congestion control. This could be done as follows:
>
> > multiple fast retransmits. Reducing cwnd multiple times for a
> > single loss event has been shown to hurt performance [GJKFV98].
> > [FF96] prescribes a fix to this problem, known as ``New-Reno''
> > congestion control. `New-Reno'' congestion control is
particularly
> > beneficial for satellite links.
>
> Then change the next paragraph as follows:
>
> > The best way to improve the fast retransmit/fast recovery
algorithms
> > is to use a selective acknowledgment (SACK) based algorithm for
loss
> > recovery, in conjunction with ``New-Reno'' congestion control to
avoid
> > multiple reductions of the congestion window in one RTT. As
discussed
> > below, these algorithms are generally able to quickly recover
from
> > multiple lost segments without needlessly reducing the value of
cwnd.
> > Even if SACK is not available, ``New-Reno'' congestion control
should
> > still be used.
> Tom
This archive was generated by hypermail 2b29 : Mon Feb 14 2000 - 16:14:46 EST