Skip to contentSkip to conversation

Comparison of several congestion control algorithms

DISCUSSION Baruch Even 2 participants 5 messages May 28, 2005 – Jun 3, 2005

Subsystems (2)
lore
Share & tools
lore
#0 lore raw

Hello,

I wanted to point you to a comparison of congestion control algorithm done at the Hamilton Institute. These experiments compare Scalable-TCP, High-Speed TCP, FAST-TCP, BIC-TCP, H-TCP and Standard TCP. They compared
fairness, compatibility with TCP and link utilisation.

You can find the results and a report at http://hamilton.ie/net/eval/

Regards,
Baruch

maintainer
#1 lore raw

From: Baruch Even <[email protected]>
Date: Sat, 28 May 2005 22:19:01 +0100

Quoted 6 lines

I wanted to point you to a comparison of congestion control algorithm done at the Hamilton Institute. These experiments compare Scalable-TCP, High-Speed TCP, FAST-TCP, BIC-TCP, H-TCP and Standard TCP. They compared
fairness, compatibility with TCP and link utilisation.

You can find the results and a report at http://hamilton.ie/net/eval/

Nice work, I enjoyed this paper very much.

There is something that none of these papers mention, but is essential for interpreting results. Did you use interfaces with TSO enabled?

There is a very serious congestion window growth bug with TSO enabled in the current 2.6.x tree. The problem is due to congestion window validation. When we build TSO frames, even if we have packets to send, we may defer a few frames until the full TSO packet can go out. But this causes the congestion window validation checks in tcp_ack() to not pass, and thus the congestion window does not grow.

I am going to have this fixed, but for now people should do congestion window algorithm tests with TSO explicitly disabled on their interfaces.

#2 lore raw
Quoted 9 lines · David S. Miller

From: Baruch Even <[email protected]>
Date: Sat, 28 May 2005 22:19:01 +0100

Quoted 5 lines

I wanted to point you to a comparison of congestion control algorithm done at the Hamilton Institute. These experiments compare Scalable-TCP, High-Speed TCP, FAST-TCP, BIC-TCP, H-TCP and Standard TCP. They compared
fairness, compatibility with TCP and link utilisation.

Quoted 7 lines
Quoted 1 line

You can find the results and a report at http://hamilton.ie/net/eval/

Nice work, I enjoyed this paper very much.

There is something that none of these papers mention, but is essential for interpreting results. Did you use interfaces with TSO enabled?

I did not do these experiments myself, but to the best of my knowledge, none of the experiments done so far in Hamilton have used the TSO feature.

This is in part because of the start of the work that was based on 2.4 kernels and even as far as the 2.6.6 kernel which had disabled TSO once it saw SACKs. This made TSO unusable for our needs.

AFAIK, the tests reported in that document used kernel 2.6.6.

Baruch

maintainer
#3 lore raw

From: Baruch Even <[email protected]>
Date: Fri, 03 Jun 2005 00:50:07 +0100

Quoted 5 lines

This is in part because of the start of the work that was based on 2.4 kernels and even as far as the 2.6.6 kernel which had disabled TSO once it saw SACKs. This made TSO unusable for our needs.

AFAIK, the tests reported in that document used kernel 2.6.6.

Sure SACKs turn off TSO currently, but you'll have them enabled at the beginning until the first loss and this affects how fast the cwnd will grow.

If you have e1000 cards, for example, you're getting TSO enabled by default.

You really need to look into this, as it has a real and very non-trivial effect on all of the results you obtained.

#4 lore raw
Quoted 15 lines · David S. Miller

From: Baruch Even <[email protected]>
Date: Fri, 03 Jun 2005 00:50:07 +0100

Quoted 5 lines

This is in part because of the start of the work that was based on 2.4 kernels and even as far as the 2.6.6 kernel which had disabled TSO once it saw SACKs. This made TSO unusable for our needs.

AFAIK, the tests reported in that document used kernel 2.6.6.

Sure SACKs turn off TSO currently, but you'll have them enabled at the beginning until the first loss and this affects how fast the cwnd will grow.

Quoted 5 lines

If you have e1000 cards, for example, you're getting TSO enabled by default.

You really need to look into this, as it has a real and very non-trivial effect on all of the results you obtained.

I checked that now and ethtool -k shows TSO to be disabled after boot. Since all the test scripts are not playing with ethtool I can be sure that TSO was off during all of our tests.

Baruch