How are ping times computed

Question

I have been graphing ping (IPV4) responses times/vs packet size. I was expecting to see a discontinuity of around 2*MTU/BandWidth in response time around the MTU boundary (actually, around 1464 byte, MTU is 1492 on this particular segment). The rationale for my expectation is that, 2*MTU/BW being the roundtrip time of a packet with 1 MTU size, packet fragmentation will increase roundtrip times in steps of twice that amount.

Alas, that's not what I see. Using

   # ping -f -c 30 -s $sz my.host

I see a linear dependence between packet size and roundtrip like follows (size, min avg max, ms.), but no discontinuities of sort:

1159  40.575 41.778 47.200
1220  41.392 42.145 45.420
1281  41.921 43.461 46.974
1342  42.498 43.840 52.638
1403  42.813 44.037 49.272
1464  43.741 45.455 49.795
1525  45.382 50.406 59.891
1586  45.579 55.605 66.309
1647  47.498 53.464 64.518
1708  49.373 73.681 84.820
1769  49.726 80.030 101.057

So I do not know if I am being tripped by something in the way packets are being sent/reported or if my reasoning is wrong some way or the other (and in these case where is the error).

It's and ADSL llink to the internet that goes through 100MB wired ethernet, crosses a FGT60 and a zyxel on its way out, and tracepath (also ping -M do) report 1492 as MTU. I am testing from a FC22 linux box. I do not know, but it seems to me that the outside details of the network should not matter (much) viz. the qualitative result I am missing, because fragmentation should happen (at least) before leaving the local interface past the 1500 MTU mark (that's the ethernet connection MTU)

Edit: And the (hidden) faulty piece of reasoning lies in equating the minimum transmission unit (which for tcpV4 over ethernet would be something around 64 bytes), lets call it the mTU, to the MTU - ie, in assuming that all packets will be padded to the MTU. That not being the case, the discontinuity due to fragmentation should be around mTU/Bw, around 20 times smaller than MTU/Bw and likely to be swallowed by the jitter due to varying network conditions

Answer 1

I'm not sure why you would think fragmentation would double the time. If a router fragments a packet, it sends both fragments sequentially. The host on the other end will get the fragments, reassemble them, and reply. The increase in time for fragmentation should be fairly linear. It takes time for a router to fragment a packet, and it takes time for the receiving host to reassemble the fragments.

Doubling the time would involve sending one fragment, getting a response, sending the next fragment, getting the response, and then reporting the time. That is not how it works.

RFC 793, TRANSMISSION CONTROL PROTOCOL, explains how IP fragmentation works.

You should also understand that ICMP (ping uses ICMP Echo and ICMP Echo Reply) is often treated differently than regular IP traffic on the Internet. It is usually low priority, and it will often be queued in favor of regular traffic, and it will be more sensitive to the variable congestion that happens. It may even take a different path than regular traffic. The added latency could end up dwarfing, by sever orders of magnitude, the latency induce by fragmentation. This can have the effect of smoothing the curve.

The real way to test fragmentation is on a controlled environment to eliminate variables which are out of your control. Start testing with a point-to-point link between two hosts. Then, start to add devices (switches, routers, etc.) between the two devices, in controlled steps. Perform each test multiple times before changing the test environment. Testing on the Internet can give you unpredictable results since you have no control over the Internet.