Home / Blogs

How the Internet Can Be Enormously Accelerated Without Fiber-Optic Cables or LEO Satellites

We got used to it: if we open a website, it's always like stop and go on a high-traffic highway or city traffic jam. At some point, we will reach the destination. The constant stalling is due to a traffic rule for the Internet called TCP (Transmission Control Protocol).

The TCP/IP protocol family comes from the American defense industry. It was introduced by DARPA (Defence Advanced Research Projects Agency) in the early 1970s. At that time, no one had the Internet as the need of the masses on the screen. It was used to control nuclear submarines.

Now 90% of all applications used on the Internet, such as web surfing, multimedia streaming, VoIP, IPTV, etc. use this protocol, which has been adapted over the last 40 years by many improvements (RFC's) to the current state of modern communication networks.

The TCP protocol is a technical achievement with a historical dimension; it still dominates the Internet. Meanwhile, however, it holds up the traffic, and it is barely changeable.

The industry has been struggling for years to eliminate bottlenecks through ever-increasing bandwidths. Their possibilities, however, reach their limits.

In view of the rapid increase in Internet usage, it has not yet been possible to eliminate the basic disadvantages of the TCP protocol or to replace it with a faster new one.

Therefore, attempts are being made to bridge the distance between server and client by setting up Content Delivery Networks (CDN), a tight installation of 5G transmission towers, low-flying micro- and nano-satellites and ever higher bandwidths. However, this causes high investment and operating costs, and it only alleviates the pain.

A new HTTP-SS Technology

The TCP rules are highly complex. The Researcher and Developer Dipl.-Ing. (FH) Klaus Rock and his team began more than 15 years ago to fight their way through the bushes and develop new rules that send all the information through the lines without stopping. Now the prototype is ready, and the patents are registered. The team has succeeded in solving the distance problem by eliminating the associated high bandwidth losses by developing a new HTTP-SS (Single Stream) Technology. Today, we can demonstrate how, independently of the existing infrastructure (copper cable, fiber optic cable, satellite), the flow rate is multiplied.

The "impossible" solution is there. It is software-based. Hardware conversions are not required. Runtime problems are eliminated, the available bandwidth can be more than doubled and the data volume to be transferred can be reduced by more than 50%. The technology is expected to be available for professional and private use this year, starting in Q4.

It will turn out that some Telecoms are right in their assessment that supplying the whole country with fiber optic cables or launching ten thousand of microsatellites cannot be economical. In fact, the existing copper pipes or geostationary satellites can be "doped" in such a way that even the rural areas get a very good supply quickly.

More information's you can securely download here:


By Klaus Rock, Researcher & Developer Dipl.-Ing. (FH) Klaus Rock

CircleID Newsletter The Weekly Wrap

More and more professionals are choosing to publish critical posts on CircleID from all corners of the Internet industry. If you find it hard to keep up daily, consider subscribing to our weekly digest. We will provide you a convenient summary report once a week sent directly to your inbox. It's a quick and easy read.

I make a point of reading CircleID. There is no getting around the utility of knowing what thoughtful people are thinking and saying about our industry.

Co-designer of the TCP/IP Protocols & the Architecture of the Internet


Some points to consider By Dave Crocker  –  Jul 13, 2019 2:04 pm PDT

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.)

A new HTTP-SS Technology By Klaus Rock  –  Jul 14, 2019 1:07 am PDT

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

Confused By Dave Crocker  –  Jul 14, 2019 5:08 am PDT

Your response leaves some basic points unclear. If your breakthrough technology is not "a proprietary protocol instead it uses standard package transmissions" that means that you are using the standard, open HTTP protocol, which runs over the standard, open TCP.  This suggests that you have merely made implementation choices that create performance that deviates from the standards. As for there being 'hundreds' of RFC that seek to deal with limitations to TCP, forgive me but no there aren't. As for your breakthrough technology not requiring changes in routers and the like, given that TCP and transport protocols in general are only implemented in end system hosts, it is unclear how your technology differs. As for your technology overcoming the problem of satellite latency issues, given the time it takes for a round-trip radio transmission via a geosynchronous satellite, I'd like to congratulate you on your finding a way around the laws of physics.

