Since you are now clearly discussing research that has much broader
implications beyond satellite-based networks, I would encourage you to
take this discussion to the end2end-interest list.
--aaron
______________________________ Reply Separator _________________________________
Subject: Re: improve SACK? <More responses>
Author: [email protected] at mime
Date: 1/29/99 2:07 AM
Some comments follow on SACK:
Tang Oo wrote:
>
> I have some ideas about improving the performance of TCP with SACK, but
> don't know if they are new and feasible ideas.
> I have read Matthew's paper on FACK and IETF RFC on SACK. Since the Sack
> provides much more information than ack, why not make use of these
> statistics? With Sack, we can get these information: The number of received
> segments during the last RTT, the number of lost segments. With these data,
> we can calculate: The average transmission rate at sender side, the arrival
> rate at receiver side(measured with timestamp), the loss rate at receiver
> side. Then adjust the window size according to the achieved throughput and
> loss rate during previous RTT. Now I am working on the algorithm of window
> adjustment. If somebody else has worked out the same idea or a good
> algorithm, pls inform me. Or if it is really a new idea, pls send me some
> comments.
> Thanks a lot.
>
> Tang Oo Research Engineer
> Network Technology Research Center
> Nanyang Technological University, Singapore
> Tel: (65)7905362 Fax: (65)7926894
What you say is interesting. There is indeed a lot of information about
the network encompassed in the information returned in the SACK list. We
have been looking at more optimal processing of this information for
quite a while now, and, sure you can use it to gauge the capacity of the
bottleneck link. The FACK (or pipe algorithm) algorithm allows the SACK
infomration to accurately estimate the number of packets in the network
even during the recovery phase.
A combination of SACK and New-Reno prevents retransmission of all lost
packets during the first RRT, but retransmission using partial ACKs and
Slow Start procedure conservatively (Slow Start has proved to be stable
in the Internet over many years). For the background to our work see:
N.K.G. Samaraweera and G. Fairhurst, "Reinforcement of TCP Error
Recovery
for Wireless Communication", Computer Communication Review,
Volume 28 Number 2, pp 30-38, April 1998.
We've also recently submitted a newer version with some more clearer
thinking, which we hop weP2ll soon be able to release and there are some
slides from a recent talk on
TSTCP Enhancements for Internet Service Provision over DVB-S NetworksCC N
Samaraweera, University of Aberdeen available at:
http://www.estec.esa.nl/artes3/workshop/nihal.html
Whether it is WISE to use SACK to configure rate control is a more
difficult question. Sure, you do get an accurate record of the rate of
packets leaving the network - enougth for rate control - but this isnP2t
really the issue, current TCP (New-Reno) can easily be exteneded to use
this information efefctively. IP2d be interested to see how your ideas
compare.
I've had this hunch that congestion avoidance leads to reduced transport
layer trhoughput efficiency under congestion, but does acheieve network
stability. Whereas rate-based schemes acheive high transport throughput
efficiency, but at the potential of generating congestion collapse when
estimators prove to be wrong. This, I guess is open to debate: Is there
a place for a good hybrid
scheme?
Gorry Fairhurst / Nihal Samaraweera.
RFC-822-headers:
Received: from CONVERSION-DAEMON by mail.hac.com (PMDF V5.1-12 #26580)
id <[email protected]>; Fri, 29 Jan 1999 02:47:08 -0800 (PST)
Received: from PROCESS-DAEMON by mail.hac.com (PMDF V5.1-12 #26580)
id <[email protected]>; Fri, 29 Jan 1999 02:47:07 -0800 (PST)
Received: from fw-es05.hac.com by mail.hac.com (PMDF V5.1-12 #26580)
with ESMTP id <[email protected]>; Fri,
29 Jan 1999 02:47:06 -0800 (PST)
Received: from assateague.lerc.nasa.gov ([139.88.112.23])
by fw-es05.hac.com (8.9.0/8.9.0) with ESMTP id CAA17247; Fri,
29 Jan 1999 02:49:41 -0800 (PST)
Received: (listserv@localhost) by assateague.lerc.nasa.gov
(NASA LeRC 8.7.4.1/2.01-main) id FAA01765; Fri,
29 Jan 1999 05:37:46 -0500 (EST)
Received: from erg.abdn.ac.uk (fw01.lerc.nasa.gov [139.88.145.14])
by assateague-fi.lerc.nasa.gov with ESMTP (NASA LeRC 8.7.4.1/2.01-main)
id FAA01760; Fri, 29 Jan 1999 05:37:14 -0500 (EST)
Received: from 139.133.206.107 (gresley.eng.abdn.ac.uk [139.133.206.107])
by erg.abdn.ac.uk (8.9.1a/8.9.1) with SMTP id KAA04340; Fri,
29 Jan 1999 10:40:14 +0000 (GMT)
Date: Fri, 29 Jan 1999 11:07:01 +0100
From: Gorry Fairhurst <[email protected]>
Subject: Re: improve SACK? <More responses>
Sender: [email protected]
Reply-to: [email protected]
Message-id: <[email protected]>
Organization: Dept Engineering, University of Aberdeen, Scotland, UK
MIME-version: 1.0
X-Mailer: Mozilla 3.01-C-MACOS8 (Macintosh; I; PPC)
Content-transfer-encoding: 8BIT
Precedence: bulk
References: <6665AC0C667ED11186E308002BB487E102732B58@exchange2>
X-Authentication-warning: assateague-fi.lerc.nasa.gov: listserv set sender to
[email protected] using -f
This archive was generated by hypermail 2b29 : Mon Feb 14 2000 - 16:14:53 EST