| Thread Links | Date Links | ||||
|---|---|---|---|---|---|
| Thread Prev | Thread Next | Thread Index | Date Prev | Date Next | Date Index |
|
Dan, I got the 80,000 number from 23/2062, “large University”. My contribution was in response to that contribution as it concluded that IRM would have a lot of duplications and I wanted to correct
the math and show that that was not true. Neither has been presented. When a STA associates with an IRM it had previously provided, it will not be a duplicate (it was “cleared” when it was provided). However, when it provides a new IRM there is a chance that it
is a duplicate. As you say, every time a STA provides a new IRM there is this same chance. However, as in the lottery example, although the chance of a particular STA providing a duplicate is very low, if there are enough STAs and associations, then one
of then could well provide a duplicate. It does not matter that the list of IRMs may be changing, it is still a list of N random addresses and hence the chance of duplicate is the same each time. But, although my lottery ticket did not win, some other lucky
bugger did win even though they had the same probability of winning as me. The calculation of how many tickets need to be need be sold for a 50% chance of someone winning is what I used for the IRM case. Having said that, when dealing with extra low probabilities,
it is all a bit academic and not really “real world” and only when I used the 80,000 figure did I get results that even come close to actually happening.
Best Graham From: Harkins, Dan <daniel.harkins@xxxxxxx> Graham, The ESS is saving 9000 random IRMs for the "next MAC address" of each of the 9000 associated STAs. So that is similar to 18,000 STAs associating at once if you don't want to have a collision between any of the associated STAs and their
"next MAC address". The number of associations per day doesn't matter because we're only concerned with the current MAC address and the next MAC address of each associated STA. Again, if I associate 3 times per day, on my 3rd association the previous
two MAC addresses I used are not being retained and any other STA's use of those MAC addresses would not constitute a collision. STAs could associate 20x per day and it's still just "current MAC and next MAC". Since there are 18,000 MAC addresses that need to be used the probability of collision is 0.0000023. And that's the number regardless of the number of associations per day or the number of days that STAs are associating.
I'm not sure where 80,000 STAs came from. I believe the current record holder for associations to a single ESS is a tad more than 30,000. If all 30,000 STAs were doing 11bh that would be 60,000 MACs and the probability of collision for
that is 0.0000255. Of course we should architect for the future but 80,000 seems somewhat excessive (and 160,000 MACs gives a probability of 0.0001818) regards, Dan. -- "the object of life is not to be on the side of the majority, but to escape finding oneself in the ranks of the insane." – Marcus Aurelius On 6/4/24, 11:24 AM, "G Smith" <gsmith@xxxxxxxxxxxxxxxxxxx> wrote: Yes Dan, you are right, but that is not the probability we are dealing with here. If the ESS is saving 9000 random IRMs, yes they change each time a STA associates,
but 9000 STA are associating 3 times a day, i.e., 27000 associations a day, each with the same probability of a duplicate, i.e., chance of a random IRM matching one of 9000 random IRMs. Someone wins the lottery, and similarly, one of the 9000 STAs will be
unlucky at some point. The result I gave is that calculation, the average number of days between any duplicate, where the probability of the duplicate rises to 50% (similar to the birthday thingy). However, as I discovered when I was working on this, we are not really interested in a duplication within the ESS, but how often each AP in the ESS would have to send
the duplicate message (it was to dispel the thought that this could jam up the ESS). Each AP only has 2000 STAs associating so the average time between duplicates is less.
Of course, at 9000 STAs it is not really a problem, that’s why I considered 80,000 which is a number I was given by another TGbh attendee. Regards Graham From: Harkins, Dan <daniel.harkins@xxxxxxx>
Just to expand on the lottery analogy, if the lottery is held every day and I buy 1 ticket, and get a number, for each day's lottery then if a losing number I got last week hits one day this week I do not win.
That number was only good for the lottery it was bought for. Similarly for MACs. A MAC I used 3 associations ago might get randomly chosen, and used, by one of the 9000 other STAs when I associate next but that's not a collision.
regards, Dan. -- "the object of life is not to be on the side of the majority, but to escape finding oneself in the ranks of the insane." – Marcus Aurelius On 6/4/24, 9:22 AM, "Harkins, Dan" <daniel.harkins@xxxxxxx> wrote: Graham, I don't think you can say "it takes eons before a duplicate actually occurs". It could occur immediately. And it might not occur for eons. We're talking probability here. Furthermore, the calculations you are
making concern any 2 STAs out of the 9000 STAs associating getting a duplicate so when you say how long it takes before a duplicate "for that STA" I think you're making a leap. The probability is not "for that STA". It's for any 2 out of the 9000. But I'm still not groking your statement that associating multiple times a day will make a duplicate occurrence more likely (and in 44 days). If I have a 1 in a billion chance of winning a lottery my odds increase
if I buy more tickets *for that one lottery*. But if the lottery occurs many times, lets say once a day, and I only buy 1 ticket for each drawing each day then my odds with each ticket are still just 1 in a billion. And since the STA is not retaining
its old MAC addresses, and it can only be associated once at a time, when it deassociates and associates anew there is no increase in the probability of 2 STAs randomly choosing the same MAC. The old MAC goes back into the pool of unused MACs which, if randomly
chosen by any one of the 9000 will not result in a collusion. Right? regards, Dan. -- "the object of life is not to be on the side of the majority, but to escape finding oneself in the ranks of the insane." – Marcus Aurelius On 6/4/24, 6:36 AM, "G Smith" <gsmith@xxxxxxxxxxxxxxxxxxx> wrote: As I explained in my contribution, the ESS maintains 9000 addresses (in this example), so each time a STA comes back and provides a new IRM, there is the same probability
of a duplicate. So it take eons before a duplicate actually occurs, for that STA. But if 2000 STAs associate 3 times a day, that time obviously reduces, for any one of the STAs to hit a duplicate, and any one AP in the ESS. That is what my contribution
analyzes. Graham From: Luther Smith <000025945f3926b3-dmarc-request@xxxxxxxxxxxxxxxxx>
I think Dan has a very good point here. That you only need to consider the current devices that are associated at the time the new randomized MAC is generated. The probability
is also contingent on the number of devices. Generating the same MAC with one other device in use does go up as the number of devices; however, that is only a small ripple in the chances of generating a conflicting MAC address.
Luther From: Harkins, Dan <daniel.harkins@xxxxxxx>
Hi Graham, I don't believe that associating 3x a day makes it 44 days for a 0.5 probability of collision. If these STAs are associating 3x per day that means they are disassociating as well. They do not maintain their old
MAC addresses for any period of time and a MAC address that is used by a STA at some slice of time is not fixed such that other STAs in their 3x per day associating will collide with it if they happen to choose it. We're talking about the probability of 2
STAs *simultaneously* choosing the same MAC address. If it's 9000 STAs then it doesn't matter if they associate once per day or 3x per day. If I chose a particular MAC address, disassociated, and then you came along later in the day and randomly selected
the same MAC address it's not a collision. The fact we chose the same MAC address *at different times* does not matter.
The odds are not 1 in 1747993 per association, they are 1 in 1747993 period. regards, Dan. -- "the object of life is not to be on the side of the majority, but to escape finding oneself in the ranks of the insane." – Marcus Aurelius On 6/3/24, 1:32 PM, "G Smith" <gsmith@xxxxxxxxxxxxxxxxxxx> wrote: Dan is correct.
The relationship between probability and odds is “1 in (1-P)/P”, which in this k=9000 case, the odds of a duplicate is 1 in 1747993 per association. If we say 1 association
per day then this probability means once every 137 years there is a 50% chance of a duplicate (401448 Associations).
But, as I tried to point out in my contribution (23/2148r1), this is not the whole story. Every time a STA associates to any AP in an ESS there is a chance of a duplicate,
so if the STA associates 3 times a day, it comes down to a only 44 days for a 50% chance of a duplicate in the ESS, but this is 200 days for each AP in the ESS (5 APs in the ESS). Hopefully all is explained in my contribution where I have tried to explain
all the formulas and their derivations. Hope this helps, Graham From: Harkins, Dan <daniel.harkins@xxxxxxx>
Hi Bob, I do not believe that means the 9001st will collide with one of the existing 9000. The probability for 9001 is basically the same. What it's saying is that the probability of any 2 STAs out of those
9000 (or 9001) randomly choosing the same MAC address is 0.000000575. It is certainly not 1. regards, Dan. -- "the object of life is not to be on the side of the majority, but to escape finding oneself in the ranks of the insane." – Marcus Aurelius On 6/3/24, 12:29 PM, "Robert Moskowitz" <rgm@xxxxxxxxxxxxxxxxxxxx> wrote:
Graham, On 6/3/24 10:15, G Smith wrote:
-- To unsubscribe from the STDS-802-11-TGBH list, click the following link:
https://listserv.ieee.org/cgi-bin/wa?SUBED1=STDS-802-11-TGBH&A=1 To unsubscribe from the STDS-802-11-TGBH list, click the following link:
https://listserv.ieee.org/cgi-bin/wa?SUBED1=STDS-802-11-TGBH&A=1 To unsubscribe from the STDS-802-11-TGBH list, click the following link:
https://listserv.ieee.org/cgi-bin/wa?SUBED1=STDS-802-11-TGBH&A=1 To unsubscribe from the STDS-802-11-TGBH list, click the following link:
https://listserv.ieee.org/cgi-bin/wa?SUBED1=STDS-802-11-TGBH&A=1 To unsubscribe from the STDS-802-11-TGBH list, click the following link:
https://listserv.ieee.org/cgi-bin/wa?SUBED1=STDS-802-11-TGBH&A=1 To unsubscribe from the STDS-802-11-TGBH list, click the following link:
https://listserv.ieee.org/cgi-bin/wa?SUBED1=STDS-802-11-TGBH&A=1 To unsubscribe from the STDS-802-11-TGBH list, click the following link:
https://listserv.ieee.org/cgi-bin/wa?SUBED1=STDS-802-11-TGBH&A=1 To unsubscribe from the STDS-802-11-TGBH list, click the following link:
https://listserv.ieee.org/cgi-bin/wa?SUBED1=STDS-802-11-TGBH&A=1 To unsubscribe from the STDS-802-11-TGBH list, click the following link: https://listserv.ieee.org/cgi-bin/wa?SUBED1=STDS-802-11-TGBH&A=1 |