Re: [Bloat] Educate colleges on tcp vs udp

Re: [Bloat] Educate colleges on tcp vs udp

[Hal Murray]

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.

Re: [Bloat] Educate colleges on tcp vs udp

[Jonathan Morton]

> On 27 May, 2021, at 10:42 am, Hal Murray <halmurray+bufferbloat@sonic.net> wrote:
> 
> 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.

You're right - the distinction between Bell and ARPA networking is a crucial foundation topic.

A discussion of the basic 10base Ethernet PHY (and how that fundamentally differs from the 8kHz multiplex of a traditional telephone network) might be helpful, since the intended audience already understands things like modulation.  Once that is established, you can talk about how reliable stream transports are implemented on top of an ARPA-style network, using Ethernet as a concrete example.

There are a lot of gritty details about how IP and TCP work that can be glossed over for a fundamental understanding, and maybe filled in later.  Things like Diffserv, the URG pointer, option fields, and socket timeouts are not relevant topics.  There's no need to actually hide them from a header diagram, but just highlight the fields that are fundamental to getting a payload from A to B.

 - Jonathan Morton

Re: [Bloat] Educate colleges on tcp vs udp

[Kenneth Porter]

On 5/27/2021 12:42 AM, Hal Murray wrote:
> 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.

UDP is also for unicast where late is just as bad as never. I've got an 
IoT sensor that unicasts readings to a PC that uses UDP in a 2-host network.

Compare to FireWire's isochronous connections that send unicast packets 
at a regular rate, intended for streaming media and commonly used for 
cameras.

[Bloat] Educate colleges on tcp vs udp

[Taraldsen Erik]

