From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from smtp115.iad3a.emailsrvr.com (smtp115.iad3a.emailsrvr.com [173.203.187.115]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by lists.bufferbloat.net (Postfix) with ESMTPS id 3AF6B3B29D for ; Sun, 12 Mar 2023 14:51:39 -0400 (EDT) Received: from app27.wa-webapps.iad3a (relay-webapps.rsapps.net [172.27.255.140]) by smtp39.relay.iad3a.emailsrvr.com (SMTP Server) with ESMTP id 9594018A4 for ; Sun, 12 Mar 2023 14:51:38 -0400 (EDT) Received: from deepplum.com (localhost.localdomain [127.0.0.1]) by app27.wa-webapps.iad3a (Postfix) with ESMTP id 7D33E21B92; Sun, 12 Mar 2023 14:51:38 -0400 (EDT) Received: by apps.rackspace.com (Authenticated sender: dpreed@deepplum.com, from: dpreed@deepplum.com) with HTTP; Sun, 12 Mar 2023 14:51:38 -0400 (EDT) X-Auth-ID: dpreed@deepplum.com Date: Sun, 12 Mar 2023 14:51:38 -0400 (EDT) From: "David P. Reed" To: starlink@lists.bufferbloat.net Cc: starlink@lists.bufferbloat.net MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_20230312145138000000_94047" Importance: Normal X-Priority: 3 (Normal) X-Type: html In-Reply-To: References: X-Client-IP: 209.6.168.128 Message-ID: <1678647098.508830273@apps.rackspace.com> X-Mailer: webmail/19.0.22-RC X-Classification-ID: 1f42256b-a81f-4b72-9f4f-8f8ed34456fb-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:51:39 -0000 ------=_20230312145138000000_94047 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable =0ARegarding unbounded queues=0AOn Sunday, March 12, 2023 12:00pm, Dave Tah= t said:=0A=0A> Also it increasingly bothers me to see= unbounded queues in so many new=0A> language libraries.=0A=0A=0AI disagree= somewhat. Unbounded queueing is perfectly fine in a programming language l= ike Haskell, where there are no inherent semantics about timing - a queue i= s an ordered list with append, and it's a GREAT way to formulate many algor= ithms that process items in order.=0A =0AWhere the problem with queues aris= es is in finite (bounded) real-time programming systems. Which include netw= ork protocol execution machines.=0A =0AIt'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 g= oroutines, but those aren't real-time appropriate components.=0A =0AWhat ma= y be the better thing to say is that it increasingly bothers you that NO ON= E seems to be willing to create a high-level programming abstraction for hi= ghly concurrent interacting distributed machines.=0A =0AThere 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).=0A1. V= erilog=0A2. VHDL=0A3. BlueSpec=0A =0AFor each one, there is a large communi= ty of programmers proficient in them. You might also consider Erlang as a c= andidate, but I think its "queues" are not what you want to see.=0A =0AWhy = 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 mi= ght be a good idea.=0A =0AA caveat about my point: I write Verilog moderate= ly 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 H= askell.=0A =0ATo 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 ha= nd-waving English "standards" without any way to verify correctness. We nee= d to stop worshipping those archaic RFCs as golden tablets handed down from= gods.=0A =0AWho am I to criticize the academic networking gods, though? ------=_20230312145138000000_94047 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable

Regarding unbounded qu= eues

=0A

On Sunday, March 12, 2023 12:00pm, Dav= e Taht <dave.taht@gmail.com> said:

=0A
=0A

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

= =0A

I disagree somewhat. Unbounded queueing is perfectl= y 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=

 

=0A

Where the problem wi= th queues arises is in finite (bounded) real-time programming systems. Whic= h include network protocol execution machines.

=0A

&= nbsp;

=0A

It's weird to me that people seem to think= that languages intended for data-transformation algorithms, parsers, ... a= re appropriate for programming network switches, TCP/IP stacks, etc. It alw= ays has seemed weird beyond belief. I mean, yeah, Go has queues and gorouti= nes, but those aren't real-time appropriate components.

=0A

 

=0A

What may be the better thing to s= ay is that it increasingly bothers you that NO ONE seems to be willing to c= reate a high-level programming abstraction for highly concurrent interactin= g distributed machines.

=0A

 

=0A

There actually are three commercial programming languages (w= hich are about at the level of C++ in abstraction, with the last maybe bein= g at the level of Haskell).

=0A

1. Verilog

=0A

2. VHDL

=0A

3. BlueSpec

=0A

 

=0A

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 s= ee.

=0A

 

=0A

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

=0A

 

=0A

= 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 Haskel= l 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

 

=0A

To me, those who write networkin= g 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 go= lden tablets handed down from gods.

=0A

 

= =0A

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

=0A
 ------=_20230312145138000000_94047--