On Mon, 10 Nov 1997, Hans Kruse wrote:
> At 17:43 -0500 11/10/97, Chuck Nunez wrote:
> >that's already been solved. Adjusting the window size to compensate for
> >the BANDWIDTH*DELAY PRODUCT the ultimate solution. The problem seems to be
> >how to get it done on any particular platform. Your comment about the
> >"setsockopt" is the key.
>
> ...
> >
> >Selective acknowledgements would be helpful, but I agree not essential.
> >
>
I would like to comment on that as well. Getting the upper limit of the
socket buffers equals to the BDP is very essential for fully utilizing the
available bandwidth(i.e. to be able to fill in the pipe). On real
experiments I carried down here in the University of Kansas over OC-3 and
OC-12 satellite (ACTS) links with TCP Reno on ATM, I obtained really good
performance (128Mbps was the max. I could get on the OC-3 link; the
theoretical maximum obtainable thruput is 134Mbps). This happened when the
BER on the satellite link was in the range of 10^(-11) to 10^(-13) as it
is supposed to be according to ACTS specs. When the BER was higher, on the
range of 10^(-7) to 10^(-8) {I was getting the BER every hour from the
ACTS console(NMT)} then TCP Reno couldn't handle it; thus thruput
obtained was really low. Obviously, more than one segments were lost in a
window (setup at 10MB with setsockopt) of data sent and therefore TCP Reno
fast retransmit was triggered several times in a RTT which resulted either
in slow start or fast recovery on a really low ssthresh. With a script we
wrote, where it captures the TCP retransmissions
from the TCP stack, you could see retransmissions occur in bursts.
Therefore, I believe having a TCP SACK implementation, which can
retransmit those packets lost, in one RTT, it will improve performance
with that BER on the satellite link. I am planning on testing TCP SACK and
SCSP-TP over the same scenarios(over ATM over ACTS on the same set of
experiments) in the near future and see how well these two new
implementations can handle retransmissions or rephrasing how well they
will do on higher BER on the satellite link.
b.t.w Did anybody implemented TCP SACK on DU4.0(A,B)?
Pambos
//////////////////////////////////////////////////////////////////
Charalambous Charalambos (Pambos) //
Department of Electrical and Computer Engineering //
Research Assistant - The University of Kansas //
Work phone: 913-864-7761 \\
E-mail: [email protected] // [email protected] \\
URLpersonal:http://www.ittc.ukans.edu/~ccharala //
URLcyprus: http://www.eecs.ukans.edu/~pambos/cyprus //
//////////////////////////////////////////////////////////////
> I disagree somewhat with these statements. Getting the window size correct
> is clearly necessary, but IMHO not sufficient for good performance. The
> large RTT creates a long feedback loop (which requires the large window);
> that means that the normal TCP responses to packet loss (either congestion
> or corruption) will be slowed down on the satellite link, resulting in
> degraded performance. This is a place where SACK should help.
>
> There are also various issues of applications design (e.g. HTTP 1.1 without
> pipelining will be really awful on a sat link); these may be outside the
> scope of this group?
>
> A question regrarding your comments on retransmit timers: Do these timers
> not adjust with the measured RTT? Or are these maximum timer values?
>
>
>
> Hans Kruse, Associate Professor
> McClure School of Communication Systems Management, Ohio University
> 9 S. College Street
> Athens, OH 45701
> 614-593-4891 voice, 614-593-4889 fax, [email protected]
>
>
This archive was generated by hypermail 2b29 : Mon Feb 14 2000 - 16:14:32 EST