[-- Attachment #1: Type: text/plain, Size: 789 bytes --]

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.


-Erik

[-- Attachment #2: Type: text/html, Size: 1247 bytes --]

Re: [Bloat] Educate colleges on tcp vs udp

[Jonathan Morton]

> On 21 May, 2021, at 9:01 am, Taraldsen Erik <erik.taraldsen@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

Re: [Bloat] Educate colleges on tcp vs udp

[Erik Auerswald]

Hi,

On 23.05.21 12:23, Jonathan Morton wrote:
>> On 21 May, 2021, at 9:01 am, Taraldsen Erik <erik.taraldsen@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.
>> [...]
> 
> I don't have a video link to hand, but let's tease out the major differences between these three protocols:
> [...]
> 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).

As an additional point to consider when pondering whether to
use TCP or UDP:

To mitigate that simple request-response protocols using UDP
lend themselves to being abused for reflection and amplification
(DDoS) attacks, either the response should be smaller than the
request, or the protocol should require authentication, with
either silent discard of packets that are not correctly
authenticated, or at least a smaller error message (with rate
limit, please) to indicate an authentication failure.

Especially if the response needs to be larger than the request,
e.g., with DNS, a response rate limit should be applied.

Since basic TCP first establishes a connection using small
packets (SYN, SYN+ACK, ACK), it is less useful for reflection
attacks than UDP.

Thanks,
Erik

Re: [Bloat] Educate colleges on tcp vs udp

[Jonathan Morton]

> On 23 May, 2021, at 9:47 pm, Erik Auerswald <auerswal@unix-ag.uni-kl.de> wrote:
> 
> As an additional point to consider when pondering whether to
> use TCP or UDP:
> 
> To mitigate that simple request-response protocols using UDP
> lend themselves to being abused for reflection and amplification…

I suspect such considerations are well beyond the level of education requested here.  I think what was being asked for was "how do these protocols work, and why do they work that way, in language suitable for people working in a different field", rather than "which one should I use for X application".

 - Jonathan Morton

Re: [Bloat] Educate colleges on tcp vs udp

[Erik Auerswald]

Hi,

On 23.05.21 23:02, Jonathan Morton wrote:
>> On 23 May, 2021, at 9:47 pm, Erik Auerswald <auerswal@unix-ag.uni-kl.de> wrote:
>>
>> As an additional point to consider when pondering whether to
>> use TCP or UDP:
>>
>> To mitigate that simple request-response protocols using UDP
>> lend themselves to being abused for reflection and amplification…
> 
> I suspect such considerations are well beyond the level of education requested here.  I think what was being asked for was "how do these protocols work, and why do they work that way, in language suitable for people working in a different field", rather than "which one should I use for X application".

Yes, I do think so as well.

Nevertheless, I want to raise awareness of the risks
inherent in building protocols based on UDP.

As an optimist, I do believe that it may be possible
that in future less new protocols are created that
are useful for amplification attacks, by often raising
awareness of the risks and how to mitigate them.

I would have preferred if the current DDoS attacks using
STUN could have been avoided, by allowing standard
compliant STUN implementations to have an amplification
factor < 1, or at least ≤ 1, and by building response
rate limits into the standard.

(See, e.g., 
https://mail.jabber.org/pipermail/operators/2021-April/003130.html)

Thanks,
Erik

Re: [Bloat] Educate colleges on tcp vs udp

[Mark Andrews]

> On 24 May 2021, at 04:47, Erik Auerswald <auerswal@unix-ag.uni-kl.de> wrote:
> 
> Hi,
> 
> On 23.05.21 12:23, Jonathan Morton wrote:
>>> On 21 May, 2021, at 9:01 am, Taraldsen Erik <erik.taraldsen@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.
>>> [...]
>> I don't have a video link to hand, but let's tease out the major differences between these three protocols:
>> [...]
>> 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).
> 
> As an additional point to consider when pondering whether to
> use TCP or UDP:
> 
> To mitigate that simple request-response protocols using UDP
> lend themselves to being abused for reflection and amplification
> (DDoS) attacks, either the response should be smaller than the
> request, or the protocol should require authentication, with
> either silent discard of packets that are not correctly
> authenticated, or at least a smaller error message (with rate
> limit, please) to indicate an authentication failure.
> 
> Especially if the response needs to be larger than the request,
> e.g., with DNS, a response rate limit should be applied.

DNS supports authentication of clients, be it DNS COOKIE, TSIG or
SIG(0).  If your DNS clients are not using one of these you should
contact the vendor and request a update.

> Since basic TCP first establishes a connection using small
> packets (SYN, SYN+ACK, ACK), it is less useful for reflection
> attacks than UDP.
> 
> Thanks,
> Erik
> _______________________________________________
> Bloat mailing list
> Bloat@lists.bufferbloat.net
> https://lists.bufferbloat.net/listinfo/bloat

-- 
Mark Andrews, ISC
1 Seymour St., Dundas Valley, NSW 2117, Australia
PHONE: +61 2 9871 4742              INTERNET: marka@isc.org

Re: [Bloat] Educate colleges on tcp vs udp

[Erik Auerswald]

Hi Mark,

On 27.05.21 00:44, Mark Andrews wrote:
>> On 24 May 2021, at 04:47, Erik Auerswald <auerswal@unix-ag.uni-kl.de> wrote:
>> Especially if the response needs to be larger than the request,
>> e.g., with DNS, a response rate limit should be applied.
> 
> DNS supports authentication of clients, be it DNS COOKIE, TSIG or
> SIG(0).  If your DNS clients are not using one of these you should
> contact the vendor and request a update.

Most modern DNS server software, including ISC's BIND, implements
response rate limiting.

Thanks,
Erik

Re: [Bloat] Educate colleges on tcp vs udp

[Erik Auerswald]

Hi Erik,

On 21.05.21 08:01, Taraldsen Erik 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.

You could take a look at:

"Video Notes: Tanenbaum, Wetherall Computer Networks 5e"

https://media.pearsoncmg.com/ph/streaming/esm/tanenbaum5e_videonotes/tanenbaum_videoNotes.html

Specifically the sections "Transport Layer, Reliable Transport"
and "Congestion Control."

For reading material I can recommend "The TCP/IP Guide"
http://www.tcpipguide.com/ .

You can find a curated list of freely available networking
(i.e., packet switching and TCP/IP) textbooks in the section
"Textbooks and Other Books You Should Read" of the "How
Networks Really Work" webinars from Ivan Pepelnjak:

https://my.ipspace.net/bin/list?id=Net101#TEXTBOOK

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

Packet switching, and the transport services built on top,
e.g., TCP, are different from other information transport
systems.  They have evolved over decades and have become
quite complex, with surprising interactions (e.g., bufferbloat).

IP data over mobile networks is even more complex, and it
differs for the different mobile network generations.

Thus I do not think one should expect to really understand
it immediately.  Jumping right into the middle with TCP ACKs,
used for both reliability and flow control, and as part of
the congestion control scheme used on the Internet, without
looking at the fundamentals first, seems quite hard.

My advice, if I may, would be to view IP/TCP as something
new to your colleagues.  It would seem advisable to me to
start by learning the fundamentals.  This would most probably
require quite some time, though.

After achieving some confidence regarding the fundamentals,
I recommend taking a look at the four links from:
https://www.unix-ag.uni-kl.de/~auerswal/networkers_essential_reading/
(especially the paper "End-to-End Arguments in System Design"
http://web.mit.edu/Saltzer/www/publications/endtoend/endtoend.pdf).

HTH,
Erik

Re: [Bloat] Educate colleges on tcp vs udp

[Taraldsen Erik]

[-- Attachment #1: Type: text/plain, Size: 3165 bytes --]

Not a brilliant idea on my part to send a question to the list just hours before I go on a multiday trip without email access.  So this is a group thank you for all the responses - off and on list.  I'll need some time to review the response.



-Erik

________________________________
Fra: Erik Auerswald <auerswal@unix-ag.uni-kl.de>
Sendt: mandag 24. mai 2021 20.51.07
Til: Taraldsen Erik; bloat
Emne: Re: [Bloat] Educate colleges on tcp vs udp

Hi Erik,

On 21.05.21 08:01, Taraldsen Erik 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.

You could take a look at:

"Video Notes: Tanenbaum, Wetherall Computer Networks 5e"

https://media.pearsoncmg.com/ph/streaming/esm/tanenbaum5e_videonotes/tanenbaum_videoNotes.html

Specifically the sections "Transport Layer, Reliable Transport"
and "Congestion Control."

For reading material I can recommend "The TCP/IP Guide"
http://www.tcpipguide.com/ .

You can find a curated list of freely available networking
(i.e., packet switching and TCP/IP) textbooks in the section
"Textbooks and Other Books You Should Read" of the "How
Networks Really Work" webinars from Ivan Pepelnjak:

https://my.ipspace.net/bin/list?id=Net101#TEXTBOOK

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

Packet switching, and the transport services built on top,
e.g., TCP, are different from other information transport
systems.  They have evolved over decades and have become
quite complex, with surprising interactions (e.g., bufferbloat).

IP data over mobile networks is even more complex, and it
differs for the different mobile network generations.

Thus I do not think one should expect to really understand
it immediately.  Jumping right into the middle with TCP ACKs,
used for both reliability and flow control, and as part of
the congestion control scheme used on the Internet, without
looking at the fundamentals first, seems quite hard.

My advice, if I may, would be to view IP/TCP as something
new to your colleagues.  It would seem advisable to me to
start by learning the fundamentals.  This would most probably
require quite some time, though.

After achieving some confidence regarding the fundamentals,
I recommend taking a look at the four links from:
https://www.unix-ag.uni-kl.de/~auerswal/networkers_essential_reading/
(especially the paper "End-to-End Arguments in System Design"
http://web.mit.edu/Saltzer/www/publications/endtoend/endtoend.pdf).

HTH,
Erik

[-- Attachment #2: Type: text/html, Size: 4883 bytes --]

Re: [Bloat] Educate colleges on tcp vs udp

[Dave Taht]

I thought I did a good demo of ack behavior in this apnic video...

https://blog.apnic.net/2020/01/22/bufferbloat-may-be-solved-but-its-not-over-yet/

On Tue, May 25, 2021 at 1:38 AM Taraldsen Erik
<erik.taraldsen@telenor.no> wrote:
>
> Not a brilliant idea on my part to send a question to the list just hours before I go on a multiday trip without email access.  So this is a group thank you for all the responses - off and on list.  I'll need some time to review the response.
>
>
>
> -Erik
>
> ________________________________
> Fra: Erik Auerswald <auerswal@unix-ag.uni-kl.de>
> Sendt: mandag 24. mai 2021 20.51.07
> Til: Taraldsen Erik; bloat
> Emne: Re: [Bloat] Educate colleges on tcp vs udp
>
> Hi Erik,
>
> On 21.05.21 08:01, Taraldsen Erik 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.
>
> You could take a look at:
>
> "Video Notes: Tanenbaum, Wetherall Computer Networks 5e"
>
> https://media.pearsoncmg.com/ph/streaming/esm/tanenbaum5e_videonotes/tanenbaum_videoNotes.html
>
> Specifically the sections "Transport Layer, Reliable Transport"
> and "Congestion Control."
>
> For reading material I can recommend "The TCP/IP Guide"
> http://www.tcpipguide.com/ .
>
> You can find a curated list of freely available networking
> (i.e., packet switching and TCP/IP) textbooks in the section
> "Textbooks and Other Books You Should Read" of the "How
> Networks Really Work" webinars from Ivan Pepelnjak:
>
> https://my.ipspace.net/bin/list?id=Net101#TEXTBOOK
>
> > 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.
>
> Packet switching, and the transport services built on top,
> e.g., TCP, are different from other information transport
> systems.  They have evolved over decades and have become
> quite complex, with surprising interactions (e.g., bufferbloat).
>
> IP data over mobile networks is even more complex, and it
> differs for the different mobile network generations.
>
> Thus I do not think one should expect to really understand
> it immediately.  Jumping right into the middle with TCP ACKs,
> used for both reliability and flow control, and as part of
> the congestion control scheme used on the Internet, without
> looking at the fundamentals first, seems quite hard.
>
> My advice, if I may, would be to view IP/TCP as something
> new to your colleagues.  It would seem advisable to me to
> start by learning the fundamentals.  This would most probably
> require quite some time, though.
>
> After achieving some confidence regarding the fundamentals,
> I recommend taking a look at the four links from:
> https://www.unix-ag.uni-kl.de/~auerswal/networkers_essential_reading/
> (especially the paper "End-to-End Arguments in System Design"
> http://web.mit.edu/Saltzer/www/publications/endtoend/endtoend.pdf).
>
> HTH,
> Erik
> _______________________________________________
> Bloat mailing list
> Bloat@lists.bufferbloat.net
> https://lists.bufferbloat.net/listinfo/bloat



-- 
Latest Podcast:
https://www.linkedin.com/feed/update/urn:li:activity:6791014284936785920/

Dave Täht CTO, TekLibre, LLC

Re: [Bloat] Educate colleges on tcp vs udp

[Taraldsen Erik]

[-- Attachment #1: Type: text/plain, Size: 4303 bytes --]

Brilliant demo.  :)


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.


-Erik

________________________________
Fra: Dave Taht <dave.taht@gmail.com>
Sendt: onsdag 26. mai 2021 20.09.44
Til: Taraldsen Erik
Kopi: Erik Auerswald; bloat
Emne: Re: [Bloat] Educate colleges on tcp vs udp

I thought I did a good demo of ack behavior in this apnic video...

https://blog.apnic.net/2020/01/22/bufferbloat-may-be-solved-but-its-not-over-yet/

On Tue, May 25, 2021 at 1:38 AM Taraldsen Erik
<erik.taraldsen@telenor.no> wrote:
>
> Not a brilliant idea on my part to send a question to the list just hours before I go on a multiday trip without email access.  So this is a group thank you for all the responses - off and on list.  I'll need some time to review the response.
>
>
>
> -Erik
>
> ________________________________
> Fra: Erik Auerswald <auerswal@unix-ag.uni-kl.de>
> Sendt: mandag 24. mai 2021 20.51.07
> Til: Taraldsen Erik; bloat
> Emne: Re: [Bloat] Educate colleges on tcp vs udp
>
> Hi Erik,
>
> On 21.05.21 08:01, Taraldsen Erik 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.
>
> You could take a look at:
>
> "Video Notes: Tanenbaum, Wetherall Computer Networks 5e"
>
> https://media.pearsoncmg.com/ph/streaming/esm/tanenbaum5e_videonotes/tanenbaum_videoNotes.html
>
> Specifically the sections "Transport Layer, Reliable Transport"
> and "Congestion Control."
>
> For reading material I can recommend "The TCP/IP Guide"
> http://www.tcpipguide.com/ .
>
> You can find a curated list of freely available networking
> (i.e., packet switching and TCP/IP) textbooks in the section
> "Textbooks and Other Books You Should Read" of the "How
> Networks Really Work" webinars from Ivan Pepelnjak:
>
> https://my.ipspace.net/bin/list?id=Net101#TEXTBOOK
>
> > 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.
>
> Packet switching, and the transport services built on top,
> e.g., TCP, are different from other information transport
> systems.  They have evolved over decades and have become
> quite complex, with surprising interactions (e.g., bufferbloat).
>
> IP data over mobile networks is even more complex, and it
> differs for the different mobile network generations.
>
> Thus I do not think one should expect to really understand
> it immediately.  Jumping right into the middle with TCP ACKs,
> used for both reliability and flow control, and as part of
> the congestion control scheme used on the Internet, without
> looking at the fundamentals first, seems quite hard.
>
> My advice, if I may, would be to view IP/TCP as something
> new to your colleagues.  It would seem advisable to me to
> start by learning the fundamentals.  This would most probably
> require quite some time, though.
>
> After achieving some confidence regarding the fundamentals,
> I recommend taking a look at the four links from:
> https://www.unix-ag.uni-kl.de/~auerswal/networkers_essential_reading/
> (especially the paper "End-to-End Arguments in System Design"
> http://web.mit.edu/Saltzer/www/publications/endtoend/endtoend.pdf).
>
> HTH,
> Erik
> _______________________________________________
> Bloat mailing list
> Bloat@lists.bufferbloat.net
> https://lists.bufferbloat.net/listinfo/bloat



--
Latest Podcast:
https://www.linkedin.com/feed/update/urn:li:activity:6791014284936785920/

Dave Täht CTO, TekLibre, LLC

[-- Attachment #2: Type: text/html, Size: 6668 bytes --]