Subject: RE: [Seamoby] Comments on DT CARD draft

From: [email-masked]
Date: Wed, 5 Mar 2003 18:58:46 -0500

Jim,

> Essentially what saying is that you are adding a new functionality on some
other
> existing element in the network.
> There is an inherent assumption that this can be added to such servers. For
example, this may
> not be possible in AAA servers given the present charter of AAA WG. The DT
members also
> seem to accept this may be the case.
>

It could be an LDAP server.

[Govind] Are you sure LDAP servers exist everywhere? Plus, you might have similar issues
as with AAA WG.

> The main point I was trying to make is
>  having an extra server (or functionality) whereever it may  reside is not
worth it at all.

Depends. There are other things in this draft (TAR calculation, for example)
that one could argue shouldn't be there.

[Govind] AFAIK, the DT draft does not talk about TAR selection. But I might have missed it.
It just mentions that the CARD output is fed to TARS. But I agree with you in the sense
that what is not essentially relevant to CARD shouldn't be there.
_______________________________________________
Seamoby mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/seamoby

---

From: "Eunsoo Shim" <[email-masked]>
Date: Thu, 6 Mar 2003 12:05:02 -0800

Regarding the CARD server, I have a few comments.

1) First of all, the dycard draft shows that CARD works without any central
server. That is, we don't need the server for CARD.

2) The DT draft also mentions that the server + beacon approach has a
security hole that allows so easy contamination of the table at the AR. In
comparison to this, the dycard draft proposes an approach that can be
designed to make such contamination very difficult. It is the discovery
approach where the mobile host delivers the IP address of the previous AR to
the current AR.

3) Certainly the CARD server, which is a central server, causes concern
about single point of failure and scalability.

So I don't quite understand why the CARD server approach was taken while it
has such disadvantages compared to an alternative approach.
Regards,

Eunsoo

---

From: "Eunsoo Shim" <[email-masked]>
Date: Thu, 6 Mar 2003 12:05:02 -0800

Eunsoo

---

From: Daichi Funato <[email-masked]>
Date: Thu, 06 Mar 2003 15:45:28 -0800

Hi Eunsoo,

> server. That is, we don't need the server for CARD.

In dycard, ARs need to be stateful for every MN just for CARD.
Most of the MN states in ARs would be useless since we just need one
MN report to build one CAR entry. Only a few MN may discover new CARs. 

After CAR cache comes to an stable condition, the MN state maintenance
is in vain. Unfortunately, an AR never knows whether it is in the stable
condition or not. So, the AR needs to continue to maintain every MN's state.
I think this is waste of the resources and not worth doing such a 
useless MN state maintenance in every AR.

If we take the server approach, we can keep ARs stateless.
This is much simpler than the dycard approach. (ARs may have some
states to avoid cache contamination, as James proposed before.
But, it is not like the dycard MN states, which are not to be used 
in most cases.)

So, I believe the server approach keeps the system simple and avoids
wasting the AR's resources for the useless MN state maintenance.

Regards,
Daichi

---

From: Daichi Funato <[email-masked]>
Date: Thu, 06 Mar 2003 15:45:28 -0800

Hi Eunsoo,

Regards,
Daichi

---

From: Robert Chalmers <[email-masked]>
Date: Thu, 06 Mar 2003 17:06:31 -0800

Daichi,

> wasting the AR's resources for the useless MN state maintenance.
I may be misinterpretting what your saying here, so please let me know
if that is the case. However, MN state is not necessary for dyCARD to
work. The protocol does introduce a stateful mode where the AR can
maintain reachability state for the mobile node, but this is just an
optional mode. Admittedly, the initial draft was written with the
stateful mode in mind. We've updated the draft to make this distinction
cleaer.

Anyway, the state maintained by the AR for the MN (in stateful mode
only) has nothing to do with the learning process between ARs. It's
purpose is to streamline the AR-MN resolution process. And again, it's
optional.

ttyl,
bob

-- 
/****************************************************************

   Robert Chalmers
   UCSB Computer Science Doctoral Candidate
   Network and Multimedia Systems Lab (NMSL)

   "My heart is in the code, but my soul lies in the process"

   | [email-masked] || http://www.cs.ucsb.edu/~robertc/ |

*****************************************************************/

---

From: Robert Chalmers <[email-masked]>
Date: Thu, 06 Mar 2003 17:06:31 -0800

Daichi,

ttyl,
bob

   Robert Chalmers

---

From: "Eunsoo Shim" <[email-masked]>
Date: Fri, 7 Mar 2003 06:52:18 -0800

Hi, Daichi,

My comments are after yours.

----- Original Message -----
From: "Daichi Funato" <[email-masked]>
To: <[email-masked]>
Sent: Thursday, March 06, 2003 3:45 PM
Subject: Re: [Seamoby] Comments on DT CARD draft

> wasting the AR's resources for the useless MN state maintenance.

Dycard does NOT require MN state maintenance at AR at all just for
discovery. For AAA, I am sure each AR may have to maintain state of MN. But
it is independent of Dycard.
Could you explain why Dycard needs MN state maintenance at AR?
Regards,

Eunsoo

---

From: "Eunsoo Shim" <[email-masked]>
Date: Fri, 7 Mar 2003 06:52:18 -0800

Hi, Daichi,

----- Original Message -----
From: "Daichi Funato" <[email-masked]>
To: <[email-masked]>
Sent: Thursday, March 06, 2003 3:45 PM
Subject: Re: [Seamoby] Comments on DT CARD draft

Eunsoo