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

[Vint Cerf]

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