<html><head><meta http-equiv="Content-Type" content="text/html; charset=UTF-8"></head><body style="zoom: 0%;"><div dir="auto">We in semiconductors test TCP on hundreds of test rigs and multiple operating systems, use statistical process controls before sending our chips, and support sw to system integrators or device manufacturers. Then, those companies do their work and test more before shipping to their customers. There is a lot of testing baked in now. If not, billions of TCP state machines wouldn't function nor interoperate. And people then wouldn't buy these products as networks are essential infrastructure.<br><br></div>
<div dir="auto">Reading the code doesn't really work for this class of problem. Code reviews are good in human processes, but escapes are quite high. Computers have to engage too and are now doing the heavy lifting <br><br></div>
<div dir="auto">Bob</div>
<div class="gmail_quote" >On Oct 16, 2023, at 10:21 AM, Spencer Sevilla via Nnagain <<a href="mailto:nnagain@lists.bufferbloat.net" target="_blank">nnagain@lists.bufferbloat.net</a>> wrote:<blockquote class="gmail_quote" style="margin: 0pt 0pt 0pt 0.8ex; border-left: 1px solid rgb(204, 204, 204); padding-left: 1ex;">
That Flakeway tool makes me think of an early version of the Chaos Monkey. To that note, Apple maintains a developer tool called Network Link Conditioner that does a good job simulating reduced network performance.
<br>
<div>
<br>
<blockquote type="cite">
<div>
On Oct 15, 2023, at 23:30, Jack Haverty via Nnagain <nnagain@lists.bufferbloat.net> wrote:
</div>
<br class="Apple-interchange-newline">
<div>
<div>
Even back in 1978, I didn't think Source Quench would work. I recall that I was trying to adapt my TCP2.5 Unix implementation to become TCP4, and I asked what my TCP should do if it sent the first IP datagram to open a TCP connection and received a Source Quench. It wasn't clear at all how I should "slow down". Other TCP implementors took the receipt of an SQ as an indication that a datagram they had sent had been discarded, so the obvious reaction for user satisfaction was to retransmit immediately. Slowing down would simply degrade their user's experience.
<br>
<br>
Glad to hear SQ is gone. I hope whatever replaced it works.
<br>
<br>
There's some confusion about the Arpanet. The Arpanet was known as a "packet switching network", but it had lots of internal mechanisms that essentially created virtual circuits between attached computers. Every packet sent in to the network by a user computer came out at the destination intact, in order, and not duplicated or lost. The Arpanet switches even had a hardware mechanism for flow control; a switch could halt data transfer from a user computer when necessary. During the 80s, the Arpanet evolved to have an X.25 interface, and operated as a true "virtual circuit" provider. Even in the Defense Data Network (DDN), the network delivered a virtual circuit service. The attached users' computers had TCP, but the TCP didn't need to deal with most of the network behavior that TCP was designed to handle. Congestion was similarly handled by internal Arpanet mechanisms (there were several technical reports from BBN to ARPA with details). I don't remember any time that "an <span style="white-space: pre-wrap">explicit ack for every packet was ripped out of the arpanet"</span> None of those events happened when two TCP computers were connected to the Arpanet.
<br>
<br>
The Internet grew up around the Arpanet, which provided most of the wide-area connectivity through the mid-80s. Since the Arpanet provided the same "reliable byte stream" behavior as TCP provided, and most user computers were physically attached to an Arpanet switch, it wasn't obvious how to test a TCP implementation, to see how well it dealt with reordering, duplication, dropping, or corruption of IP datagrams.
<br>
<br>
We (at BBN) actually had to implement a software package called a "Flakeway", which ran on a SparcStation. Using a "feature" of Ethernets and ARP (some would call it a vulnerability), the Flakeway could insert itself invisibly in the stream of datagrams between any two computers on that LAN (e.g., between a user computer and the gateway/router providing a path to other sites). The Flakeway could then simulate "real" Internet behavior by dropping, duplicating, reordering, mangling, delaying, or otherwise interfering with the flow. That was extremely useful in testing and diagnosing TCP implementations.
<br>
<br>
I understand that there has been a lot of technical work over the years, and lots of new mechanisms defined for use in the Internet to solve various problems. But one issue that has not been addressed -- how do you know whether or not some such mechanism has actually been implemented, and configured correctly, in the millions of devices that are now using TCP (and UDP, IP, etc.)? AFAIK, there's no way to tell unless you can examine the actual code.
<br>
<br>
The Internet, and TCP, was an experiment. One aspect of that experiment involved changing the traditional role of a network "switch", and moving mechanisms for flow control, error control, and other mechanisms used to create a "virtual circuit" behavior. Instead of being implemented inside some switching equipment, TCP's mechanisms are implemented inside users' computers. That was a significant break from traditional network architecture.
<br>
<br>
I didn't realize it at the time, but now, with users' devices being uncountable handheld or desktop computers rather than huge racks in relatively few data centers, moving all those mechanisms from switches to users' computers significantly complicates the system design and especially operation.
<br>
<br>
That may be one of the more important results of the long-running experiment.
<br>
<br>
Jack Haverty
<br>
<br>
<div class="moz-cite-prefix">
On 10/15/23 18:39, Dave Taht wrote:
<br>
</div>
<blockquote type="cite" cite="mid:CAA93jw5LBgm3JYdxyv8LQNXgFBX7aYr53gjH-XZACV__WkBzQw@mail.gmail.com">
<pre class="moz-quote-pre" wrap="">It is wonderful to have your original perspectives here, Jack.
But please, everyone, before a major subject change, change the subject?
Jack's email conflates a few things that probably deserve other
threads for them. One is VGV - great acronym! Another is about the
"Placeholders" of TTL, and TOS. The last is the history of congestion
control - and it's future! As being a part of the most recent episodes
here I have written extensively on the subject, but what I most like
to point people to is my fun talks trying to make it more accessible
like this one at apnic
<a class="moz-txt-link-freetext" href="https://blog.apnic.net/2020/01/22/bufferbloat-may-be-solved-but-its-not-over-yet/">https://blog.apnic.net/2020/01/22/bufferbloat-may-be-solved-but-its-not-over-yet/</a>
or my more recent one at tti/vanguard.
Most recently one of our LibreQos clients has been collecting 10ms
samples and movies of what real-world residential traffic actually
looks like:
<a class="moz-txt-link-freetext" href="https://www.youtube.com/@trendaltoews7143">https://www.youtube.com/@trendaltoews7143</a>
And it is my hope that that conveys intuition to others... as compared
to speedtest traffic, which prove nothing about the actual behaviors
of VGV traffic, which I ranted about here:
<a class="moz-txt-link-freetext" href="https://blog.cerowrt.org/post/speedtests/">https://blog.cerowrt.org/post/speedtests/</a> - I am glad that these
speedtests now have latency under load reports almost universally, but
see the rant for more detail.
Most people only have a picture of traffic in the large, over 5 minute
intervals, which behaves quite differently, or a pre-conception that
backpressure actually exists across the internet. It doesn't. An
explicit ack for every packet was ripped out of the arpanet as costing
too much time. Wifi, to some extent, recreates the arpanet problem by
having explicit acks on the local loop that are repeated until by god
the packet comes through, usually without exponential backoff.
We have some really amazing encoding schemes now - I do not understand
how starlink works without retries for example, an my grip on 5G's
encodings is non-existent, except knowing it is the most bufferbloated
of all our technologies.
...
Anyway, my hope for this list is that we come up with useful technical
feedback to the powers-that-be that want to regulate the internet
under some title ii provisions, and I certainly hope we can make
strides towards fixing bufferbloat along the way! There are many other
issues. Let's talk about those instead!
But...
...
In "brief" response to the notes below - source quench died due to
easy ddos, AQMs from RED (1992) until codel (2012) struggled with
measuring the wrong things ( Kathie's updated paper on red in a
different light: <a class="moz-txt-link-freetext" href="https://pollere.net/Codel.html">https://pollere.net/Codel.html</a> ), SFQ was adopted by
</pre>
</blockquote>
</div>
</div>
</blockquote>
</div></blockquote></div></body></html>