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?
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.
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.
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.