Search code examples
network-programmingtcptransportcongestion-controlmptcp

Throughput of TCP

I am studying about TCP and multipath TCP. There are some points that make me confuse. I was wondering if TCP is an aggressive or non-aggressive protocol? if there is just one link and there is not any other traffic, the sender can use all throughput of the link? and if I have two TCP flows, each TCP flow can get half of the throughput?

there is a goal that tells multipath TCP has not be more aggressive than a TCP over a path. Based on this goal,in the following picture, multipath TCP ( two sub-flows together) can get maximum 50% of channel? enter image description here

is there any limitation for TCP throuput over 3G or WIFI?

Solution

  • I was wondering if TCP is an aggressive or non-aggressive protocol?

    Actually it's in between, let's say normal, erring on the side of non-aggressiveness. TCP uses an algorithm that maximizes throughput and minimizes congestion. Its goal is to send at the highest transmission rate supported by the network, but not more. When congestion is detected, it backs off. So you could say it is optimal.

    For this reason it is used as a reference when evaluating other protocols. Usually the goal is that a protocol is never more aggressive than TCP.

    If there is just one link and there is not any other traffic, the (TCP) sender can use all throughput of the link?

    Yes.

    If I have two TCP flows, each TCP flow can get half of the throughput?

    Yes, approximately, and on average for longer periods of time. This is called fairness. But only if they have similar RTTs. If they have different RTTs but share a bottleneck link, flows with larger RTTs usually achieve lower throughput.

    There is a goal that tells multipath TCP has not be more aggressive than a TCP over a path. Based on this goal,in the following picture, multipath TCP ( two sub-flows together) can get maximum 50% of channel?

    Note: the image is from this article: https://www.eecs.berkeley.edu/~sylvia/cs268-2014/papers/mptcp.pdf

    Yes. If a MPTCP flow with multiple subflows shares the bottleneck link with a TCP flow, the MPTCP flow will use approximately 50% of the bandwidth.

    Note that is not the case if MPTCP is replaced with multiple parallel regular TCP flows. Let's say 2 as in the figure. In that case the parallel transfer will get 66% of the bandwidth.

    Is there any limitation for TCP throuput over 3G or WIFI?

    TCP usually doesn't know nor need to know what kind of network it runs over. It simply uses:

    • positive acknowledgements as a sign that packets reached the destination, in which case it should send more
    • packet loss as a sign of congestion, in which case it should back off
    • RTT has an indirect influence on the throughput, since positive acknowledgements will arrive with a delay because of this, which slows down the sending eventually.

    The problem with wireless is that packets may be dropped because the link is congested, or because of radio interference. In the former case TCP should back off, in the latter it should retransmit right away. An idea to handle this is https://en.wikipedia.org/wiki/WTCP (RFC 3481). I don't know how often it is deployed in practice, but according to the book "Broadband Internet Deployment in Japan" Jan 1, 2008 by H. Esaki and H. Sunahara (ISBN-13: 978-1586038625 ISBN-10: 1586038621) at least one ISP in Japan, NTT DoCoMo deployed it on their 3G network.