Re: abrupt speed changes and TCP
I'd hope that the 4G and 5G radios might operate in such a way that it would intelligently manage packets coming from either radio and, when possible, seemlessly merge them virtually and then pass them to the underlying OS stack. Or have the OS do it. Maybe this is why the rollout of 5G is slow as the carriers and handset manufacturers figure out the issues of jumping between 4G and 5G networks. It may be why Apple decided to hold off on 5G in September 2019. Didn't they figure this out between 3G and LTE/4G? Or was it not a problem? And maybe it won't be a problem? On Thu, 30 Jan 2020, Ahmed Borno wrote: I am only guessing here, but I think the Apps of today would have their own built in mechanisms to work around lower layers, starting with DB query timeouts, load balancers performance based resets. CDN segmentation, QUIC, HTTP2etc But it is a valid question and I'd like to know from people with real experience in TCP performance impact of 4 to 5G switching. ~A On Thu, Jan 30, 2020 at 10:59 AM Michael Thomas 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. Mike --- Peter Beckman Internet Guy beck...@angryox.com http://www.angryox.com/ ---
Re: abrupt speed changes and TCP
On 1/30/20 11:46 AM, William Herrin wrote: On Thu, Jan 30, 2020 at 10:58 AM Michael Thomas 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. I kinda hope that Fred will chime in here because he's usually clued in about research stuff. I suppose at some level we've been here with the transition between 3 and 4G, but streaming, etc were a lot less common then. So do you think it would effectively settle into the least common denominator or would it be an ongoing cluster fuck? Mike
Re: abrupt speed changes and TCP
I am only guessing here, but I think the Apps of today would have their own built in mechanisms to work around lower layers, starting with DB query timeouts, load balancers performance based resets. CDN segmentation, QUIC, HTTP2etc But it is a valid question and I'd like to know from people with real experience in TCP performance impact of 4 to 5G switching. ~A On Thu, Jan 30, 2020 at 10:59 AM Michael Thomas 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. > > Mike > >
Re: abrupt speed changes and TCP
On Thu, Jan 30, 2020 at 10:58 AM Michael Thomas 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 b...@herrin.us https://bill.herrin.us/
abrupt speed changes and TCP
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. Mike
