Internet speeds
-
So I made this chart of AT&T and Spectrum internet speeds offered by their websites when I type in my home address.
My current speed seems to be 15 down, 1.5 up, which is not only not offered by AT&T, but also not offered by MilwaukeePC.
Side WTF: The MilwaukeePC form to see which speeds are available at your address simply runs
alert('THANK YOU! Your information has been successfully sent.')regardless of whether any of the form fields were filled, and the "captcha" seems to always be "What is 1+3?"
-
I'm thinking having that many dimensions/values in a bar graph should be a crime.
In other news I'd pick something like 200/10, seems like a sweet spot in price performance.
Unless you need the upload speed, of course.
-
@ben_lubar said in Internet speeds:
Side WTF: The MilwaukeePC form to see which speeds are available at your address simply runs
alert('THANK YOU! Your information has been successfully sent.')regardless of whether any of the form fields were filledBonus side WTF: It seems that they use JQuery to do this. Not to catch the form submission. JQuery is used to pop up the alert box and basically nothing else.
-
@ben_lubar said in Internet speeds:
and the "captcha" seems to always be "What is 1+3?"
The correct answer is "The up and down speed in bits per second"
-
@hungrier said in Internet speeds:
@ben_lubar said in Internet speeds:
and the "captcha" seems to always be "What is 1+3?"
The correct answer is "The up and down speed in bits per second"
I wonder what the minimum bits per second is before you're not even getting a whole TCP packet. Probably in the hundreds.
-
@swayde said in Internet speeds:
I'm thinking having that many dimensions/values in a bar graph should be a crime.
additionally, for ISPs, a download speed distribution graph across their subscriber base as well as a time series chart of average internet speed over a single day should be required
-
@ben_lubar said in Internet speeds:
@hungrier said in Internet speeds:
@ben_lubar said in Internet speeds:
and the "captcha" seems to always be "What is 1+3?"
The correct answer is "The up and down speed in bits per second"
I wonder what the minimum bits per second is before you're not even getting a whole TCP packet. Probably in the hundreds.
-
@bb36e said in Internet speeds:
additionally, for ISPs, a download speed distribution graph across their subscriber base as well as a time series chart of average internet speed over a single day should be required
I'd take 10% of the maximum speed for any of the Spectrum plans over what I have now.
-
@ben_lubar said in Internet speeds:
My current speed seems to be 15 down, 1.5 up
Which sounds like ATT25 after the physics of a shoddy line are accounted for.
-
@ben_lubar said in Internet speeds:
@hungrier said in Internet speeds:
@ben_lubar said in Internet speeds:
and the "captcha" seems to always be "What is 1+3?"
The correct answer is "The up and down speed in bits per second"
I wonder what the minimum bits per second is before you're not even getting a whole TCP packet. Probably in the hundreds.
If we just consider the TCP/IP part, a basic no-options SYN packet (or a SYN/ACK, or the ACK that ACKs the SYN/ACK)(1) is 20 bytes for the IP header (40 for IPv6) plus 20 bytes for the TCP header, and no data payload. That's 40 bytes = 320 bits for IPv4, or 60 bytes = 480 bits for IPv6. So yes, "in the hundreds".
(1) Don't get me started on the "four way", or, more precisely, "dual two-way" handshake, please.
-
@swayde said in Internet speeds:
I'm thinking having that many dimensions/values in a bar graph should be a crime.
In other news I'd pick something like 200/10, seems like a sweet spot in price performance.
Unless you need the upload speed, of course.At 300 Mbps down of TCP, Windows 10 with no special tuning will be sending 7Mbps of ACK packets up.
My own fibre link is nominally 200/100. When the traffic shaper is on, it's actually about 300/100, and when the traffic shaper is OFF, I think it's GIG/100, and I've seen it as high as 922 down, which stresses my UTM a bit. Poor thing is only rated up to 1.1Gbps, but it is at least fanless.
-
@Steve_The_Cynic said in Internet speeds:
four way
Four way handshake? I thought it was three packets for TCP and five and a half for TLS 1.3.
-
@ben_lubar said in Internet speeds:
@Steve_The_Cynic said in Internet speeds:
four way
Four way handshake? I thought it was three packets for TCP and five and a half for TLS 1.3.
Normally, you see SYN to the server, SYN/ACK to the client, ACK to the server, which is the three-way handshake that everyone thinks is THE way to open a TCP connection.
Sadly, there's no such thing as A TCP connection. The best you have is two half-connections. One (that I'll call "CS") carries data to the server and acknowledgements to the client, and the other ("SC") carries data to the client and acknowledgements to the server. If the port numbers are chosen carefully (they normally are), you can carry acknowledgement information for SC in data packets for CS, and vice versa.
However, the RFCs do not mandate that you open the two half-connections in a three-way handshake. It's theoretically possible to open just one (CS), send some data, and then close it. Or, if you want both open, you can do SYN(CS), ACK(CS) then later SYN(SC), ACK(SC). The three-way shake is SYN(CS), SYN(SC)/ACK(CS), ACK(SC).
It's even theoretically possible for the packet sequence to be SYN(CS), SYN(SC), ACK(SC), ACK(CS), as FOUR packets.
-
@Steve_The_Cynic pretty sure you can't do that - not because the spec forbids it, but because it's probably very rare for a NAT to support that kind of thing.
-
@Steve_The_Cynic said in Internet speeds:
At 300 Mbps down of TCP, Windows 10 with no special tuning will be sending 7Mbps of ACK packets up.
Wouldn't that depend on the packet sizes? ACK packets are 40 or 60 bytes each, right? With jumbo frames, you can fit 8960 bytes of payload into a TCP packet. That's only 167kbps of ACKs.
-
@ben_lubar said in Internet speeds:
Wouldn't that depend on the packet sizes? ACK packets are 40 or 60 bytes each, right? With jumbo frames, you can fit 8960 bytes of payload into a TCP packet. That's only 167kbps of ACKs.
Unless you have black fiber, MTU is 1.5k ( obviously exceptions exists https://www.tp-link.com/us/FAQ-190.html )
-
@ben_lubar Not every incoming segment has to be acknowledged individually. At a 256kb window size, it is perfectly reasonable to only send an acknowledgement every 64kb or 128kb, even when 1.5kb packets are in use.
-
@PleegWat said in Internet speeds:
window size
y'know, I've heard that term but never actually looked up what that did.
-
@ben_lubar The window size (in bytes) is advertised by the receiver and indicates how much unacknowledged data can be 'in flight' before the sender has to wait for an acknowledgement. If a peer receives a packet which is beyond the end of its receive window it should drop it immediately.
Retransmits occur if after a certain amount of time the packet has not been acknowledged yet; TCP does not have a 'negative acknowledgement'. Large window sizes relative to packet size mean a single missing packet can cause a lot of data to be retransmitted. Small window sizes can increase the impact of latency on the bandwidth to a certain destination.
-
@ben_lubar said in Internet speeds:
@Steve_The_Cynic pretty sure you can't do that - not because the spec forbids it, but because it's probably very rare for a NAT to support that kind of thing.
The NAT itself shouldn't care, but many packet-inspecting IDS / IPS firewalls (that also do NAT) don't support it.
When I say that the NAT shouldn't care:
- SYN(CS) creates a IP+port<=>IP'+port' mapping.
- ACK(CS) should in theory be able to be de-mapped by running the mapping in reverse.
- SYN(SC), should also be able to be de-mapped, whether it arrives before or after ACK(CS)
- ACK(SC) will be able to be mapped regardless of timing.
All that's only true if the NAT doesn't care about the connection states, of course, but to do the translation once it has been established by SYN(CS), the NAT doesn't need to care, much. (It does have to care if it wants to correctly handle connection termination, and most NATs won't, as you say, handle the four-way / dual two-way handshake correctly.)
-
@ben_lubar said in Internet speeds:
@Steve_The_Cynic said in Internet speeds:
At 300 Mbps down of TCP, Windows 10 with no special tuning will be sending 7Mbps of ACK packets up.
Wouldn't that depend on the packet sizes? ACK packets are 40 or 60 bytes each, right? With jumbo frames, you can fit 8960 bytes of payload into a TCP packet. That's only 167kbps of ACKs.
See the other answers about window sizes and delayed-ACK, but note also that the figure of 7 Mbps is an empirical observation, not a theoretical calculation.
-
@PleegWat said in Internet speeds:
@ben_lubar The window size (in bytes) is advertised by the receiver and indicates how much unacknowledged data can be 'in flight' before the sender has to wait for an acknowledgement. If a peer receives a packet which is beyond the end of its receive window it should drop it immediately.
Retransmits occur if after a certain amount of time the packet has not been acknowledged yet; TCP does not have a 'negative acknowledgement'. Large window sizes relative to packet size mean a single missing packet can cause a lot of data to be retransmitted. Small window sizes can increase the impact of latency on the bandwidth to a certain destination.
More modern revisions of TCP do have a form of limited negative-ACK, called "SACK", for "selective ACK". A receiver can say to the sender, "I received this chunk and this chunk and this chunk, but not the gaps in between." See RFC 2018.
-
@Steve_The_Cynic said in Internet speeds:
However, the RFCs do not mandate that you open the two half-connections in a three-way handshake. It's theoretically possible to open just one (CS), send some data, and then close it. Or, if you want both open, you can do SYN(CS), ACK(CS) then later SYN(SC), ACK(SC). The three-way shake is SYN(CS), SYN(SC)/ACK(CS), ACK(SC).
The client is allowed to send data with the SYN segment, but I'm not sure if it would be able to formulate a valid segment with additional data, since it would not have an acknowledgement position to send at that point and I'm pretty sure packets on which none of SYN, RST, and ACK are sent are always invalid. Certainly from the server's perspective if such a second data packet sent before server SYN would arrive before the initial client SYN then it should be dropped:
RFC 793, discussing incoming packets in LISTEN state:
fourth other text or control
Any other control or text-bearing segment (not containing SYN) must have an ACK and thus would be discarded by the ACK processing. An incoming RST segment could not be valid, since it could not have been sent in response to anything sent by this incarnation of the connection. So you are unlikely to get here, but if you do, drop the segment, and return.
The server also wouldn't be able to acknowledge this data without sending SYN, as while the client in SYN-SENT would need to verify the acknowledgement position on any incoming segment, it would not actually be doing any acknowledgement processing in that state.
RFC 793, discussing incoming packets in SYN-SENT state:
fifth, if neither of the SYN or RST bits is set then drop the segment and return.
Indicating no part of such an incoming server packet would affect client state.
Of course later RFCs may have modified this, but I think that's unlikely as all later additions have been formulated to work nicely with existing hardware which doesn't support those additions.
@Steve_The_Cynic said in Internet speeds:
It's even theoretically possible for the packet sequence to be SYN(CS), SYN(SC), ACK(SC), ACK(CS), as FOUR packets.
That's a simultaneous connect, which is perfectly valid.
-
@Steve_The_Cynic said in Internet speeds:
@ben_lubar said in Internet speeds:
@hungrier said in Internet speeds:
@ben_lubar said in Internet speeds:
and the "captcha" seems to always be "What is 1+3?"
The correct answer is "The up and down speed in bits per second"
I wonder what the minimum bits per second is before you're not even getting a whole TCP packet. Probably in the hundreds.
If we just consider the TCP/IP part, a basic no-options SYN packet (or a SYN/ACK, or the ACK that ACKs the SYN/ACK)(1) is 20 bytes for the IP header (40 for IPv6) plus 20 bytes for the TCP header, and no data payload. That's 40 bytes = 320 bits for IPv4, or 60 bytes = 480 bits for IPv6. So yes, "in the hundreds".
(1) Don't get me started on the "four way", or, more precisely, "dual two-way" handshake, please.
How long can that process take before it times out and starts over from the beginning? That would be the absolute lower limit on your connection speed, right?
-
@anotherusername said in Internet speeds:
How long can that process take before it times out and starts over from the beginning?
It varies, but 20–30 seconds is entirely possible. :(
-
@dkf It's what makes spotty mobile connections such a pain in the ass to be in.
If the application sees you have no connection at all, great, it gives up and shows the offline content or at least an error message. But if literally just 4 or 5 bytes manage to go through every minute... you're stuck with a spinner and a blank screen forever.
