NFD

The purpose of a 0.4.0-beta1 release to give library and application developers a chance to adapt to the breaking change to be introduced by NDNLPv2 in 0.4.0 release.

What is the breaking change in 0.4.0?

Previously, network-layer packets (Interest and Data) are directly transmitted on NFD faces, except that
(1) local application face has the option to use LocalControlHeader to carry additional information;
(2) Ethernet face talks in NDNLPv1.

0.4.0 contains NDNLPv2 implementation, which changes all faces to talk in NDNLPv2.
NFD 0.4.0 can accept bare Interest/Data, but all outgoing packets are LpPacket.
This is incompatible with libraries designed for previous versions.

What should be included in this release?

• #2930 ndn-cxx send/receive LpPacket
• #3088 LpFace
• #3165 UnixStreamTransport in face refactoring
• #3168 UdpTransport in face refactoring
• part of #3104 GenericLinkService, at least: encoding/decoding of LocalControlHeader-equivalent fields
• #3177 counters in LpFace
• #3156 NACK in forwarding and best-route strategy

What should not be included in this release?

• #3166 TcpTransport

How should we deploy this release?

0.4.0-beta1 requires a flag day for testbed routers: deploy on all testbed routers at the same time.

After deployment on testbed, end hosts connecting to the testbed via UDP would stop working because they cannot understand incoming NDNLPv2 packets.
They can connect to the testbed via TCP, which is still talking in old format.

When an end host is upgraded, ndn-cxx applications are not affected because #2930 changes ndn-cxx to talk in LpPacket.
Applications using other libraries would stop working because they cannot understand incoming NDNLPv2 packets.
They can connect to NFD via TCP on the loopback IP, which is still talking in old format.

How to upgrade old end hosts?

An end host upgrading to 0.4.0-beta1 should connect to the testbed via UDP.
Applications with upgraded libraries should connect to NFD via UNIX socket.

Upon 0.4.0 release, upgraded end hosts and applications won't be affected because packet format on UDP and UNIX socket is unchanged.
End hosts and applications that have not been upgraded (and are connected via TCP) will stop working.

20150910 conference call agrees that 0.4.0-beta1 release is necessary and beneficial, but it does not need to be a change that breaks all existing end hosts and libraries.

1. LpPacket should be encoded as bare Interest/Data, if no header field is present.
   With that, an NDNLPv2 sender would send bare Interest/Data except when fragmentation or LocalControlHeader-equivalent fields are used, and bare Interest/Data can be understood by a non-NDNLPv2 receiver.
   This limits the change to break only those links with fragmentation, and those applications that uses LocalControlHeader.
2. The only link that uses fragmentation is Ethernet multicast.
   When we leave EthernetFace unchanged, it's unaffected.
3. ndn-cxx and jNDN are the only two supported libraries that support LocalControlHeader.
   ndn-cxx will be upgraded in #2930 together with NFD, so there's little impact.
   jNDN connects to NFD via TCP, so when we leave TcpFace TcpLocalFace unchanged, it's unaffected.
4. All supported libraries will ignore a packet with unknown top-level TLV-TYPE, so if an LpPacket such as a NACK is returned to those libraries, they will just drop the LpPacket without causing an error.

The new plan is:

• #2930 #3088 #3165 #3168 #3104 #3156 should be included in the release
• #3169 may be included in the release
• #3166 #3170 #3171 must not be included in the release

Unfortunately the release still breaks one scenario: when UNIX sockets are disabled, NFD-RIB attmepts to talk to NFD over TCP. ndn::TcpTransport on RIB side is talking NDNLPv2, but nfd::TcpLocalFace on NFD side is talking LocalControlHeader. This eventually leads to "prefix registration timeout" error on RIB thread and terminates nfd process.

A high-priority Bug #3236 is being fixed.
I suggest delaying binary release to incorporate the fix.

At that time, a new git tag should be created for "beta2" and then binary packages can be created based on that.