Traffic throttling for bit rate constraint is not directly related to ping, that's a separate routing decision made by the various trunks on the Internet to keep massive traffic from single target from saturating large capacity data lines.
Er, OK. "Ping" (ICMP in this instance) has nothing to do with data rates. It doesn't measure anything except the round trip time. There is no direct or indirect relationship. This is the only thing I have been discussing in response to the
original question.
As I have said multiple times in this thread you could have a connection with massive bandwidth (gigabytes per second) but huge latency (round trip time on a wall clock). For example an optical fiber to the tropical moon of Endor: you may get good data rates (bytes/second) but slow transit times from data in at one end to data out at the other.
Let me be very clear in case my point was lost in translation: there is no relationship between an ICMP ping (latency) and the bandwidth (data rate) between two points.
The water pipe analogy is wholly correct and frequently used to teach this distinction.
PING can drastically effect TCP/IP bitrate outside of router based throttle simply because TCP/IP requires each and every packet to be acknowledge send and received
I have no idea how ICMP ping here is supposed to relate to TCP/IP acknowledgements. The two are not inter-related in any way.
With regard to acknowledgements per packet, reference to
https://tools.ietf.org/html/rfc2018 is in order.
and there can be some pretty serious delays if something arives out of order and it has to re-negotiate the packet order.
Packet order is not "renegotiated", the OS simply reorders data in memory before it is passed to the application.
There are many things that affect absolute speed in TCP/IP: slow start, window scaling, MTU, TCP options, the evil bit. It is impossible to just throw together sentences with the word "dynamic" and "cloud" and "internet hub".