&gt; If you wanted simple transport of large data chunks, you would have chosen likewise.<p>That&#x27;s not entirely fair. UDP is actually a very convenient transport for packetized data of 65,000 bytes or less.<p>&gt; You picked UDP because you have latency requirements that cannot be met by TCP.<p>That is not really a good reason to use UDP, as you won&#x27;t necessarily get better latency (as has oft been demonstrated).<p>You <i>should</i> pick UDP because you have a connectionless protocol and&#x2F;or one with data loss requirements that are different from those built in to TCP.<p>&gt; that means you need to know what your packets are actually doing, and that includes fragmentation.<p>UDP is supposed to abstract IP fragmentation issues for you.<p>&gt; 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.<p>I&#x27;ve used UDP based protocols all the time. I&#x27;d agree that I&#x27;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&#x27;ve <i>never</i> done MTU discovery.<p>&gt; But let&#x27;s not start editorializing our titles: the apps for which GCE is &quot;unusable&quot; are buggy apps to start with.<p>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&#x27;s fragmentation &amp; defragmentation logic up in layer-7.<p>Isn&#x27;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?