[Bloat] Fwd: [ih] booting linux on a 4004

[Bloat] Fwd: [ih] booting linux on a 4004

[Dave Taht]

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

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@elists.isoc.org
>
Date: Thu, Oct 10, 2024 at 5:53 AM
Subject: Re: [ih] booting linux on a 4004
To: Greg Skinner <gregskinner0@icloud.com>
Cc: Vint Cerf via Internet-history <internet-history@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@LOKI.BBN.COM>

Cc: end2end-tf@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@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@icloud.com>
wrote:

>
> On Oct 5, 2024, at 5:42 PM, Craig Partridge <craig@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@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@elists.isoc.org
https://elists.isoc.org/mailman/listinfo/internet-history


-- 
Dave Täht CSO, LibreQos

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