Snake oil senses tingling By The Famous Brett Watson  –  Jul 15, 2019 3:55 am PDT

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

This seems straightforwardly false, or at least true only with a lot of conditions which aren't mentioned.

The Latency Challenge By Klaus Rock  –  Jul 15, 2019 4:14 am PDT

TCP Latency is a big problem!

Details you can find here:



Confusing documentation of the problem with documentation of the solution By Dave Crocker  –  Jul 15, 2019 5:11 am PDT

Variously citing basic details about TCP or link behavior or server implementation issues or client implementation issues does nothing to tell us what exactly your revolutionary product actually does, and it especially does not tell us how it accomplishes this without deviating from any of the relevant standards that you claim to conform to.

It remains especially perplexing that you cite the problems of TCP yet claim you are using standard HTTP, which runs over that very same TCP.

(btw, RTT reflects both link behavior and server behavior, without distinguishing between them.)

Clearing your Doubts By Klaus Rock  –  Jul 15, 2019 7:28 am PDT

I am well aware of all these doubts and open questions.

Let me just shortly dig a little bit into the history of these tough R&D;Activities.

I started already 2000 to look behind the scene of all these issues and all contacted experts confirmed that my approach to solve this all is absolutely impossible.

There is no solution, Pasta!!

But this encouraged me even more to go straight forward because knowing the impossible is possible.

Here in Germany we say:

If all say it is impossible suddenly someone comes and make it possible.

But frankly saying it was a long way of failures, tries, mistakes and heavy frustrations.

September 2018 however there was a breakthrough similar to Mr. Edison's first working glowing thread.

The Architecture and Process Flows worked the first time and it delivered the expected results so I can confirm that this is no brain spook but reality.

Proof of Concept is now available and I have to push this new Technology towards a market ready product.

Hope I could clear a little bit your doubts.

Many words, but no technical content By Dave Crocker  –  Jul 15, 2019 1:55 pm PDT

Sorry to frustrate your stated hope but in spite of all the words about history, there was nothing in your posting that discussed the technical substance of this breakthrough you claim to have made.

EU Patent Law By Klaus Rock  –  Jul 15, 2019 11:24 pm PDT

The EU Patent Law does not allow disclosing technical Details before a proper application.

My Patent Attorney strictly advised me accordingly.

If somebody has a proof that you did so you will loose the Patents in case of an ongoing Patent infringement Litigation.

After submitting and proper Registration at the EU Patent Office I'm willing to dive deeper with you into the technical core solution which will then answer all your questions.

# 14 Reply (max. reply level reached)  |  Link  |  Report Problems
Answer to bring Clarity By Klaus Rock  –  Jul 14, 2019 6:16 am PDT

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.

How do you conform to the existing By Dave Crocker  –  Jul 15, 2019 5:12 am PDT

How do you conform to the existing standards, as you claim, while altering the number of handshakes those standards specify?

Meeting all Standards By Klaus Rock  –  Jul 15, 2019 5:42 am PDT

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.

Repeating my concern does not answer By Dave Crocker  –  Jul 15, 2019 1:56 pm PDT

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

Disclosing after Patent Registration By Klaus Rock  –  Jul 15, 2019 11:13 pm PDT


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.

There are other problems here By Michael Roberts  –  Jul 16, 2019 1:53 pm PDT

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.

Answers to there are other problems By Klaus Rock  –  Jul 17, 2019 1:19 am PDT

(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

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.

'Very old' does not guarantee a need to replace By Dave Crocker  –  Jul 17, 2019 3:32 am PDT

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.

TCP can not replaced in a reasonable time - but! By Klaus Rock  –  Jul 17, 2019 6:02 am PDT

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.

Repeating marketing language does not respond to technical queries By Dave Crocker  –  Jul 17, 2019 6:09 am PDT

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.

Technical deficit can only be fixed by contracts By Klaus Rock  –  Jul 17, 2019 6:57 am PDT

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.

Add Your Comments

 To post your comments, please login or create an account.



Brand Protection

Sponsored byAppdetex

Domain Names

Sponsored byVerisign


Sponsored byThreat Intelligence Platform

DNS Security

Sponsored byAfilias

New TLDs

Sponsored byAfilias


Sponsored byWhoisXML API


Sponsored byVerisign