RFC 01 Human Handshaking protocol for instant messaging (work in progress)

Abstract

Instant Messaging (IM) can be disruptive and cognitively hard to handle because it requires context switching. This results in 2 potentially counter productive effects:

• lowering the quality of the conversation for both parts that are not equally concentrated;
• it can introduce a repulsion towards this protocol.

Since this is a human problem, this proposal is a human based solution.

Proposal

When you want to talk to someone you ask for «real availability» and a «time slot» and a «summary» of what you want to talk about  given a «priority». It is in the interest of both party to agree on something mutually benefiting.

The idea is to propose a multi cultural loosely formal flow of conversation for agreeing to a talk in good conditions.
 

Implementation. 

Casual priority is fine and is the only proposed level.
Default arguments are:

• time slots : 10 minutes (explained later). NEVER ask more than 45 mins;
• summary : What's up? (salamalecs explaiend later);
• priority : casual (except if you want people to dislike you).

 

Time negociation

Ex: «hey man, can you spare some 10 minutes for me?»


The interrogative formulation should put your  interlocutor at ease so he understands he can refuse or postpones.

Asking for an explicit time slot helps your interlocutor answer truthfully.

If the receiver is not answering it means he or she cannot.

Don't retry the opening message aggressively. Spacing gracefully the requests should be based on the historic of conversation you had. If you had not talked to someone over 1 year, don't expect the person to answer you back in 5 mins, but rather in the same amount of time since you last interacted.

If you really want to push, multiply each retry by an order of magnitude. Min time for repushing should be done according to the how busy your interlocutor is, your proximity with the person, and your «average level of interaction» on a rough moving average of one month.

It should never go below 5 mins for the first retry (with a good friend you interact a lot with) and 15 mins for a good friend you have not talked in years.

(try to find a rough simple equation based on sociogram proximity)

Summary/context.

Announcing the context

At this point, the talk is NOT accepted.
A tad more negotiation may be needed.

It is cool for person to interact to have a short summary so that people can know if it will be "information" (asymmetric with a higher volume from the emitter) "communication" (symmetric), "advice" (asymmetric, but reversed).

Defaut is symmetric. Asymmetry is boring and if so you should think of NOT using IM.

Context: 

business related/real life related/balanced

Default:  balanced.

If you use IM for business related stuffs, I don't think this proposal applies to you. There are multiple ISO norms for handling support. People also tends to dislike doing free consulting in an interruptive way out of the blue. If you poke someone for asking him business related stuffs, you are probably asking for free consulting. Please, DON'T. There is no such things as free beers. If so you should propose clearly a compensation, even if it casual at the beginning.

Ex : Please, can you Can you give me 10 mins of your time between now and thursday on IEEE 802.1q? I will gladly pay you back a coffee sunday for your help.

Notice the importance of being polite. DON'T use imperative forms, they express orders. Use polite structured form. Give all the information in a single precise statement.

The more you are needing the advice, the less you should be pushy. It means you value this person much and you should not alienate her/his good will.

Default : Salamalecs (work in progress)

When greeting  each others you can't help but notice muslims/persians have an efficient advanced human protocol for updating news on a social graph called in french salamalecs.
http://en.wikipedia.org/wiki/As-salamu_alaykum

I don't know the religious part, but the human//cultural behaviour that results is clearly a handshaking protocol that seems pretty efficient.

I don't know how to transpose it yet in an occidental way of thinking, but I am working on it.

Receiver expected behaviour

People at my opinion tend to answer too much.

You have a life and a context. If you trust the person poking you, you expect him to know the obvious:

1. you may not have time to answer;
2. you may be dealing with a lot of stuff;
3. it may be unsafe (either you are driving, or at a job interview)
4. you may not be interested by the topic, but it does not mean you don't like the person.

Learn to not answer and not be guilty.

In the old days we tended to send an ACK to every sollicitations because network delivery could failed (poorly configured SMTP, netsplit....) and we could not know if the receiver was connected.

Today, we are receiving far more solicitations and we may forget about old messages.

If you did not answer, have faith in your interlocutor to repoke you in a graceful way. The x2 between every sollicitation is based on the law of «espérance»(find translation in english + reference) when having incomplete information about the measure of an event.
Believe me, mathematically, it is pretty much a good idea to make every solicitations if important spaced by a 2x factor (kind of like DHCP_REQUEST)

