Abstract: "Analysis and improvement of TCP Hybla"

Due to the nature of the TCP protocol, it is possible a number of flows are synchronising with each other.

This means that flows influence each other in such a way that possibly one flow benefits from the synchronisation by claiming a large share of capacity,

while an other flow is not able to receive a reasonable portion of the capacity. This problem is most likely to occur in (simple) network simulations and possibly in actual networks with large data transfers.

The synchronisation effect is caused by the relation between the round trip time (RTT) of packets of certain flows and the moment when a new slot comes available at a saturated DropTail queue (from which multiple flows make use of).

When a certain RTT is in sync with the time a slot comes available at the queue, the flow having that RTT is able to be the first to fill the available slot at that queue, leaving the other flow with a constantly filled queue leading to starvation of the other flow(s).

Both TCP New Reno and TCP Hybla (a TCP variant especially aimed at adjusting RTT behaviour for wireless high RTT connections) were researched and both suffer from the same synchronisation effect. With TCP New Reno the synchronisation effect was mapped, while with TCP Hybla some more extensive tests were done.

This because TCP Hybla has some RTT adjusting techniques embedded, which might have led to less synchronisation effect.

As it turned out, none of the adjustments were sufficient to rule out the synchronisation effect.

A solution to the synchronisation effect could be inserting random packets into the network. This packet insertion makes sure that it is hard for the RTT to be exactly the same every time, thus not being able to come in sync with the queue.

Another solution is using other queueing schemes. It seems like the RED queueing scheme is an effective solution due to its more dynamic nature of queueing, creating variations in the RTT and more fairness when dropping packets of flows. RED however is not widely available in actual networks,

so this would mainly be a solution for network simulations.