Subject: Re[2]: improve SACK? <More responses>

From: [email-masked]
Date: Fri, 29 Jan 1999 09:54 -0800 (PST)

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-masked] 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:
Date: Fri, 29 Jan 1999 11:07:01 +0100
From: Gorry Fairhurst <[email-masked]>
Subject: Re: improve SACK? <More responses>
Sender: [email-masked]
Reply-to: [email-masked]
Organization: Dept Engineering, University of Aberdeen, Scotland, UK