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

From: [email-masked]
Date: Mon, 17 Mar 2003 09:10:08 -0500

Hi Ajoy,

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

It was also made clear that this seamless first handoff only happens with
a probability that is smaller than 1, and that there might be situations in
which might not even happen. 

>
>2. The servers are easier to configure and manage. 

A server that does not exists is even easier to manage, namely not at all. Your statement
is really kind of funny. Instead of answering the fundamental question why we need the server,
you come over and over again with the argument that servers are easy to manage. This is fundamentally
wrong if we don't need the server. Hence, the concerns are not about manageability, there are about 
necessity. As long as we haven't clarified the latter, the former doesn't matter.

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

---

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

Hi Dirk,

please see comment in line.

marco

> necessity. As long as we haven't clarified the latter, the former doesn't matter.

Again, both approaches have pros and cons. Now, I agree that some issues
might be easier to solve when having no server function. But what's the
tradeoff with an alternative approach? DT just proposed the server
function for this interface (and is open to modify in particular this interface
when reasonable and when there is a consensus in the entire WG). But to
just decry the proposed mechanism and to address negative characteristics
is probably not the right way. We should also evaluate positive
characteristics of the proposed mechnism and tradeoff when going for
an alternative apporach. As I just indicated in a reply to Eunsoo, dynamic
learning is a good idea, but we have to evaluate how realistic dynamic learning is
to meet requirements on chache maintenance and scalability. I expect some
additional protocol complexity with a dynamic learning approach to
authenticate info filling ARs' caches. Now, this is not critical with regard
to timing issues, but might drop down scalability within the access network.

marco

---

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

Hi Dirk,

marco

marco