TCP/IP had nothing to do with nuclear submarines or “the defense industry”. Though funded by the Department of Defense, the work was done by the open research and development community. TCP’s flow control mechanisms have evolved over time, as experience with real-world operation has dictated.  When someone goes to replace it, they need to provide extremely detailed documentation and operational data to show the benefits, because garnering such benefits over the open Internet and at scale is challenging.

Contrary to the article, there have multiple, new transport and transport-like protocols deployed, such as RTP, RTCWeb, SIP, and SCTP. Also the reference to 5G is confusing since it appears to be predicated on the view that 5G will replace the backbone of the Internet, rather than only provide the last-mile access for mobile devices, while remaining otherwise fully integrated with Internet services.

Based on the http-ss.com website, this appears to be an effort to develop a proprietary corner on web transport.  Consider the open QUIC effort in the IETF instead.  (FWIW, I have no involvement in it.)

The most popular network protocol in the world, TCP/IP protocol suite, was designed in 1970s by 2 DARPA scientists—Vint Cerf and Bob Kahn, persons most often called the fathers of the Internet.

There is no doubt that there is a military background to insure that important orders will reach securely there destinations even routes are destroyed and package will smartly find themselves alternative ones.

Experts are demanding since a long time to substitute this very old pessimistic TCP Protocol by another modern robust optimistic one which fulfills the QoS Standards of modern high speed Communication Networks.

Hundreds of RFC’s are submitted and integrated meanwhile to fix weak points within this outdated Protocol which leads into misinterpretations and wrong reactions on it instead of eliminating the evil at the root.

QUIC, RTP, RTCWeb, SIP or SCTP are simply another tries to make Data Transmission for specific Applications faster because TCP can’t to it.

The HTTP-SS Architecture and Technology is by no way a proprietary protocol instead it uses standard package transmissions in a very smart and optimistic way to guarantee a latency free and secure Data Delivery in modern high speed Communication Networks.

So there is no need to publish something to Committees or the Internet World.

Nothing is to change in existing Network Infrastructures and works fully transparent.

Either in all Kinds of Servers (WEB, Cloud, EDGE, Streaming etc. etc.) nor at the Client Site (Windows, Android, iOS).

This was by the way the greatest challenge to correct the problems at the root without developing a new or changing an existing Protocol, updating Servers, Clients and all kinds of Rooters (DSL, VSAT, SWITCHES).

The 5G Specifications claims to provide speeds upto 1 Gbit/s but can only be reached at a short distance (within a Cell max. 1 KM2).

Going beyond greater Distances TCP will slow down it dramatically because of his Protocol Overhead, send- and receive Buffer Dependency and Latency Sensitivity.

As a simple example having 100 Mbit/s available at 30 ms RTT you can use only 20 Mbit/s with TCP.

HTTP-SS does not know these Problems and is therefore best suited for future 5G Networks especially because it already integrates the very important Network Slicing Feature which 5G does not right now.

Last but not Least it opens the door for accepted Satellite based Internet Services (LEO, MEO, GEO) because the ugly Latency Problem in this Area does not exist anymore.

Proof of Concept is available.

Please see: https://twitter.com/klausrock3/status/1141253334562684928

The Secret lies in the amount of necessary Handshakes no matter which protocol is used.

QUIC tries also to reduce TLS handshakes via the Standard UDP protocol but implements most of all the TCP drawbacks to be compatible with all existing Routers and Servers.

Very important in this Context is to understand how a protocol is interacting between Sender and Receiver and find a Method to reduce the Handshakes to a Minimum which is going to 1.

When we look to a Satellite Link we have of course physical Laws which is impossible to outwit.

But it makes a difference using 100’s of Handshakes (TCP Connection Setup, ACK, Keep Alive, Slow Start, provoked Retransmission’s, TLS, HTTP etc. etc.,) or even get all Data with one request and one shot from Sender to Receiver.

