[Starlink] RFC: bufferbloat observability project

[Starlink] RFC: bufferbloat observability project

[Dave Taht]

I just put together a list of common tools developers use every day,
that would benefit from observing and managing network latency better.
Things like git, and so on. Could some folk out there please pitch in
with additional suggestions?

https://docs.google.com/document/d/1SPuDhjMggexUuIGV8lUziQ3r8JjyLSwpZPoHieVLiaE/edit#heading=h.fyd7g5rbur4a

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

-- 
Roy Beatty (from Blade Runner) and I: https://www.understandinglatency.com/
Dave Täht CEO, TekLibre, LLC

Re: [Starlink] [Rpm] RFC: bufferbloat observability project

[Robert McMahon]

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

Hi Dave,

Thanks for the mention of iperf 2. I want to clarify that the tooling over the last many years has a focus on ultra low latency both in metrics and mechanisms. Bufferbloat is supported mostly as a rating through the use of synthetic traffic and Little's Law. David Reed had pointed out that synthetic traffic does not match real world traffic, which comes from chaotic distributions and might be infinite in the possibilities (though maybe less than infinity squared.)


Bob



On Mar 12, 2023, 5:52 AM, at 5:52 AM, Dave Taht via Rpm <rpm@lists.bufferbloat.net> wrote:
>I just put together a list of common tools developers use every day,
>that would benefit from observing and managing network latency better.
>Things like git, and so on. Could some folk out there please pitch in
>with additional suggestions?
>
>https://docs.google.com/document/d/1SPuDhjMggexUuIGV8lUziQ3r8JjyLSwpZPoHieVLiaE/edit#heading=h.fyd7g5rbur4a
>
>Also it increasingly bothers me to see unbounded queues in so many new
>language libraries.
>
>--
>Roy Beatty (from Blade Runner) and I:
>https://www.understandinglatency.com/
>Dave Täht CEO, TekLibre, LLC
>_______________________________________________
>Rpm mailing list
>Rpm@lists.bufferbloat.net
>https://lists.bufferbloat.net/listinfo/rpm

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

Re: [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@deepplum.com>
> To: starlink@lists.bufferbloat.net
> Subject: Re: [Starlink] RFC: bufferbloat observability project (Dave
> 	Taht)
> Message-ID: <1678647418.092929775@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@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?