Isn't fragment reassembly essentially implying all the packets (fragments) will arrive, and will be rearranged in order? i.e. exactly what TCP does?
For example imagine sending a single 1MB packet via UDP, letting it fragment and be reassembled. What distinguishes that from TCP?
No. It is implying that it does what UDP does. TCP is different because it constructs a continuous stream. UDP is inherently packet/message based.
UDP ensures that all of the IP fragments for a given UDP packet get reassembled and rearranged and order. The UDP packets themselves are not arranged in order, and it is possible to see duplicates.
> For example imagine sending a single 1MB packet via UDP
Not possible. You can't send more than a 65,507 byte packet via UDP[1].
Sigh... unfortunately, there are a lot of misconceptions about the basic plumbing of TCP/IP.
[1] UPDATE: as was pointed out in comments, my statement was only true for IPv4. Since IP packets in IPv6 can have jumbograms larger than 65,535 packets, IPv6 UDP does support larger packets. Of course, in that case, UDP doesn't handle the fragmentation/defragmentation protocol itself, and of course GCE won't handle anything IPv6.
https://tools.ietf.org/html/rfc2147
(Good luck with that over the public internet, but it is possible to make udp packets larger than 64K)
IPv6 jumbograms are a whole different kettle of fish, as they are really handled at the IP layer, and are supposed to only be for cases where you have an MTU > 65,575 bytes. As that link describes, the UDP protocol itself doesn't do any fragmentation or reassembly of those packets. RFC 2147 is really just an update to handle the fact that IPv6 can have a single packet that is larger than an IPv4 packet.
It's a thought experiment not a specific number. I'm trying to demarcate some of the differences between TCP and UDP, and UDP reassembling fragments looks a whole lot like TCP.
There is only a tiny bit of similarity in that they are both dealing with reassembling a higher layer protocol payload from fragments split up over IP.
Let's count the ways they are different:
1. UDP does provide ordering guarantees within a UDP packet. It provides no ordering guarantees between UDP packets. Consequently, the protocol never has to worry about ordering more than 2^16 bytes of IP data (that makes the sorting algo really simple and efficient).
2. UDP doesn't have to deal with complex stalls or partial delivery of data. Either it has all the IP packets for a given UDP packet (in which case, it immediately delivers the UDP packet), or it doesn't (in which case it doesn't deliver it). If there is a UDP packet is missing a fragment, but a subsequent UDP packet is fully assembled, that one gets delivered.
3. There is no retransmission. UDP doesn't retransmit. It doesn't even guarantee deduplication. It is entirely possible that fragmented packets going different routes can end up creating an echo of multiple copies of a UDP packet being transmitted to the recipient.
The above makes UDP far simpler, and the contract application layers operate under very, very different. If you look at your typical TCP stack's logic for reassembling fragments, you'll find it far, far more complex than for UDP.
No handshaking, no blocking, no resending, no throttling.
It's the same as a small UDP packet in every way except for a higher chance of packet loss.
UDP has no feedback from the receiver to the source. If a packet is dropped, the IP stack on the receiver will never complain and the IP stack on the sender will never resend. SO the receiver will silently drop the whole packet.
Notice it can be hard to tell if a packet is dropped, or is reordered. You receive 2,3 - maybe 1 is still coming but reordered? So detecting dropped packets is a heuristic, depending on timing. Various algorithms will use a timer to say when to give up on a packet, or drop a packet if a frame from a subsequent packet is received, or tolerate one frame from a subsequent packet (maybe the last frame of the previous packet was reordered with the first of the next) and so on. But all the work is on the receiver. The sender is not involved.
Unless there is some application-layer protocol that notices packets arriving with a gap, and sends something back (that might also not arrive) like "I got packet a,b,d but missed c". Etc. Notice the application cannot resend frames; only packets because it is unaware of fragmentation/reassembly which happens in the IP stack.