But to accomplish this, a complex and very powerful Smart Server Architecture behind the Scene is necessary.

This and how to integrate all transparent into existing Network Infrastructures and moreover to fulfill all the existing Internet Standards was the most import work.

Not an easy task which needed over a decade of hart R&D;Work.

Yes this is exactly the solution.

Fulfilling all existing standards but at the same time reducing the handshakes to 1.

Sounds unrealistic but it works and will be filed as another Patent to the European Patent Office in Munich until end of this month.

When filed I can forward to you the Patent Application Link.

I asked *how* you reduce handshakes without violating the standards.  You did not answer that basic and essential question.

Sorry

This is a trade secret which can only be remedied after a proper patent application.

Just ongoing and accomplished end of July.

Priority 9.2018

Extended by a 5G Network Sclicing Connector so HTTP-SS is ideally suited for the coming 5G Mobile Networks.

After that I can forward to you the link of the registrations.

In addition to the points made by Dave and Brett, here are other items:
(1) Internet Engineers are always seeking improvements to the protocols, but do not look kindly on performance claims not supported by third party supervised data to support the claims. Pls return to this forum when you have them.
(2) One of the great strengths of Internet engineering is that the fundamental protocols, which function as standards, are open source and always have been. It would improve the reception for your work if you committed to an open source future.
(3) The DARPA unclassified research programs of the last fifty plus years have contributed immeasurably to technical progress in a host of areas, not just the Internet. If your reference to the Defense Department is intended to denigrate TCP/IP for that reason, you are badly misinformed.

(1) In these times performance and speed in modern communication networks is
  everything. Internet Engineers can not ignore this and rely on it that third
  parties will fix this problem by all kinds of additional RFC’s and more and more
  bandwidth.
 
  Moreover the performance approach must be an important part of the standard
  protocol design and standardization.
 
(2) The patents are shortly published and everybody can use this technology.

(3) My indention with this DARPA history statement was not to denigrate their
  research work only on TCP/IP.

  I just wanted to express that TCP/IP is already very old and should be replaced
  by a new one which is perfect suited for modern high-speed networks and computing
  power of existing and future server architectures and hardware.
 
  Only to mention: Fiber Optic, LEO Satellites, 5G, QUIC, AI, QUANTUM etc. etc.

Your language implies that TCP and IP work has not been concerned with performance, but they have performed well across seven or eight orders of magnitude increase in bandwidth. So your premise is not supported by 40 years of deployment experience.  Also your conclusion doesn’t match the claim of your work.  A call for ‘replacement’ is not satisfied by work that you have characterized as staying within the protocol specifications.

There is absolutely no doubt that TCP works well and delivers a reliable data delivery over decades and can not replaced in a manageable time
 
Even Google’s QUIC protocol need years until all active network components like switches rooters, servers and mobile devices will work without any problem.
 
But at the root TCP does not fulfill the requirements of modern communication networks in our times.

Rather, it is a brake to satisfy the current bandwidth needs which doubles every year.
 
Great efforts are made only to reduce the distance between the sender and the receiver in order to get a grip on the bandwidth-destroying latency problem caused by TCP.

Only to mention low orbit satellites, small 5G cells (1 KM2) and content delivery networks (CDN).
 
HTTP-SS through his new architecture and smart data transmission technology does not know this distance problem and is therefor latency resistant.
 
No matter whether there is a RTT of 30, 50, 100 or 1000 ms HTTP-SS provides always the
maximum available bandwidth up-to the Gbit/s areas and beyond.

It’s now clear that technical substance, to substantiate the claims being made, is not forthcoming.  Let us know when you can remedy that fundamental deficiency in your efforts to market your breakthrough work.

No one would disclose technical secrets on such a platform.
All specifications and user manuals are ready for system integration.
If you want to have a deep insight into all technical details which
answers all your questions - contracts like NDA, MOU etc. etc. are necessary.