back to article Boffins brew TCP tuned to perform on lossy links like Wi-Fi networks

The world is awash with proposals to improve the venerable TCP/IP protocol. The latest, from researchers at the University of Cincinnati, addresses shortcomings in the protocol's behaviour on wireless networks. Since wireless, rather than a coloured Ethernet cable, is the default connection for most devices, how WiFi handles …

  1. Brian Scott

    Broadcast?

    "As an example of how TCP congestion control can get in the way of network performance, the paper cites a broadcast of two packets to multiple receivers:"

    I think I see a problem here... (hint for non-network people: TCP is very strictly point-to-point not broadcast).

    In fairness I couldn't find the word broadcast in the original paper, on the story.

    1. jake Silver badge

      @ Brian Scott (was: Re: Broadcast?)

      Strictly speaking, IP is point to point. TCP & UDP are connection oriented and connectionless, respectively.

      None of the above were designed for anything resembling "broadcast".

      1. Suricou Raven

        Re: @ Brian Scott (was: Broadcast?)

        UDP can be broadcast, though. Just set a destination of all-ones and every node on the subnet gets it, thanks to the use of a similar all-ones address at the next layer down.

        1. jake Silver badge

          @Suricou Raven (was: Re: @ Brian Scott (was: Broadcast?)_

          "UDP can be broadcast, though."

          Show me a sysadmin who routinely allows that across the network, and I'll happily fire the idiot. Was a handy tool back in the day. Today? An accident waiting to happen.

          1. John Robson Silver badge

            Re: @Suricou Raven (was: @ Brian Scott (was: Broadcast?)_

            Very useful to allow it - OK, it's on a limited subnet, but when many things need to listen to the same data - it's useful.

            Particularly if that data is out of date as fast as is it created - say in an audio distribution network.

          2. Gideon 1

            Re: @Suricou Raven (was: @ Brian Scott (was: Broadcast?)_

            UDP broadcast is used routinely even if you don't like it, e.g. by printers and printer drivers for auto discovery and toner low messages.

        2. Arthur the cat Silver badge
          Headmaster

          Re: @ Brian Scott (was: Broadcast?)

          The article and original proposal are about TCP. UDP is a completely irrelevant red herring. UDP packets are allowed to be dropped on the floor so there's no retransmission involved and no redundancy needed.

      2. Anonymous Coward
        Anonymous Coward

        @JAKE re: Brian Scott (was: Broadcast?)

        Have you never heard of IP multicast? IGMP used extensively, built in to nearly every decent switch.

        DHCP? The way that it use 'broadcast' addresses to find a DHCP server to allocate an address?

  2. Gideon 1

    Fixing at the wrong layer

    It's the radio transport layer that needs the forward error correction applied when the signal gets ropey, sort it locally where there is information about signal strengths and error rates rather than have the TCP stack compensate for a problematic link that could be thousands of miles away.

    1. Anonymous Coward
      Anonymous Coward

      Re: Fixing at the wrong layer

      I was thinking the same - why is the wifi base station not able to cache a half second or so of recent packets and re-transmit them as needed as part of a wifi protocol?

      Must be faster than hopping all the way back to the original server for a re-send.

      1. Yes Me Silver badge
        Stop

        Re: Fixing at the wrong layer

        No. Fixing it at layer 2 (or 3) is much worse than fixing it at layer 4. Actually the successful work at MIT on coded TCP proves this very neatly. If you detect errors at layer 2 (which is by definition hop-by-hop, not end-to-end) then a burst of bit errors followed by layer 2 retransmission (which is very common on a radio link) will result in a dramatic increase in the transfer time for a packet. This is a common problem on WiFi or 4G connections. Vanilla TCP will see a dramatically increased RTT, mistake this for congestion, and slow down as a result. Your performance goes down the tubes. That's why the MIT people figured out how to switch off layer 2 retransmission to get their factor 20 gain in throughput (Google "coded tcp" to find the evidence). The work reported in this story seems to be along the same lines.

        1. Gideon 1
          Go

          Re: Fixing at the wrong layer

          Retries are bad, especially if the round trip time is long. Better is to increase the forward error correction to compensate for the radio link quality as it adds a much smaller overhead to both the local radio channel and the long distance fibre links, keeping the retry rates down. WiFi needs more of the redundancy coding goodness developed for LTE.

          These studies often only consider their own data throughput, selfishly grabbing bandwidth at the expense of other users sharing the same links. TCP/IP was carefully designed to allow efficient sharing of limited bandwidth, and that is where many of these proposals fail.

        2. Michael Wojcik Silver badge

          Re: Fixing at the wrong layer

          That's why the MIT people figured out how to switch off layer 2 retransmission to get their factor 20 gain in throughput (Google "coded tcp" to find the evidence). The work reported in this story seems to be along the same lines.

          It is along the same lines - the "TCP/NC" in the graph and article is TCP using Network Coding, which I believe is what you're referring to. This latest paper uses Fountain Coding instead, to reduce the computational complexity of decoding at the receiver, for two reasons: to accommodate receivers that have scarce CPU resources1, and to reduce latency caused by decoding2.

          1Whether they need to use the CPU sparingly to reduce power consumption (mobile) or just don't have much of a CPU in the first place (IoT).

          2Network Coding decoding involves solving a relatively difficult mathematical problem - Gaussian elimination in a Galois finite field - for each received message. There are various fountain codes, but e.g. Raptor codes (RFCs 5053, 6330) can also be decoded by Gaussian elimination, but less compute-intensive alternatives are available.

      2. yorksranter

        Re: Fixing at the wrong layer

        HSPA networks do this (HARQ)

      3. Henry Wertz 1 Gold badge

        Re: Fixing at the wrong layer

        "I was thinking the same - why is the wifi base station not able to cache a half second or so of recent packets and re-transmit them as needed as part of a wifi protocol?"

        It does. The default is 7 retransmissions of unacknowledged packets. Wifi is a harsh mistress, despite the retransmission mechanism it still has some degree of packet loss, particularly under poor RF conditions.

  3. Etherealmind

    firewalls/proxy/IDS - has to work with them

    Wont work through firewalls or other network security devices therefore the technology is a bust.

    1. Michael Wojcik Silver badge

      Re: firewalls/proxy/IDS - has to work with them

      Wont [sic] work through firewalls or other network security devices

      Citation needed.

      In fact, from the paper:

      The intermediate nodes do not have to be aware of the existence of the coding algorithms at the transport layer and do not have to take part into encoding or decoding.

      Their proposal is transparent to intermediate nodes.

      I realize actually looking at the paper before posting a vapid comment is above and beyond the call of duty, but it'd save you from looking like a fool.

  4. brooxta
    Unhappy

    "TCP/IP protocol"

    Grrrr.

POST COMMENT House rules

Not a member of The Register? Create a new account here.

  • Enter your comment

  • Add an icon

Anonymous cowards cannot choose their icon