UDP Fragmentation and DF bit..

UDP Fragmentation and DF bit..

[Vincent, Pradeep]

After running into issues with UDP in multi-MTU network environment, I
started digging through the code and found somewhat inconsistent behavior
(if I read the code right)

OMan 7 ip¹ declares that ³The  system-wide  default  is  controlled  by  the
ip_no_pmtu_disc  sysctl  for SOCK_STREAM  sockets,  and  disabled  on all
others.² which led me to think ODF¹ bit will not be set for UDP packets.
But..

The code in ip_output.c seems to do the following,

1. If packet size <= current PMTU, then set the DF=1 and send the packet
out.
2. If packet size > current PMTU, then set DF=0 and send the packet out
after fragmentation.

In a network environment where MTU-big and MTU-small co-exist (and have
router¹s fragmentation turned off in favor of PMTU discovery), UDP packets
that are > MTU-small and < MTU-big find the PMTU effectively but UDP packets
that are > MTU-big get dropped. This looks like inconsistent behavior to me
and doesn¹t seem to match the advertised behavior.

Is there a reason why PMTU support for UDP is somewhat inconsistent ?

Is there a reason ODF¹ bit cannot be set on fragmented packets on UDP
transmission ? I couldn¹t find anything in RFC for IP protocol that
prohibited DF bit on fragmented packets. Did I miss
something here ?

Would it be reasonable if PMTU discovery is performed (DF bit set +
appropriate icmp logic) even for locally fragmented packets ? I think this
will be a great help for UDP users that don¹t have PMTU handling logic in
the application (most udp applications belong to this category in my
experience). Thoughts ?

Thanks,

- Pradeep Vincent

Re: UDP Fragmentation and DF bit..

[Andi Kleen]

"Vincent, Pradeep" <pradeepv@amazon.com> writes:

> OMan 7 ip¹ declares that ³The  system-wide  default  is  controlled  by  the
> ip_no_pmtu_disc  sysctl  for SOCK_STREAM  sockets,  and  disabled  on all
> others.² which led me to think ODF¹ bit will not be set for UDP packets.
> But..

One should add ip.7 is not really a spec, just documentation
how things were quite a few years ago. It unfortunately
does often not get updated when things change.

>
> In a network environment where MTU-big and MTU-small co-exist (and have
> router¹s fragmentation turned off in favor of PMTU discovery), UDP packets
> that are > MTU-small and < MTU-big find the PMTU effectively but UDP
> packets


I don't understand your mtu-small/big concept. PMTU is per IP and per
flow. So there's only always a single PMTU, not small and big.

Or do you refer to a single IP NAT situation where a single IP
shares different MTUs?

> Is there a reason ODF¹ bit cannot be set on fragmented packets on UDP
> transmission ? I couldn¹t find anything in RFC for IP protocol that
> prohibited DF bit on fragmented packets. Did I miss
> something here ?

> Would it be reasonable if PMTU discovery is performed (DF bit set +
> appropriate icmp logic) even for locally fragmented packets ? I think
> this


DF=1 on fragments would mean the application has to do pmtu discovery
even with fragments for the case when the kernel does not know 
the path mtu yet. But if the app supports pmtu discovery it's better
to not use fragments in the first place.

-Andi

-- 
ak@linux.intel.com -- Speaking for myself only.

Re: UDP Fragmentation and DF bit..

[Vincent, Pradeep]

Thanks Andi.

> I don't understand your mtu-small/big concept. PMTU is per IP and per
> flow. So there's only always a single PMTU, not small and big.

Example Setup: One part of the network supports MTU-big and another part of
the network supports MTU-small. The NIC interfaces are configured with MTU
corresponding to the part of the network they are connected to.

When a host in MTU-big part of the network sends a packet to a host in
MTU-small part of the network, the router bordering these two sections of
the network sends ICMP messages to the host in MTU-big section of the
network to enable PMTU discovery.

Everything works great for TCP. UDP's PMTU discovery seems to be available
for some datagram sizes ( size < MTU-big) but not otherwise.

>DF=1 on fragments would mean the application has to do pmtu discovery
> even with fragments for the case when the kernel does not know
> the path mtu yet.

Is there a reason kernel can't learn the PMTU using ICMP messages generated
due to large size fragments with DF=1 ?


>But if the app supports pmtu discovery it's better
> to not use fragments in the first place.

Absolutely. 

Thanks,

- Pradeep Vincent

On 5/27/10 2:43 AM, "Andi Kleen" <andi@firstfloor.org> wrote:

> "Vincent, Pradeep" <pradeepv@amazon.com> writes:
> 
>> OMan 7 ip¹ declares that ³The  system-wide  default  is  controlled  by  the
>> ip_no_pmtu_disc  sysctl  for SOCK_STREAM  sockets,  and  disabled  on all
>> others.² which led me to think ODF¹ bit will not be set for UDP packets.
>> But..
> 
> One should add ip.7 is not really a spec, just documentation
> how things were quite a few years ago. It unfortunately
> does often not get updated when things change.
> 
>> 
>> In a network environment where MTU-big and MTU-small co-exist (and have
>> router¹s fragmentation turned off in favor of PMTU discovery), UDP packets
>> that are > MTU-small and < MTU-big find the PMTU effectively but UDP
>> packets
> 
> 
> I don't understand your mtu-small/big concept. PMTU is per IP and per
> flow. So there's only always a single PMTU, not small and big.
> 
> Or do you refer to a single IP NAT situation where a single IP
> shares different MTUs?
> 
>> Is there a reason ODF¹ bit cannot be set on fragmented packets on UDP
>> transmission ? I couldn¹t find anything in RFC for IP protocol that
>> prohibited DF bit on fragmented packets. Did I miss
>> something here ?
> 
>> Would it be reasonable if PMTU discovery is performed (DF bit set +
>> appropriate icmp logic) even for locally fragmented packets ? I think
>> this
> 
> 
> DF=1 on fragments would mean the application has to do pmtu discovery
> even with fragments for the case when the kernel does not know
> the path mtu yet. But if the app supports pmtu discovery it's better
> to not use fragments in the first place.
> 
> -Andi
> 
> --
> ak@linux.intel.com -- Speaking for myself only.
> --
> To unsubscribe from this list: send the line "unsubscribe netdev" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html
>