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

[GRIMAULT Jean-Luc RD-CORE-CAE]

Hello,

 

I have installed nepl-0.2-mcoa-beta2-20060630. Thank you very much to
the implementers. 

I have noticed a slight performance limitation which might be fixed in
new versions 

of nepl-0.2-mcoa, if technically feasible. 

 

I have used nepl-0.2-mcoa-beta2-20060630 in a classical configuration:

    [To see the diagram, please used a fixed sized font as courier new
10]

 

---------|            |-------|--wifi1--|Access Router1|-------|-----|

terminal |----wifi0---|  MR   |                                | HA  |

         |   ingress  |       |                                |
|----+

---------|            |-------|--wifi2--|Access Router2|-------|-----|
|

 
|

 
|

 
|-----------------|

                                                        | generator of
|

                                                        | udp numbered
|

                                                        | packets
|

                                                        | towards
terminal|

 
|-----------------|

  

MR is a laptop (HP compaq nc6000; Intel Pentium M; cpu 1.46 Ghz; RAM 500
Mo).

wifi1 has BID set to 100 with priority set to 10 and with an active CoA.

wifi2 has BID set to 200 with priority set to 20 and with an active CoA.

 

For the test, wifi2 (BID 200) is the sole interface used to send the udp
numbered packets 

from the generator towards the terminal, meaning that on the HA the
following command 

has been passed: "ip6tables -A PREROUTING -t mangle -p udp --source
<generator address> 

-j MARK --set-mark 200".

 

The problem consists in a small perturbation which is noticeable when,
for testing purpose, 

one changes the CoA of the non used tunnel (wifi1 in the above
configuration 

(by passing for example the command "iwconfig wifi1 essid <new
essid>")). 

In principle, the flow from the generator to the terminal should not be
disturbed by this CoA 

changing on wifi1, because the flow transits on wifi2 (BID 200). Yet, I
have observed that it 

is not completely true:

 

For the test, the udp flow sent by the generator was of the following
characteristics: 

Ethernet size 1430 bytes, frequency of 100 packets per second.

 

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. 

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 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).

 

By the way, with preference mechanism NEPL version, I had also noticed
this kind of perturbation. 

With the preference mechanism implementation it seemed to me that, as
soon as the MR has decided 

to engage into changing its active interface (preferred one to less
preferred one or vice versa), 

it were incapable to handle the packets received on the previous
interface until the BA is received 

on the new one. The point was that the perturbation began a little
before the BU was sent 

(at a moment may be when no more RA from the old AR were being detected
or when RAs from the new AR 

were being detected, I don't know exactly). At the 1430/100 couple, the
perturbation was about 

at the same level (4 to 17 lost packets).

 

Therefore, in both cases (
<http://software.nautilus6.org/packages/MCoA/nemo-0.2-mcoa-beta2-2006063
0.tar.bz2> nepl-0.2-mcoa-beta2-20060630 and preference mechanism
version), 

it seems that the handling of a new CoA by the MR disturbs a little the
routing on the MR 

during a brief duration.

 

I don't know if this problem has been already reported on the support
list.

Anyway, thank you in advance for any investigation which might be made
on this matter.

 

Regards.

Jean-Luc Grimault

 

-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://ml.nautilus6.org/pipermail/support/attachments/20061109/3fc91bbc/attachment.htm