4 ms·

> Isn't fragment reassembly essentially implying all the packets (fragments) will arrive, and will be rearranged in order? i.e. exactly what TCP does? No. It i

by cbsmith 11y ago

> Isn't fragment reassembly essentially implying all the packets (fragments) will arrive, and will be rearranged in order? i.e. exactly what TCP does? 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.

jacquesm 11y ago
There is this thing called 'IPv6 jumbograms'. https://tools.ietf.org/html/rfc2147 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)
- cbsmith 11y ago
  Sorry. I was presuming we were talking about about UDP fragmentation with IPv4, as this was the bug report and of course GCE doesn't support IPv6. 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.
  - jacquesm 11y ago
    It is me that should say 'sorry', I found this on a bit of documentation about GCE: "Note: Compute Engine networks only support point-to-point IPv4 traffic. Broadcast and Multicast are not supported." https://cloud.google.com/compute/docs/networking?hl=en https://cloud.google.com/compute/docs/networking?hl=en And this: https://code.google.com/p/google-compute-engine/issues/detail?id=8 https://code.google.com/p/google-compute-engine/issues/detai... So: Sorry!
ars 11y ago
> Not possible. You can't send more than a 65,507 packet via UDP. 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.
- Dylan16807 11y ago
  Each individual packet has separate reassembly and delivery. Losing a fraction of packet 1 won't stop packets 2 and 3. 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.
- cbsmith 11y ago
  > 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.
  - ars 11y ago
    > UDP doesn't have to deal with complex stalls or partial delivery of data. Are you sure? If some fragments show up and some not, doesn't it have to wait and see if the rest show up? Maybe it doesn't have to wait for a long time (like TCP), but it does have to wait. Both point 1 and point 2 are a matter of quantity vs TCP, rather than quality. i.e. UDP+fragments is a sort of TCP-lite.

by cbsmith 11y ago

jacquesm 11y ago

There is this thing called 'IPv6 jumbograms'. https://tools.ietf.org/html/rfc2147 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)

cbsmith 11y ago
Sorry. I was presuming we were talking about about UDP fragmentation with IPv4, as this was the bug report and of course GCE doesn't support IPv6. 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.
- jacquesm 11y ago
  It is me that should say 'sorry', I found this on a bit of documentation about GCE: "Note: Compute Engine networks only support point-to-point IPv4 traffic. Broadcast and Multicast are not supported." https://cloud.google.com/compute/docs/networking?hl=en https://cloud.google.com/compute/docs/networking?hl=en And this: https://code.google.com/p/google-compute-engine/issues/detail?id=8 https://code.google.com/p/google-compute-engine/issues/detai... So: Sorry!

ars 11y ago

> Not possible. You can't send more than a 65,507 packet via UDP. 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.

Dylan16807 11y ago
Each individual packet has separate reassembly and delivery. Losing a fraction of packet 1 won't stop packets 2 and 3. 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.
cbsmith 11y ago
> 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.
- ars 11y ago
  > UDP doesn't have to deal with complex stalls or partial delivery of data. Are you sure? If some fragments show up and some not, doesn't it have to wait and see if the rest show up? Maybe it doesn't have to wait for a long time (like TCP), but it does have to wait. Both point 1 and point 2 are a matter of quantity vs TCP, rather than quality. i.e. UDP+fragments is a sort of TCP-lite.