> If you wanted simple transport of large data chunks, you would have chosen likewise. That's not entirely fair. UDP is actually a very convenient transport fo

> If you wanted simple transport of large data chunks, you would have chosen likewise. That's not entirely fair. UDP is actually a very convenient transport for packetized data of 65,000 bytes or less. > You picked UDP because you have latency requirements that cannot be met by TCP. That is not really a good reason to use UDP, as you won't necessarily get better latency (as has oft been demonstrated). You should pick UDP because you have a connectionless protocol and/or one with data loss requirements that are different from those built in to TCP. > that means you need to know what your packets are actually doing, and that includes fragmentation. UDP is supposed to abstract IP fragmentation issues for you. > If you want to play in that world you need to be prepared to handle MTU discovery on your own, or else design your app around deliberately small packet sizes. I've used UDP based protocols all the time. I'd agree that I've had to be a bit more aware of path MTU when it comes to diagnosing or debugging problems, but in terms of the application code reading and writing UDP packets, I've never done MTU discovery. > But let's not start editorializing our titles: the apps for which GCE is "unusable" are buggy apps to start with. Considering there are bytes in the UDP header specifically designed to allow you send packets larger than MTU size, this is actually a huge problem. For many people, this requires reimplementing UDP's fragmentation & defragmentation logic up in layer-7. Isn't it bad enough that people are reimplementing TCP on top of UDP? Do we really need to tell them to reimplement UDP on top of UDP?