[Ntp] In reference to NTP protocols 3 & 4 Quality of Service Protocol & the TCP & UDP & QUICC Protocols : https://www.ietf.org/archive/id/draft-scheffenegger-congress-rfc5033bis-00.txt

[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

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