From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail222c25.carrierzone.com (mail440c25.carrierzone.com [209.235.146.210]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by lists.bufferbloat.net (Postfix) with ESMTPS id C529A3B29D for ; Thu, 27 May 2021 03:42:53 -0400 (EDT) X-POP-User: hmurray@megapathdsl.net Feedback-ID: halmurray+buffe Received: from ip-64-139-1-69.sjc.megapath.net (ip-64-139-1-69.sjc.megapath.net [64.139.1.69]) by mail222c25.carrierzone.com (8.14.9/8.13.1) with ESMTP id 14R7gpri012526 for ; Thu, 27 May 2021 07:42:52 +0000 Received: from shuksan (localhost [127.0.0.1]) by ip-64-139-1-69.sjc.megapath.net (Postfix) with ESMTP id E8D8740605C; Thu, 27 May 2021 00:42:50 -0700 (PDT) X-Mailer: exmh version 2.7.2 01/07/2005 with nmh-1.3 To: bloat@lists.bufferbloat.net cc: Hal Murray From: Hal Murray Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Thu, 27 May 2021 00:42:50 -0700 Message-Id: <20210527074250.E8D8740605C@ip-64-139-1-69.sjc.megapath.net> X-CSC: 0 X-CHA: v=2.3 cv=M6Az1B4s c=1 sm=1 tr=0 a=OWgXOY7Tc8w5m7k7nGX6Zw==:117 a=OWgXOY7Tc8w5m7k7nGX6Zw==:17 a=kj9zAlcOel0A:10 a=5FLXtPjwQuUA:10 a=8Uh7sDRXC1Bi6_HA6DQA:9 a=CjuIK1q_8ugA:10 X-CTCH-RefID: str=0001.0A742F26.60AF4D7D.000C, ss=1, re=0.000, recu=0.000, reip=0.000, cl=1, cld=1, fgs=0 X-CTCH-VOD: Unknown X-CTCH-Spam: Unknown X-CTCH-Score: 0.000 X-CTCH-Rules: X-CTCH-Flags: 0 X-CTCH-ScoreCust: 0.000 X-Origin-Country: US Subject: Re: [Bloat] Educate colleges on tcp vs udp X-BeenThere: bloat@lists.bufferbloat.net X-Mailman-Version: 2.1.20 Precedence: list List-Id: General list for discussing Bufferbloat List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 27 May 2021 07:42:53 -0000 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.