From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from smtp118.iad3a.emailsrvr.com (smtp118.iad3a.emailsrvr.com [173.203.187.118]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by lists.bufferbloat.net (Postfix) with ESMTPS id C35EC3B29D for ; Sun, 12 Mar 2023 14:56:58 -0400 (EDT) Received: from app27.wa-webapps.iad3a (relay-webapps.rsapps.net [172.27.255.140]) by smtp7.relay.iad3a.emailsrvr.com (SMTP Server) with ESMTP id 2F4681A17 for ; Sun, 12 Mar 2023 14:56:58 -0400 (EDT) Received: from deepplum.com (localhost.localdomain [127.0.0.1]) by app27.wa-webapps.iad3a (Postfix) with ESMTP id 1745E21B92 for ; Sun, 12 Mar 2023 14:56:58 -0400 (EDT) Received: by apps.rackspace.com (Authenticated sender: dpreed@deepplum.com, from: dpreed@deepplum.com) with HTTP; Sun, 12 Mar 2023 14:56:58 -0400 (EDT) X-Auth-ID: dpreed@deepplum.com Date: Sun, 12 Mar 2023 14:56:58 -0400 (EDT) From: "David P. Reed" To: starlink@lists.bufferbloat.net MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_20230312145658000000_91234" Importance: Normal X-Priority: 3 (Normal) X-Type: html In-Reply-To: <1678647098.508830273@apps.rackspace.com> References: <1678647098.508830273@apps.rackspace.com> X-Client-IP: 209.6.168.128 Message-ID: <1678647418.092929775@apps.rackspace.com> X-Mailer: webmail/19.0.22-RC X-Classification-ID: 31a1e13a-470c-4b0b-908f-a17f86d9d25b-1-1 Subject: Re: [Starlink] =?utf-8?q?RFC=3A_bufferbloat_observability_project_=28?= =?utf-8?q?Dave_Taht=29?= X-BeenThere: starlink@lists.bufferbloat.net X-Mailman-Version: 2.1.20 Precedence: list List-Id: "Starlink has bufferbloat. Bad." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 12 Mar 2023 18:56:58 -0000 ------=_20230312145658000000_91234 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable =0AI 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.).=0A =0AOn Sunday, March 12, 2023 2:51pm, "David P. Reed" <= dpreed@deepplum.com> said:=0A=0A=0A=0ARegarding unbounded queues=0AOn Sunda= y, March 12, 2023 12:00pm, Dave Taht said:=0A=0A> Als= o it increasingly bothers me to see unbounded queues in so many new=0A> lan= guage libraries.=0A=0A=0AI disagree somewhat. Unbounded queueing is perfect= ly 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.=0A = =0AWhere the problem with queues arises is in finite (bounded) real-time pr= ogramming systems. Which include network protocol execution machines.=0A = =0AIt's weird to me that people seem to think that languages intended for d= ata-transformation algorithms, parsers, ... are appropriate for programming= network switches, TCP/IP stacks, etc. It always has seemed weird beyond be= lief. I mean, yeah, Go has queues and goroutines, but those aren't real-tim= e appropriate components.=0A =0AWhat may be the better thing to say is that= it increasingly bothers you that NO ONE seems to be willing to create a hi= gh-level programming abstraction for highly concurrent interacting distribu= ted machines.=0A =0AThere actually are three commercial programming languag= es (which are about at the level of C++ in abstraction, with the last maybe= being at the level of Haskell).=0A1. Verilog=0A2. VHDL=0A3. BlueSpec=0A = =0AFor each one, there is a large community of programmers proficient in th= em. You might also consider Erlang as a candidate, but I think its "queues"= are not what you want to see.=0A =0AWhy doesn't IETF bother to try to dele= gate a team to create such an expressive programming language or whatever? = I'd suggest that starting with Verilog might be a good idea.=0A =0AA caveat= about my point: I write Verilog moderately well, and find it quite express= ive 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.=0A =0ATo me, those who wri= te networking code in C or C++ are stuck in the past when protocols were do= cumented by bit-layouts of packets and hand-waving English "standards" with= out any way to verify correctness. We need to stop worshipping those archai= c RFCs as golden tablets handed down from gods.=0A =0AWho am I to criticize= the academic networking gods, though? ------=_20230312145658000000_91234 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable

I should have added th= is: 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.).

=0A<= p style=3D"margin:0;padding:0;font-family: arial; font-size: 10pt; overflow= -wrap: break-word;"> 

=0A

On Sunday, March 12, = 2023 2:51pm, "David P. Reed" <dpreed@deepplum.com> said:

<= /p>=0A

=0A

Regarding unbounded queues

=0A

On Sunday, March 12, 2023 12:00pm, Dave Taht <dave.tah= t@gmail.com> said:

=0A
=0A

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

=

=0A

I disagree somewhat. Unb= ounded queueing is perfectly fine in a programming language like Haskell, w= here there are no inherent semantics about timing - a queue is an ordered l= ist with append, and it's a GREAT way to formulate many algorithms that pro= cess items in order.

=0A

&nbs= p;

=0A

Where the problem with= queues arises is in finite (bounded) real-time programming systems. Which = include network protocol execution machines.

=0A

 

=0A

=  

=0A

What may be the be= tter 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 concur= rent interacting distributed machines.

=0A

 

=0A

Ther= e 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).

=0A

1. Verilog<= /p>=0A

2. VHDL

=0A

3. BlueSpec

=0A

 

=0A

=0A

 

=0A

Why doesn't I= ETF bother to try to delegate a team to create such an expressive programmi= ng language or whatever? I'd suggest that starting with Verilog might be a = good idea.

=0A

 

=0A<= p style=3D"margin:0;padding:0;margin: 0; padding: 0; font-family: arial; fo= nt-size: 10pt; overflow-wrap: break-word;">A caveat about my point: I write= Verilog moderately well, and find it quite expressive for modeling network= ing 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 n= ot written much Haskell.

=0A

=  

=0A

To me, those who w= rite 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" wi= thout any way to verify correctness. We need to stop worshipping those arch= aic RFCs as golden tablets handed down from gods.

=0A

 

=0A

Who am I to criticize the academic networking gods, though?

=0A=0A
 ------=_20230312145658000000_91234--