Once the topic/time are accepted, you can begin the conversation.
Content negociation SHOULD not exceed 4 lines/15 minutes (waiting/1st retry included). The speed of negotiation should give you an hint on the expected attention span of the receiver.
If you can't spare the time for negotiating DONT answer back. It is awkward for both parties.

Time agreement: When // for how long.

minimum time slot: 7 mins.

Experimentally it is good for better conversation, it makes you able to buffer your conversation in your head and be able to higher the bandwidth.

Using a slow start that is casual and progressively getting in the subject can be regarded as the human counterpart of old time modems negotiating for the best throughput.

You emitter is NOT a computer. Civility and asking questions about the context will help you adapt, it is not wasted time. It is clever to ask news that are correlated to the ability of your receiver to be intellectually available. Slow start means you should not chains the questions in one interaction.

ex: Are you fine? How are you kids? Is your job okay?

Multiple questions are NOT a good opening. Always serialize your opening.

Making a branch prediction with combined questions may give awful results.

What if the guy lost his wife and kids due to his tendency to workaholism?

Once the time is agreed you can set a hard limit: by saying : clock on.

It is cool to let the person with the busiest context tell the clock off.

It is fun to hold to your words about time. You'll learn in the process how chronophage IM are.

A grace time after the clock is off is required to close the conversation gracefully with the usual polite formulation. It should be short and concise.

Ex:
A :  thks, bye :)
B : my pleasure, @++

References: 

To be done

* netiquette (IETF RFC 1830?)
* multitasking considered harmfull
* something about RS232 or any actual low level HW protocol could be fun;
* maybe finding an outdated old fashioned book with funny pictures totally outdated with a pedantic title like «le guide de la politesse par l'amiral mes fesses» should be funny
* I really love salamalecs so finding a good unbiased article by an anthropologist is a must
* putting a fake normalization comity reference or creating one like HNETF could be fun: Human NOT an Engineer Task Force with a motto such as «we care about all that is way above the applicative OSI layer» to parody/make an hommage of IETF should be fun.
* some SERIOUS hard data to backup my claims (X2 estimations, concentration spans, ...)

TODO 

