5 ms·

The overwhelming issues with WiFi are 1. It is slow to connect, taking multiple seconds rather than a few milliseconds. (Wifi unreliability would have much les

• dataflow 2y ago
  > It is slow to connect, taking multiple seconds rather than a few milliseconds. What is the reason for this?
  • zamadatix 2y ago
    For standard Wi-Fi the biggest factors for a fresh association are: - Discovery. You have to wait to see which saved networks are broadcasting. Broadcasting more often = less efficient airspace for already attached clients. Broadcasting less often = longer delay for clients to "see" the network when they start listening. - External authentication. E.g. if you're doing RADIUS auth or MAC auth with an external database instead of a PSK exchange there is extra time in setting up this exchange and then waiting for the external authenticator to validate it. - DHCP / NDP. Wi-Fi assumes you more or less want to emulate a standard Ethernet + IP session but over this new fangled air connection. This is an additional delay for an additional exchange with the services responsible for this. Typical clients e.g. Windows will also perform extra address duplication checks slowing things further. There are some extensions in more modern Wi-Fi standards for clients that want to "sleep" for long periods, immediately do some stuff, then sleep for long periods (like IoT). Particularly TWT (target wait time). These, and more, are already found in purpose built protocols like LoRa/LoRaWAN though.
    • londons_explore 2y ago
      Discovery could take up to 100 milliseconds. All the others, if properly implemented, are speed-of-light things. Eg. RADIUS auth to an external database on the same physical site should easily be doable within 1 millisecond. It's not like that database has a multi-second queue of other users to connect first.
      • Two4 2y ago
        You've never dealt with enterprise networks where the auth server lived on a different continent
        • nine_k 2y ago
          A different continent is usually a few hundred milliseconds away. (The worst delay I had in my life was between me in Europe and the target machines in Japan, and the round-trip still was about a second.) The response time of an under-provisioned or poorly implemented API endpoint on a machine in the same rack can be multiple seconds though :(
        • lucb1e 2y ago
          an edge case you can come up with != typical experience. What you're saying is not far fetched, but also not the common case, especially at home and it's not like this latency only occurs on RADII networks
      • zamadatix 2y ago
        While 100 milliseconds (well, slightly more actually - 100 time units != 100 ms, it's just very close) is the default beacon interval, most clients will scan for longer than that to ensure they hear the best SSID (and AP for that) before initiating a connection just to throw it away/immediately roam anyways. This allows higher beacon intervals to work without the clients thrashing themselves between advertising stations. Also, not every beacon will actually make it through heard so connections generally assume they shouldn't just go with the first time they hear it. As for how a RADIUS auth should take 1 ms... sure, and updating macOS on an M3 shouldn't take an hour either. I'm not saying how tech should be, I'm saying how it is and which steps often add significant latency as implemented. Even a dedicated Aruba ClearPass authentication server on prem scaled for 25k clients can't handle 1,000 auths/second (ignoring that AD would fall over before then). Usually the drivers are also part of the problem (both on the AP and the client). Same with OS software around it. Things that should be instant just aren't. E.g. go try to disconnect and reconnect to the same SSID on macOS via the GUI. If you do that in ~1 second you should get an error - not a delay, an error that it hadn't synced up with its own connection state and couldn't possibly figure out how to try to connect. None of that is actually Wi-Fi, if you implement an IoT device with an embedded radio and sidestep a lot of those layers suddenly the protocol is much quicker to connect (still not as fast as some simpler ones though).
• tjoff 2y ago
  1. Can't remember when this had any effect on my use. Unreliability wouldn't improve either if you cut the connection and reconnected as it would bring down all open connections. No thanks. 2. Been years since I've seen one of those. The use-case is pretty much being abroad or in a really remote area with bad cell reception. And even in those cases it seems those captive portals are going out of fashion. All in all, so far down the list that I probably wouldn't think of them even if I tried.
  • habosa 2y ago
    It’s been years since you’ve seen a captive portal? I can’t remember the last time I saw a WiFi network that didn’t have a password that also had no captive portal. I’m pretty sure every airport in the US has captive portal WiFi.
    • olyjohn 2y ago
      I haven't seen one either. But I haven't needed to connect to a public WiFi point in years. That might be the difference. Usually where there is public WiFi I can just tether on my own phone.
    • Marsymars 2y ago
      I expect their point, which jives with my experience, is that cell coverage is now good enough that there’s no need to connect to random wifi networks where you have to deal with their portals and contend with worse performance than your cell connection.
      • johnnyanmac 2y ago
        I can't even get "5g" in my own house. I had to order a signal strengthener (fortunately for no extra cost)... That connects to my wifi. And the speeds make me wonder if we really came that much farther from 3G. The US mobile infrastructure is an absolute sham, even in the outskirts of a large city. I can only imagine how some entire states fare.
      • nine_k 2y ago
• sneak 2y ago
  It (almost always) lacks forward secrecy or, indeed, any encryption at all when using unauthenticated networks. These are much bigger problems. The fact that they haven’t been fixed is so glaring that one can attribute it to enemy action, not carelessness.
• tzs 2y ago
  > I cannot for the life of me understand why the standards committee cares much about various other minor improvements when these issues are still unsolved after two decades. It's different people. WiFi is a pretty wide field. There are plenty of people whose interests and/or qualifications only extend to part of it. Should they just sit around twiddling their thumbs if the parts they can contribute to aren't the parts with the biggest issues?
  • jessriedel 2y ago
    You can re-phrase my main question as: why is there enough interest in doing these minor improvements when there is apparently little interest in fixing the major and long-lasting deficiencies?
    • 14 2y ago
      I think what you call minor improvements would be considered significant to others who may benefit from it.
    • MerManMaid 2y ago
      In the context of this thread, IEEE aren't the ones who can improve such things. WiFi 6E and WiFi 7 both make considerable improvements on connect time but at the end of the day, they deal with the "backend" if you will. They have no control over crappy WiFi NIC cards that delay connections or how Apple displays captive portals.
    • cheema33 2y ago
      > why is there enough interest in doing these minor improvements... Why are people working on improvements to wi-fi at all, when there are people around the world dying of hunger? If you can answer that, I think you'll be able to answer your own question.
      • jessriedel 2y ago
        No. Ending hunger is hard.
• nine_k 2y ago
  1. Wi-Fi is of course capable of reconnecting fast, so you don't even notice it. When you see a multiple seconds worth of a connectivity gap, it's likely not because Wi-Fi is stupidly waiting. Most probably it's radio interference, or the access point can be overloaded and have not enough resources to service all the connections, so it drops some. 2. Wi-Fi is a transport layer; equally TCP and even HTTP do not offer a generic mechanism for logging in and accepting terms. This needs to be addressed at a different level, but I totally agree, it would be great to have a reasonable standard that's open and is better than a captive portal.
  • ajb 2y ago
    Or it can be multiple access points on the same SSID without 802.11r set up properly
  • jessriedel 2y ago
    1. When I have looked into this, it turns out the basic WiFi standard has rules about polling rate (allegedly to save power). Like, the standard is literally something like “poll for a few hundred microseconds every couple seconds”. Macbooks even have special workarounds that decrease the connection time by ~half by mildly abusing the standard.
• azernik 2y ago
  2 is rather irrelevant to the intended use case: devices connecting to a network with pre-shared credentials. Think cash registers and crop humidity sensors connecting to the internet, not cafe wifi. 1 is kind of unavoidable if you want a massively shared medium, mildly reliable connections once set up, and decent throughput.
  • jessriedel 2y ago
    1 is not unavoidable. I’ve never gotten a clear answer on the explanation, but the most reasonable ones involve power-saving and frequency-saving strategies (only poll for new connections for a few hundred microseconds per second). And I think these are eminently solvable. On 2, my question isn’t “why haven’t they fixed #2 for this use case?” it’s “where does the effort to address this relatively small use case come from while #2 remains unaddressed “?
    • azernik 2y ago
      A few hundred microseconds is not enough time to send an announcement at the low bitrates required for noisy channels, and then you need to multiply it by the number of cells in a collision domain. This is a hard limit of information theory and physics. And it is possible for the vast array of computer scientists in the world to work on more than one thing at a time; this particular work was done by a small team, whose specialties are in any case not suitable for work on better open authentication/consent protocols.
      • jessriedel 2y ago
        My memory of the consensus, the last time this topic came up, is that the number is in fact less than a hundred microseconds. But it doesn't matter for my point if it's a few milliseconds or whatever. The problem is solvable.
• deleted 2y ago
  [deleted]
• Klasiaster 2y ago
  A major problem is that one can only have a single connection. It would be nice to do WiFi Direct or AdHoc mode while being connected to an AP. Being able to use WiFi without losing the AP connection (or having a standardized AdHoc channel for discovery) would replace uses of Bluetooth in consumer devices where Bluetooth is used for the initial connection to join a WiFi - some devices rely on WiFi Direct but the UX is very bad because the AP connection gets lost.