The IP Address Paradox

[Ryan_Todd]

Original thread:
"What is the strangest issue with a robot you have ever seen?"

This thread:
I read the following post (full text in the above thread), and it got me thinking.

Originally Posted by Aaron.Graeve

Lone Star this year (I was FTAA). One robot refused to connect to the Driver Station, and the Driver Station refused to connect to FMS. As it was practice day, we were willing to take extra time and figure out what the issue was.

...snip...

Fast forward 30 minutes, still no progress. We have re-run FMS pre-start at least 4 times; the 5 other robots come up fine, but this Driver Station and robot refuse to budge. The team is understandably panicking that they may not be able to compete at all. As a shot in the dark, I turn to the FTA and ask if the Field could be getting a 10.41.*.* IP address from the convention center. As it turns out, the field was getting a 10.41.255.* address with a subnet that conflicted with the 10.41.55.* addresses that the team needed to use.

5 minutes later, the problem is resolved and both of the teams laptops are working fine. The Field exterior IP address is usually checked during setup day for possible conflicts, but must have been missed for some reason. The team was extremely grateful for the resolution and was patient and helpful the entire time.

TL;DR:
A 1 in ~650,000 chance that the FMS wants your IP as its IP.

(emphasis mine)


That may sound like it's practically impossible, but I'm pretty sure that's not the case.

For a quick refresher of the concepts involved, here's a closely related example from your everyday life: The Birthday Paradox.

Anyhow, I was struck with inspiration...
This is just the kind of question that can only be answered one way: MATH!

-------------------

If there is a "1 in ~650,000 chance" that any given team will experience an IP address conflict with the FMS, then there's a ~(1 - (1 / 650,000)) = ~99.99985% chance that any given team will *not* experience such a conflict at any given event.

Note: I'm electing to work backwards from this number, as opposed to using the probability of a conflict (1/650,000) directly; otherwise, we'd pretty much end up solving for the Nth root of the number of molecules in an unladen swallow.

.
Since the FRC rule for assigning team IP addresses means that we don't have to worry about conflicts *between* teams, the odds of a conflict happening at an event with 66 teams are best expressed as (1 - (~0.9999985 ^ 66)) = ~0.01015%.

Also note that my actual math uses way more sig-figs than I've shown in this post. Since all of this math is only based on rough numbers in the first place, however, this works out just fine.

.
That may sound pretty unlikely, but what happens if we expand all of the way out to the scope of an entire FRC season? We'll need to know the number of times an FMS received a new IP address, and the number of teams that connected to each of these IPs.

Counting events with multiple competition fields like MSC and CMP, teams competed on a freshly configured FMS no less than 137 times this past season; depending on whether or not each FMS got a new IP on Saturday morning, there may have been as many as 272 unique IP addresses used by competition FMS setups this season (note that the Einstein fields only operated for one day each). Of course, this ignores any possible field resets mid-day due to technical difficulties!

As for the number of teams that connected to each FMS, I can't seem to find a solid number for the average number of teams per FMS. Since I didn't feel like making a Dropbox account just to pull up Jaci's Data Dump, I just spent a few minutes clicking around the event results listing at random; this (completely unscientific) survey pointed to an average around 50.

.
Taking all these numbers together, we get a lower estimate somewhere around (1 - ((0.9999985 ^ 50) ^ 137)) = 1.05% and an upper estimate around (1 - ((0.9999985 ^ 50) ^ 272)) = 2.07%.

-----------------

TL; DR:
There was at least a 1% chance of a robot-to-FMS IP conflict happening to somebody during the 2016 competition season; still not exactly likely, but well within the realm of possibility.

Now, how many shared birthdays do we have among this year's robots?

[Aaron.Graeve]

I think I should chime in with why I spit-balled the 1 in 650,000 odds. I was basing this on some (rather shaky) assumptions about DHCP, scorekeeper tendencies, and the reader.

For the sake of laziness, I assumed that the IP addresses the FMS is handed by DHCP are uniformly distributed at least in the first two bytes. I also assumed that the reader (the "your" in the quote) has one team association and does not care about the other teams. Lastly, I assumed that scorekeepers check for an IP conflict 9 out of every 10 times they should (i.e. they forget 10% of the time).

