View Issue Details
| ID | Project | Category | View Status | Date Submitted | Last Update |
|---|---|---|---|---|---|
| 0005441 | unreal | ircd | public | 2019-10-15 02:39 | 2019-12-11 16:11 |
| Reporter | ScriptTiger | Assigned To | syzop | ||
| Priority | normal | Severity | feature | Reproducibility | always |
| Status | acknowledged | Resolution | open | ||
| Product Version | 4.2.4.1 | ||||
| Summary | 0005441: Current ping timeout configuration unreasonable for radio/satellite communicatons | ||||
| Description | I have been a fan of UnrealIRCd for well over a decade now and in that time I have also worked with various network typologies employing mobile communications, everything from household smartphones to VSAT units, both in the public and private sectors. While some of the environments I have worked in have had the budgets to employ specialized network equipment to ensure high ping-through rates even with higher bit-error rates, other environments I have worked in have not been so fortunate and running applications such as UnrealIRCd becomes impractical due to the extremely unforgiving ping timeout thresholds. I have read from various sources that UnrealIRCd currently enforces a strict 2-strike rule when it comes to missed pings, "missed pings" being defined as pings that did not reciprocate a reply in a predefined amount of time and therefore timed out. Currently the only custom user-defined value that can be set here is the interval between pings, or pingfreq, which is obviously an extremely limited feature set when taking into account the other variables here that could and should easily be user-defined, as well, for a higher range of flexibility, especially as it pertains to mobile communications. For better flexibility and resiliency, especially for mobile communications, I recommend also allowing custom user-defined values for how many "missed pings" constitute reason for disconnect as well as how long to wait for each ping to consider it timed out, in milliseconds. All of the currently defined defaults are completely acceptable and should remain as the defaults, but the aforementioned custom values should be allowed to deviate from the defaults as needed. | ||||
| Steps To Reproduce | Connect to UnrealIRDd using any given device over a mobile communications link. | ||||
| Tags | No tags attached. | ||||
| 3rd party modules | |||||
|
|
I wouldn't use bold terms myself, like calling it extremely unforgiving, a timeout of x minutes, but I guess that's a matter of perspective. In my experience those links don't recover well or indeed take quite a long time. That begs the question if you want your link to freeze for X minutes while thinking everything is fine (but you are not receiving any communication) or if it would be better to reconnect. What I have planned for U5 is the ability to send more frequent pings while specifying a timeout. So splitting those two things up. The reason for that is NAT (and other) connection tracking timeouts. Some have really low values such as 30 seconds and even 60 seconds isn't very uncommon. Currently this forces you to set a pingfreq of 30 or 60 which results in a timeout of 30(*2) or 60(*2) which is rather stupid. So the plan is to allow a ping every <low frequency> to avoid NAT / connection tracking timeouts while still allowing <normal / higher timeout> for the actual timeout to occur. More or less what you request, just for a different reason (unrelated to high latency and lossy links). |
|
|
I see. I would be completely cool with those changes, but another big thing for me is also sample size, which still wouldn't be addressed. In my original description I just said allowing a user-defined limit for number of missed pings, but really a percentage of loss per period of time would be fine, as well. From my experience a sample of 2 can hardly be called a sample at all, and that's what I was referring to as being "extremely unforgiving." I can totally see where you are coming from, from the network protocol timer side of the house, but for me with mobile communications a larger sample is really a must because every ping can vary so greatly and it's a lot messier than just fixed timers that are known quantities. Believe me, I can completely understand where you are coming from and can totally see how what I am saying just doesn't seem necessary because I know it's not a broad use case. However, the kind of mobile communications I have experience with include things like decades-old mobile mission-critical RANs (radio access networks) with several layers of encryption designed for relaying information like GPS, text messages, personnel load out, way point coordinates, and other tiny yet critical pieces of data for first responders, military, etc. Many organizations have the funds to pay for custom software and annual contracts, but others don't and IRC is still heavily in use in such lower-end environments. And to be honest, I have even seen the higher-end environments that do have custom software and annual contracts run IRC alongside their program-of-record systems just for an added channel of communications between leadership as not to interfere with the more boots-on-the-ground operations. |
|
|
Setting this to 'feature'. Also, to be transparent: I have dropped this as a 5.0.0 target. |
| Date Modified | Username | Field | Change |
|---|---|---|---|
| 2019-10-15 02:39 | ScriptTiger | New Issue | |
| 2019-10-16 09:44 | syzop | Note Added: 0021042 | |
| 2019-10-16 09:44 | syzop | Assigned To | => syzop |
| 2019-10-16 09:44 | syzop | Status | new => acknowledged |
| 2019-10-16 12:35 | ScriptTiger | Note Added: 0021044 | |
| 2019-10-26 19:37 | syzop | Summary | Current ping timeout configuration unreasonable for mobile communicatons => Current ping timeout configuration unreasonable for satellite communicatons |
| 2019-10-26 19:38 | syzop | Summary | Current ping timeout configuration unreasonable for satellite communicatons => Current ping timeout configuration unreasonable for radio/satellite communicatons |
| 2019-12-11 12:33 | syzop | Severity | major => feature |
| 2019-12-11 12:33 | syzop | Note Added: 0021160 | |
| 2019-12-11 12:33 | syzop | Note Edited: 0021160 | |
| 2019-12-11 16:11 | syzop | Priority | immediate => normal |
