Hi Oliver, Neels, community, I had some comments on the D-GSM work that didn't really fit directly to the gerrit code review, and I thought I'd post it here. == DNS zone / .msisdn suffix === One question I had was regarding the use of the .{msisdn,imsi} TLD. I would argue it is probably besser to use something that fits within the existing DNS hierarchy without contesting IANA's authority on gTLDs. Historically, ETSI/3GPP made the mistake of using ".gprs" for resolving APNs on the GRX. This was later changed to something with 3gppnetwork.com or the like, hwere that domain would actually be registered by 3GPP with normal domain registrars, but without any publicly accessible zone records. This way the name is reserved in the public hierarchy and no risk of clashes. I'm not sure how much of a concern this is to us, given that our use case is much more niche than the GRX. However, the "cost" is probably rather small to change this to something like .{msisdn,imsi}.dgsm.osmocom.org ? Sure, the packets will get larger by a few bytes, but given all the other overhead I think it's not really going to have any impact? What are your thoughts on that? == MSISDN format == Another thought is whether or not there are any concerns regarding the MSISDN format. Historically, this is one of the weaknesses of OsmoMSC, inherited from the OpenBSC days where we just thought in terms of PBX extension numbers. In reality, a MSISDN consist of a TON (type of number), NPI (numbering plan indicator) and the related digits. IIRC, in the TON one can also specify if it's supposed to be national or international, i.e. if it's prefixed with the country code or not. It would be great to make sure that the format used in the mDNS queries is somewhat standardized, if not at least only by the documentation requiring that all queries should be done in fully qualfiied form with country code present. NPI is sort-of bogus as IMOH E.164 is the only one applicable for MSISDN. Any thoughts? == The use of 'age' vs. absolute timestamp == In my original D-GSM idas I always thought we'd send an absolute UTC timestamp when a given HLR/MSC has ever seen that subscriber. The idea here being that any rural GSM network will have some kind of GNSS recevier for clock stability in the BTS anyway, and one can hence assume that timestamps are synchronized. The advantage of a relative 'age' is obvious: You don't care about the absolute clock value being correct anymore. The potential downside is that propagation delay might matter. If you have a rather slow / loaded geostationary sattelite link from one village, but a faster terrestrial link from another village, the 'age' will be ambiguous while an absolute timesetamp wouldn't have that. Given that the delays we're talking about are probably all sub-second or maybe possible about 1s, it's probably not a problem. == GSUP keepalives / connection loss detection == In the presence of unreliable back-haul mesh between villages, the GSUP connection can also not be seen as reliable. We would expect to see TCP stalls due to packet loss, etc. Have you considered this in your implementation and/or done any testing based on simulated lossy networks to ensure we properly use either TCP keepalives or IPA application-level PING/PONG to detect lost connections and recover from such situations (by closing the old and re-establishing)? Unreliable networks can be easily simulated by Linux built-in 'tc netem' for providing configurable packet loss / latency / jitter. I also saw some comments / code related to "if a second connection using the same IPA ID arrives, we're screwed" (paraphrasing here). I would expect this not to be uncommon even if every MSC/HLR out there is configred correctly exactly because e.g .the remote MSC/HLR has already decided that the TCP/GSUP is dead and starts to reconnect by performing a local-end release, while the "local" MSC/HLR still thinks the old connection is alive. If the old connection "wins" (i.e. is preferred) I see potential trouble here. Situations like that probably warrant some carefully designed tests to create exactly those situations. Regards, Harald -- - Harald Welte <laforge(a)osmocom.org> http://laforge.gnumonks.org/ ============================================================================ "Privacy in residential applications is a desirable marketing option." (ETSI EN 300 175-7 Ch. A6)