On Thu, Aug 31, 2023 at 2:42 PM David Hubbard <dhubbard@dino.hostasaurus.com> wrote:
any new TCP flow is subject to numerous dropped packets at establishment and then ongoing loss every five to ten seconds.
Hi David, That sounds like normal TCP behavior over a long fat pipe. After establishment, TCP sends a burst of 10 packets at wire speed. There's a long delay and then they basically get acked all at once so it sends another burst of 20 packets this time. This doubling burst repeats itself until one of the bursts overwhelms the buffers of a mid-path device, causing one or a bunch of them to be lost. That kicks it out of "slow start" so that it stops trying to double the window size every time. Depending on how aggressive your congestion control algorithm is, it then slightly increases the window size until it loses packets, and then falls back to a smaller size. It actually takes quite a while for the packets to spread out over the whole round trip time. They like to stay bunched up in bursts. If those bursts align with other users' traffic and overwhelm a midpoint buffer again, well, there you go. I have a hypothesis that TCP performance could be improved by intentionally spreading out the early packets. Essentially, upon receiving an ack to the first packet that contained data, start a rate limiter that allows only one packet per 1/20th of the round trip time to be sent for the next 20 packets. I left the job where I was looking at that and haven't been back to it. Regards, Bill Herrin -- William Herrin bill@herrin.us https://bill.herrin.us/