On Mon, 10 Nov 1997, C. Charalambous wrote:
> 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;
^^^^^^^
Sorry, after I had a look at the paper, the max we got was
119Mbps on the OC-3 link.
Thanks
Pambos
>
> 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:33 EST