Added value?
"we want to provide mechanisms to let operators try to add value"
Can anyone explain what "added value" is in this context? Why would I want it? (And I don't mean being whored to advertisers by my ISP)
It's not often that someone crafts a protocol expecting to destroy it, but that's what Cisco distinguished engineer Joe Hildebrand and a bunch of other Internet architecture boffins are doing right now. When NSA whistleblower Edward Snowden talked of a protocol called SPUD – Substrate Protocol for UDP Datagrams – it piqued the …
As an application developer, I want the protocol to do all the heavy lifting. I don't want to have to code a lot of stuff into my app that shouldn't have to be there, and potentially get it wrong. I just want to be able to either create a connection, or receive a connection, and know that what I pass down that pipe will get there in a fast and secure fashion. Today, I find myself using API after API; MSMQ, signalR, IOCP->ImmutableStack, because the heavy lifting is bubbled up to the application layer. But its not like my requirements are fundamentally different to 99.9% of everyone else doing TCP development, who just need to get the data to get from A to B, or A to Many. If this means losing the 'value add' of rate-limiting protocol-massaging that my ISP believes is 'helping me', then so be it.
But TLS over TCP?
I think one of the suggestions pointed out is that if we assume encryption is part of the basic protocol, then we could remove some of the unnecessary layering.
It is good to have a logical stack like the OSI model but an awful lot of the protocols that we have are little more than hacks stacked on top of each other (NAT - I'm looking at you).
I do like the idea of stepping back and thinking really hard about a properly engineered stack solution.
Assuming TMMM === The Mythical Man Month (where Chapter 11 has the title Plan To Throw One Away). [Is there anything else it might be?]
Still essential (although obviously dated: e.g. microfiche references). Your scrummasters etc and indeed almost everyone else should Read This First. And it needn't cost anything but time.
Freely downloadable (presumably legitimately: how about an El Reg article about Archive.org one day?):
https://archive.org/details/mythicalmanmonth00fred
This sounds good.
Some sort of proxying is needed to prevent IP address leakage. It'll make the old IP layer redundant but pruning it is probably too much to ask at this stage. Privacy next decade, efficiency a few decades later, maybe.
I wonder if anyone's got a working UDP-based implementation today that allows P2P gaming without exposing IPs to the other players or their ISPs; that's the gist of this. Then eventually SPUD's successor would standardize, optimize, and simplify such protocols, right? Nah... that's basically TOR; too much latency. We need ISP/backbone routers to support anonymous routing... verifiably... in a DDoS-proof manner. In all sincerity, good luck with that!
You run into a Hard problem. Routing by definition involves a source and a destination. Think of an Internet packet like an envelope. In order for it to get to its destination, it needs a recipient, and in order for a return in case of a problem, it needs a sender. There's no escaping these requirements without envelopes getting dropped on the floor and lost. Given that, there is always an inescapable paper trail. And given there's always a demand for efficiency (if for nothing else than to conserve energy use), how do you balance out these conflicting demands?
This is true, but a separation of the routing information and payload would be beneficial. For instance, assume the entire payload was deeply encrypted, adding a tag to say the payload contained encrypted video traffic would allow for as much information as an ISP should need to know for rate limiting, without having to deep packet inspect every last byte.