format that as a PEP or RFC
make RFC 00 for defining the RFC format/way of interacting to make that evolve
specify it is a draft somewhere
find an IRC channel for discussing :)
corrections (grammar/orthograph)
experiment, and share to have feedbacks, maybe it could actually work.
don't overdo it.
make a nice state/transition diagram
provide a full example with time line (copy/paste, prune, s/// of an actual conversation that worked this way).
add a paragraph about multi culturalism and the danger of expecting people to have the same expectation as you

EDIT : name it salamalec protocol, I really love this idea.

DevOps are doomed to fail: you never scale NP problems

We live in a wonderful world: all new technologies have proven that old wisdom about avoiding NP problems was stupid.

The Travelling salesman problem? (which is not NP, I know)
Well, can't google map give you wonderful optimized routes?

And K-SAT?
What is K-sat by the way?

SAT problem is the first problem to be known as NP. (wp, youhou)

What does NP mean in computer science nowadays, that can translate in word devops/business can understand?

It cannot scale by nature. 

Most devs reason as if we can always add CPU, bandwidth, memory to a computer.

The truth is the world is bounded. At least by one thing called money.

So here is what I am gonna do:
- first try to help you understand the relation ship between KSAT and dependency resolution;
- then we are gonna try to see roughly what are the underlying hidden problems;
- I am gonna tell you how we cheated so far;
- then we will show that the nature of the problem is predictably in contradiction with accepted actual business practices.

Solving the problem of knowing which package and in which order to install them given their dependency is NP complete. 

The more correct way to explain this homeomorphism is here.

So: K-SAT is about the generic problem of solving boolean equation with k-parameters where some parameters maybe in fact an expression of other parameters (solution of an another equation) (that are the cycles I will talk about later).

After all, boolean are the heart of a computer, it should be easy.

Seems easy as long as the equation is a tree. And aren't all our languages based on the parsing of an AST? Don't they work? So we could write a language for it.


Well, no. Computer manipulate data. A register does not tell you what the data is. Is it one variable of my equation, its name, its value, its relation with other adresses...?

The hard stuff in computer science is to make sense of data: to make it become information by handling the context.

Installing a package on a computer is in fact building a huge graph (40k nodes on debian) and when a package is to be installed you begin by asking the first equation
Ready_to_install = Union(dependencies == satisfied)
if false then we go to the dependency solving stage

For each dependency listed in the dependency (to the nth order)
build a list of package not installed that should be required.

Plan installation of this package with the actual solutions chosen (there may be more than one way to solve your dependency, so the equation as not one but potentially N solutions).

So ... you have to evaluate them ... recursively (because parameters are solution of other equations)... then stack them ... sometimes the solution is not good, so you backtrack to another solution, modify the stack ... and sol long.

And it's over?

Bof, not really.

What if package A is installed and package B requires A+1 and A & A+1 are mutually exclusive?  (small cycle ex: centos6.4 git requiers git-perl and git-perl requires git)
What if package B requires A, C , D. C requires E, E requires F and G, G requires B? This is a circular dependency or a cyclic graph.
In which order to install the package so that after every step all software still works? (I don't have the right to wipe software installed to solve a version dependency).

Where is the hic?

Variable subtitution can make the boolean equation impossible.

ex: A & B = True given A what is the value of B? easy True

The given equation is the desired state of the system package A and B should be installed.

A is True because package A is installed.

What if B = ~A ?

The equation is not solvable. Trivial case that normally don't happen.

What if B expressed requires C, D and D requires N and N is exclusive of A?
(Example A == apache, N == nginx and the software B requires nginx on 0.0.0.0:80).

Testing for cycle is easy given K determinated vertex. Finding how to check all the possibilities given all the N set of I partial solutions is quite more complex.

This is known as the DLL Hell!

That is called software requirements (see ITIL that makes a lot of fuss on this).

We already are facing small problems, but nothing that really matters. We have not talked about how we cheat, and why some are heading for a disaster.

Why do computer engineers avoid NP problems by the way?

The universe is bounded.

The data structure needed to solve the resolution dependency is a graph.

The edge are the packages (variables).
The vertex are the logical expression of software requirements (A.version > B.version)

So  before talking of algorithm just one basic:
in worst case, when you add a node to a graph with n nodes you add at least n-1 vertex.

Thus the number of total relations has grown more than linearly.

You still have to store the information ... in memory (for the work to be done fast).

Then, you have to detect the cyclic references. The first order are easy.

But not always. There are ambiguity in the vertices. A requiers B.version>1.1
and C requires B.version < 2.2 may conflict if B is only available in version 1.0 and 3.0. ... so ... there is much more than what the eyes can see :)

And cycle can be bigger than the usual classical 2 exclusive packages.

But that is not all.

The algorithmic normal way to solve the equation is to create the graph. And do the systemic evaluation of the cases.

The time of computing grows in worst case explosively.

But we are not in worst case: with my «blabla» OS it takes me 3s with 4k package to install and 3s with 41k packages installed

Well, we cheat.

One part of the cheat is not going for the exact solution but given known property of real world packages KSAT solvers are optimized.

We cheat even more by relying on human beings.

Maintainers in most distributions are doing an excellent job at testing, and fixing the bugs the OS users report and make very minimal dependency.
We are in a special case where the vertex are not very dense.

The algorithm seems to scale. But ... it can't... since we are changing the domain of validity of the KSAT solver we use. Optimization that relies on : sparse connections//few requirements per software.

DevOps problematic is not ONE computer. It is a set of computers with different Operating Systems. And in house developers that ignore what packaging is all about.

So you don't have one set of equations to solve your dependencies, you have n sets. And now, the requirements may link to other sets of equations :
exemple My python program on server X requires nginx on the front end Y.  

OOps, I don't have a graph of 40k nodes anymore, but 800k nodes now.
Do you want to compute the number of potential vertex with me? No. It is huge.

My sets of depencies has grown a lot. My input data in my algo have grown exponentially, so will my CPU time needed to solve the new problem.

if your apt-get install apache is 3 seconds on your ubuntu, your chef deployment will take you 3 minutes.

And, in real life, there are still people installing software from the sources without using a package manager (if that was not complex enough).

So your data are possibly not even accurate.

To sum up:
We are tending to :
- multiply the number of edges more than linearly;
- increase the number of vertices more than linearly
and feed that to an algorithm that takes exponentially more time given more input in the worst case and we tend to move towards the worst case.

The time and complexity is increasing very much.

Why old wisdom matters!

“I tend to think the drawbacks of dynamic linking outweigh the advantages for many (most?) applications.” — John Carmack

The fashion for android and OSX is to prefer statically build application.  It diminishes the vertex in the graph a lot.  It diminishes the software requirements.... on the front.

But smartphones and tablets are CPU/IO/battery bound very much, so we deport more and more computing in a distributed system called the cloud.

And let's zoom on the cloud system requirements.

Since we exploded the resources available on one computer we are replacing in cache memory available to more than one threads to distributed in memory cache (memcached, mongo, redis...). We are adding software requirements. We are straffing/caching/backuping data everywhere at all levels.

Since we can't serve the application on one server anymore we create cross dependencies to higher the SLA

Ex: adding a dependency on HAproxy for web applications.

For the SLA.

So your standalone computer needs no 99.9% SLA when it is shut down.

But now, since we don't know when you are gonna use it, where you are, we have to increase the backend's SLA.  

By the way, SLA adds up.

My CDN is 99.9%
My heroku is 99.9%
Our's ISP is 99.9%
so my SLA is know ...between 99.9% and 99.3% yep, you forgot to add the necessary links between your CDN and heroku, and your customers ...

You need a 99.9% SLA. It is cool, it is your upper bound.

But you build a growing uncertainty for the worst case.

Or you could expect more SLA from your provider.

What is the SLA beast?

Service Level Agreement. The availability of a service over a given time on average.

99% SLA over one year ~= 3.65 days down.

Would you use still google/fb/twitter/whatever if it was down 4 day per year?

If you have a business 1% off on a critical service (like mail) you have 1% gross income less.

So ... our modern distributed technologies are aiming at 99.999%

Mathematically SLA is thus a decreasing function

And they are de facto based on increased requirements. They rely on an algorithm that is NP complete.

Mathematically resolution dependency is an exponentially time consuming function. And you are feeding more than linearly growing input.

So ....

Mathematically they are bound to intersect.

Just for memory: chef recommends 30 min per run // the equivalent of apt-get install on your computer that takes 3 to 45seconds.

These are

Availability per day per     month         per year
99.999%         00:00:00.4 00:00:26 00:05:15
99.99%         00:00:08 00:04:22 00:52:35
99.9%         00:01:26 00:43:49 08:45:56
99%         00:14:23 07:18:17 87:39:29

So, well... imagine a distributed deployment did happened bad, what do you think of the SLA?
And, do you trust people who says they never made any mistakes?

I don't say the days are near where this NP complete aspect of software deployment will bite us.
I say these days exist.
I say the non linear nature of the problem makes it impossible to predict when.
I say the phenomenon will be very abrupt due to nature of the phenomenon.
I say we are pushing towards choices that will create the problem.
I say business analysts, companies, CTO will not see it coming.

And that is my last point:

Our scientific education makes us blind to non linear problems

The first words of your scientific teachers that you have forgotten before teaching you science/math was: «most problems are not linear, but we only study these one because there are the only one for which we can make easily accurate predictions»

If you have a linear system you can predict, plan ... and make money. Without well, you are playing the lottery.


What are non linear stuff ?
- weather (weather forecast after 24 hours is still a scam even though our computers can crush even more data since 40 years);- actuariat/finance: selling products based on the probability connected problem will happen ; 
- resource consumption (coal, oil, fish, cows);
- biodiversity;
- cryptography (you search for symmetrical operations with non symmetrical CPU cost)
- floating point behaviour (a operator b != b operator a is not always true)
- economy;
- coupled moving systems in classical physics (randomness can be obtained easily with predictable system if you couple them correctly);
- quantum mechanics (it bounds the max frequency of the CPU);
- the movements of the planets (you can send me your exact solutions for where the moon will be relatively to the sun in one year (length) relatively to a referential made of 3 distant stars).
- internet bandwidth when bought to a tiers one;
- real life, sociology, politics, group dynamics .... 

You see a common point there?

We still have not solved these problems, and we do not learn how to solve them in our regular curriculum.

I don't say there is no solutions.
I say there is no solution. Yet. We will never find the solutions if we don't get aware of the problem.
Non linear problems are not a computer problem. They are an intellectual problem that requires proper thinking.
It requires education.

We are pretending to live under the empire of necessity, but there is no necessity to accept this reign.

We try to build a new world with the wrong tools because we are making the false assumption we can handle the problem we face with the methods we learned at school. We rely on the «giant's shoulder» to make the good tools. But, since we are not well educated, we invest money on the wrong tools for our problem. Tools often made by the right guys for often no actual problem.


Firstly, we should slow down our adoption of async/distributed systems;
Secondly, we should lower the SLA to reasonnable levels. If 2% of a service interruption in one of your production can kill you, your business is not reliable;
Lastly, we should understand how the more our systems is efficient the more fragile it is becoming.
It maybe the time to trade efficiency for durability. It maybe the time to slow down and enjoy all the progress we made.