7 ms·

It would have been great if they would have used the opportunity to leverage SCTP instead of building it into QUIC. They could have defaulted to plain jane SCTP

by MertsA 6y ago

It would have been great if they would have used the opportunity to leverage SCTP instead of building it into QUIC. They could have defaulted to plain jane SCTP on IPv6 and tunnel it in UDP for IPv4. That would have been the perfect opportunity to drive adoption of SCTP while implementations of all sorts of middleboxes are still young enough to be swayed into supporting it. We could have all of the benefits of QUIC but with proper layer separation and multi-homing, and the ability to build future applications on it.

api 6y ago
You can't "drive adoption" of anything new in the basic IP protocol space. You're kicking a dead mule. ISPs and IT departments don't care and have little reason to say anything but "no" or "its on the road map" (forever). The present IP stack is fixed in amber, and we'll be lucky to see IPv6 complete adoption. At this point I'd give IPv6 a 50/50 chance of failure. Reasons for this: * No upstream incentive due to little or no competition and not enough "killer apps." * Security FUD: if it's new then it might allow something currently not understood. * ISP desire to control traffic and prohibit anything new. * First thing IT will do if there's a problem is "turn the new thing off." (This happens a lot with IPv6 even if IPv6 is not a cause.) * Vendors with a vested interest in treating the disease (supporting technical debt) rather than curing the patient (actually fixing the problem, reducing the need for complex solutions). My point in the original comment was that QUIC might help stop further ossification by making UDP actually necessary. Otherwise we face the potential for removal of UDP and even removal of non-standard TCP ports, eventually leading to "http only" networks. ISPs and IT departments would like that since less capability equals less support queries and less to monitor. If IP were re-designed today I would suggest at least non-cryptographic but difficult to efficiently modify authentication of all fields (e.g. keyed or nonced checksums), and obfuscation (fast minimal encryption?) of everything under the IP header. No NAT, and nothing useful to filter on. If it's visible and mutable it will become ossified since people will MITM it. That way there would be no choice but to fix endpoint security instead of deploying firewalls and no choice but to adopt IPv6 instead of NAT. You couldn't temporarily work around fundamental problems by nerfing the net. I think there's a general principle here. If easy short term fixes that incur long term technical debt are allowed, they will be deployed. If such a hack is deployed in a federated or decentralized system, it becomes permanent unless extra-systemic means (e.g. legislation or financial incentives) are used to force it to be removed. Therefore federated and decentralized systems should not permit such hacks. Front load the pain by forcing the problem to actually be fixed. This is one thing block chains kind of get right. Everything is cryptographically hashed and authenticated. You can't modify state unilaterally. You either have a compliant node or you don't, and changes must be adopted globally either as soft or hard forks.

by MertsA 6y ago

api 6y ago

You can't "drive adoption" of anything new in the basic IP protocol space. You're kicking a dead mule. ISPs and IT departments don't care and have little reason to say anything but "no" or "its on the road map" (forever). The present IP stack is fixed in amber, and we'll be lucky to see IPv6 complete adoption. At this point I'd give IPv6 a 50/50 chance of failure. Reasons for this: * No upstream incentive due to little or no competition and not enough "killer apps." * Security FUD: if it's new then it might allow something currently not understood. * ISP desire to control traffic and prohibit anything new. * First thing IT will do if there's a problem is "turn the new thing off." (This happens a lot with IPv6 even if IPv6 is not a cause.) * Vendors with a vested interest in treating the disease (supporting technical debt) rather than curing the patient (actually fixing the problem, reducing the need for complex solutions). My point in the original comment was that QUIC might help stop further ossification by making UDP actually necessary. Otherwise we face the potential for removal of UDP and even removal of non-standard TCP ports, eventually leading to "http only" networks. ISPs and IT departments would like that since less capability equals less support queries and less to monitor. If IP were re-designed today I would suggest at least non-cryptographic but difficult to efficiently modify authentication of all fields (e.g. keyed or nonced checksums), and obfuscation (fast minimal encryption?) of everything under the IP header. No NAT, and nothing useful to filter on. If it's visible and mutable it will become ossified since people will MITM it. That way there would be no choice but to fix endpoint security instead of deploying firewalls and no choice but to adopt IPv6 instead of NAT. You couldn't temporarily work around fundamental problems by nerfing the net. I think there's a general principle here. If easy short term fixes that incur long term technical debt are allowed, they will be deployed. If such a hack is deployed in a federated or decentralized system, it becomes permanent unless extra-systemic means (e.g. legislation or financial incentives) are used to force it to be removed. Therefore federated and decentralized systems should not permit such hacks. Front load the pain by forcing the problem to actually be fixed. This is one thing block chains kind of get right. Everything is cryptographically hashed and authenticated. You can't modify state unilaterally. You either have a compliant node or you don't, and changes must be adopted globally either as soft or hard forks.