UDP fragmentation

[indo3]

TCP packets can be maximal 64kb in size. They are mostly fragmented in smaller parts
if send over the internet.
My question: Sending a 64kb UDP packet between two endpoints,
do they have to maintain a protocol similar to TCP for keeping
the correct order of the IP fragments?

Second question: IPv6 not supports fragmentation of IP packets,
so I guess it is not longer possible to transmit large UDP packets,
so can UDP not longer be used for sending an e.g. 50kb IP packet and
TCP must be used which would devide the 50kb packet in e.g. 1.5 kb packets
and assemble them in a correct order at the receiver?

[Casper H.S. Dik]

Post by indo3
TCP packets can be maximal 64kb in size. They are mostly fragmented in smaller parts
if send over the internet.
My question: Sending a 64kb UDP packet between two endpoints,
do they have to maintain a protocol similar to TCP for keeping
the correct order of the IP fragments?

No, IP reassembles. But note that a 64K packet constists of 44
fragments and that even 2.5% packet loss means that none of your UDP
packets is likely to arrive. (But 2.5% packet loss is fairly exceptional,
but perhaps not when you send a burst of 44 packets).

Casper

[Rick Jones]

No, IP reassembles. But note that a 64K packet constists of 44
fragments and that even 2.5% packet loss means that none of your UDP
packets is likely to arrive. (But 2.5% packet loss is fairly
exceptional, but perhaps not when you send a burst of 44 packets).

To expand on that a little - all fragments of a fragmented IP datagram
must arrive at the destination for the IP datagram to be reassembled.
If even one IP datagram fragment is lost, the IP datagram cannot be
reassembled and so it will end-up being tossed. Hence, the UDP
datagram (or TCP segment) carried in that fragmented IP datgram is
lost. IP does not provide retransmissions, so the Upper Layer
Protocol (ULP) will have to recover somehow.

If the packet loss rate (ie probability p) is 2.5%, that means the
packet "not-loss" rate is (1-p). Since _all_ fragments must arrive,
the probability of that is then (1-p)^numfrags. So, taking the
numbers from above, that would be 0.975^44 or a very very small
number.

That "amplification" of the packet loss rate into a much larger
datagram loss rate by IP fragmentation is one of, it not _the_
principle reason IP fragmentation is considered "bad."

And then of course, there are Frankengrams :)

rick jones

[Robert Wessel]

Post by indo3
TCP packets can be maximal 64kb in size. They are mostly fragmented in smaller parts
if send over the internet.
My question: Sending a 64kb UDP packet between two endpoints,
do they have to maintain a protocol similar to TCP for keeping
the correct order of the IP fragments?

Neither UDP or TCP really see IP fragmentation. If a packet is
fragmented at the IP layer, it is reassembled by the receiving IP
before being passed up the stack to UDP or TCP (or whatever). There
is not really a 64KB limit in TCP other than the IP packet limit
(excluding the urgent pointer) - TCP normally segments a stream of
data into many packet, but this is *not* fragmentation.

In IP4 the base header contains enough information to identify each
packet (the receiver will use the source and destination IP plus the
ID field), plus an indication of how each fragment fits into the whole
(where it starts, and if there are more segments after this fragment).
The receiving IP starts reassembly when it receives the first
fragment, and waits until it has all the pieces before passing the
reassembled packet on (unless it times out, in which case everything
is discarded).

Post by indo3
Second question: IPv6 not supports fragmentation of IP packets,
so I guess it is not longer possible to transmit large UDP packets,
so can UDP not longer be used for sending an e.g. 50kb IP packet and
TCP must be used which would devide the 50kb packet in e.g. 1.5 kb packets
and assemble them in a correct order at the receiver?

This is incorrect. In IP6, *routers* may no longer fragment packets.
Fragmentation, if necessary, must be done by the sending IP, the
receiving IP reassembles pretty much as always. This means that
sending hosts either need to do PMTU discovery (or use other data
sources to determine what size packets to send) or limit themselves to
the 536 octet guaranteed minimum size. In IP6 fragments are defined
with an IP header option, rather than using fields defined in the base
header as in IP4, but it's pretty much the same set of fields.

And finally, IP6 supports jumbograms of up to 4GB, obviously only on
links which support packets (datagrams) of that size. There are
specifications to allow UDP and TCP to deal with jumbograms. Note
that jumbograms are intended for use in a very local environment with
extremely high data rates (for example, using a direct
memory-to-memory interface between two supercomputers), and
fragmentation is *not* allowed.