> We also now have to debug against every single userland TCP > implementation someone can come up with, the barrier to entry is > insanely low with TOU. Maybe this sounds great to you, but to me > it is quite terrifying > No, it doesn't sound great, but the major problem we have is that Android and to some extent iOS & Windows take a long time to update the kernel, and it can take an _extremely_ long time if we need them to actively enable features that are needed by applications. For instance, TFO was put in the Linux several years ago, but it still hasn't been enabled in Android and only fairly recently enabled in iOS. If we (e.g. Facebook) implement a userspace stack in clients and control the stack in our servers we can roll out a feature like that in a couple of months. I don't see anyway to fix other than trying to take control of our own destiny. It seems like it's either this or use something like QUIC which bypasses the kernel completely and discards TCP-- we have far too much invested to commit to that alternative at this point.
> This sounds really great on paper, however I find it hard to believe > that makers of middleware boxes are just going to throw their hands in > the air and say "oh well, we lose." > Happy Eyeballs is implied. There's pretty good data that the majority (>90%) of the Internet will pass UDP without issue, QUIC is already seeing good deployment and there are several UDP based protocols productively deployed. There is also an effort in IETF, PLUS, to define a substrate layer that makes UDP based transport protocol palatable to middleboxes with some sort of signaling. > Rather, I think people are going to start adding rules to block TOU > tunnels entirely because they cannot inspect nor conditionally > filter/rewrite the contents. This is even more likely if Joe Random > and so easily can do their own userland TCP stack over TOU. > Unfortunately, encryption is the only proven solution to protocol ossification. If the network doesn't see it, it can't ossify it. > BTW, I have a question about the pseudo header checksum. If the outer > IP addresses can change, due to NAT or whatever, and therefore the > session key is used for connection demuxing instead of the addresses, > why don't we also have to use the session key instead of the IP > addresses for the pseudo header used in checksum calculations? Yes, the inner checksum will need to be handled differently in case of NAT. Need to update draft to take that into account. Thanks, Tom
