
Beyond TCP: The evolution of Internet transport protocols - jsnell
http://www.slideshare.net/obonaventure/beyond-tcp-the-evolution-of-internet-transport-protocols
======
jorangreef
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
Shouldn't RED type algorithms in routers prevent buffer bloat?

~~~
jorangreef
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).

~~~
stplsd
Maybe I misunderstood your first message about 'buffer bloat'. I was thinking
about buffer bloat in routers/switches when many TCP connection start to send
packet, router starts to buffer them, once packets are dropped, congestion
avoidance in TCP connections is activated and synchronises - bandwidth goes
down and once again increases in all TCP connections, and this cycle (more
packets are sent/packet drops/congestion avoidance triggered) repeats again.

~~~
noselasd
Note that bufferbloat is a problem regardless of there being many or few TCP
connections.

------
ElijahLynn
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
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
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
Do you have any more info on this? What protocols are being dropped? And which
routing systems are dropping them Just curious

~~~
unethical_ban
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
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
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.

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

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

