General list for discussing Bufferbloat
 help / color / mirror / Atom feed
From: Hal Murray <halmurray+bufferbloat@sonic.net>
To: bloat@lists.bufferbloat.net
Cc: Hal Murray <halmurray+bufferbloat@sonic.net>
Subject: Re: [Bloat] Educate colleges on tcp vs udp
Date: Thu, 27 May 2021 00:42:50 -0700	[thread overview]
Message-ID: <20210527074250.E8D8740605C@ip-64-139-1-69.sjc.megapath.net> (raw)


Erik Auerswald said:
> But I'm afraid the "learn tcp" part works more as a refresher than an
> introduction.  Remember this is the first meeting with an ack for most of my
> co workers.  To get the proper understanding I think the basics must be more
> hammered into them.

My 2 cents.

I would back up.  You need to understand how networks work before discussing 
TCP or UDP.

The internet is not like a phone system.  There are no connections within the 
network and hence no reserved bandwidth and nothing like a busy signal to tell 
you that the network is full.  (There are host-host connections, but the 
network doesn't know anything about them.)  Packets are delivered on a 
best-efforts basis.  They may be dropped, delayed, mangled, or duplicated.

Links have a max size packet they will support.  (MTU)  If you want to send 
larger data, the sender needs to break it down into packets that will fit and 
the receiver needs to put things back together.

A key concept is the bottleneck link.  If all the links are the same speed and 
there is no competing traffic, then the rest of network can deliver whatever 
the sending host can send.

There are two ways to get a bottleneck.  One is to have the outgoing link of a 
router be slower than the incoming link.  The other is to have some other 
traffic using one of the links your traffic is trying to use.

If you send faster than the bottleneck can support, the buffers will fill up.  
If packets arrive when the buffers are full, some packet will get dropped.  
(not necessarily the new one)

For something like FTP, and additional potential bottleneck is the software on 
the remote host.  Can it write to disk as fast as you can send over the 
network?

TCP is for things like FTP and web browsing - transferring large chunks of 
data.  UDP is for simple things like NTP or DNS.  TCP is generally implemented 
in the kernel.  UDP retransmissions are generally implemented by user code.

The hard part of TCP is figuring out how much traffic the bottleneck link can 
handle and keeping track as it changes.


-- 
These are my opinions.  I hate spam.




             reply	other threads:[~2021-05-27  7:42 UTC|newest]

Thread overview: 14+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2021-05-27  7:42 Hal Murray [this message]
2021-05-27 12:15 ` Jonathan Morton
2021-05-27 22:17 ` Kenneth Porter
  -- strict thread matches above, loose matches on Subject: below --
2021-05-21  6:01 Taraldsen Erik
2021-05-23 10:23 ` Jonathan Morton
2021-05-23 18:47   ` Erik Auerswald
2021-05-23 21:02     ` Jonathan Morton
2021-05-23 21:42       ` Erik Auerswald
2021-05-26 22:44     ` Mark Andrews
2021-05-27  3:11       ` Erik Auerswald
2021-05-24 18:51 ` Erik Auerswald
2021-05-25  6:38   ` Taraldsen Erik
2021-05-26 18:09     ` Dave Taht
2021-05-27  6:32       ` Taraldsen Erik

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

  List information: https://lists.bufferbloat.net/postorius/lists/bloat.lists.bufferbloat.net/

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20210527074250.E8D8740605C@ip-64-139-1-69.sjc.megapath.net \
    --to=halmurray+bufferbloat@sonic.net \
    --cc=bloat@lists.bufferbloat.net \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox