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 we�ll soon be able to release and there are some
slides from a recent talk on
�TCP Enhancements for Internet Service Provision over DVB-S Networks� 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 isn�t
really the issue, current TCP (New-Reno) can easily be exteneded to use
this information efefctively. I�d 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.
This archive was generated by hypermail 2b29 : Mon Feb 14 2000 - 16:14:53 EST