In order for a reader's specific team to get an IP and subnet conflict using the assumptions above, the first octet of the IP would need to be 10 (a 1 in 256 chance), the second octet would need to be the reader's team's first two digits as applicable (another 1 in 256), and the third octet would need to be different from the last two digits of the reader's team number (255 out of 256). Taken together and based on the assumptions given, there should be a 1 in ~65,700 chance that the IP FMS gets from DHCP will conflict with a specific team IP (I truncated to two sig-figs just because). Given that the scorekeeper/FTA will catch an IP conflict 9 out of every 10 times, the odds that a conflict would impact a specific team would be reduced to 1 in ~650,000.

Overall, it is a very small chance that it will happen to you, but a not so small chance that it will happen to someone.

Another good example of the birthday paradox. Props to OP for the math and teachable moment.

[AllenGregoryIV]

That math all assumes the odds of any number in the first octet are equal when in fact at most venues the FMS is likely to be given a private IP (https://en.m.wikipedia.org/wiki/Private_network) so 10, 172, or 192 are far more likely to start the address then say 1 or 254.

[cpapplefamily]

I wonder if this has something similar to do with our experiences a few weeks ago with our robot, driver station, and Kangaroo. This is a alink to the start of the discussion. https://www.chiefdelphi.com/forums/s...1&postcount=19
It starts at post #19 and continues from there
https://www.chiefdelphi.com/forums/s...=149295&page=2

[Mark McLeod]

Originally Posted by cpapplefamily

I wonder if this has something similar to do with our experiences a few weeks ago with our robot, driver station, and Kangaroo. This is a alink to the start of the discussion. https://www.chiefdelphi.com/forums/s...1&postcount=19
It starts at post #19 and continues from there
https://www.chiefdelphi.com/forums/s...=149295&page=2

I can't say this was the problem, but each of the IPs you chose for your Kangaroo are incorrect for field use.

Keep the last numbers .5 or greater and less than or equal to .19. 5<=IP<=19
The field begins assigning DHCP addresses at .20, but is not necessarily assigning them sequentially. Any static IP you use between .20 and .200 can randomly produce a conflict.
It's quite likely that your Driver Station or roboRIO was receiving a duplicate .20 address.

Static IPs for the Kangaroo, but dynamic IPs for the Driver Station and roboRIO will also prevent it from working with the competition pit/home dynamic IPs of 169....
For your use case I would recommend that you keep everything at consistent 10.TE.AM static IPs, both for at home and for competition.
Don't worry about your robot radio IP. You can leave it at the setting given it by the home or competition radio kiosk.

[cpapplefamily]

Through that thread we adapted team 900 zebra vision iP assignments. Post #22 https://www.chiefdelphi.com/forums/s...6&postcount=22
It uses the ranges that you explain. The biggest trouble we haven't uncovered was why in the pits after configured the radio for the event we had no driverstational to roborio comms everything else seemed ok. We panicked before the first match and removed everything but the radio and Rio to get comms. Never tested on the field and worked fine when we got back home before re-configuring the radio.

[Mark McLeod]

There might have been an unanticipated problem in your setup mixing USB communications with Ethernet communications.

When you use a USB connection between the Driver Station and the roboRIO (through that UNITEK USB device or direct) that introduces yet another IP address that can break your setup.
The DS USB to roboRIO uses a hardcoded 172.11.22.1 IP address scheme.
That's fine for DS to roboRIO communication, but would not allow your DS to communicate directly with either the Kangaroo or the IP camera.
There's nothing in the communication path that can bridge 172. addresses to 10. addresses.
If the DS doesn't interface with either of those, then it won't matter. If the DS does then it would work when the DS was communicating wirelessly or through an Ethernet tether, but not in the pits at competition or at home when connected via a USB tether.

[cpapplefamily]

We kind of sniped the original post topic. I would love to continue the conversation maybe over in my original thread? I'm not quite following the last post. In the pits we had DS to Kangaroo, DS to IP camera, but no DS to Roborio.