Subject: RE: [SeaMoby] Topic #3: Cache contamination

From: Singh Ajoy-ASINGH1 <[email-masked]>
Date: Sun, 16 Mar 2003 14:58:57 -0600

-----Original Message-----
From: Eunsoo Shim [mailto:[email-masked]]
Sent: Sunday, March 16, 2003 5:26 PM
To: Singh Ajoy-ASINGH1
Cc: [email-masked]
Subject: Re: [SeaMoby] Topic #3: Cache contamination

> I am also very interested to hear from other members of WG about the DT
> proposal who are not members of the DT and are not affiliated to them.
> There were many issues raised about the DT proposal such as cache
> contamination and even the fundamental need of the central server.
> I have not heard convincing explanations from the DT members as well as
any
> supporting opinion from non-DT members yet.
> I'd appreciate if anyone provides one.
>
> AJOY-> I have indicated in my earlier email that we need
> discuss your so called cache contamination comments
> either offline to during IETF presentation. BTW,
> here a few reasons for having server (e.g., AAA)
> based CARD functions:
>
> 1. Server based approach is able to provide seamless
> handoff even if the CAR information is not available in
> the current AR cache. This has been made clear
> in previous discussion.
>
[eunsoo] This is about initial population of the cache. We had lots of
discussion about this. There were arguements about whether we need initial
population of the cache. However it was clear that any existing management
tool can be used for the initial population from the discussion. It tells us
that we don't need to invenet the wheel for initial router configuration.

AJOY-> Initial population of cache does not address the problems due to 
cache timeout as well as cases when a new AP is added or removed from 
the coverage area of an AR. Also, server less approach of initial cache 
population is very difficult and challenging task for the service providers.

That is why we are defining CARD protocol in first place. If service
provider would like to manually configure L2->L3 mapping at each and 
every ARs then there is no good reason for the existence of the CARD
protocol. 

> 2. The servers are easier to configure and manage.
>
[eunsoo] It is arguable. If you have to figure out proper scope-ids for
every AR whenever there is a change in the network, it is not a really dummy
job.
Also we have to pay attention to the price of having a central server. In
general it is easier to manage one entity than many entities but you have to
pay the price of reliability (single point of failure) and scalability. 

I don't think the price is smaller than the benefit of easiness.

AJOY-> BTW, there is no additional price if the CARD is integrated 
with AAA function. On the contrary, I think probably managing 1000s of 
AR would be more expensive and error prone than managing a few 
servers. 

> 3. Server can be used for inter-AR authorization.
>
>
[eunsoo] Again, if we need a AAA server, we use it. We don't have to
introduce a new type of server functionality.

AJOY-> If we need to use AAA server then 
why not enhance that to support CARD functionality as well. I do 
see any justification for deploying a complicated protocol such 
as dycard when we can achieve the same function my making some 
enhancements to AAA function.  

An important point is that there is alternative requiring no central server.
Why should we bother ourselves with the server? 

AJOY-> This is because AAA servers are anyway required in an access
network and can also be useful tool for providing inter-AR 
authorization. So, I do not see any convincing reason for deploying a 
complicated protocol like dycard. 

We need compelling reasons
such as something that should/can be provided only by the central server and
that is not feasible in a solution without the server. 
Certainly it should
not be the case where there is already the wheel or the price is much larger
than the benefit.

AJOY-> I guess my previous reply would have answered your question. 

Eunsoo
_______________________________________________
Seamoby mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/seamoby

---

From: "Eunsoo Shim" <[email-masked]>
Date: Sun, 16 Mar 2003 16:41:13 -0800

> population is very difficult and challenging task for the service
providers.
[eunsoo] Initial population in Dycard is just done by one handoff between
each pair of CARs. What is so difficult and challenging? Can you please
explain your claims?

It was pointed out that the cache (CAR table) would be refreshed by repeated
handoffs and thus we would see rarely timeout of the cache entries unless
there was no handoff between two CARs for a long time. Of couse, when a new
AP/AR is added, we need a learning period in Dycard like the dynamic IP
routing protocol. Because of tradeoffs between static and central system and
dynamic and distributed system, people have adopted dynamic and distributed
IP routing protocols in most cases. Also please notice that you need to
reconfigure the server whenever there is a change in AP/AR, like even simple
IP address change.
I don't think the learning period justifies any static and central system.

> every ARs then there is no good reason for the existence of the CARD
[eunsoo] You are confused. In Dycard, the admin does NOT have to configure
L2-L3 mapping entries at each AR. It is discovered dynamically. Actually the
server approach require that it is manually entered in the server.

> AR would be more expensive and error prone than managing a few
[eunsoo] The fact there is an AAA server does not mean we should use it. Or
it does not mean we have to share (actually double) the price of reliability
and scalability with the AAA server.
Now the discussion is getting into somewhat philosophical stage: Dynamic and
distributed system versus static and central system....
Also it sounds to me like this. We have a printer server. So let's build a
central file system. Also let's build a central routing system. All the
reliability and scalability cost was already paid by the printer server...
This is not a right approach. The central AAA server does not mean we can
make CARD also kind of a central system without any additional price. Now
you are putting the reliability and scalability cost on the CARD protocol as
well as the AAA protocol.

> enhancements to AAA function.
[eunsoo] Please see my above comments.

> complicated protocol like dycard.
[eunsoo] Can you please substantiate your claim that Dycard is a complicated
protocol?

> AJOY-> I guess my previous reply would have answered your question.
[eunsoo] Not really. The main argument was that there was a AAA server and
thus let's use it as the central CARD server. You did not say what could be
done by having the server which was not possible without the server.
Regarding the initial cache population, it was also mentioned many times
that we could use any existing management tool if we need it.

Eunsoo

---

From: "Eunsoo Shim" <[email-masked]>
Date: Sun, 16 Mar 2003 16:41:13 -0800

Eunsoo

---

From: Liebsch <[email-masked]>
Date: Tue, 18 Mar 2003 20:22:33 +0100

Hi Eunsoo,
please find some comments below,

marco

> each pair of CARs. What is so difficult and challenging? Can you please

[marco] I think the idea is good, but I have some doubts on how realistic and
reliable such a dynamic learning approch is. Please correct me if I'm
wrong. Now, first of all, AR caches are updated by MNs after a
handover. This is done after each handover, independent of cache entries
require an update or not. Each update makes use of high cost radio bandwidth.
Furthermore, additional protocol handshakes are most probably required
to allow newARs to check whether or not a MN has been really attached
to the oldAR (kind of authenticity check). Last but not least, conveying
cache info via a MN's handover requires this MN to be active
(otherwise no real handover will be performed, the MN only attaches
to the new AP/AR). Most of terminals are idle, so, most probably,
future systems will support dormant mode for MNs. Now, looks
very cost intensive to wake up MNs only to maintain caches in new ARs.

> server approach require that it is manually entered in the server.

[marco] Sure, dycard is dynamic learning.
But we have to evaluate both approaches, both have pros and cons.
Just to clarify on your statement, server function does not require
administrative configuration. ARs have certs and possibly the
scope-ID configured.
From then process is automatically performed, which is ARs register with
the server function. This entry is also to be updated from time to time to
avoid unrecognized death of a particular AR. This lifetime is much larger as
ARs' cache entries time out. So, only administrative configuration to be done
on ARs is when they are integrated with a system and this is the
password/certs for initial weak authentication from the system and
possibly kind of scope-ID, if we go for such an approach.

---

From: Liebsch <[email-masked]>
Date: Tue, 18 Mar 2003 20:22:33 +0100

Hi Eunsoo,

marco