5

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

  • You are posting the results, but you are forgetting to give the parameters. You need to edit your question with a diagram and description of the network between the two devices. – Ron Maupin Jun 1 '16 at 16:09
  • 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) – Alien Life Form Jun 1 '16 at 16:21
  • You should edit your question to include that. – Ron Maupin Jun 1 '16 at 16:31
3

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.

| improve this answer | |
  • 1
    fragmentation has to go through the "slow path" via the system processor. (in Cisco terms, "punted") CPU packet processing is slow. Fragmentation is an edge case in modern networking, so it's generally done slowly, at low priority. (the fortigate has hardware forwarding, the zyxel likely doesn't.) And extra processing has to be done at the receiver to put it all back together. – Ricky Beam Jun 1 '16 at 18:49
  • "I'm not sure why you would think fragmentation would double the time." This makes me see my error. - See following comment. – Alien Life Form Jun 3 '16 at 6:55
  • The (hidden) faulty piece of reasoning is that I was equating the minimum transmission unit (which for tcp over ethernet would be something around 64 bytes) to the MTU - ie, I was assuming that all packets need to be padded to the MTU. That not being the case, the discontinuity due to fragmentation should be around mTU/Bw, around is 20 times smaller than MTU/Bw and likely to be swallowed by the jitter due to varying network conditions. – Alien Life Form Jun 3 '16 at 7:03
  • And of course, all the other objections also make a lot of sense - however, I was expecting a qualitative effect which, on that fairly unloaded link, should have been quite obvious (a 20 ms. jump over a 30 ms. ping) even accounting for outside, unknown perturbations. But of course, I was wrong. – Alien Life Form Jun 3 '16 at 7:08

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

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