> On 28 Jul 2016, at 22:03, Joe Touch <[email protected]> wrote: > > > > On 7/28/2016 12:57 PM, Olle E. Johansson wrote: >>> All you can do is cause them visibly break so you can detect and >>>> eradicate them. >> If you check the paper I referred to they have detected the presence >> of TCP proxys, which may help us with setting protocol options >> right in order to work. Or just fail. > My point is that this logic is backwards. > > The order of TCP options is whatever TCP wants them to be at the > endpoints. It should NEVER be constrained by these devices, which are > already clearly violating spec. > > I don't want everyone's TCP to "just fail" when it hits these boxes - > perhaps it would be useful to create a custom TCP that can be used to > find these boxes, but once they're found we need to point them out and > demand they be removed (if you're paying for "Internet" behind such a > box, you might have the right to make such a demand). > > I.e., we should NEVER use these boxes to govern how we build TCP for the > masses.
That’s right - but we do need to find out what happens. Right now our support is getting a lot of issues that is hard to explain and we’re not even customers of these carriers. Telling the customer that the net is broken doesn’t help us - “Facebook, Pokemon and the others work” We either break the assumption that TCP is reliable, find these boxes and refuse to work with them or will continue to get complains… We are pressed into a corner and want to find a way out. At some point we as a community need to find a good “INternet test tool” for the masses that doesn’t just focus on download bandwidth - but also quality of the Internet connectivity. /O
