[Bloat] An interesting, and probably erroneous, article on 5G and TCP buffering

[Bloat] An interesting, and probably erroneous, article on 5G and TCP buffering

[Dave Collier-Brown]

[-- Attachment #1: Type: text/plain, Size: 2439 bytes --]

In "the morning paper", https://blog.acolyer.org/2020/10/05/understanding-operational-5g/, reviewing http://xyzhang.ucsd.edu/papers/DXu_SIGCOMM20_5Gmeasure.pdf

With TCP the story is less compelling, with common congestion control algorithms not suiting 5G characteristics

Traditional loss/delay based TPC algorithms suffer from extremely low bandwidth utilization – only 21.1%, 31.9%, 12.1%, 14.3% for Reno, Cubic, Vegas, and Veno, respectively!

Only being able to use 20% of the bandwidth is clearly not good (on 4G the same algorithms achieve 50-70%). BBR<https://blog.acolyer.org/2017/03/31/bbr-congestion-based-congestion-control/> does much better with 5G, achieving 82.5% utilization. An investigation reveals the problem to be caused by buffer sizes. In the radio portion of the network, 5G buffer sizes are 5x 4G, but within the wired portion of the network only about 2.5x (this is with a 1000 Mbps provisioned cloud server). At the same time the download capacity of 5G is about 5x greater: "i.e., the capacity growth is incommensurate with the buffer size expansion in the wireline network." Doubling the wireline buffer size would alleviate the problem. BBR does better because it is less sensitive to packet loss/delay.

--
David Collier-Brown,         | Always do right. This will gratify
System Programmer and Author | some people and astonish the rest
dave.collier-brown@indexexchange.com<mailto:dave.collier-brown@indexexchange.com> |              -- Mark Twain



CONFIDENTIALITY NOTICE AND DISCLAIMER : This telecommunication, including any and all attachments, contains confidential information intended only for the person(s) to whom it is addressed. Any dissemination, distribution, copying or disclosure is strictly prohibited and is not a waiver of confidentiality. If you have received this telecommunication in error, please notify the sender immediately by return electronic mail and delete the message from your inbox and deleted items folders. This telecommunication does not constitute an express or implied agreement to conduct transactions by electronic means, nor does it constitute a contract offer, a contract amendment or an acceptance of a contract offer. Contract terms contained in this telecommunication are subject to legal review and the completion of formal documentation and are not binding until same is confirmed in writing and has been signed by an authorized signatory.

[-- Attachment #2: Type: text/html, Size: 6571 bytes --]

Re: [Bloat] An interesting, and probably erroneous, article on 5G and TCP buffering

[Michael Richardson]

[-- Attachment #1: Type: text/plain, Size: 1346 bytes --]


Dave Collier-Brown <dave.collier-brown@indexexchange.com> wrote:
    > Only being able to use 20% of the bandwidth is clearly not good (on 4G
    > the same algorithms achieve
    > 50-70%). BBR<https://blog.acolyer.org/2017/03/31/bbr-congestion-based-congestion-control/>
    > does much better with 5G, achieving 82.5% utilization. An investigation
    > reveals the problem to be caused by buffer sizes. In the radio portion
    > of the network, 5G buffer sizes are 5x 4G, but within the wired portion
    > of the network only about 2.5x (this is with a 1000 Mbps provisioned
    > cloud server). At the same time the download capacity of 5G is about 5x
    > greater: "i.e., the capacity growth is incommensurate with the buffer
    > size expansion in the wireline network." Doubling the wireline buffer
    > size would alleviate the problem. BBR does better because it is less
    > sensitive to packet loss/delay.

Is this with one flow or many thousands one would expect a real network to have?

Since we want buffers to be empty, it's unclear to me if TxOps are really
being lost, or what.


--
]               Never tell me the odds!                 | ipv6 mesh networks [
]   Michael Richardson, Sandelman Software Works        |    IoT architect   [
]     mcr@sandelman.ca  http://www.sandelman.ca/        |   ruby on rails    [


[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 487 bytes --]