[hipl-users] Re: long delay in mobility handling procedure

  • From: Szabolcs Nováczki <novaczkisz@xxxxxxxxx>
  • To: hipl-users@xxxxxxxxxxxxx
  • Date: Sun, 8 Mar 2009 16:40:44 +0100

Ok. I'll keep you updated.

2009/3/8 Tobias Heer <heer@xxxxxxxxxxxxxxxxx>

> Hi!
>
> Good to hear you solved your problem. Do you also get the weird error in
> the trace with the second machine? If you find out what the error was, could
> you please post a short description to the list? At least I would be very
> interested in understanding the root of the problem.
>
> Thanks!
>
> Tobias
>
>
>
> Am 07.03.2009 um 13:32 schrieb Szabolcs Nováczki:
>
>  Hi!
>>
>> Yesterday we could find a workaround for the problem. We simply used
>> another machine for mobile node which had different wifi card. We could
>> speed up handover but its still not clear what was the problem with the
>> other one.
>> Thanks for the help!
>>
>>
>> Br,
>> Szabi
>>
>> 2009/3/6 Tobias Heer <heer@xxxxxxxxxxxxxxxxx<mailto:
>> heer@xxxxxxxxxxxxxxxxx>>
>>
>> Hi.
>>
>> Am 06.03.2009 um 16:12 schrieb Szabolcs Nováczki:
>>
>>
>>
>> Not yet but sounds like a good idea, but how can you measure this.
>>
>> I once wrote a little test application that did nothing more than sending
>> floods of UDP packets to a destination. We recorded the incoming UDP packets
>> at the destination with tcpdump and analyzed the resulting race with
>> wireshark later. The disruption shows in a number of missing packets (gap)
>> in the trace. We also tried iperf for generating the flood of packets but it
>> had problems when switching IP addresses and stopped sending when the
>> handoff occured. I don't know if there is a smarter way to do it (there
>> probably is) but we got quite convincing results with this method.
>>
>> I can send you the flooder program if you whish.
>>
>>
>> Could you have a look at the trace?
>>
>> Could you send me the trace once again (on private - maybe as zip or tar).
>> Somehow I did not get the attachment.
>>
>>
>> The 2.13GHz Pentium with 2G RAM laptop we use as mobile should be fast
>> enough, I guess.
>>
>>
>> Sure. Crypto should only be a minor factor then.
>>
>> BR, Tobias
>>
>>
>>
>>
>>
>>
>> I hope this provides some insights into the problem.
>>
>> BR,
>>
>> Tobias
>>
>>
>>
>> Am 06.03.2009 um 14:03 schrieb Szabolcs Nováczki:
>>
>> Hi!
>>
>> Yes, I did not get your message on the list. Wonder why...
>>
>> Anyway. Here is the answer:
>>
>> See my answers inline!
>>
>> #################
>> Hi,
>>
>> I will try do give some assistance but I need a bit more information about
>> the problem.
>> a) Could you provide some numbers in ms or s? What means significant? I
>> was
>> not able to read your attachment and it probably lacks timing information
>> anyway.
>> Sorry i forgot to give this info :). The delay is about 2 secs. I attached
>> the file again but you have right: there is no timing.
>>
>> b) Could you also give some detail about the machines you are working with
>> (CPU speed) ...
>> Ill send this later cause i am not sure of the detailes.
>>
>> c) ... and the test setup you are using (directly connected vs. sited at
>> different sites).
>> All is IPv6. There are three different  /64 networks. One for the cn and
>> two
>> for the mobile. The cn is attached on wire. The mobile is attched to one
>> of
>> the latter two sites through  wireless acces points and uses IPv6
>> stateless
>> autoconfiguration when receiving router advertisements to configure its IP
>> address. We use a script which periodically changes (iwconfig new_ap) from
>> one ap to the other and back. The mobile reconfigures its ip address which
>> triggers the hip update mechanism.
>>
>> d) Do you move between different (wireless?) networks?
>> see answer for c.)
>>
>> e) Are you using the same IP address in these different networks?
>> We use different addresses:
>> 2001:0738:2001:2084:0213:ceff:fe7b:fd28
>> 2001:0738:2001:2088:0213:ceff:fe7b:fd28
>>
>> BR,
>>
>> Tobias
>>
>> ##############
>>
>> Br,
>> Szabi
>>
>> 2009/3/6 Tobias Heer <tobias.heer@xxxxxx<mailto:tobias.heer@xxxxxx>>
>>
>> Just in case you missed the message on the list...
>>
>>
>> Anfang der weitergeleiteten E-Mail:
>>
>> Von: Tobias Heer <heer@xxxxxxxxxxxxxxxxx<mailto:heer@xxxxxxxxxxxxxxxxx>>
>>
>> Datum: 6. März 2009 09:59:05 MEZ
>> An: "hipl-users@xxxxxxxxxxxxx<mailto:hipl-users@xxxxxxxxxxxxx>" <
>> hipl-users@xxxxxxxxxxxxx<mailto:hipl-users@xxxxxxxxxxxxx>>
>> Kopie: Goodzi <goodzi@xxxxxx<mailto:goodzi@xxxxxx>>
>>
>> Betreff: Re: [hipl-users] long delay in mobility handling procedure
>>
>> Hi,
>>
>> I will try do give some assistance but I need a bit more information
>> about
>> the problem.
>> a) Could you provide some numbers in ms or s? What means significant? I
>> was not able to read your attachment and it probably lacks timing
>> information anyway.
>>
>> b) Could you also give some detail about the machines you are working
>> with
>> (CPU speed) ...
>>
>> c) ... and the test setup you are using (directly connected vs. sited at
>> different sites).
>>
>> d) Do you move between different (wireless?) networks?
>>
>> e) Are you using the same IP address in these different networks?
>>
>> BR,
>>
>> Tobias
>>
>> Am 06.03.2009 um 09:11 schrieb Szabolcs Nováczki:
>>
>> Hi hipl users!
>>
>>
>> We are doing some tests with infraHIP recently. With basic mobility
>> tests
>> we run into the following behaviour:
>>
>> There is a significant delay in infraHIP (on the mobile side) before
>> sending out the first update package.
>>
>> I attached a commented trace of the hipd output (hipd_trace_medium)
>> where
>> I highlighted the suspected part.
>>
>> My request is that if some of you has time to analyze this or someone
>> knows the reason for this behaviour please share with us! What happenes
>> there? Is this delay ok? We are also interested of  mechanisms
>> triggering
>> the update procedure in hipd, and how this trigger is processed.
>>
>> Thx!
>>
>> Br,
>> Szabolcs Novaczki
>>
>> Ps.: hipd is running on 2.6.27-11 generic kernel installed from ubuntu
>> interpid package
>>
>>
>>
>>
>>
>> --
>> Dipl.-Inform. Tobias Heer, Ph.D. Student
>> Distributed Systems Group
>> RWTH Aachen University, Germany
>> tel: +49 241 80 207 76
>> web: http://ds.cs.rwth-aachen.de/members/heer
>>
>>
>>
>>
>>
>>
>>
>>
>>
>> <hipd_trace_medium.txt>
>>
>>
>>
>>
>>
>> --
>> Dipl.-Inform. Tobias Heer, Ph.D. Student
>> Distributed Systems Group
>> RWTH Aachen University, Germany
>> tel: +49 241 80 207 76
>> web: http://ds.cs.rwth-aachen.de/members/heer
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>> --
>> Dipl.-Inform. Tobias Heer, Ph.D. Student
>> Distributed Systems Group
>> RWTH Aachen University, Germany
>> tel: +49 241 80 207 76
>> web: http://ds.cs.rwth-aachen.de/members/heer
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>
>
>
> --
> Dipl.-Inform. Tobias Heer, Ph.D. Student
> Distributed Systems Group
> RWTH Aachen University, Germany
> tel: +49 241 80 207 76
> web: http://ds.cs.rwth-aachen.de/members/heer
>
>
>
>
>
>
>
>
>

Other related posts: