Saturday, January 20, 2018

TCP ACK Packets & Provider Upload Limits

Providers are starting to roll out 1gbps download speeds to customers (business & residential) without using FTTH. Cable providers are doing this, typically, with DOCSIS 3.1 (though I've heard of a few doing it with DOCSIS 3.0). Cox offers 1gpbs/35mbps using D3.1, Comcast appears to be the same (it was really hard to find info on them), and I think AT&T customers are out of luck unless they have fiber.

So I was doing some math and I think it's right - but call me out if it's not.

(Math obviously varies if you're using 103 vs 210 units. I'm using the latter - 1024. And yes, I've simplified and not accounted for the downstream headers and such.)

1000 mbps = ~1,048,576,000 bits/sec ... / (1500 bytes ethernet MTU * 8 = 12000) = ~87,380 packets/sec.

So, assuming we're using TCP - every packet needs it's ACK... which is ~54 bytes * 8 = ~432 bits.

That gives us: 87,380 ACKs/sec * 432 bits = 37,748,160 bits/sec of TCP ACKs... or ~36mbps.

None of this accounts for duplicates, retransmissions, drops, etc. I'm assuming best-case-scenario (which I know full well that it's not).

So, if my math is correct, that seems to mean that anyone selling 1000 mbps download bandwidth while only providing 35mbps of upload is actually selling you download bandwidth that's mathematically impossible to obtain unless you're using UDP or another connectionless protocol (whee, let's download all of our files with TFTP - even that sends its own ACKs on Layer 7, lol - I just happen to have a TFTP capture open, the acks are 50 bytes on the wire.)

Obviously for those with deep enough pockets to be on a SONET ring with a synchronous 1000/1000+ connection (or be lucky enough to have some form of cheaper fiber deployed), this is a non-issue.

Am I thinking clearly? I did the math several times and I'm kinda in shock. I hadn't given it much thought until recently.



No comments:

Post a Comment