[ih] bufferbloat and modern congestion control (was 4004)

Sun Oct 6 12:29:45 PDT 2024

Thank you for the analogy with working sets, I hadn't thought of that.

"Resource allocation is a tricky business." - Denning, "The Working Set Model for Program Behavior", 1968. (I still think that was one of the last great discoveries in CS, in the same year as the Dijkstra letter.)

I just found this wonderful page: http://denninginstitute.com/pjd/PUBS/Workingsets.html

Regards
    Brian

On 07-Oct-24 07:01, John Day via Internet-history wrote:
> This is one of the things that really bothers me.  When buffer bloat first became a big thing, several people recounted papers reporting seeing it as far back as the mid-90s, Jack’s may be even earlier.  Yet no one took notice. We can conjecture why not, but it would only be conjecture.
> 
> Similarly in 2004, Appenzeller then at Stanford reported on the advantage of pooled vs static buffers in routers and that 90% of the memory in high routers was unnecessary. That fundamental result had been reported by Peter Denning in 1968 in timesharing systems. But the differences were so stark that it was obvious that it applied in general. (I have been using the result since I first read the paper in the early 70s.) It has been rediscovered at least two other times (probably more) on about a 10 year cycle. (There is a very good paper on DCTCP that stumbled on to it and was surprised by the result but didn’t seem to realize why it happened.)
> 
> This discussion of congestion suffers from the same thing. I have not seen a paper in 20 years that cites the Raj/KK’s work or that they found that ECN notification should begin when the average queue length is less than or equal to 1.
> 
> All of these have different degrees of being non-intuitive and should be pointed out.  Who knows how many other major results are so poorly known.  They certainly aren’t covered in the networking textbooks. I cover them in my course along with other unreported principles.
> 
> This is the behavior of a craft, not a science.
> 
> Take care,
> John
> 
>> On Oct 6, 2024, at 02:29, Vint Cerf via Internet-history <internet-history at elists.isoc.org> wrote:
>>
>> sounds like your test discovered bufferbloat....
>>
>> v
>>
>>
>> On Sat, Oct 5, 2024 at 6:28 PM Jack Haverty <jack at 3kitty.org> wrote:
>>
>>> IIRC:
>>>
>>> When the internal mechanisms (such as SQ) were being debated and choices
>>> made to create TCP/IP V4 for adoption as the DoD Standard, the technology
>>> world was quite different.   At the time (early 1980s), gateways had very
>>> little memory - sometimes only enough to hold one or at most a few IP
>>> datagrams.   If a datagram arrived and there was no place to hold it, SQ
>>> back to the source was a way to say "Slow down.  I just had to drop your
>>> last datagram".
>>>
>>> Over the decades, memory became a lot more available.  So gateways could
>>> easily have space to queue many datagrams.  In one test I did just a few
>>> years ago, a stream of datagrams was sent from one site to another.  All
>>> were received intact and in order as sent.  No SQ messages were received.
>>> But latency soared.  Some datagrams took more than 30 seconds to reach
>>> their destination.   Memory had become cheap enough that datagrams could
>>> just be held as long as needed.
>>>
>>> For anyone involved in operating a piece of the Internet, or for
>>> diagnosing users' complaints like "it's too slow", ICMP's facilities were
>>> crucial tools.   They were flawed and incomplete, but still useful as ways
>>> to figure out what was happening.
>>>
>>> When the TCP/IP RFCs were adopted as the DoD Standard, ICMP was not
>>> included.  As someone involved in diagnosing operational problems, we
>>> yelled, screamed, cajoled, encouraged, lobbied, and did whatever we could
>>> to get the DoD procurement folks to add ICMP to their list of required
>>> implementations.
>>>
>>> This discussion about SQ reminded me of another "gateway issue" from the
>>> 1980s ICCB to-do list - "End-Middle Interactions".   I'll write what I
>>> remember about that separately.
>>>
>>> Jack
>>>
>>>
>>>
>>> On 10/5/24 11:26, Craig Partridge via Internet-history wrote:
>>>
>>> All sorts of goodies:
>>>
>>> ICMP Echo (what used to power Ping until people decided they didn't like
>>> folks probing)
>>>
>>> ICMP Unreachable (port or host)
>>>
>>> ICMP Problem Param (diagnostic)
>>>
>>> many more.
>>>
>>> On Sat, Oct 5, 2024 at 10:50 AM Vint Cerf via Internet-history <internet-history at elists.isoc.org> wrote:
>>>
>>>
>>> isn't there more to ICMP than source quench? Seems wrong to ignore all ICMP
>>> messages.
>>>
>>> v
>>>
>>>
>>> On Sat, Oct 5, 2024 at 12:04 PM Greg Skinner via Internet-history <internet-history at elists.isoc.org> wrote:
>>>
>>>
>>> On Oct 3, 2024, at 9:02 AM, Greg Skinner via Internet-history <internet-history at elists.isoc.org <mailto:
>>>
>>> internet-history at elists.isoc.org>>
>>>
>>> wrote:
>>>
>>> Forwarded for Barbara
>>>
>>> ====
>>>
>>> Having trouble emailing again so i did some trimming on the original
>>>
>>> message....
>>>
>>> Putting my packet radio hat back on, a source quench message could help
>>>
>>> disambiguate whether loss in the network is due to congestion or
>>>
>>> something
>>>
>>> else (like in wireless, loss due to harsh environments, jamming,
>>> mobility).   I also think it is not obvious what you should do when you
>>> receive a source quench, but to me trying to understand this is just part
>>> of trying to see if we can make things work better.  How about what you
>>> could do when you don't receive a source quench but have experienced
>>>
>>> loss?
>>>
>>> How is network coding coming along these days?
>>>
>>> barbara
>>>
>>> Any serious attempts to reinstitute ICMP source quench would have to go
>>> through the IETF RFC process again because it’s been deprecated for some
>>> time. [1]  Also, many sites block ICMP outright (even though they’ve been
>>> warned not to do this). [2]
>>>
>>> --gregbo
>>>
>>> [1] https://datatracker.ietf.org/doc/rfc6633/
>>> [2]
>>>
>>>
>>> https://www.linkedin.com/pulse/icmp-dilemma-why-blocking-makes-you-networking-noob-ronald-bartels-ikvnf
>>>
>>> --
>>> Internet-history mailing listInternet-history at elists.isoc.orghttps://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 listInternet-history at elists.isoc.orghttps://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
>> -- 
>> Internet-history mailing list
>> Internet-history at elists.isoc.org
>> https://elists.isoc.org/mailman/listinfo/internet-history
> 