4 ms·

>The last fragment will almost never have the optimal size. For large transfers this means a significant part of the traffic will be composed of suboptimal shor

• tyingq 9y ago
  I believe the context is where something in the middle is fragmenting almost every packet. Like if you don't negotiate path MTU. So "last" meaning the last fragment of every packet sent, not just the literal last packet. Say 3600 bytes sent with an initial mtu size of 1500, but frags needed at 1200. At least 6 packets sent, versus 3 packets if you used an initial size of 1200. Add in the headers, frag needed packets, etc, and you've sent not only more packets, but more bytes.
• nickcw 9y ago
  The fragmentation is typically from a 1500 byte packet to a slightly smaller value, so you end up with one 1400 byte packet and one 100 byte packet. The fragmentation happens after your computer has packetised the data.
• majke 9y ago
  > For large transfers The implicit assumption is that a fragmented packet will be slightly more than MTU. So for a large transfer - say N packets, of packet size MTU + 1 - you will see N "first fragments" fragmented to the size of MTU, and another N last fragments of size 1. (actually IP header + 1) In other words 50% of the packets flowing will have size of 1 which is super bad use of router switching resources.
  • gsich 9y ago
    But wouldn't that be multiple transfers?
    • majke 9y ago
      By "transfer" here I mean a thing like a curl on a large file.
      • tyingq 9y ago
        It would even apply to a single socket send() of say, a 4k buffer, which is pretty common. Broken MTU negotiation could easily result in twice as many packets as needed in that scenario.
        • haimez 9y ago
          Twice as many packets per reduced MTU hop. The worst case is pretty bad and far north of 2x the number of packets sent from origin.
          • im3w1l 9y ago
            The worst case is that the routers support N, N-1, N-2, N-3, which means one additional packet per hap. I know what you are thinking: "well what if it's N/2, N/4, N/8 etc". And the answer is that in such a network you are screwed anyway. Lots of small packets would be unavoidable.
• topspin 9y ago
  "With large transfers, the most packets will have the maximum length" There is no universal "maximum length" among the links in a route. Some link will have a smaller maximum forcing the previous link to fragment nearly every packet; instant 2x (or more) packet overhead. "Large" transfers exacerbate this as nearly every packet is max size when it leaves the origin host.
• noselasd 9y ago
  Say the TCP stream sends packets of 1500 bytes, an optimal size for most part of most part of the journey of the packet At one point the MTU is smaller, a router have to fragment it in two, say one fragment of 1260 bytes and the last fragment contains the remaining 240 bytes. So, a lot of segments gets fragmented into one 1260 byte fragment and one 240 byte fragment. That 240 byte fragment is far from optimal, the overhead to payload ratio is a lot worse than for the 1260 fragment. A much more optimal approach would be for the endpoint to adjust the segment size, and send all packets as 1260 bytes. (which is what will happen if PMTU works)
  • kazinator 9y ago
    Path MTU discovery is supposed to ferret out the fact that the TCP segment size should be reduced. IP fragmentation is just a best effort mechanism that is better than the datagrams being dropped due to their excessive size; it allows connections to be established. You don't want to be doing bulk transfers with fragmentation. IP fragmentation won't help with latency, because it is redundant. The TCP window is already a form of "fragmentation". TCP already fragments the data into segments that can be received out of order, individually re-transmitted and re-assembled. For large transfers over fast, high latency networks, TCP supports window scaling. Larger individual segments (and thus IP fragmentation) is not required for the sake of having more data "in the air".
    • Borealid 9y ago
      This neglects the fact that IP imposes a fixed per-packet overhead. More packets means lower efficiency. Using larger packets reduces the overhead as a percentage of traffic, so is desirable regardless of the TCP window size. Higher efficiency means higher bandwidth, which means lower latency for small transfers. Waiting for two 10-byte packets yields latency equal to the higher of the two latencies. Waiting for one 20-byte packet is, on average, lower latency (because you take one sample instead of worst-of-two).
      • kazinator 9y ago
        Of course, we want to be using the largest packets that the underlying network allows. My comment is about using larger packets specifically while relying on fragmentation to deliver them. Fragmentation re-introduces the overhead since fragments carry IP headers. If a protocol already segments data into datagrams and reassembles them into a stream, it derives no advantage from IP fragmentation. IP fragmentation basically provides the possibility of operating in the face of misconfiguration (hopefully temporarily), with reduced performance (better than no performance at all). (Of course I'm not saying that since TCP chops the data into pieces and has a sliding window that can scale, there is no downside to making the pieces small just for the heck of it, like 50 bytes of payload!)
• hinkley 9y ago
  You're thinking of streams. The fragmentation discussed here is of packets. Recent equipment might be sending packets of 9000 bytes. When you cross over into older networks that gets split into 6 or 7 packets, so the length of the last packet is a problem but it's 15% of the traffic. But going from older networks into quirky ones (wireless, modems, or ancient systems) will split your ~1500 byte packet into two. Like 1344 and 166 or 900 and 600.
  • Hikikomori 9y ago
    Even recent and not so recent equipment that supports jumbo frames do not have it enabled by default. Large mtu hosts (or the specific interface with a large MTU) should be in an isolated network where all hosts have that large MTU. Best practice is to not mix MTU sizes on hosts that should talk to each other and never go over 1500 for hosts/interfaces that need to talk to the internet.
    • hinkley 9y ago
      Interesting. I haven't participated in a network architecture at the hardware level for a bit so I'm out of the loop. Of course, this whole article is about the differences between what should be and what you encounter in the wild. But if I have jumbo packets in my data center and a reverse proxy at the edge, I either have an application layer creating fragments, or I have another, lesser problem with packet sizes. If I don't see fragmentation, I will instead see some jitter in packet transmission due to buffering. Many workloads wouldn't even notice but some care. The proxy will end up holding onto the last partial packet until the next one is processed. If that packet has a message boundary in it then the jitter turns into latency from the perspective of the destination system.