[support] slight performance limitation on nepl-0.2-mcoa-beta2-20060630 ?

[Romain KUNTZ]

Hi Jean-Luc,

Thank you for your feedback on the implementation.
Here are some clues to explain the issues you met in your tests:

GRIMAULT Jean-Luc RD-CORE-CAE wrote:
> When the CoA is changing on wifi1, a first step occurs where a BU/BA 
> exchange takes place with lifetime in BU set to "0". The consequence
> is the deletion of the wifi1 tunnel.

This step occurs because the wifi link became unavailable. A L2 trigger
is catched by NEPL, that sends a deregistration-BU to the HA for the
CoA/BID that became unavailable.

> The second step (3 to 5 s later, depending of the time to set up the
> new address on wifi1) consists in a new BU/BA exchange with in the BU
> the new acquired CoA and a positive lifetime (lifetime as configured
> in nemod.conf).

This BU registers the new available CoA on the wifi1 interface.

As the MR uses multiple interfaces, each time one of the interface
becomes unavailable, a de-registration BU for this interface's CoA/BID
is sent through another available interface. This allows to redirect the
traffic (at the HA and the MR) via another available MR-HA tunnel, even
during an horizontal handover of one of the interface. This allows to
minimize the packet loss during vertical handovers.

> This is about at the same time (the time of the second BU/BA
> exchange) that the perturbation happens : 8 packets are lost for a
> size/frequency flow of 1430/100; these 8 packets are then not routed
> towards the terminal by the MR (via ingress wifi0).

This issue is due to some specific policies installed on the MR when a
BU is sent. When the MR sends a registration BU, NEPL installs some
specific policies to forbid output traffic as long as no BAck was
received (to avoid unsollicited traffic on the new link as long as the
CoA has not been binded to the HA).

I think you can optimize this behaviour using the "OptimisticHandoff
enabled;" option (check the manpage) that deactivates those policies
(thus assuming your MR will always manage to bind its CoA to the HA).
Please tell me if it solved your issue.

Those policies were initially designed for a singled-interface node, so
the current design is not perfect for a multiple-interfaced node (for
example it currently cannot block the traffic for a single interface,
but it blocks it for the whole node, that's why your traffic could not
be routed even through wifi2).

Another issue we noticed is that on the HA, ioctl calls to manage the
tunnels takes around 40ms, and during this time the HA cannot forward
any traffic (no interruption are possible).

We are still working on this MCoA implementation, I hope to release a
new version fixing bugs and updating to a newer kernel before the end of
this year. In the meantime, do not hesitate to report your issues on 
this list.

Thanks,
-- 
Romain KUNTZ
kuntz at sfc.wide.ad.jp