TCP Optimization with Software Based Switching

The source for this blog post is taken from Ivan Pepelnjak’s recent software gone wild podcast on TCP Optimization with Juho_Snellman.

Based in Switzerland, Teclo networks is a 4-year-old start-up offering TCP Optimization services with a software based switching product platform. Its product offerings are geared to Mobile networks looking to optimize delivery of information to and from the workspace. Experts in the field of software delivery such as will know the extreme effort that it can take to deliver a properly optimized digital service. The entire optimization process is carried out in software with a new TCP stack on Linux OS. Teclo use standard x86 chip set with an enhanced TCP stack optimized for Radio network requirements that enhance delivery performance. No special application-specific integrated circuit (ASIC) hardware is needed. They run on standard hardware – HP or Dell and use Intel based NICs.


Properties of Radio Networks

Radio networks have different mechanisms than Internet. They operate differently and have different requirements for network function of packet loss, traffic fairness and bandwidth allocation for flows.


Cellular Network

Packet Loss

If you lose a packet on cellular network, error correction is in place. Don’t lose anything even when you are experiencing congestion. Instead, of packet loss you experience a lot of queuing. During normal operation there is no packets loss with radio networks.

You may experience packet loss when transferring to another pay station. But the reaction time is much quicker than with a fixed line. Radio technology with 2G, Round Trip Time (RTT) is few seconds. On LT networks you get 25 milliseconds (ms) of RTT, 3G connections offer 50 ms for baseline latency. Obviously, once you start pushing data the RTT will gradually rise in accordance to data increase.

Bandwidth Variation

Radio network experience-big differences in bandwidth from one interval to another. For example, 1-sec interval bandwidth could be 5 Mbps, next second you achieve 1 Mbps. Radio networks have huge changes in bandwidth per second.

They are considered shared media meaning if a neighbor start transmitting it will slow you down. Unfortunately, algorithms don’t give everyone a fair share of bandwidth. There isn’t a fair shareness element that you can have with other networks. For example, if two end stations are both sending to Internet – station A has a bit better signal quality than station B, station A might get huge amount of additional bandwidth than the other end station.

Instead, of treating end hosts; equally, the base station is trying to maximize data it can push through in that particular transmission interval. The pricing model is based on charging per total data transmitted. Machines side by side to each other witness-variable environments.

Effect on TCP

TCP in its classic form plays horribly with this environment. TCP will slow down to a crawl due to re-transmission timeout triggered. Slower 3G networks can recover from this and every RTT will lower the congestion window. So, theoretically TCP can recover but its slow. One other issue is bufferbloat and its effect on network performance. Bufferbloat is excessive buffering performed in various parts of TCP stack and within the network. Excess buffering of packets causes high latency and packet delay variation, known as Jitter. Jitter is bad for-network performance.

Solution – Teclo TCP Proxy

How did they solve this? Telcro designed TCP proxies to insert in traffic path. TCP proxies are installed on GI link next to the GGSN. GI interface is IP based interface between GGSN and a public data network (PDN) either directly to the Internet or through a WAP gateway. GGSN is the mobile gateway network. It has IP on one side, encapsulates it into GPRS Tunneling Protocol (GTP) for base station transport. It acts as a gateway for IP and the overlay network. The encapsulation is GTP (UDP) so you want to install the proxy on the GI link, which speaks TCP.


GGSN network

TCP proxies are transparent, bump in the wire. It observes the transit TCP packet. It sees the SYN packet going in, later a SYN ACK and; then, an ACK. This process shows connection symmetry going through the device. If the traffic is asymmetric; then, you do not see all phases of the handshake. If TCP proxies do not see the full TCP handshake it will just pass the connection through i.e it doesn’t break any traffic.

TCP proxies observe the handshake and from the TCP process being complete, they can optimize the traffic. Teclo use a custom TCP stack.

Teclo use a standard TCP stack on the Internet side but towards the mobile side using custom TCP optimization. This is where they can performance tune and take responsibility of the end-to-end delivery of packets. They are running a kind of application level proxy. They terminate one TCP session and handle the other side of the TCP sessions. but they do not terminate the TCP connection. They semi terminate the TCP connection by letting the handshake go through – SYN and SYN ACK pass through. Only after that they take over the connection. TCP proxy are transparent on the TCP connection and do not tamper with the TCP sequence numbers.

They run Linux ( CentOS ) but do not use Linux TCP stack. The Linux TCP stack is good for throughput but not for mobile network performance. Mobile networks needs over 5 million connections and that is hard to do in Kernel space. Have no option but to have User space in TCP stack. There are many User space TCP stacks available but they aim for low latency and aim to get the packet to its destination as soon as possible. Not many existing TCP stacks deal with the type of concurrent connections that mobile network might need.


Closing Words

Because they do not terminate TCP connections, no existing TCP stack would actually be able to deal with the two flows that are not linked together. Normal TCP would always terminate the TCP connections. If Teclo wanted to terminate the connection; then, they would lose all that nice transparency and sequence number preservation. They had to write a new TCP stack and decided not to take an existing TCP stack and make it mobile ready.



About Matt Conran

Matt Conran has created 184 entries.

Leave a Reply