abrupt speed changes and TCP

Peter Beckman beckman at angryox.com
Fri Jan 31 02:40:18 UTC 2020


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,
> HTTP2....etc
>
> 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 <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.
>>
>> Mike
>>
>>
>

---------------------------------------------------------------------------
Peter Beckman                                                  Internet Guy
beckman at angryox.com                                 http://www.angryox.com/
---------------------------------------------------------------------------



More information about the NANOG mailing list