Project

General

Profile

Bug #1651

udp4 packet has DF flag set

Added by Junxiao Shi over 5 years ago. Updated about 5 years ago.

Status:
Closed
Priority:
Normal
Category:
Faces
Target version:
Start date:
06/07/2014
Due date:
% Done:

100%

Estimated time:

Description

Environment: Ubuntu 12.04 64-bit, OpenVZ kernel 2.6.32

Steps to reproduce:

  1. create a udp4 tunnel
  2. tcpdump on NIC used by this udp4 tunnel
  3. cause an Interest to be sent via the tunnel

Expected: "Don't Fragment" flag is unset on the udp4 packet

Actual: "Don't Fragment" flag is set on the udp4 packet

NFD does not plan to have fragmentation on udp4 tunnels, and needs to rely on IP fragmentation.

With "Don't Fragment" flag set, IP fragmentation is disabled.

DF.pcap (1.52 KB) DF.pcap Junxiao Shi, 06/08/2014 01:45 AM
osx10-9.pcap (481 Bytes) osx10-9.pcap Alex Afanasyev, 06/20/2014 01:53 PM

History

#1 Updated by Alex Afanasyev over 5 years ago

Is this flag set even when packet size is larger than MTU size?

#2 Updated by Junxiao Shi over 5 years ago

The tested system has 1500-octet MTU.

UDP packet for a 1572-octet NDN packet is fragmented, and has no DF flag.

UDP packet for a 1470-octet NDN packet has DF flag set.
However, universally supported MTU for IPv4 is 576.
Even if all backbones support 1500-octet MTU, most datagram-based VPN would decrease MTU to around 1396.

#3 Updated by Junxiao Shi over 5 years ago

  • Assignee set to Davide Pesavento

#4 Updated by Davide Pesavento over 5 years ago

Isn't this behavior part of the path MTU discovery that Linux does by default for TCP and UDP?

I don't think this actually created any problems in your particular test case, otherwise the send call would have returned EMSGSIZE and you should have noticed that in the logs.

In any case, since we cannot do sender-side datagram fragmentation in nfd (unless we use ndnlp for udp too), we are unable to properly respond to ICMP "datagram too big" messages, for instance by reducing the datagram size. Therefore we should probably disable PMTU discovery on the udp socket.

Does the same happen on mac?

#5 Updated by Davide Pesavento over 5 years ago

Any comments on my previous comment? Other ideas? If not, do you want me to submit a patch to disable PMTU discovery for udp4 faces?

#6 Updated by Junxiao Shi about 5 years ago

As decided in 20140619 conference call, Davide should submit the patch only if it's "not complicated" and it is platform-independent.

#7 Updated by Alex Afanasyev about 5 years ago

Check on OSX 10.9. No flags are set when < 1500 byte UDP datagram is sent out.

#8 Updated by Davide Pesavento about 5 years ago

Alex Afanasyev wrote:

Check on OSX 10.9. No flags are set when < 1500 byte UDP datagram is sent out.

Ok, then we can conclude that this behavior is Linux-specific. Consequently, I'm going to assume that the "platform-independent" requirement (comment #6) no longer applies.

#9 Updated by Davide Pesavento about 5 years ago

  • Status changed from New to In Progress

#10 Updated by Davide Pesavento about 5 years ago

  • Status changed from In Progress to Code review
  • % Done changed from 0 to 90

#11 Updated by Alex Afanasyev about 5 years ago

Checked how fragmentation works for IPv6. On my machine UDP datagrams more than 1232 bytes is getting fragmented. In any case, this would universally work for all paths, since IPv6 spec requires 1280 as minimum MTU.

root@benz:/home/cawka# tcpdump -vv -ni tun0 host 1::1
tcpdump: listening on tun0, link-type RAW (Raw IP), capture size 65535 bytes
20:18:42.451461 IP6 (hlim 64, next-header UDP (17) payload length: 1240) 2607:f010:3f9::1.6363 > 1::1.6363: [udp sum ok] UDP, length 1232

...

20:18:45.292617 IP6 (hlim 64, next-header Fragment (44) payload length: 1240) 2607:f010:3f9::1 > 1::1: frag (0x94bcca39:0|1232) 6363 > 6363: UDP, length 1233
20:18:45.292628 IP6 (hlim 64, next-header Fragment (44) payload length: 17) 2607:f010:3f9::1 > 1::1: frag (0x94bcca39:1232|9)

This behavior is consistent with and without the patch in the code review.

#12 Updated by Davide Pesavento about 5 years ago

  • % Done changed from 90 to 100

#13 Updated by Alex Afanasyev about 5 years ago

  • Status changed from Code review to Closed

Also available in: Atom PDF