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