5 ms·

Beyond TCP: The evolution of Internet transport protocols

71 points by jsnell 11y ago

ElijahLynn 11y ago
Is there a recording? Slides only supply maybe 50% of the information needed to form the picture. If the accompanying spoken words are left out then it is difficult to receive the message as intended.
- norswap 11y ago
  There are no recordings, I asked. There's this presentation at the IETF: https://www.youtube.com/watch?v=Wp0Kr3B64tA https://www.youtube.com/watch?v=Wp0Kr3B64tA These are not the same slides, but it should tell you all you want to know about Multipath TCP.
AndrewDucker 11y ago
It really annoys me that some routing systems drop packets that use any protocol other than TCP/UDP. It makes innovation of new protocols basically impossible.
- jayflux 11y ago
  Do you have any more info on this? What protocols are being dropped? And which routing systems are dropping them Just curious
  - unethical_ban 11y ago
    Many firewalls filter out non-TCP/non-UDP traffic as a matter of policy. Heck, network professionals are having to be reminded NOT to block all ICMPv6 on their border (like they do for v4).
    - digitalsushi 11y ago
      This generally occurs far enough down the stream that it's only a matter of bopping a clueless senior netop on the head. Nothing upstream is going to block arbitrary packet types. Could you imagine if backbone peers were dropping packets like that? The internet "routes around the damage" and this would be an application of that. At the social level, it would involve people within an org saying "fix this".
      - noselasd 11y ago
        Pretty much every router/modem people have at home does NAT, and does so for UDP, TCP, ICMP and some do GRE and that's it. And they're not getting updated to NAT any new protocol directly over IP that people come up with.
  - AndrewDucker 11y ago
    See slide 22.
jorangreef 11y ago
One of the major problems with TCP often not mentioned is bufferbloat. TCP's common congestion avoidance algorithms usually have no precautions against bufferbloat and frequently induce it, i.e. when probing the congestion window. And those TCP congestion avoidance algorithms which do manage bufferbloat are often not deployed in public for fear of losing out to greedy congestion algorithms. QUIC uses fundamentally the same basic congestion avoidance algorithm as TCP (QUIC's algorithm is a work in progress AFAIK) so even QUIC is still in the same bloat. The problem eventually bubbles up the stack and affects most web applications, so that a single user, just using a web application on one machine, can break the Internet for all other users on the same LAN. Try this demo for yourself: 1. Run "ping google.com" from another computer on your LAN. 2. Upload a 10-20MB file via Gmail or Dropbox from your computer. 3. Watch the ping times on the other computer skyrocket from around 100ms to upwards of 5-10 seconds. 4. Try a Google search from any other computer on your LAN while this is happening. Web applications which use protocols such as WebSockets have no way to reduce the bufferbloat footprint of their application, other than re-implement their own delay sensitive congestion avoidance algorithm on top. And actually, if you want to build a robust application which does any uploading (or plenty of downloading), this is what you need to do. For example, to prevent inducing bufferbloat, Apple's software update actually uses a variant of LEDBAT (the delay sensitive congestion avoidance algorithm from BitTorrent's protocol) when downloading software updates.
- stplsd 11y ago
  Shouldn't RED type algorithms in routers prevent buffer bloat?
  - jorangreef 11y ago
    It may help for other users on the LAN but it's going to be years before it's fully deployed. It's not the solution for today. In any event, I don't think it's going to make any inroads towards fixing bufferbloat for a single user on the same machine, i.e. where multiple applications are creating several seconds of bufferbloat each, the latency sensitive applications (Skype, Google searches, typical web browsing) are still all going to suffer. I think it's actually not a router issue but an application issue, in the same sense that CPU overusage by one application is an application issue. Applications just need to be better designed to not bloat a user's network. Hopefully, the next major Apple OS update will include bufferbloat measurements in Activity Monitor, so offending apps can be named and shamed. But even this won't prevent web apps from having massive bufferbloat footprints (for that the browsers will need to share data with Activity Monitor, or highlight this to the user). After this, I think pressure from users on application developers to reduce bufferbloat footprint and build network efficient apps is the way forward. Then we will be able to switch to some of the better higher-bandwidth TCP congestion avoidance algorithms without having to settle for algorithms which ignore latency as a congestion signal (packet loss is a poor signal and causes throughput to saw-tooth).
gkfasdfasdf 11y ago
I wonder why SCTP over UDP was not mentioned. This solves the problem of routers dropping unrecognized protocols.
jMyles 11y ago
I wish for a HN URL replacement algorithm that replaces decks with talk videos.

