[lwip-devel] [patch #5834] Don't fragment flag

[David Empson]

Follow-up Comment #18, patch #5834 (project lwip):

In our initial port (based on 1.2.0) we noticed the DF flag was set, and
couldn't see any reason for it to be there (without path MTU discovery), so
we simply turned it off. We have reassembly enabled at present, and are only
talking to full TCP/IP implementations which support reassembly, so it won't
be a problem yet. We aren't particularly short of memory so I see no need for
us to disable reassembly.

In future we might want to talk to simpler devices that don't support
reassembly. These are likely to be on the local network so path MTU won't be
an issue.

We have no need for a complex scheme allowing the DF flag to be set on a
per-connection basis. I'm working from a theoretical basis, considering how
other people might use the stack.

We have made one other change I know of in this area: our LWIP implementation
is configured with separate MTU values for local traffic (same subnet) and
distant traffic. This allows us to configure a pessimistic value for going
over unreliable networks that use short MTUs (in the order of 576) to keep
the error rate down, while allowing best performance over the local network.
This feature should only be needed if the receiving host doesn't support
reassembly, and the network has a shorter path MTU than the LWIP end's LAN
(given that DF=0 in LWIP's transmissions).

I'll look into whether we can supply a patch for this so that others can use
it. (Lack of familiarity with the diff/patch mechanism is a temporary
stumbling block.) Our LWIP implementation has diverged a fair amount from the
reference release, mostly due to changes integrating it into our in-house OS
(with cooperative multitasking) and memory management.

Re Simon's comment #16:

> I think a reason to associate it with IP_REASSEMBLY is that if you can't
send to the other host without fragmentation, the other host won't succeed in
that, either.

This assumes that both hosts are configured with the same MTU. LWIP might be
sending large packets to a host which does support reassembly, through a
constrained network, and therefore should be sending them without DF set, but
might be receiving short packets (with or without DF set) that will make it
through the path MTU without being fragmented.

If LWIP has reassembly disabled, it is required that the other host know this
in advance, and be configured with a small enough MTU for the network (or
implement path MTU discovery) so it can get data through.

This has nothing to do with whether LWIP should be setting the DF flag when
transmitting data to that host.

If the other host supports reassembly, it is safe for LWIP to send packets
without DF.

If the other host doesn't support reassembly then LWIP must be configured
with a small enough MTU to be able to get through the network, since it
doesn't implement path MTU discovery. It doesn't matter whether it sets DF:
in either case, an packet larger than the path MTU will fail to get through.

If LWIP sends a packet which is too big and it has DF set, then a router
along the way will discard it and should send back an ICMP error.

If LWIP sends a packet which is too big and it doesn't have DF set, then a
router along the way will fragment it, and the receiving host will discard it
(because it doesn't reassemble fragments). This won't produce any feedback.

It is probably better to assume most hosts support reassembly, therefore it
is better to never set DF.

The main benefit I can see for setting DF is that sending a packet larger
than than the path MTU will generate ICMP errors from the router, which might
be useful to identify the problem even if LWIP ignores it. It will also
eliminate useless traffic over a constrained network (and distant portions of
the route).

Some documentation is probably in order. Since LWIP doesn't support path MTU
discovery, it is essential that if dealing with other hosts that don't
support reassembly, LWIP must be configured with a small enough MTU to make
it through the network to that host.

DF should not be tied to !IP_REASSEMBLY because transmission of DF has
nothing to do with LWIP's receive capabilities.

I think that the DF flag should be permanently disabled (except for special
applications like ping), until such time that LWIP gains support for path MTU
discovery.

It might be useful to provide an option for setting DF (to allow ICMP error
messages to give hints as to MTU configuration errors), but this could be
tested manually using pings with DF set.

    _______________________________________________________

Reply to this item at:

  <http://savannah.nongnu.org/patch/?5834>

_______________________________________________
  Message sent via/by Savannah
  http://savannah.nongnu.org/