From: "Venkata Jagana" <jagana@us.ibm.com>
To: "David S. Miller" <davem@redhat.com>
Cc: yoshfuji@wide.ad.jp, kkumar@beaverton.ibm.com,
kuznet@ms2.inr.ac.ru, ajtuomin@tml.hut.fi, lpetande@tml.hut.fi,
netdev@oss.sgi.com, linux-kernel@vger.kernel.org
Subject: Re: [PATCHSET] Mobile IPv6 for 2.5.45
Date: Fri, 1 Nov 2002 16:32:13 -0800 [thread overview]
Message-ID: <OF5B9EF40F.E3D52B05-ON88256C65.000191C7@boulder.ibm.com> (raw)
Hello Dave,
>Just like a router changes and monitors routes, a home agent daemon
>would change and monitor mipv6 state. So for the same reason we don't
>put OSPF routing databases into the kernel, we do not put the home
>agent registration into the kernel :-)
I absolutely understand your concerns about keeping the Home Agent
registration in the kernel. However, I still believe that keeping
this code in userspace would cause problems for handoffs. (btw, this
code will never get executed on a regular host - only routers configured
as Home Agents would be running this code as a module).
Currently, when a Home Agent receives a registration request during the
Mobile Node's handoff mechanism, it needs to respond in a reasonably
quick time period so that the sessions on the MN can continue without
experiencing delays. Longer delays could be harmful for applications
such as VoIP, for which the latencies are quite critical.
By moving this registration process to userspace, we have no control
over when the home registration would complete, since there are no
guarantees when the home agent daemon would run. BTW, according to
ongoing discussions at Mobile IP WG, it is believed that even few
hundred millisecs of latencies are not acceptable to critical apps,
during which time the IP packet transfer is completely stopped.
With such latency issues, I still believe that moving the registration
to userspace would create issues for the MN.
Thanks,
Venkat
----------------------------------------------------------------
Venkata R Jagana
IBM Linux Technology Centre, Beaverton
jagana@us.ibm.com
Tel: (503) 578 3430 T/L 775-3430
next reply other threads:[~2002-11-02 0:27 UTC|newest]
Thread overview: 13+ messages / expand[flat|nested] mbox.gz Atom feed top
2002-11-02 0:32 Venkata Jagana [this message]
-- strict thread matches above, loose matches on Subject: below --
2002-11-02 21:13 Krishna Kumar
2002-11-03 2:23 ` Werner Almesberger
2002-11-02 1:15 Krishna Kumar
2002-11-02 3:00 ` YOSHIFUJI Hideaki / 吉藤英明
2002-11-02 8:36 ` Pekka Savola
2002-11-02 8:23 ` Jeff Garzik
2002-11-02 1:03 Jean Tourrilhes
2002-11-01 6:51 Venkata Jagana
2002-11-01 10:37 ` David S. Miller
2002-11-01 2:19 Krishna Kumar
2002-11-01 2:17 ` David S. Miller
2002-11-01 2:36 ` YOSHIFUJI Hideaki / 吉藤英明
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=OF5B9EF40F.E3D52B05-ON88256C65.000191C7@boulder.ibm.com \
--to=jagana@us.ibm.com \
--cc=ajtuomin@tml.hut.fi \
--cc=davem@redhat.com \
--cc=kkumar@beaverton.ibm.com \
--cc=kuznet@ms2.inr.ac.ru \
--cc=linux-kernel@vger.kernel.org \
--cc=lpetande@tml.hut.fi \
--cc=netdev@oss.sgi.com \
--cc=yoshfuji@wide.ad.jp \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox
all inboxes | Powered by JetHome®