Outlook, DHT, P2P, NAT, WLAN, WiFi, Networking, Development Backlog, Support Tickets

Post date: Sep 17, 2016 8:30:26 AM

Experienced some annoying email delays both with outlook.com as well as outlook 365 services, both. It's seems to be pretty standard life with current cloud services. Performance is tuned so that it's "okish", not too good. Of course this provides optimum utilization for systems, but in case there's any problem it quickly builds up backlogs which take a long while to exact.
Short summary about stuff we've been talking about with friends: DHT technology details, P2P networking, NAT hole punching, IP address hiding solutions, relays, etc. Data transfer windows in custom UDP based protocol. PII sanitization. Performance requirements, problems with flooding DHT table with too many 'connections' even if UDP is stateless. User and identity reputation management, counter party risk management. Transfer Window Scaling algorithms and options. Message queue and retransmissions, packet loss. Maintaining pseudonym privacy and identity hidden. Rotating identities and contact information. Out of band identity verification or using trusted 3rd party for new identity linking for trusted parties. Keeping true capabilities secret. Risks of acting on partial or non-complete date. Acting probably reveals targeting to the target making them very careful and probably paranoid. Pervasive internet monitoring and mitigation practices. 'Killing' old identities so that those can't be even technically re-used. This makes sure that the attacker can't trick me into revealing my old identities by asking some kind of proof or something. What's gone, is gone. Using public key cryptography to maintain option to provide high reliability proof that I'm the one. Aka confirm linked hidden identities, if it suites me. But the identity can still remain completely anonymous. Some people claim that it's stupid to post signed messages, without providing the public key. No, it isn't. I can provide the public key and signed additional proof later. If I want to. Not providing the public key doesn't matter at that point. Technical solutions for anonymous long term storage. That's challenging, because someone should actually store and provide the bandwidth for that data. It can be done collaboratively like in case of Freenet. But of course that doesn't guarantee data durability. Multiple different ways of linking / verifying separate identities. Using PKI, ECC, DH, Shared Keys, Nonces, Tokens, etc. Multiple JSON message structure and database schema discussions.
Complains about serious network issues, reason? They've added parallel WLAN NAT router box with enabled DHCP to same network. It doesn't work? Well it does, it works exactly as it should in this case. Which naturally means it doesn't work, especially because they've connected their existing LAN to this boxes LAN and now they've got two competing DHCP servers and one is issuing addresses and gateway which WAN side isn't connected to anything at all. What's the problem? I don't get it. Well, it was trivial to fix, just check addressing, and disable DHCP server. But as far as I can see, there was no malfunction of any kind. It's not my fault if people configure and install stuff in a manner, which it hasn't been planned to work, nor should even work at all.
The only rule of the fight club is that you don't talk about the fight club.
Just noticed that I've got over 130 entries in blog about backlog and about 2k entries in development backlog. This is one of the reasons why keeping backlogs isn't a great idea often. I'm pretty sure that many of the entries in the development backlog have been 'expired' or become 'obsolete' in someway. Situations change, so either you'll do it now, or don't backlog it is just fine.
I wonder that would be beneficial idea for customer services and help desks. All tickets which are older than 30 days will be auto deleted. No, not closed. Then someone could possibly re-open the ticket. It's much better to delete the ticket and force who ever created it into first place to re-create it from scratch. When they complain about some thing not being taken care of, you can always ask for proof. They start talking something about ticket that doesn't exist anymore. Well, fail, just retry.