[Starlink] RFC: bufferbloat observability project

[David Fernández]

"in the past [...] protocols were documented by bit-layouts of packets"

https://indico.esa.int/event/57/contributions/2701/attachments/2245/2598/Data_Modelling_with_ASN.1.pdf#page=4&zoom=auto,-278,13

ASN.1 compilers generate C code, though.


> Date: Sun, 12 Mar 2023 14:56:58 -0400 (EDT)
> From: "David P. Reed" <dpreed at deepplum.com>
> To: starlink at lists.bufferbloat.net
> Subject: Re: [Starlink] RFC: bufferbloat observability project (Dave
> 	Taht)
> Message-ID: <1678647418.092929775 at apps.rackspace.com>
> Content-Type: text/plain; charset="utf-8"
>
>
> 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 at deepplum.com>
> said:
>
>
>
> Regarding unbounded queues
> On Sunday, March 12, 2023 12:00pm, Dave Taht <dave.taht at 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?