[Nfd-dev] NDNLP fragmentation design for UDP faces?

[Davide Pesavento]

On Wed, Feb 14, 2018 at 12:21 PM, Susmit <susmit at cs.colostate.edu> wrote:
> Hi,
>
> I am looking at the code and looks like for Ethernet the
> fragmentation/reassembly options are set here for multicast and
> unicast, respectively:
> https://github.com/named-data/NFD/blob/4d82692800314193b48d3dbb06cbecf168699a48/daemon/face/ethernet-factory.cpp#L247
> https://github.com/named-data/NFD/blob/4d82692800314193b48d3dbb06cbecf168699a48/daemon/face/ethernet-channel.cpp#L201

Yes.

> If I am reading this correctly, it should be relatively easy to add
> the same logic during UDP face creation. Is there anything else that
> needs to be configured?

Enabling fragmentation/reassembly on UDP faces is trivial, it's just a
matter of setting a couple of flags in GenericLinkService.

The problem is knowing the correct MTU. You can always play it safe
and set an MTU of ~64kB (max UDP datagram size), but at that point
NDNLP fragmentation will never be triggered since NDN packets can't
exceed 8800 bytes. Since there was no pressing use case for this,
nobody investigated the MTU problem further (at least to my
knowledge).

> I also looked at the MTU issue:
> https://redmine.named-data.net/issues/4005. I am not sure why PMTUD is
> disabled for UDP faces or how much work it would be to enable it, so
> pointers are appreciated.

PMTU discovery is disabled on Linux because it causes the networking
stack to set the DF flag on outgoing UDP datagrams (see issue #1651).
DF prevents IP routers from fragmenting the datagrams, instead they
will reply with an ICMP error. We didn't have a good mechanism to
respond to these ICMP errors at the time, in fact we wanted IP to do
the fragmentation/reassembly for us, therefore we decided to disable
PMTU discovery, thus also disabling the DF flag.

Why is this a problem for you though?

Davide