[ih] booting linux on a 4004

[Vint Cerf]

John,

you may be referring to an early Van Jacobson idea, "slow start" - things
have gone well beyond that, I believe, with mechanisms that use the
acknowledgement intervals to assess/control flow. Round-trip time is no
longer a key metric.

v


On Wed, Oct 2, 2024 at 5:19 PM John Day <jeanjour at comcast.net> wrote:

> Busy day. Just getting to looking at these.
>
> AFAIK, Raj and KK are the real experts on this topic. The 4-part DEC
> Report is a masterpiece. The epitome of what good computer research should
> be. Their initial work really nailed the problem. It is unfortunate that it
> appears to have been totally forgotten. Of course there was still work to
> do. A few conclusions:
>
> Flow control is a pair-wise issue, Congestion management is an n-party
> issue.
>
> Any layer that relays will exhibit congestion. (Contention for
> multi-access media is a form of congestion.)
>
> A Congestion solution should minimize congestion events and
> retransmissions. (TCP maximizes both.)
>
> Congestion is a stochastic phenomena. The cause is too many packets
> arriving with a given short period.
>
> Load is not the root cause of congestion but does increase the
> probability. (This is an error I see in most every paper I read on the
> topic.) Congestion has been observed on a network with a .1% loading. Often
> congestion will clear on its own. Waiting for load to be the condition for
> a response makes the response late.
>
> The effectiveness of any congestion avoidance solution will deteriorate
> with increasing time-to-notify.
>
> Something like ECN or SourceQuench (if like ECN it is sent to all sources
> of the congested router) is absolutely required to ensure that the effects
> of congestion management remain localized to the layer in which it
> occurred. However, neither one alone is sufficient without the action to be
> taken in response to receiving them. (I would think SQ would have some
> advantage in that the sender would be notified sooner than with ECN.)
>
> Without ECN, the congestion scheme is predatory and will interact badly
> with congestion solutions in lower layers.
>
>
> Jacobson’s solution for TCP is about the worst, one could expect: A
> congestion *avoidance* solution that works by causing congestion? It has
> potentially done irreparable damage to the Internet, because it is
> predatory. (implicit notification, no ECN)  In a way this is not Van’s
> fault. It is the classic engineer’s mistake: Solve the narrow problem but
> fail to consider the context. This solution might acceptable for a network,
> but not for an Internet, where multiple layers (some of less scope) relay
> and are thus subject to congestion. Attempts to do congestion control in
> lower layers with TCP congestion control results in warring feedback loops
> with very different response times.
>
> As Jain and KK point out, TCP optimizes for the edge of the cliff of
> congestion collapse, while they propose optimizing for the knee of the
> throughput/delay curve to minimize both congestion events and
> retransmissions.
>
> There is probably much more, but this is what comes to mind.
>
> Take care,
> John
>
>
> On Oct 1, 2024, at 22:10, Vint Cerf via Internet-history <
> internet-history at elists.isoc.org> wrote:
>
> One basic problem with blaming the "last packet that caused intermediate
> router congestion" is that it usually blamed the wrong source, among other
> problems. Van Jacobson was/is the guru of flow control (among others) who
> might remember more.
>
>
> v
>
>
> On Tue, Oct 1, 2024 at 8:50 PM Barbara Denny via Internet-history <
> internet-history at elists.isoc.org> wrote:
>
> In a brief attempt to try to find some information about the early MIT
> work you mentioned, I ended up tripping on this Final Report from ISI in
> DTIC.  It does talk a fair amount about congestion control and source
> quench (plus other things that might interest people). The period of
> performance is 1987 to 1990 which is much later than I was considering in
> my earlier message.
>
> https://apps.dtic.mil/sti/tr/pdf/ADA236542.pdf
>
> Even though the report mentions testing on DARTnet, I don't remember
> anything about this during our DARTnet meetings.  I did join the project
> after the start so perhaps the work was done before I began to participate.
> I also couldn't easily find the journal they mention as a place for
> publishing their findings. I will have more time later to see if I can
> something that covers this testing.
>
> barbara
>
>    On Tuesday, October 1, 2024 at 04:37:47 PM PDT, Scott Bradner via
> Internet-history <internet-history at elists.isoc.org> wrote:
>
> multicast is also an issue but I do not recall if that was one that Craig
> & I talked about
>
> Scott
>
> On Oct 1, 2024, at 7:34 PM, Scott Bradner via Internet-history <
>
> internet-history at elists.isoc.org> wrote:
>
>
> I remember talking with Craig Partridge (on a flight to somewhere) about
>
> source quench
>
> during the time when 1812 was being written - I do not recall
> the specific issues but I recall that there were more than one issue
>
> (if DoS was not an issue at the time, it should have been)
>
> Scott
>
> On Oct 1, 2024, at 6:22 PM, Brian E Carpenter via Internet-history <
>
> internet-history at elists.isoc.org> wrote:
>
>
> On 02-Oct-24 10:19, Michael Greenwald via Internet-history wrote:
>
> On 10/1/24 1:11 PM, Greg Skinner via Internet-history wrote:
>
> Forwarded for Barbara
>
> ====
>
> From: Barbara Denny <b_a_denny at yahoo.com>
> Sent: Tuesday, October 1, 2024 at 10:26:16 AM PDT
> I think congestion issues were discussed because I remember an ICMP
>
> message type called source quench (now deprecated). It was used for
> notifying a host to reduce the traffic load to a destination.  I don't
> remember hearing about any actual congestion experiments using this message
> type.
>
> Of only academic interest: I believe that, circa 1980 +/- 1-2 years, an
> advisee of either Dave Clark or Jerry Saltzer, wrote an undergraduate
> thesis about the use of Source Quench for congestion control. I believe
> it included some experiments (maybe all artificial, or only through
> simulation).
> I don't think it had much impact on the rest of the world.
>
>
> Source quench is discussed in detail in John Nagle's RFC 896 (dated
>
> 1984).
>
> A trail of breadcrumbs tells me that he has an MSCS from Stanford, so
> I guess he probably wasn't an MIT undergrad.
>
> Source quench was effectively deprecated by RFC 1812 (dated 1995).
>
> People
>
> had played around with ideas (e.g. RFC 1016) but it seems that basically
> it was no use.
>
> A bit more Google found this, however:
>
> "4.3. Internet Congestion Control
> Lixia Zhang began a study of network resource allocation techniques
>
> suitable for
>
> the DARPA Internet. The Internet currently has a simple technique for
>
> resource
>
> allocation, called "Source Quench."
> Simple simulations have shown that this technique is not effective, and
>
> this work
>
> has produced an alternative which seems considerably more workable.
>
> Simulation
>
> of this new technique is now being performed."
>
> [MIT LCS Progress Report to DARPA, July 1983 - June 1984, AD-A158299,
> https://apps.dtic.mil/sti/pdfs/ADA158299.pdf ]
>
> Lixia was then a grad student under Dave Clark. Of course she's at UCLA
>
> now. If she isn't on this list, she should be!
>
>
> Brian Carpenter
>
>
>
> --
> Internet-history mailing list
> Internet-history at elists.isoc.org
> https://elists.isoc.org/mailman/listinfo/internet-history
>
>
>
> --
> Please send any postal/overnight deliveries to:
> Vint Cerf
> Google, LLC
> 1900 Reston Metro Plaza, 16th Floor
> Reston, VA 20190
> +1 (571) 213 1346 <(571)%20213-1346>
>
>
> until further notice
> --
> Internet-history mailing list
> Internet-history at elists.isoc.org
> https://elists.isoc.org/mailman/listinfo/internet-history
>
>
>

-- 
Please send any postal/overnight deliveries to:
Vint Cerf
Google, LLC
1900 Reston Metro Plaza, 16th Floor
Reston, VA 20190
+1 (571) 213 1346


until further notice