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

[Jack Haverty]

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 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
>> --
>> Internet-history mailing list
>> Internet-history at elists.isoc.org
>> https://elists.isoc.org/mailman/listinfo/internet-history
>>
>

-------------- next part --------------
A non-text attachment was scrubbed...
Name: OpenPGP_signature.asc
Type: application/pgp-signature
Size: 665 bytes
Desc: OpenPGP digital signature
URL: <http://elists.isoc.org/pipermail/internet-history/attachments/20241005/62fae61c/attachment.asc>