Stuff Yaron Finds Interesting

Technology, Politics, Food, Finance, etc.

Articles relating to Internet Protocols, protocol design issues, etc.

State diagrams for Paxos made simple

I was reading through Paxos made simple and I really wished there were state diagrams to help explicate the protocol. So I wrote them up and share them below. Please keep in mind that the diagrams just explore naive Paxos, that is single value, no distinguished proposer or distinguished learner. So this version of Paxos is pretty useless in practice but it completely captures the core mechanisms that make Paxos work (with the exception of how to pick a distinguished learner). Please note that this article is intended to be used by someone going through Paxos made simple. It is an adjunct, not a replacement.
Read More

Wrapped or Native Paxos?

So let's say I want to build a nice highly consistent multi-data center store, something like Megastore. Most everyone at this point has something like Bigtable already deployed in their data centers. What they typically don't have is a way to keep different instances of their table stores guaranteed consistent with each other across DCs. Megastore steps in to address this issue. But this begs a fundamental question - what's better, to wrap a Paxos coordinator on top of existing table stores or to build a new Paxos native storage service?
Read More

Average, percentiles and measuring service performance

Measuring the performance of services is tricky. There is an almost irresistible desire to measure average performance. But measuring service performance using averages is pretty much guaranteed to provide misleading results. The best way (I know of anyway) to get accurate performance results when measuring service performance is to measure percentiles, not averages. So Do Not use averages or standard deviations, Do use percentiles. See below for the details.
Read More

Distributed Storage Reading List

My technical wanderings of late at Microsoft have taken me into the realm of massively distributed storage. Of course, I've been here before but this time I need to bring some other folks along. So I was asked to put together suggested readings to help people come up to speed. I thought the list might be of general interest so I'm posting it here.

What do you think? Is this a good list? A bad one? What would you suggest?

Read More

OAuth 2.0 Bearer tokens – unsafe at any speed?

Eran's latest article raises a number of specific security threats by way of arguing that bearer tokens are irredeemably insecure. In this article I examine the attacks Eran calls out and demonstrate that they are already addressed by OAuth 2.0. Eran's article does bring up the interesting question of - do we need defense in depth for the tamper resistance and confidentiality provided by SSL/TLS?

Read More

Why does OAuth need request tokens?

m4s0n501

OAuth's current access dance is based getting a request token that is later exchanged for an access token. Introducing the request token takes what could have been a 4 round trip protocol and makes it into a 6 round trip protocol. Couldn't we just simplify OAuth down to 4 round trips by getting rid of the request token all together? Or is there some critical use case enabled by request tokens that makes all the complexity worth the price?

[5/26/2009 – Updated with Q&A on open redirectors]

[6/2/2009 – Updated with a note from Allen Tom on another way to prevent open redirector attacks]

Read More

Claims, Tickets and HTTP – Security protocols for services

I'm writing an enterprise service. A request comes in. Do I honor the request or reject it? Answering this apparently trivial access control question has spawned whole universes of interlocking protocols. Kerberos, Shibboleth, SAML, WS-*, Liberty, OAuth, OpenID and so on. Before I can pick which protocol to use I need to define my requirements.

DISCLAIMER: Although I am an architect on .NET Services' Access Control Service nothing said in this document necessarily represents the opinions of my employer, my friends, my enemies or my teddy bears. No warranty express or implied. Your mileage may vary. Do not remove tag.

Read More

Two Phase Commit Need Have Nothing To Do With ACID or Any Other Kind of Transaction!

O.k., it's pet peeve time. Otherwise intelligent people seem to get really confused whenever they hear "two phase commit". They immediately assume that if one is using two phase commits then one must be implementing an ACID or at least Atomic transaction. Nonsense! A two phase commit is nothing more than a coordination mechanism. It allows one to guarantee that a group of independent systems will either all perform or all not perform a particular action. Historically the 'action' was usually some kind of ACID or at least Atomic transaction. But there is nothing in two phase commits that requires or even implies any particular action, atomic, ACID or otherwise.

Read More

Rights Not Exercised are Lost – Tibco, BPEL & Rendezvous

Our rights only exist to the extent that we defend them in our daily lives. The right to free speech, for example, would quickly drain away if we didn't frequently exercise it and by so doing kept the knowledge of the rights importance and the mechanisms to protect it alive and well. But too often people believe that the need to defend our rights doesn't apply to them because they are just a single individual. Who cares what a single person does? But when each individual believes their actions don't matter then they significantly reduce the work required by those who would take our rights away.

Read More

BPEL, TIBCO and trademarking the English language

Issue 202 in the BPEL TC is a demand from Tibco that the BPEL TC change the word 'rendezvous' that is used as the value of an attribute in the BPEL programming language because Tibco has trademarked the word 'rendezvous'. To be clear, trademarks do not apply to 'descriptive' uses and that is exactly how BPEL uses the term 'rendezvous'. So legally speaking Tibco most likely doesn't have a leg to stand on. I do have sympathy for Tibco because one is required to 'vigorously' enforce a trademark in order to keep it. So to protect their trademark they need to be seen to be defending it, hence issue 202. But now people in the group are scared that Tibco will sue them (or their employer) if we don't change the term. Hopefully the group will stand up for the freedom to use the English language and reject issue 202 on next week's call. An even better outcome would be a change in the law that would make it illegal to get a Trademark on a common English word. The fact that Tibco could trademark the word 'rendezvous' and then try to banish its use from technical efforts is insane.