> On 28 Jul 2016, at 22:17, Joe Touch <[email protected]> wrote: > > > > On 7/28/2016 1:11 PM, Theodore V Faber wrote: >> On 7/28/16 13:04, Joe Touch wrote: >> >>> I.e., we should NEVER use these boxes to govern how we build TCP >>> for the masses. >> >> To say that another way: vendors who produce such devices are failing >> to follow the Postel principle. > > The Postel Principle talks about what to do when the docs don't say > otherwise. > >> Whether the IETF says anything >> explicitly or not, > > Actually, they're quite directly contradicting explicit existing standards. > >> they're producing artifacts of less value to their >> customers. Standards-compliant stacks will emit TCP options in ways >> that such vendors evidently don't expect. > > Those vendors shouldn't be looking at TCP options or TCP at all. It's > none of their business. Well, the question is what they are trying to solve by breaking TCP? I personally suspect that the latency on some radio networks cause a lot of retransmits. By adding a TCP proxy they avoid retransmits wasting bandwidth and at the same time causing issues when it doesn’t work. Can we help them with a better solution if this is the problem?
Does anyone know what the problem they are trying to solve is? (Still trying to find information) > > Maybe we should just start using IPsec in BTNS mode (to avoid needing > keys) as a tunnel to get through all such devices. > >> >> The IETF standard reflects a consensus among designers and >> implementers that there's no constraint on TCP option ordering. The >> time to argue about it is past; live with it or produce crappy products. > > This issue cannot be fixed merely by reacting to what vendors deploy. > > The solution has been clear for a long time - *compliance verification*. > I assure you that vendors that get sued for saying "Internet compatible" > who are not would behave differently. So where do we have a good specification that we agree on defining “Internet compatible” ? /O
