Some comments on the "standard mechanisms" draft:
1. I think there is too much tutorial material that is not very
relevant. In particular, the essential points of lines 124-164 are
basically reiterated in the paragraphs immediately following.
Furthermore, the ``cheerleading'' about how good satellites are for
multicast and mobility (lines 165-171) is definitely not relevant.
Also, I don't think that the long treatise on the benefits of using FEC is
necessary. You could simply state that TCP performance is highly
sensitive to the BER of the underlying channel.
2. Is there any evidence that Path MTU discovery is more beneficial than
raising the default MSS for nonlocal destinations? It seems to me that if the
network is able to handle fragmentation without bad things happening
(particularly congestion-related loss of fragments), the satellite TCP
connection would be better off not allowing the MTU to be negotiated downward.
Of course, it would be network-unfriendly to turn off Path MTU discovery in
heterogeneous environments, but strictly from a TCPSAT perspective, I'm not
convinced that Path MTU discovery would give me better performance in practice
than just setting the default MSS to Ethernet size.
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