[Bloat] Fwd: [ih] booting linux on a 4004
Dave Taht
dave.taht at gmail.com
Thu Oct 10 09:04:28 EDT 2024
vintage van jacobson rant from 1987, from a raging debate on the always
excellent internet-history mailing list.
---------- Forwarded message ---------
From: Craig Partridge via Internet-history <internet-history at elists.isoc.org
>
Date: Thu, Oct 10, 2024 at 5:53 AM
Subject: Re: [ih] booting linux on a 4004
To: Greg Skinner <gregskinner0 at icloud.com>
Cc: Vint Cerf via Internet-history <internet-history at elists.isoc.org>
Hi Greg:
Thanks for correcting my faulty memory. As partial recompense for being
wrong, I'll note I have a partial set of the end2end-interest archives if
there are questions. As recompense for my error, I offer the following
tidbit:
Posted-Date: Tue, 31 Mar 87 17:58:17 PST
To: Craig Partridge <craig at LOKI.BBN.COM>
Cc: end2end-tf at venera.isi.edu
Subject: Re: Thinking about Congestion
In-Reply-To: Your message of Fri, 27 Mar 87 08:43:19 EST.
Date: Tue, 31 Mar 87 17:58:17 PST
From: Van Jacobson <van at lbl-csam.ARPA>
Craig -
Your note pushed one of my buttons: Sending a lot of data
into a congested network doesn't improve transmit efficiency
any more than disconnecting the collision detect wire on
your ethernet would. Either action makes everyone on the net,
including you, lose.
There is always an optimum window size but computing it requires
knowing how packet loss scales with window size. To first order,
the scaling will be the exponential (1 - A)^W where W is the
window size and A is a network dependent constant (0 < A < 1).
For a long haul net, no-loss throughput will scale with window
size like W/T where T is the round trip time. The effective
throughput will go like the product of these two terms. For
small W the linear term dominates and you see linear throughput
increase with increasing window size. For large W the loss term
dominates and you see exponential throughput decrease with
increasing window size. For small A (low loss rates), the
optimum window size will scale like -1/log(1-a).
It's possible to do a more exact analysis. A few years ago a
friend of mine was working on a tcp/ip implementation for a well
known supercomputer manufacturer. At the time there was a huge
debate in the company on whether to "modify" tcp. It seems that
some cretin in management had decided that the only way to get
good network performance was to do huge transfers, where "huge"
was much larger than the 64K allowed by the tcp window size
field. I was simulating very high performance fiber optic nets
at the time and found this argument to be completely at odds with
my results. I was so incensed that I wrote a little 5 page paper
for my friend titled "Some notes on choosing an optimum transfer
size" that started out:
"The choice of network transfer size seems to have been
driven by the idea that ``bigger is better''. While this
reflects a good, American upbringing, it bears only faint
resemblance to reality. In the unlikely event that a future
decision is made on rational grounds, this note describes the
mathematical basis for choice of window and transfer size."
I'm afraid it went on in much the same tone (I must have been
drunk when I wrote it) but I did summarize how to apply Erlang's
and Hill's loss functions to tcp (the same analysis would apply
to rdp - the only difference is rdp gains a factor of two in
throughput over tcp at very high loss rates). If you're
interested in the math, I'd be glad to send you extracts from
this thing or the references I used.
- Van
On Thu, Oct 10, 2024 at 12:47 AM Greg Skinner <gregskinner0 at icloud.com>
wrote:
>
> On Oct 5, 2024, at 5:42 PM, Craig Partridge <craig at tereschau.net> wrote:
>
>
> As someone who was in touch with Raj/KK and Van/Mike during the
> development of congestion control. They were unaware of each other's work
> until spring of 1988, when they realized they were doing very similar
> stuff. I think, someone (Dave Clark) in the End2End Research Group became
> aware of Raj & KK's work and invited them to come present to an E2E
meeting
> in early 1988 and E2E (more than IETF) was where Van was working out the
> kinks in his congestion control work with Mike.
>
> Craig
>
>
> I looked into this a bit, and discovered that Raj/KK and Van/Mike were all
> at the 6th IETF, which took place in April 1987. [1] (It was a joint
> meeting of the IETF and ANSI X3S3.3 Network and Transport Layer standards
> groups.) Both teams presented their work at the meeting.
>
> On Sat, Oct 5, 2024 at 5:34 PM John Day via Internet-history <
> internet-history at elists.isoc.org> wrote:
>
>> The work of Jain’s DEC team existed at the same time and I believe
>> Jacobson’s original paper references it.
>>
>> As I said, at least it does congestion avoidance without causing
>> congestion (unless under extreme conditions).
>>
>> I suspect that the main reason Jacobson didn’t adopt it was that they
>> were trying to maximize the data rate by running as close to congestion
>> collapse as they could. While Jain’s work attempted to balance the
>> trade-off between throughput and response time. But that is just policy
>> they still could have used ECN to keep from being predatory and used ECN
>> while waiting until the queue is full to mark the packets. That is what
TCP
>> use of ECN does now. Of course, I think that is bad choice because it
>> generates lots of retransmissions.
>>
>>
> Some of the reasons why Van/Mike took the approach they did were discussed
> in a email message Van sent to the tcp-ip list. It included some
> discussions that had taken place on the ietf and end2end-interest lists.
> [2] IMO, it’s unfortunate that the existing archives of those lists,
> because we would be able to read the points of view expressed by the list
> participants.
>
> When I asked Jain why his wasn’t adopted, he said he isn’t an implementor,
>> but an experimenter.
>>
>> But it is not uncommon to be so focused on the immediate problem to fail
>> to notice the system implications.
>>
>
> John, what could they have done that would have met your criteria and
> yielded a deployable solution to the congestion problems existing at that
> time in the timeframe that it was needed? IMO, their paper should be
> assessed in that context.
>
> --gregbo
>
> [1] https://www.ietf.org/proceedings/06.pdf
> [2] https://ee.lbl.gov/tcp.html
>
>
--
*****
Craig Partridge's email account for professional society activities and
mailing lists.
--
Internet-history mailing list
Internet-history at elists.isoc.org
https://elists.isoc.org/mailman/listinfo/internet-history
--
Dave Täht CSO, LibreQos
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.bufferbloat.net/pipermail/bloat/attachments/20241010/9701e5bd/attachment.html>
More information about the Bloat
mailing list