[Bloat] Educate colleges on tcp vs udp

[Jonathan Morton]

> On 21 May, 2021, at 9:01 am, Taraldsen Erik <erik.taraldsen at telenor.no> wrote:
> 
> I'm getting some traction with my colleges in the Mobile department on measurements to to say something about user experience.  While they are coming around to the idea, they have major gaps in tcp/udp/ip understanding.  I don't have the skill or will to try and educate them.
> 
> Is there good education out there - preferably in the form of an video - which I can send to my co workers?  The part of tcp using ack's is pure magic to them.  They really struggle to grasp the concept.  With so basic lack of understanding it is hard to have a meaningful discussion about loss, latency an buffering.
> 
> I don't mean to talk them down to much, they are really good with the radio part of their job - but the transition into seeing tcp and radio together is very hard on them.

I don't have a video link to hand, but let's tease out the major differences between these three protocols:

IP (in both v4 and v6 variants) is all about getting a package of data to a particular destination.  It works rather like a postal system.  The package has a sender's address and a recipient's address, and the routers take care of getting it to the latter.  Most packages get through, but for various reasons some packages can be lost, for example if the sorting office (queue) is full of traffic.  Some packages are very small (eg. a postcard), some very large (eg. a container load), and some in between.

UDP is an "unreliable datagram" protocol.  You package it up in an IP wrapper, send it, and *usually* it gets to the recipient.  It has an additional "office" address, as the postal system only gets the package to the right building.  If it doesn't arrive, you don't get any notification about that - which is why it is "unreliable".  Each package also stands on its own without any relationship to others, which is why it is a "datagram".  Most UDP packets are small to medium in size.

TCP is a "reliable stream" protocol.  You use it when you have a lot of data to send, which won't fit into a single datagram, or when you need to know whether your data arrived safely or not.  To do this, you use the biggest, container-sized packages the post office supports, and you number them in sequence so you know which ones come first.  The recipient and the post office both have regulations so you can't have too many of these huge packages in the system at once, and they reserve the right to discard the excess so they can function properly (this is "congestion control").  So you arrange for the recipient to send the containers back empty when they've been received (they collapse to a small size when empty), and then you know there's room in the system for it to be sent out full again, with a fresh sequence number (this is the "stream").  And if you notice that a particular container *didn't* come back in the expected sequence, you infer that it got lost somewhere and send a replacement for its contents (making the delivery "reliable").

In fact, the actual containers are not sent back, but an acknowledgement postcard basically saying "all containers up to XXX arrived safely, we have room for YYY more, and the post office told us to tell you to slow down the sending rate because they're getting overwhelmed."  Some of these postcards may themselves get lost in the system, but as long as some *do* get through, the sender knows all is well.

It's common to use TCP for transferring files or establishing a persistent command-and-control connection.  It's common to use UDP for simple request-response applications (where both the request and response are small) and where timeliness of delivery is far more important than reliability (eg. multiplayer games, voice/video calls).

 - Jonathan Morton