[e2e] Re: [Tsvwg] FTCP algorithm
Dohy.Hong at ens.fr
Fri Apr 26 09:46:48 PDT 2002
You are right. The idea is not new.
But I'm really surprised by the conclusions given
in the paper infocom2000.
Without knowing these previous works, my conclusion
was exactly the opposite.
I'll try to understand more clearly what was the exact
implementation done by Aggarwal, Savage and Anderson.
I doubt some differences in the leaky-bucket mechanism
which could lead to very different results.
In particular, in FTCP, the parameter MPPN
(Maximum Patient Packet Number) may be crucial.
The number of packets waiting for 'pacing' must be
kept small. So, if this number reaches the value MPPN
the most patient packet is immediately sent.
What do you think?
On Fri, 26 Apr 2002, Lloyd Wood wrote:
> On Fri, 26 Apr 2002, Dohy HONG wrote:
> > I would like to open discussions about the ideas of
> > FTCP algorithm presented in:
> > http://www.ietf.org/internet-drafts/draft-hong-ftcp-00.txt
> > This algorithm propose a simple modification of
> > TCP algorithm to improve the performance in a way
> > which is 'socially better'.
> > And it seems that there are 2 interesting properties
> > in using FTCP (F for fluid):
> > One is that it improve the End-to-End performance for
> > its user.
> > The second is that it encourages others to also use
> > this algorithm and become 'socially better'.
> > The basic idea is based on the remark that the
> > packet burstiness inside each RTT is not good:
> > especially with Slow Start and long RTTs.
> > If you have CWND=10 with RTT~1 second, it is better
> > to send 1 packet every 100 ms that to send a burst
> > of 10 packets.
> That's the basic idea of TCP pacing, which your draft doesn't mention.
> You might want to wander through e.g.:
> Understanding the Performance of TCP Pacing
> Amit Aggarwal, Stefan Savage, Thomas Anderson
> and compare your approach to other rate-based TCP pacing schemes.
> > What is your gain? I did some simple test modifying
> > the linux kernel and doing FTP and HTTP
> > (I also did some simple NS simulation which is described
> > in the draft).
> > My feeling was that you could gain about 0-50%
> > depending on RTT, congestion state etc. It would be
> > nice if other people could check this
> > independently. I would be more than happy to help
> > anyone who would like to do kernel modification
> > (or for ns-2) for FTCP and get any feedback.
> > What is the cost? Well, I think FTCP idea is more
> > efficient with a good timer granularity.
> > Timer is needed by the fact that you need to be
> > patient before sending packets after ACKs reception
> > (roughly speaking: try to send 1 packet every
> > CWND/RTT).
> > A good point is also that this idea could be
> > implemented at the source or/and the destination level.
> > I naively hope that FTCP could become useful to
> > people in practice.
> > All feedbacks, comments, criticisms (even blames) are very
> > welcome.
> > Dohy
> > ===================================================
> > Dohy HONG
> > INRIA-ENS
> > Projet TREC (Théorie des Réseaux Et Communications)
> > ECOLE NORMALE SUPERIEURE
> > Département Informatique
> > 45 rue d'Ulm, 75230 PARIS CEDEX 05, FRANCE
> > Tel : 33 (1) 4432 2112, Fax : 33 (1) 4432 2151
> > ------------------------------------
> > Email : Dohy.Hong at ens.fr
> > http://www.di.ens.fr/~trec
> <L.Wood at surrey.ac.uk>PGP<http://www.ee.surrey.ac.uk/Personal/L.Wood/>
Projet TREC (Théorie des Réseaux Et Communications)
ECOLE NORMALE SUPERIEURE
45 rue d'Ulm, 75230 PARIS CEDEX 05, FRANCE
Tel : 33 (1) 4432 2112, Fax : 33 (1) 4432 2151
Email : Dohy.Hong at ens.fr
More information about the end2end-interest