Lossy cogent p2p experiences?

William Herrin bill at herrin.us
Sun Sep 3 14:49:03 UTC 2023


On Thu, Aug 31, 2023 at 2:42 PM David Hubbard
<dhubbard at 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 at herrin.us
https://bill.herrin.us/


More information about the NANOG mailing list