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?

  • See Also: virtual reassembly and large receive offload In general routers do as little "touch" as possible. But there are mechanisms to reverse the process of fragmentation, and pre-assemble TCP packets into one larger packet (almost always host-side -- one vs. multiple IRQs)
    – Ricky
    Commented Apr 1, 2018 at 23:08
  • I notice your question is tagged for ethernet. Neither ethernet packets (include the Preamble, SoF Delimiter, and frame), nor ethernet frames (include the ethernet header, payload, and FCS) are routed; they only exist on the link (packet) or layer-2 LAN (frame). Routers route layer-3 (network/internetwork, e.g. IPv4 or IPv6) packets, so nothing of ethernet will cross a router.
    – Ron Maupin
    Commented Apr 3, 2018 at 22:18

2 Answers 2


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
<--------------   Head                     Tail

                  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.

  • Yes. Excellent write-up. I see the problems, and some aren't as bad as you think. A router recalculates the checksum anyway because the ip.ttl changes as well as the macs. We already identify flows and have queues, we'll just create queues within queues. You wouldn't want to do this most places, this is for a clogged pipe situation where you are trying to squeeze the last bit of utilization out of a pipe. When you look at all the other delays, a bit of queueing delay in a router is pretty minimal. The bigest problem in all this is the end nodes. Commented Apr 7, 2018 at 14:39
  • @FredPhillips A "flow" is commonly derived from a 5-tuple {Src IP, Dst IP, Protocol (i.e. TCP/UDP), Src TCP/UDP port, Dest TCP/UDP port). Two packets A and B are said to belong to the same flow if their 5-tuples are identical. Now, you are aware that the TCP/UDP header appears at the beginning of the IP payload. This means that when the IP datagram is fragmented, only the first fragment contains the TCP/UDP header. So there is no way that an implementation can arrive at the conclusion that P1, P2 and P5 (in the example above) belong to the same flow.
    – mere3ortal
    Commented Apr 7, 2018 at 16:43

I think you mean layer-2 frames, not layer-3 packets.

Are normal packets ever combined into jumbo packets?

No. There are no such things as jumbo packets. There are such things as jumbo frames at layer-2. Frames, at layer-2, are sent directly from host to host on the LAN. Routers strip off the frames in order to forward the packets, and they create new frames for the next network to which the packets are forwarded.

Packets may be fragmented by routers if the MTU of the next network is smaller than the packet size. The packet fragments are then routed as individual packets, and the destination host will reassemble the packets. Routers route packets individually, including fragments, regardless of any other packets.

A router's primary job is to route packets as fast as possible, and fragmentation and reassembly take considerable router resources that are better spent routing the packets, which is why the standard is that router fragments the packets as necessary in order to be able to deliver them, but the destination host is the one to reassemble the packet fragments.

From RFC 791, Internet Protocol:

The basic internet service is datagram oriented and provides for the fragmentation of datagrams at gateways, with reassembly taking place at the destination internet protocol module in the destination host. Of course, fragmentation and reassembly of datagrams within a network or by private agreement between the gateways of a network is also allowed since this is transparent to the internet protocols and the higher-level protocols. This transparent type of fragmentation and reassembly is termed "network-dependent" (or intranet) fragmentation and is not discussed further here.

IP leaves the possibility that two routers on a link could coordinate to fragment and reassemble packets at each end of the link, but that is not part of the standard.

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.

Routers strip frames from the packets, they do not route frames, so, no, they will not combine frames. Routers route packets that are the payload of frames.

The idea of routers combining packets really goes against the IP standard. Routers really have no idea if a packet is simply a packet, or is it part of a larger group of packets. A router sees each packet as an individual packet, and it tries to forward it as fast as possible, and it has no idea that another packet that could be combined with the first is even coming.

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.

Doing that for a QoS backlog makes no sense. The outbound interface can only serialize at its rated speed, so combining packets actually gains nothing, and a larger packet would monopolize the interface for a longer time, which goes against the premise of QoS, which is fairness. QoS actually works best with smaller packets.

Or are jumbo frames always end-end?

Jumbo frames are actually end-to-end, but frames only exist on a single layer-2 LAN because routers strip off the frame before forwarding the packet (frame payload). As I explained before, frames are not routed. Frames (layer-2) may be bridged (switched) on a LAN, but they do not survive crossing a router (layer-3).

At layer-2, if a jumbo frame hits an interface of a bridge or host that cannot use jumbo frames, the frame is dropped as damaged or giant. Evey interface through which jumbo frames pass must recognize the jumbo frames. The problem with that is that there is no standard for jumbo frames. Each vendor has its own way to do that, and even within a vendor, different devices may use different jumbo frame sizes. There are switches that can use one size for some interfaces, but other sizes for other interfaces. You must carefully plan the LAN to use jumbo frames, and your hosts must recognize them, too.

  • In your rush to point out that you know the definition of packet and frame you forgot that they are often used interchangeably and missed the point. Also, in this instance I used them perfectly. Internally the router process that is creaing a Jumbo Frame on the output side would be working with packets internally. A packet gets split into fragments so why couldn't it combine them? (And I totally qualified the part about not forwarding immediately because of a queue backup, which would be the reason to do it in the first place) Commented Mar 31, 2018 at 23:30
  • 1
    Where do you get any idea that there are jumbo packets? There may be jumbo frames on LANs that support them, but frames are not routed, so jumbo frames have nothing to do with routers because routers strip off the frame before forwarding the packet. I also explained that routers do not combine packets because a router has no idea that a packet is associated with any other packet. Routers treat packets individually.
    – Ron Maupin
    Commented Mar 31, 2018 at 23:35
  • 3
    @FredPhillips There is no such thing as a "jumbo packet". IP packets can be up to 64 Ki in size and you can't make them larger. Using packets and frames interchangeably is not a good idea - it might not hurt in some cases but can be a big problem in other cases, e.g. when mixing up "MTU" and "maximum frame size".
    – Zac67
    Commented Apr 1, 2018 at 10:02
  • 1
    @FredPhillips "In your rush to point out that you know the definition of packet and frame you forgot that they are often used interchangeably" - Not among network professionals, which is the focus of this particular SE community. If you were asking on Super User, where the audience if different, this complaint may have more merit.
    – YLearn
    Commented Apr 3, 2018 at 1:31
  • When in doubt - probessionals read the RFC tools.ietf.org/tools/rfcmarkup/rfcmarkup.cgi?rfc=0948 Commented Aug 15, 2021 at 12:24

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.