[Congress] Congress - Congestion Control - Combined Network QOS Routing Table Tree-Swarm - Quality of Service Protocol & the TCP & UDP & QUICC Protocols

[Duke Abbaddon <[e-mail]>]

Quality of Service Protocol & the TCP & UDP & QUICC Protocols :
https://www.ietf.org/archive/id/draft-scheffenegger-congress-rfc5033bis-00.txt

*
Processor Model for TCP, UDP & QUICC : (c)RS

To put TCP, UDP & QUICC in a proper place in your minds for application,
Think about Applying them to processors; Particularly Neuromorphic, ML
& GPU/CPU!

How exactly?

Address space modelling for data transfer:
Between RAM, HDD/SDD & CPU & Internally mapping across cache & Sparse
Model NAND Gates.

In the situation internal to Device Gates & Logic Circuits; We map
address spaces across the processor,
We internalize the location logic as a network & utilise TCP, UDP & QUICC,

We do not need the sending strategy of Data Transfer to be Random;
Random wastes Bandwidth!
But we do need a QOS Data Transfer policy & Networking Tactics!

Why ? Not all processor functions are directly connected in MultiChip
& 3D Model Processor.
*

By thinking about the Processor Model for TCP, UDP & QUICC : (c)RS
We soon find the best light TCP, UDP & QUICC Network Strategy.

Think about this model designing the Network Protocols

RS

*
"Kevin Cisco-Kevin

Date: Tue, 21 Feb 2023 08:32:03 -0800
Subject: Re: To think about the Network Model : Processor Model for
TCP, UDP & QUICC : (c)RS
What we really need is a transfer layer mechanism modeled after Swarm
where packets are broken up into chunks and reassembled after
handshaking.  But we don't live in that world."

Kevin Suggests we think about Swarm : RS : What do i think on average (Swarm)

I think that Swarm; Multi Target Networking is a primary method under
consideration for QUICC & UDP & NTP Responses,

Swarm is high noise; High Volume Send & Receive,
With alteration though Statistical & Machine rout optimisation... That
bandwidth cost reduces,
ML : Neural network, Send, Receive & Confirm, Swarm, In effect on
globally predictable commodities such as:
NTP, DNS (popular), News & Decetralised command...

Can work! Network Command requires directly applied logic; What i mean
is : Confirmed Command & Reception affirmation & Action!

So i propose the following:

Combined Network QOS Routing Table Tree-Swarm : CNetQSRT-Tree-Sw :
Rupert S 2023-02

Swarm:ML (Known Receiver : Known Sender)

QOS
NTP
DNS Global Submit

Network Tunneling, For example: Torado, Large Download Acceleration

Secure Network Tunneling, For example: VPN, VPS, Ethernet, 3G, 4G LTE,
Volt, 5G Volt, Telecommunications Networking & GPS)

Defined routing with QOS Network optimisation (Localised) & Data
bandwidth data (Localised)

Global Zone routing through tables...

Statistic Enhanced Routing & Delivery

*

QOS : Quality Of Service protocol : RS https://is.gd/LEDSource

Personally I believe QOS : Quality Of Service protocol be introduced
to all network traffic,
Primarily the Point A to point Z route needs planning first.

QOS Datagram
Network throughput Capacity of the network card
Advertise Capacity in local network
Plan routes based on network capacity

So the Quality Of Service Protocol needs to send a datagram to the
network adapter of site:

A to Z

A list of local routes needs to be cached & prioritised based on
Network point A's network capacity & priority,

The rout needs Point A to Z mapped & Z to A

We then send data with a packet listing preferred routes

[QOS][Origin : Target][Preferred route list forward sent][Network
Performance Metric Packet]
[Origin : Target][Preferred route list forward sent][Semi Static Route Tunnel]
[Packet ID][Origin : Target][Data Packet]

Searching for a route with every packet costs processor Cycles; So
preferred routes need to be tunnelled & Secured with TLS

Rupert S

https://is.gd/CryptographicProves

https://science.n-helix.com/2022/03/ice-ssrtp.html
https://science.n-helix.com/2022/01/ntp.html

Code Speed
https://science.n-helix.com/2022/08/simd.html
https://science.n-helix.com/2022/09/ovccans.html

Chaos
https://science.n-helix.com/2022/02/interrupt-entropy.html
https://science.n-helix.com/2022/02/rdseed.html
https://science.n-helix.com/2020/06/cryptoseed.html

Example of a Secure Tunnel System:

https://is.gd/SecurityHSM https://is.gd/WebPKI

TLS Optimised https://drive.google.com/file/d/10XL19eGjxdCGj0tK8MULKlgWhHa9_5v9/view?usp=share_link

Ethernet Security
https://drive.google.com/file/d/18LNDcRSbqN7ubEzaO0pCsWaJHX68xCxf/view?usp=share_link

*****

Date: Fri, 17 Feb 2023 16:39:25 +0100
Subject: New Version Notification for
draft-scheffenegger-congress-rfc5033bis-00.txt
Hello,

In order to facilitate the github based editorial process of a revised
RFC5033 document that outlines the current best practises when it comes
to designing new congestion control mechanisms, I want to invite
everyone who has commented across various lists and in meetings, to
raise issues and contribute text here:


https://rscheff.github.io/rfc5033bis

https://github.com/rscheff/rfc5033bis/issues


As the home for this work has not yet fully formed yet, I created this
as an individual draft. There are no text changes in rfc50333bis-00
compared to rfc5033, only minor editorial changes due to the use of
markdown for the body of the document.

A number of individuals have already expressed their interest in
contributing improvements to this document. I am looking forward to
those contributions - either as issues and discussion points, or as
concrete text snippets - in order to reflect the current best
understanding of the congestion control environment.


A new version of I-D, draft-scheffenegger-congress-rfc5033bis-00.txt
has been successfully submitted by Richard Scheffenegger and posted to
the IETF repository.

Name:           draft-scheffenegger-congress-rfc5033bis
Revision:       00
Title:          Specifying New Congestion Control Algorithms
Document date:  2023-02-17
Group:          Individual Submission
Pages:          11
URL:
https://www.ietf.org/archive/id/draft-scheffenegger-congress-rfc5033bis-00.txt
Status:
https://datatracker.ietf.org/doc/draft-scheffenegger-congress-rfc5033bis/
Html:
https://www.ietf.org/archive/id/draft-scheffenegger-congress-rfc5033bis-00.html
Htmlized:
https://datatracker.ietf.org/doc/html/draft-scheffenegger-congress-rfc5033bis


Abstract:
    The IETF's standard congestion control schemes have been widely shown
    to be inadequate for various environments (e.g., high-speed
    networks).  Recent research has yielded many alternate congestion
    control schemes that significantly differ from the IETF's congestion
    control principles.  Using these new congestion control schemes in
    the global Internet has possible ramifications to both the traffic
    using the new congestion control and to traffic using the currently
    standardized congestion control.  Therefore, the IETF must proceed
    with caution when dealing with alternate congestion control
    proposals.  The goal of this document is to provide guidance for
    considering alternate congestion control algorithms within the IETF.




The IETF Secretariat