Just to get the pricing thing out of the way, the pricing is not to license a protocol but to actually distribute app content -- from our servers worldwide. And

Just to get the pricing thing out of the way, the pricing is not to license a protocol but to actually distribute app content -- from our servers worldwide. And our current customers are finding that it's pretty comparable to what they maybe already paying for such a service to other providers. Agreed that the standards will get there at some point. And it'll be a joyous day for all. But I'll have to humbly disagree with you that TCP Fast Open or Multipath or HTTP/2 provide the answer for the mobile app use case today. TFO will save you one round-trip for the handshake.. but that's about it. Multipath is only available for Apple's own use the last I heard so it's not really a factor... but even if it does become available, it's still TCP. And in both cases, TCP is still hampered by the usual problems outlined in the blogpost. No concept of a session, slow-start, exponential backoff, unrealistically long timeouts etc. etc. I guess the meta point here is that TCP is designed for the general case and it's great for what it is meant for. But by narrowing the use-case to native mobile apps, one can constrain the problem domain and gain more freedom in what you can design.