71 points by jsnell 11y ago

Is there a recording? Slides only supply maybe 50% of the information needed to form the picture. If the accompanying spoken words are left out then it is difficult to receive the message as intended.

norswap 11y ago
There are no recordings, I asked. There's this presentation at the IETF: https://www.youtube.com/watch?v=Wp0Kr3B64tA https://www.youtube.com/watch?v=Wp0Kr3B64tA These are not the same slides, but it should tell you all you want to know about Multipath TCP.

AndrewDucker 11y ago

It really annoys me that some routing systems drop packets that use any protocol other than TCP/UDP. It makes innovation of new protocols basically impossible.

jayflux 11y ago
Do you have any more info on this? What protocols are being dropped? And which routing systems are dropping them Just curious
- unethical_ban 11y ago
  Many firewalls filter out non-TCP/non-UDP traffic as a matter of policy. Heck, network professionals are having to be reminded NOT to block all ICMPv6 on their border (like they do for v4).
  - digitalsushi 11y ago
    This generally occurs far enough down the stream that it's only a matter of bopping a clueless senior netop on the head. Nothing upstream is going to block arbitrary packet types. Could you imagine if backbone peers were dropping packets like that? The internet "routes around the damage" and this would be an application of that. At the social level, it would involve people within an org saying "fix this".
    - noselasd 11y ago
      Pretty much every router/modem people have at home does NAT, and does so for UDP, TCP, ICMP and some do GRE and that's it. And they're not getting updated to NAT any new protocol directly over IP that people come up with.
- AndrewDucker 11y ago
  See slide 22.

jorangreef 11y ago

One of the major problems with TCP often not mentioned is bufferbloat. TCP's common congestion avoidance algorithms usually have no precautions against bufferbloat and frequently induce it, i.e. when probing the congestion window. And those TCP congestion avoidance algorithms which do manage bufferbloat are often not deployed in public for fear of losing out to greedy congestion algorithms. QUIC uses fundamentally the same basic congestion avoidance algorithm as TCP (QUIC's algorithm is a work in progress AFAIK) so even QUIC is still in the same bloat. The problem eventually bubbles up the stack and affects most web applications, so that a single user, just using a web application on one machine, can break the Internet for all other users on the same LAN. Try this demo for yourself: 1. Run "ping google.com" from another computer on your LAN. 2. Upload a 10-20MB file via Gmail or Dropbox from your computer. 3. Watch the ping times on the other computer skyrocket from around 100ms to upwards of 5-10 seconds. 4. Try a Google search from any other computer on your LAN while this is happening. Web applications which use protocols such as WebSockets have no way to reduce the bufferbloat footprint of their application, other than re-implement their own delay sensitive congestion avoidance algorithm on top. And actually, if you want to build a robust application which does any uploading (or plenty of downloading), this is what you need to do. For example, to prevent inducing bufferbloat, Apple's software update actually uses a variant of LEDBAT (the delay sensitive congestion avoidance algorithm from BitTorrent's protocol) when downloading software updates.

stplsd 11y ago
Shouldn't RED type algorithms in routers prevent buffer bloat?
- jorangreef 11y ago
  It may help for other users on the LAN but it's going to be years before it's fully deployed. It's not the solution for today. In any event, I don't think it's going to make any inroads towards fixing bufferbloat for a single user on the same machine, i.e. where multiple applications are creating several seconds of bufferbloat each, the latency sensitive applications (Skype, Google searches, typical web browsing) are still all going to suffer. I think it's actually not a router issue but an application issue, in the same sense that CPU overusage by one application is an application issue. Applications just need to be better designed to not bloat a user's network. Hopefully, the next major Apple OS update will include bufferbloat measurements in Activity Monitor, so offending apps can be named and shamed. But even this won't prevent web apps from having massive bufferbloat footprints (for that the browsers will need to share data with Activity Monitor, or highlight this to the user). After this, I think pressure from users on application developers to reduce bufferbloat footprint and build network efficient apps is the way forward. Then we will be able to switch to some of the better higher-bandwidth TCP congestion avoidance algorithms without having to settle for algorithms which ignore latency as a congestion signal (packet loss is a poor signal and causes throughput to saw-tooth).

gkfasdfasdf 11y ago

I wonder why SCTP over UDP was not mentioned. This solves the problem of routers dropping unrecognized protocols.

jMyles 11y ago

I wish for a HN URL replacement algorithm that replaces decks with talk videos.