Hi Hermon,
I am planning to get some implementation of SACK and run it over
satellite links. But since you have done some experiments I had few
questions about your implementations.
1. what are the typical BERs (Bit Error Rates) you tried in the
intermediate transmission links (any delay characteristics)
2. what type of errors have you tried.: Random errors or bursty
errors?
Thanks
Ravi
* * * * * * * * * * * * *
Ravi Malghan
MTS, Systems Engineering Group
COMSAT Labs Tel: (301) 428-4412
22300 Comsat Drive Fax: (301) 601-5850
Clarksburg, MD 20871 E-mail: [email protected]
* * * * * * * * * * * * *
______________________________ Reply Separator _________________________________
Subject: Re : TCP SACK
Author: Hemon Bruno <[email protected]> at INTERNET
Date: 10/21/97 1:55 PM
We are 2 graduate students working for the UCLA Internet Research Lab. We
have been working on TCP Sack for almost one year now and our project is
in its final phase. We are currently writing a report on our experiments
and it should be ready in one month.
We have a web page for our project that can be found at :
http://irl.cs.ucla.edu/sack.html
This page is under permanent construction and should be updated soon, but
it gives anyway a good idea of what we are working on.
When the report is done, it will be available on this page.
The first conclusions of our tests are that first, as expected, TCP Sack
has, in most cases, a better throughput than TCP Reno. This was confirmed
by experiments in our lab and over the Internet. We have quantified this
improvement for different delays and loss probabilities.
We have run more extensive tests in the case of long delay. We compared
the throughput of TCP Sack, for different loss probabilities, with the
throughput of TCP Reno and the maximum theoretical throughput.
Finally, we studied the negative impact that TCP Sack could have on other
competing connections. Our conclusion is that this negative impact is
low. TCP Sack improves its throughput by using more efficiently the
bandwith, otherwise wasted by TCP Reno, but does not steal an unfair share
of bandwith from its competitors.
We will keep on posting any important news concerning the development of
our project to the relevant mailing lists. We would like also to know
what are the research groups currently working on TCP Sack.
--------------------------------------------------------------
TCP Sack Project
Internet Research Lab
Computer Science Department at UCLA
Team : Renaud Bruyeron [email protected]
Bruno Hemon [email protected]
Advisor : Lixia Zhang [email protected]
-------------------------------------------------------------
Received: from ro.ctd.comsat.com (134.133.40.45) by smtpgw2.cws.comsat.com with
SMTP
(IMA Internet Exchange 2.11 Enterprise) id 0002529A; Tue, 21 Oct 97 19:21:14
-0400
Received: from achtung.sp.trw.com [129.4.51.2]
by ro.ctd.comsat.com with smtp (Exim 1.71 #2)
id 0xNnbZ-0006zp-00; Tue, 21 Oct 1997 19:20:53 -0400
Received: by achtung.sp.trw.com (4.1/SMI-4.1)
id AA27204; Tue, 21 Oct 97 13:50:31 PDT
Received: from mailman.cs.ucla.edu by achtung.sp.trw.com (4.1/SMI-4.1)
id AA27199; Tue, 21 Oct 97 13:50:29 PDT
Received: from condor.cs.ucla.edu (condor.cs.ucla.edu [131.179.160.67])
by mailman.cs.ucla.edu (UCLACS-3.0) with ESMTP id NAA26908
for <[email protected]>; Tue, 21 Oct 1997 13:55:33 -0700
(PDT)
Received: from localhost (bruno@localhost)
by condor.cs.ucla.edu (8.8.5/UCLACS-3.0) with SMTP id NAA20457
for <[email protected]>; Tue, 21 Oct 1997 13:55:32 -0700
(PDT)
X-Authentication-Warning: condor.cs.ucla.edu: bruno owned process doing -bs
Date: Tue, 21 Oct 1997 13:55:31 -0700 (PDT)
From: Hemon Bruno <[email protected]>
To: [email protected]
Subject: Re : TCP SACK
In-Reply-To: <[email protected]>
Message-Id: <[email protected]>
Mime-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Sender: [email protected]
Precedence: bulk
This archive was generated by hypermail 2b29 : Mon Feb 14 2000 - 16:14:31 EST