Federation

[elear]

I think federation is an area worth a lot more exploration. We began discussing this a bit on list, and I really want to get into with you just a bit more.

When we look at the history of wifi, it is one of federation, and it is a HUGE success. Thanks to my dear friend and former colleague Klaas Wierenga, students, researchers, and professors can travel to just about any university and connect. It's lovely. But it's not the only federation. We can consider iPass a commerical federation, and now there is Open Roaming. We're about to see the same sorts of mechanisms spread to private 5g.

But federation, as you say, does have its limitations. In the case of public 5g and anything of that scale, capital costs are so prohibitive as to limit the number of entrants. Is this Internet centralization? Maybe not, but a key factor seems to me to be that universities and most enterprises aren't in the business of offering wifi, so they don't mind its use so long as its not abuse. More on that in another issue ;-)

[mnot]

University connectivity is a non-commercial deployment; the incentives are fundamentally different. For better or worse, much of the Internet is commercial now. Maybe the lesson here is that we shouldn't be designing protocols without considering the incentives for deployment, nor should we be counting on cooperation as the only motivation.

I think there should be a new bit of text somewhere (perhaps substantial) talking about how so many factors feed into centralization - economic, complexity, social, etc. and how they should be considered, but no one on its own is decisive (typically).

I don't think that's specific to federation, though. For this issue, what are you wanting to see - more examples? More properties of federation explored, as they relate to centralization? If this is just a note to say 'expand the federation section', I tend to agree...

[elear]

Perhaps the lesson is that protocol developers should consider incentive alignment in a way that permits deployments to benefit from one another (e.g., the network effect). We think about that effect in the context of connectivity, but someone might be able to make that work for safety and security, higher layers of communication like instant messaging, such that someone trying to be king of the mountain gets left behind...

There is a layer 8/9 aspect here that I hesitate to qualify, because it could occur at either layer: if the federation offers inherent value, so long as it is not exclusive, sites could join.

Let's take that IM example from Issue #33 : if the federation rules are established, then perhaps new social networking sites who abide by those rules can spring up. The protocol elements discussed would support those rules.

I'll also add that the game may be different when there are already dominant players.

[mnot]

I question how much influence protocol design has, as opposed to market forces and regulation. I think (and I hope the draft supports) that the best we can do is make open, decentralized, functional protocols available; what's done with them is out of our hands. As they say, hope is not a strategy.

This also calls to mind the law of conservation of attractive profits from Clayton Christensen, described in the HBR (Feb 2004):

Products are most profitable when they're still not "good enough" to satisfy consumers. This is because to make them performance competitive, engineers must use interdependent, proprietary architectures. Use of such architectures makes product differentiation straightforward, because each company pieces its parts together in a unique way.

Once a product's performance is good enough, companies must change the way they compete. The innovations for which customers will pay premium prices become speed to market and the ability responsively and conveniently to give customers exactly what they need, when they need it. To compete in this way, companies are forced to employ modular architectures for products. Modularity causes the products to become undifferentiable and commoditized. Attractive profits don't evaporate, however...

They move elsewhere in the value chain, often to subsystems from which the modular product is assembled. This is because it is improvements in the subsystems, rather than the modular product's architecture, that drive the assembler's ability to move upmarket toward more attractive profit margins. Hence, the subsystems become decommoditized and attractively profitable.

My sense is that these shifts are more than coincidental; I suspect that when most products start to become commoditized or modularized, this tum of events kick-starts a decommoditization process somewhere else in the value chain. As a general rule, one side of an interface in the value chain must be modular to allow the side that's not yet good enough to be optimized.

My friend Chris Rowen, CEO of Tensilica, suggested that we call this phenomenon the law of conservation of attractive profits. (He was playing off the law of conservation of energy, which states that energy cannot be created or destroyed, though it may be changed from one form to another.) Translated into managerial terms, the law goes something like this: When attractive profits disappear at one stage in the value chain because a product becomes modular and commoditized, the opportunity to earn attractive profits with proprietary products will usually emerge at an adjacent stage.

Again and again, we see proprietary efforts at establishing those modular architectures, so that the proponent can control the market. They're "platforms" but they're still centralized. The IETF has seen this story before: TCP was not the first or only network protocol, but the proprietary vendors moved on to other things when they realised the value was in a different place. I don't think we're going to convince the current crop to do likewise -- but we're not the only regulators in town any more.

Returning to the issue -- I'll take this as a general one to expand upon federation some.

[mnot]

Returning to federation - while uni wifi is successful, I'm not sure what that says about centralization. My uni can still revoke access, and a lot more wifi is deployed as a complement -- e.g., free in a coffee shop.

[elear]

I think it says that federation doesn't have to have a centralizing impact so long as it is non-exclusive, and so long as associated COGS don't make new entry prohibitive. The IETF enables federation through a number of technologies, including authentication of certificates, and OAUTH. Add to that SAML from OASIS.

Here's another real life case the industry is facing today:

Governments are about to require software bills of material (SBOMs) to be delivered to customers in certain markets, and the industry is moving toward delivering that information. But some producers want to authenticate recipients. Now put yourself in a recipient's position, where you are monitoring perhaps 2,000 device types. How to scale that such that the admin isn't constantly typing in credentials for different producers? There are a few choices:

• introduce a trusted aggregator service (there are a few of these)
• use a federation to authenticate (there are a few of these)

Each has pluses and minuses. The capital costs to enter are fairly low. Both of these mechanisms could be viewed as intermediary services. Will they concentrate/centralize and what might the impact be if people are using them to determine whether devices are safe to connect to?

One potential next step, by the way, would be to track the evolution of this use case over the next two-three years.

[mnot]

My takeaway is that federation, for some styles of protocol, is necessary to help mitigate centralisation, but not sufficient. Whether centralization depends on how deployments use it -- especially, who they allow federation with. If it's universal (e.g., e-mail) that's great -- if it's selective or internal-only (as many eg XMPP deployments are), it's a problem.

Whether or not it's universal is a very case-by-case thing; in the case of e-mail, there's clearly enough value in the ecosystem where a competitor that does't federate is going to lose; other incompatible systems purposefully gateway to email because of this.

In other cases, there isn't enough shared value to motivate deployments like this -- or there's enough value in not federating that they take that path.

However, that choice isn't in the hands of standards bodies -- so I don't think it's in scope for this document.