abrupt speed changes and TCP

William Herrin bill at herrin.us
Thu Jan 30 19:46:16 UTC 2020


On Thu, Jan 30, 2020 at 10:58 AM Michael Thomas <mike at mtcc.com> wrote:
> So it occurs to me in the rollout of 5G just walking down the street you
> might shift back and forth between high speed 5G bands and 4G because of
> uneven deployment and all sorts of other reasons. It sounds like this
> could vary block by block practically.
>
> I assume TCP just views this as congestion? But with all of the
> congestion avoidance algorithms and the rapidly fluctuating bandwidth,
> wouldn't that result in the sender essentially adapting to the least
> common denominator (eg 4G)? The same goes with latency, I suppose for
> real time apps.

Hi Mike,

TCP speed is about two things: round trip time and packet loss.

If the round trip time gets long and then gets short again, TCP will
immediately adjust. It doesn't much care about the clock time, it
cares about whether it has received the ack it was looking for.

When packets are lost... trouble. TCP starts with 10 packets, waits
for an ack, doubles to 20 packets, waits for an ack, doubles to 40
packets, etc. This is called the congestion window and that early
phase is called "slow start." When the first packet is lost, that
doubling growth stops hard. Slows down to one or two additional
packets per round trip time. Then there's later packet loss.. get very
much and the congestion window starts halving and only growing pack at
a packet or two per round trip time. So if you drop packets switching
back and forth between 4G and 5G, that TCP connection will slow to a
crawl.

And just for fun: packet reordering is often interpreted as packet
loss. So if your 5G packet beats your earlier 4G packet to the
destination, it's as if you lost a packet.

Regards,
Bill Herrin



-- 
William Herrin
bill at herrin.us
https://bill.herrin.us/



More information about the NANOG mailing list