4 ms·

IETF is working on better stuff – and it will be standard. RFC 7413 TCP Fast Open, already deployed on Android and Chrome OS. RFC 6824 Multipath TCP, already

IETF is working on better stuff – and it will be standard. RFC 7413 TCP Fast Open, already deployed on Android and Chrome OS. RFC 6824 Multipath TCP, already deployed on iOS. And the most important upgrade: HTTP/2. Sorry, I'm not using commercial proxies with proprietary protocols. I believe that anything as low level as transport layer shouldn't have a "pricing" link. P.S. QUIC is an interesting experiment, maybe it will become a standard like SPDY became HTTP/2. But UDP can't always be used... My university's WiFi just blocks all UDP completely, for example.

chetanahuja 12y ago
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.

4 ms·

IETF is working on better stuff – and it will be standard. RFC 7413 TCP Fast Open, already deployed on Android and Chrome OS. RFC 6824 Multipath TCP, already

by floatboth 12y ago

chetanahuja 12y ago
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.