# Are normal packets ever combined into jumbo packets?

Fred Phillips 05/26/2018 at 18:34. 1 answers, 0 views

Do routers ever combine multiple small frames into a jumbo frame then split them up again on the other end? I know that most of the time it wouldn't make sense to do because you would add latency by waiting for the second packet to come in, but if you had a QOS backlog it might make sense. Or are jumbo frames always end-end?

mere3ortal 04/01/2018.

Let me see if I am understanding your scenario correctly:

• there is a router R somewhere in the path between a sender A and a receiver B (i.e. R is not necessarily the first hop router from A)
• this router sees multiple fragments of an IP datagram sent from A to B
• there is congestion on the outgoing interface from R (i.e. a "QoS backlog") thereby causing these fragments to sit in a queue waiting to get transmitted
• the outgoing interface on R is capable of jumbo frames
• the implementation on R examines the packets sitting in the queue, realizes they are all fragments of the same IP datagram and thinks "hey, why don't I reassemble these packets and send them out as a single jumbo frame?"

Assuming my understanding of your problem statement is correct, let's see what it would take to implement this.

Let's say the queue on the egress interface looks like this at some instant:

  (out)           Queue                    Queue

P1  P2  P3  P4  P5  P6 . . .

(1) Identification: The router would have to examine these packets, check if they are IPv4 or IPv6 (with the fragmentation extension header), then look at the fragmentation fields to identify reassembleable fragments. (Not all packets are IPv4 or IPv6, and the implementation would have to leave these packets alone.)

(2) Transmit order: It is possible that P1, P2 and P5 are fragments of one datagram, and P3, P4 and P6 are fragments of a different datagram. The implementation would therefore have to first reassemble and transmit (P1 + P2 + P5), then (P3 + P4 + P6). Normally queues are first-come-first-served, but now you'd have to "cherry-pick" fragments from across the entire queue.

Also consider what would happen if P5 is not the last fragment of the datagram; so you have to wait till the last fragment showed up in the queue, but in the meanwhile (P3 + P4 + P6) is ready to be reassembled and transmitted, so would you transmit it?

(3) Out-of-order fragments: Note also that it is possible that P2 might in fact be the first fragment, P1 the second and P5 the third. This is because these fragments may have taken different paths on their journey from A to R. Normally, end hosts deal with this situation of out-of-order fragments, but if routers start doing reassembly, this is something that they have to take care of as well.

(4) Checksum recomputation : Another thing you'd have to take care of after reassembly is checksum recomputation. Note that earlier in the routing pipeline we have already recomputed the checksum once (after decrementing the TTL), and now in the output queueing stage, we'd have to do it again after reassembly.

(5) Refragmentation: Another thing you'd have to consider is refragmentation: if in the above example P1, P2 and P3 were of sizes 4000, 4000 and 1500 bytes, and the output interface had an MTU of 9000, would you leave the three fragments alone or would you refragment into two packets of size 9000 and 500 ?

(6) Then finally you'd have to think about performance. All the above processing would have to be done at line rate, i.e. after every enqueue to the queue. For a router that supports even 10Gbps line rate performance you can calculate how fast the reassembly related processing described above has to happen.

In summary I'd say that this is possible in principle, but the practical issues are many. And the benefit does not justify the engineering cost involved in implementing this (read: if you were a buyer, how much more money would you be willing to spend on a router that can reassemble versus a router that can't?). Having said that, if some smart end-user application designer can build an application that can demonstrate superior performance (measured in terms of  :-)) by using routers that support reassembly, then it's a different story.