On Tue, Feb 9, 2016 at 10:59 AM, Warren Kumari <warren@xxxxxxxxxx> wrote: > <rant> > There seems to be a fair amount of discussion requiring knowledge of the > host stack, or understanding of the capabilities of a specific network (e.g: > all the hosts support [reassembly of "large" fragments | TCP fast open], all > the routers in my network support looking deep into EH, all my devices set > flow labels, etc.). > > This feels deeply flawed to me - applications shouldn't need to have deep > knowledge of the network or end system stack behavior, and relying on > specific behavior of a system / network makes the application brittle and > non-portable[0]. Absolutely. And I see similar issues when people try to get me to use HTTP features in Web Services. I know all about said HTTP features. I wrote some of them. But when I am running a Web Service over HTTP, HTTP is a lower level protocol layer and I don't want my application to depend on any feature at that level unless there is a clean separation of concerns. > Until a behavior is supported by the lowest common denominator / (almost) > everything, it probably makes sense to avoid it[1]. Probably. But there is another option: Put all the wood behind one arrow. The IETF is architected as a research lab rather than a standards body. That has good points and bad points. One of the bad points is that we don't end up with one consistent and coherent way to achieve an outcome, we end up with multiple options and a hope that 'the market' will come to a decision. And then people are upset when the market decides that it is quite happy where it is. The other problem is that as Warren points out, the process doesn't really produce proposals that are fully interchangeable. For years people were trying to persuade people to move to DNSSEC and IPv6 with what I call the 'boat anchor' strategy of forcing other specs to build on them as a platform requirement. I once sat through a BOF where a group of people who claimed to be doing 'home automation' (what we called IoT before) who started off by mandating IPv6. If you are writing an application protocol and it mandates IP let alone a specific version then you are doing it wrong. > Yes, this sucks. It means that innovation slows down - apps avoid > non-ubiquitous features, which means that vendors / stack have less > incentive to build / deploy them. Waving the protocol bible and saying "but > the spec says..." doesn't really change the incentives of reasonable people > optimizing for their own (selfish) reasons. TCP fast start does at least have the advantage that the endpoints can always gracefully degrade to regular TCP. So it does have something of a transition strategy. But probably not enough right now to convince me that I should move away from a UDP hack (if I was doing one).