[ih] booting linux on a 4004

Wed Oct 2 14:30:42 PDT 2024

The response to bufferbloat has always struck me as looking for your keys under a street light when that wasn’t where you dropped them but there is light there.

Initially, bufferbloat was not a problem because memory was expensive and when TCP ran out of buffers (or got low), the connection simply blocked the sending application until buffers were available. This was still true with the advent of NIC cards. Memory was still tight. However, as memory got cheap and NIC cards had oceans of memory, TCP never got low on buffers and no one told the application to slow down or wait, so there was local congestion collapse:  bufferbloat.

One part of the solution would be interface flow control between the sending application and TCP (you would have thought that would have occurred to implementers any way, it is obvious) and/or simply restrict the amount of buffers TCP has available so that it runs out and blocks the sending the application before things get bad and opens up when buffers are available.  But virtually all of the papers I see are on different drop-strategies, and oddly enough they never find their keys.

Take care,
John

> On Oct 2, 2024, at 01:48, Barbara Denny via Internet-history <internet-history at elists.isoc.org> wrote:
> 
> Just throwing some thoughts out here ......
> I can see how this happens in a FIFO queuing world.   However a lot of work has gone into fair queuing starting in the late 80s.  Just wondering if anyone has done work utilizing fair queuing and source quench.  For example, I think I can see how to use fair queuing information to better select who to send a source quench to. At least I can see how to do it with Stochastic Fairness Queueing since I worked on it and I  remember a fair amount about how it was implemented. I wouldn't be able to provide a guarantee that the wrong host would never receive a source quench but the likelihood should be much lower.  Considering whether the use of NAT creates undesirable behavior is also important and I am sure there are probably other cases that need to be checked.
> Hum,  it might also be interesting to speculate whether this could have any effect on bufferbloat but I fess up I need to learn more about the work done in the area of bufferbloat.  I was involved with other things when this started to appear on my radar screen as a hot topic.  I will admit I wish I had done more work on possible buffering effects from implementation choices at the time I did work on SFQ but there were contractual obligations that restricted how much time I could devote to the SFQ part of the project. 
> Just curious, ECN (Explicit Congestion Notification) is optional . Does anyone have any idea about its use in the Internet?
> barbara
> 
>    On Tuesday, October 1, 2024 at 07:10:25 PM PDT, Vint Cerf <vint at google.com> 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 CerfGoogle, LLC1900 Reston Metro Plaza, 16th FloorReston, VA 20190+1 (571) 213 1346
> 
> 
> until further notice
> 
> 
> 
> -- 
> Internet-history mailing list
> Internet-history at elists.isoc.org
> https://elists.isoc.org/mailman/listinfo/internet-history