Re: [Starlink] RFC: bufferbloat observability project (Dave Taht)

["David P. Reed" <dpreed@deepplum.com>]

[-- Attachment #1: Type: text/plain, Size: 2622 bytes --]


I should have added this: I am aware of a full TCP stack implementation implemented in Verilog. (In fact, my son built it, and it is in production use on Wall St.).
 
On Sunday, March 12, 2023 2:51pm, "David P. Reed" <dpreed@deepplum.com> said:



Regarding unbounded queues
On Sunday, March 12, 2023 12:00pm, Dave Taht <dave.taht@gmail.com> said:

> Also it increasingly bothers me to see unbounded queues in so many new
> language libraries.


I disagree somewhat. Unbounded queueing is perfectly fine in a programming language like Haskell, where there are no inherent semantics about timing - a queue is an ordered list with append, and it's a GREAT way to formulate many algorithms that process items in order.
 
Where the problem with queues arises is in finite (bounded) real-time programming systems. Which include network protocol execution machines.
 
It's weird to me that people seem to think that languages intended for data-transformation algorithms, parsers, ... are appropriate for programming network switches, TCP/IP stacks, etc. It always has seemed weird beyond belief. I mean, yeah, Go has queues and goroutines, but those aren't real-time appropriate components.
 
What may be the better thing to say is that it increasingly bothers you that NO ONE seems to be willing to create a high-level programming abstraction for highly concurrent interacting distributed machines.
 
There actually are three commercial programming languages (which are about at the level of C++ in abstraction, with the last maybe being at the level of Haskell).
1. Verilog
2. VHDL
3. BlueSpec
 
For each one, there is a large community of programmers proficient in them. You might also consider Erlang as a candidate, but I think its "queues" are not what you want to see.
 
Why doesn't IETF bother to try to delegate a team to create such an expressive programming language or whatever? I'd suggest that starting with Verilog might be a good idea.
 
A caveat about my point: I write Verilog moderately well, and find it quite expressive for modeling networking systems in my mind. I also write Haskell quite well, and since BlueSpec draws on Haskell's model of computation I find it easy to read, but I've not written much Haskell.
 
To me, those who write networking code in C or C++ are stuck in the past when protocols were documented by bit-layouts of packets and hand-waving English "standards" without any way to verify correctness. We need to stop worshipping those archaic RFCs as golden tablets handed down from gods.
 
Who am I to criticize the academic networking gods, though?

[-- Attachment #2: Type: text/html, Size: 6150 bytes --]