Our goal is to test the ALTQ package to show its performance.

The test environment consists in two BSD machine connected with an ATM 155Mbps link (PVC). The first machine runs the TTCP sender and the ALTQ package; the second machine runs the TTCP receiver and, in some test, the TTT program to show graphical results.

In some test we have used a second configuration with 3 machines: the first is the TTCP sender, the second the ALTQ router, the third the TTCP receiver.

Since the first two machines are connected via a shared Ethernet, we set the CBQ bandwidth to 1Mbps to guarantee that the bottleneck was the CBQ link and not the Ethernet.

First tests are done defining a channel of 1Mbps (the root class), and partitioning it in two sub_classes with the same priority but with different share. In a first test suite the share is 40-60%, in a second test suite 20 – 80%.

All results of this section are extracted with the TTCP program.

The classifier was been activated first on a basis of the Destination Port on the incoming packet, then on a basis of the Protocol type. Results show that in both cases the classifier seems run properly: there aren’t no differences between the classification on a port basis, and on a Protocol basis.

The configured share is respected by the CBQ daemon, and the total bandwidth is closely near to the Root class Bandwidth (1Mbps, but this bandwidth include also the Level 2 network overhead).

In these tests the amount of the TCP traffic, with the same filter, is a bit less than the amount of the UDP traffic: this is due to the congestion control mechanisms embedded in TCP.

Some test are done with mixed traffic (UDP and TCP) but results are equivalent to the above tests.

Since CBQ is a non Work Conserving schedule discipline, some test are done with only one flow. Result matches very well the tests with two flows.

To improve performance, in CBQ it’s possible to specify that if one class has a lot of traffic and an other has unused bandwidth, the traffic of the first class can use also the free bandwidth of the second. This feature must be explicitly configured and this "borrow process" must be done on a parent class.

Results show that there is a lot of problem with this feature. Results show that:

• the total allocated bandwidth exceed the root class bandwidth
• the throughput of the class that has not the borrow is reduced compared with the other test (in other word: the traffic in one class affects the traffic in the other class), and can be seen clearly comparing test 1 and 3 (UDP throughput: 356.65 against 560.88).

The trace shows a very strange behavior: the CBQ daemon only sometime give bandwidth to the flow that has no borrow. Before the "borrow" flow starts, vice versa, the behavior of this flow is normal (oscillation are due to the small bandwidth used, 1Mbps for the root class).

The same test is performed changing the class tree distribution, defining a new intermediate class with the 50% share. Tests show a better behavior, but it’s not yet the ideal behavior.

This problem with the "borrow" parameter is confirmed in the ALTQ paper (ftp://ftp.csl.sony.co.jp/pub/kjc/papers/altq98.ps.gz) but the author report only that "the priority and borrowing especially when a class has high priority but a small share of bandwidth does not work well".

NOTES

• All tests are done with the same fixed priority for all classes.
• In this report aren't shown the result of the second machine configuration (with 3 PC): the results are equivalent to the 2 machine configuration (in the TCP tests, because Java TTCP is not able to send UDP traffic, so UDP tests can not be done)

We have done some test to understand the performance, in the time domain, of the ALTQ package.

We used the configuration with 2 machines: the first has the CBQ daemon and two TTCP Senders, the second is the TTCP receiver and it has the TTT graphics package installed to evaluate the traffic leaving the CBQ daemon.

The classes configuration is always the same: a root class with two sub_classes: one has the 20% and the other has the 80% of the root bandwidth. In these test the root class has 10Mbps.

In this test we use two TCP flow both are in the same CBQ class. Results show that the two connections share correctly the 50% of the total bandwidth. But this graph shows also one problem: the used bandwidth is quite low compared to the root bandwidth (10Mbps). This seems does not depend from the test suite (TTCP) because without the CBQ daemon the throughput is very high.

This test has been performed also with:

• two UDP connection in the same class
• two TCP connection in the same class (classification on a port basis)
• two UDP connection in the some class (classification on a port basis)

In all these tests the maximum throughput is nearly 1.8Mbps.

This graphs show the result with two flows, one UDP and one TCP, belonging to two different class. The UDP flow was assigned to the slow class (20%), and the TCP flow was assigned to the fast class. Results show that:

1. The total bandwidth is near 1.8Mbps (as the previous tests)
2. When a flow start it occupies all the bandwidth, not only its share (20 or 80%) (NOTE: there is no the borrow flag)
3. At run time, with two flow, the share is not respected: UDP traffic (20% class) is more that TCP traffic (that has 80%)
4. Regarding the graphs one should note that normally the UDP and TCP traces show a complementary behavior: if one increase the other decrease and vice versa. This shows that the two classes influence each other.

The same test are repeated with two flow (one TCP and one UDP) differentiated on a port basis: results are the same.

Test are repeated with 1Mbps as the root bandwidth: results show that in this case the behavior is correct: the share is quite good, one class use only its bandwidth even if there aren't any other flows, the classes does not influence each other, the bandwidth used is 1Mbps.

These two test shows the behavior in a configuration when two equal flow (TCP-TCP and UDP-UDP) are sent in the CBQ daemon. These flow, despite they belong to the same protocol, are differentiated by the destination Port: so one flow was put in the high priority flow, and the second was put in the low priority class. Results show that:

• if the two flow are UDP there is a difference between them (but the share, 20% - 80% was not respected)
• if the two flow are TCP they share equally the bandwidth (50-50) despite their class
• as usual the total bandwidth is about 1.8Mbps, and when a class has no traffic the other class consume all the bandwidth even if the "borrow" flag is not activated.

ALTQ package seems have the following problems:

• "Borrow" flag seems to run not properly
• If the root bandwidth is set to 10Mbps:
• the CBQ daemon seems not able to use more than 1.5Mbps
• the CBQ daemon is not able to share properly the bandwidth among various classes
• the classes in the test seems to influence each other (when a class decreases the bandwidth the other increases)
• these problem seem not happen if the root bandwidth is set to 1Mbps