Subject: [SeaMoby] Topic #2:Do we need a server for CARD

From: "Eunsoo Shim" <[email-masked]>
Date: Tue, 11 Mar 2003 14:47:42 -0800

Hi,

Currently a series of discussion about DoS attack is going on about CARD.
Also we had lots of discussion about possible problems about the server
approach.

But I'd like to raise a more fundamental question about the server approach
taken in the DT draft.
Dycard shows that CARD is possible without introducing any server which
causes concerns about reliability and scalability.
Then why do we need the server at all? Or why do we have to introduce the
server for CARD?
I look forward to hearing the necessity of introducing the server before how
the server approach can or cannot defend certain threats or resolve certain
issues.
Regards,

Eunsoo

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

---

From: [email-masked]
Date: Tue, 11 Mar 2003 18:39:16 -0500

Hi James,
> 
> Why are these approaches mutually exclusive?

[Govind] As I pointed out in my first email, I don't think they are mutually exclusive.
One approach works with just a cache, second with a cache and server. 
> 
> One of the drawbacks of Dycard is that it needs a learning 
> period.

[Govind] dycard, as is in the 01 draft now, needs one handover between ARs.
 I would rather put it that way than open ended as "learning period". In a real life scenario,
 this handover will happen quite soon. In the future, if there are pico-cellular environments
I would guess it may be more frequent. Note, until a handover happens you don't need 
to know about the other AR. Once a handover happens you will know about the other AR in dycard.
The correct choice of lifetimes of cache entries should be able to take care of the rest. 

>Naturally,
> the ISP can hire somebody to walk around and seed the cache, 
> but that's
> expensive. 
[Govind] I don't think the ISP really needs to do it. I don't think the loss of
ability to provide one seamless handover between ARs is a big deal in the 
long run. Plus, as the DT draft points out, it does not guarantee that the 
request made to a server will get back in time for the MN anyways.
Even in the DT scheme, any non cache answered case is not guaranteed.
dycard has  a way to make the first handover seamless in a probabilistic
sense also, but in all honestly I don't think that one handover is that big of a deal,
compared to putting up a server. 

>A server could prime the cache in the router with 
> a collection of
> AP/AR mappings that may not be geographically adjacent, but 
> over time the ones
> that aren't would drop out. 
[Govind] Well this causes an increase in traffic between ARs that are
not GAARs (using a defunct term) which I think is more problematic
than loosing one handover. I'm not saying that in dycard you cannot have
incorrect entries in the cache. This is an issue that both the protocols
need to address in detail.  But dycard handles this quite similarly. The other 
issue is how easy it is to get these entries into the AR's cache in either scheme. 
This is something that probably needs some more thought. 

>Thus, the ISP would not have to 
> go through the
> timeconsuming task of classifying whether they APs are 
> geographically adjacent.

[Govind] I don't know what you are implying by this statement. But
if you are stating that ISPs need to do this in dycard, then it is incorrect. 
If you are talking about the scope-id approach which would need some
classification, I agree. 

> 
> After the server has been used to initially populate the 
> cache, any changes
> would be propagated directly by CARD.

[Govind] I don't think we need a server initially to propagate the cache. I think handovers
between ARs, that will happen anyways, can be used to maintain the cache. We have
done some study in this scenario and in the steady state the chances of a cache miss is
quite low, even with incorporating some of the security schemes to prevent contamination
of cache.  

-Govind.

---

From: Singh Ajoy-ASINGH1 <[email-masked]>
Date: Tue, 11 Mar 2003 17:59:02 -0600

Govind,
Please find my inline reply.
Regards,
Ajoy 

-----Original Message-----
From: [email-masked] [mailto:[email-masked]]
Sent: Tuesday, March 11, 2003 5:39 PM
To: [email-masked]; [email-masked]; [email-masked]
Subject: RE: [SeaMoby] Topic #2:Do we need a server for CARD
Hi James,

long run.

AJOY-> The cache is not permanent so whenever there is 
loss of cached information, dycard will not be able to support 
fast handoff. 

 Plus, as the DT draft points out, it does not guarantee that the 

AJOY->This is not correct and should be removed from design team draft. Whenever 
there is sufficient overlap between coverage area of adjacent ARs,  server based 
approach should not have any problem. 

-Govind.

---

From: Singh Ajoy-ASINGH1 <[email-masked]>
Date: Tue, 11 Mar 2003 17:59:02 -0600

Govind,

-----Original Message-----
From: [email-masked] [mailto:[email-masked]]
Sent: Tuesday, March 11, 2003 5:39 PM
To: [email-masked]; [email-masked]; [email-masked]
Subject: RE: [SeaMoby] Topic #2:Do we need a server for CARD
Hi James,

-Govind.

---

From: [email-masked]
Date: Wed, 12 Mar 2003 08:37:14 -0500

> loss of cached information, dycard will not be able to support 
[Govind] I agree that cache entries have a lifetime. I think handovers are enough to update these
entries. Handovers will happen in real life.

> approach should not have any problem. 

[Govind] Writing up a spec that is constrained on the assumptions on
the  physical layer scenario is not the correct approach IMO. 
But, lets leave this at that. I think you say it can be guaranteed most of the
time, while I don't think so.
_______________________________________________
Seamoby mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/seamoby

---

From: [email-masked]
Date: Wed, 12 Mar 2003 08:37:14 -0500

---

From: [email-masked]
Date: Wed, 12 Mar 2003 09:54:10 -0500

Hi James,

you are not seriously suggesting a "can you hear me now" guy as being required for Dycard, are you?

As pointed out often enough, it is the very first handoff that is used to populate the cache, that's it. The
drawback of that has also clearly pointed out, namely having the first handoff a hard one. Nobody ever
denied that, on the contrary we explicitly asked the question whether or not the removal of this "drawback" 
is worth establishing a server. Coming now with "expensive walk around hiring" scenarios that are "time consuming"
for ISPs (you exactly have to wait at each AR until ONE handoff happened) seems to me rather a nice anecdote than
a technical argument.

Thanks,

Dirk

>From: ext James Kempf [mailto:[email-masked]]
>To: Eunsoo Shim; [email-masked]
>Subject: Re: [SeaMoby] Topic #2:Do we need a server for CARD
>
>
>period. Naturally,
>the ISP can hire somebody to walk around and seed the cache, but that's
>expensive. A server could prime the cache in the router with a 
>collection of
>that aren't would drop out. Thus, the ISP would not have to go 
>through the
>            jak
>----- Original Message -----
>From: "Eunsoo Shim" <[email-masked]>
>To: <[email-masked]>
>Sent: Tuesday, March 11, 2003 2:47 PM
>Subject: [SeaMoby] Topic #2:Do we need a server for CARD
>
>
>> Hi,
>>

---

From: [email-masked]
Date: Wed, 12 Mar 2003 09:54:10 -0500

Hi James,

Thanks,

Dirk

---

From: [email-masked]
Date: Wed, 12 Mar 2003 10:02:07 -0500

Hi Ajoy,
>approach should not have any problem. 

Unfortunately, it is still rather subjective what "sufficient" overlap means
in order to "not have any problems". It highly depends on your notion of
"sufficient overlap", the mobility pattern of the mobile involved and the topology
of your system, i.e., the experienced delay for L2-L3 requests. We need simulations and
best current practices demonstrating how to set up the system properly for certain environments.
These evaluations could also reveal how to prevent situations (if they are preventable) in which
the probability of a seamless first handoff is actually damn close to zero (i.e., identifying pathological 
situations).

It all boils down to the fact that it is unclear right now how the claimed P(failure of timely delivery of answer)=1 with "proper configuration"
is actually achieved in the server approach. Until then, P(.) less than one is a valid assumption until proven otherwise, and the question 
remains whether or not it is worth going through the whole server thing for this. 

Thanks,

Dirk

---

From: [email-masked]
Date: Wed, 12 Mar 2003 10:02:07 -0500

Hi Ajoy,

Thanks,

Dirk

---

From: [email-masked]
Date: Wed, 12 Mar 2003 10:11:24 -0500

Hi Marco,

>I don't think that the server function approach has a large impact on
>handover timing issues,
>since I do not expect that a mobile tries to learn about CARs when
>already losing connection
>to its current AR. Worst case is that a current AR has no entry for a
>particular requested
>CAR in its cache. This means that the current AR retrieves address info
>of this CAR
>from the server function, possibly together with static capabilities.
>For further requests,
>the current AR just contacts the CAR directly to request dynamic
>capabilities directly
>withour contacting the server anymore until the cache etry is about to
>expire.
>Now, we could evaluate and compare probability of CARD
>failure due to a small delay (server function access) and an 
>immediately
>breaking connection,
>and a failure due to a missing entry in the current AR's cache in
>dycard. I don't expect results
>that degrade the server function based approach.

As I answered to Ajoy comment in this respect, these expectations of non-impact
are too much dependent on the actual system setup, physical topology in place, and
mobility pattern. Hence, I think that raising these expectations are mainly speculations
until shown otherwise.  But I think we all can agree that the probability of failure 
if somewhere below 1, and the question remains "is it worth doing it for this very first
population handoff to be, maybe, seamless"??

>Now, a stronger argument for the server function here is to not rely on
>mobiles to fill ARs' caches,
>always making use of radio bandwidth to update caches. 

We are talking about a triple (see Dycard draft) of information to be sent after
each handoff! This will certainly not decrease the overall performance of radio system,
won't it?

> If 
>cache updating
>in dycard should
>achieve same efficiency as the server based approach, static
>capabilities are to be transmitted
>over the air as well, isn't it? Not sure if this is really a 
>good solution.

I'm not sure I understand what you mean? Do you suggest that Dycard is
transmitting the capabilities of ARs (?) over the air or it should in order to be
"efficient"? Dycard DOES NOT transmit the capabilities of any ARs over the
air, and I don't see why it should in order to be more efficient (not even talking about
how the MN knows ALL AR capabilities to be sent to the new AR). The new AR will contact the
old AR to obtain the capabilities.

Thanks,

Dirk

---

From: [email-masked]
Date: Wed, 12 Mar 2003 10:11:24 -0500

Hi Marco,

Thanks,

Dirk

---

From: [email-masked]
Date: Wed, 12 Mar 2003 10:53:43 -0500

Hi Marco,

> Not sure about this. If we think about functional entities 
> for CARD, the
> server function is one, but
> for dycard, in addition the actual CAR discovery, a further functional
> entity is on the mobile terminal
> performing similar functions as the server function in the DT draft,
> isn't it?
[Govind] I don't know what functional identity you are talking about here.
The MN sends the APids that it hears. As an optimization it then sends a message 
if it stops hearing a particular APid. This is to reduce the information that is 
sent down at the time of CAR selection. The MN sends a RI message on handover
to a new AR. Thats it. 

 This is to keep caches
> updated in ARs, same as the server function does. The only 
> difference is
> that the additional dycard
> function is not based on a request-response approach, but on a push
> approach, and this with
> much more expensive link-costs between ARs and the push function. What
> do you think?
> 
[Govind] Cache entries are updated via handovers (which will happen) 
and capabilities are updated via refresh messages. I don't really think we need to worry about inter-AR bandwidth for now. I think the DT draft does something similar
too for dynamic capabilities. I don't think proactively pushing dynamic capabilities 
is a problem. This helps during decision making. However, if you think that this is a big deal, we can always put it as an option and support a pull function too.

> failure due to a small delay (server function access) and an immediately
> breaking connection,
>always making use of radio bandwidth to update caches. If cache updating
>in dycard should
>over the air as well, isn't it? Not sure if this is really a good solution.

[Govind] As I described to Ajoy, I don't think we should decide a protocol
on some physical layer assumptions that may not be true. I don't think
you can ever guarantee that the overlap is large. It depends on the environment
the speed of the MN and other issues, which we don't need to go through. 
Consider this case. Assume that there is an optimization in the MN that 
APids are not reported as soon as they are heard but when a bunch of them
are heard to save on bandwidth. Now the time for reaction is less isn't it?
Further, there was talk of tagging the server onto some existing network
element. Apart from convincing the AAA (as an example) folks to accept this,
these servers now will be time sharing between CARD as well as their regular
functions. This is something that needs to be thought of too.
Plus, I think in a steady state the chance that a server will be asked for info
is quite less if cache entry updates happen. So whats the need of one?
I thought one of the DT members sent out a mail that the server is useful only for 
bootstrap. So is the server justified? Regarding your point that radio bandwidth
is used for cache population, I would guess you are talking about the RI message.
You are right. One more message is needed. However, this could be piggybacked
on existing messages.  I don't think this is a gross wastage
of bandwidth as you seem to point out. 
But note, even in the DT scheme, you do populate the cache with help of the MNs help
too. The MN sends APids and the info is brought from the server down to the cache. Plus as I pointed out earlier, it is difficult to recognize malicious MNs which are
artificially creating APids and transmitting them from MNs that listen to APids from
other domains. The main point is that once we are talking about the cache, both 
the approaches need to work to make sure that it is secure. But the number of benefits got from servers may not justify in putting  servers in the network for CARD.

I don't understand your "static capabilities" point. 

> Here, I guess, the server function could support ARs learning 
> capability
> about wrong or right
> cache entries when using the scope-ID approach, as briefly referred to
> in the DT draft. Either
> ARs process scope-IDs or the server could already do, which reduces
> superfluous traffic
> in the network. Since feeding caches in dycard is mobile controlled,
> malicious mobiles
> could update caches regularly and maintain wrong information 
> in caches,
> isn't it?
[Govind] The scope-id reduces the scope of the problem to a "scope-id" scope.
So it doesn't really solve the problem completely. All I was saying is that
if there are better approaches to tackle the problem, and I believe there are,
we should attempt to use it. Further this assumes that AR and AP locations are
correlated, which may not be true at all. Further this needs some effort on
the ISP's part to configure the server which is an added "cost". 
Regarding dycard, ofcourse there is a chance that malicious MNs may attempt
to do what you suggest, and we are attempted to make this very difficult to do
by putting in some checks into the protocol.

Regards,
-Govind.

---

From: [email-masked]
Date: Wed, 12 Mar 2003 10:53:43 -0500

Hi Marco,

 This is to keep caches

Regards,
-Govind.

---

From: [email-masked]
Date: Wed, 12 Mar 2003 11:23:28 -0500

Hi Ajoy:

One comment below, DT hat off.

-----Original Message-----
From: ext Singh Ajoy-ASINGH1 [mailto:[email-masked]]
Sent: Tuesday, March 11, 2003 6:59 PM
To: Krishnamurthi Govind (NRC/Boston); [email-masked]; [email-masked]; [email-masked]
Subject: RE: [SeaMoby] Topic #2:Do we need a server for CARD

Govind,

-----Original Message-----
From: [email-masked] [mailto:[email-masked]]
Sent: Tuesday, March 11, 2003 5:39 PM
To: [email-masked]; [email-masked]; [email-masked]
Subject: RE: [SeaMoby] Topic #2:Do we need a server for CARD
Hi James,

Hemant -> I am trying to do some back of the envelope calculation here. There are two ARs and first handoff happens between them. Let us say cache lifetime is few hours. If another handoff occurs during those few hours, cache gets refreshed for another few hours. If no handoff occurs between those two ARs in few hours, why do we need to care of about seamlessness in the first place. Probably ARs are placed in the middle of the ocean. Of course assumption is that AR geographical closeness is static over few hours time scale.

-Govind.

---

From: Singh Ajoy-ASINGH1 <[email-masked]>
Date: Wed, 12 Mar 2003 10:39:21 -0600

Unfortunately, it is still rather subjective what "sufficient" overlap means
in order to "not have any problems". It highly depends on your notion of
"sufficient overlap", the mobility pattern of the mobile involved and the
topology
of your system, i.e., the experienced delay for L2-L3 requests. We need
simulations and
best current practices demonstrating how to set up the system properly for
certain environments.
These evaluations could also reveal how to prevent situations (if they are
preventable) in which
the probability of a seamless first handoff is actually damn close to zero
(i.e., identifying pathological 
situations).

AJOY->  By sufficient overlap, I mean overlap required to support fast
handoff or any seamless handoff. 
BTW, without overlapping coverage area it is not possible to support any
seamless handoff in 
real world.  Again please note that AR cache is updated when the new L2 ID
is detected 
based upon link layer scanning. The new link layer id  should be detected
prior 
to initiation of any L2 handoff. I mean MN won't until the link layer
connection with current AR is being lost
to update the discovery of new AP id.  

-----Original Message-----
From: [email-masked] [mailto:[email-masked]]
Sent: Wednesday, March 12, 2003 9:02 AM
To: Ajoy Singh; [email-masked]; [email-masked];
[email-masked]; [email-masked]
Subject: RE: [SeaMoby] Topic #2:Do we need a server for CARD

Hi Ajoy,

Unfortunately, it is still rather subjective what "sufficient" overlap means
in order to "not have any problems". It highly depends on your notion of
"sufficient overlap", the mobility pattern of the mobile involved and the
topology
of your system, i.e., the experienced delay for L2-L3 requests. We need
simulations and
best current practices demonstrating how to set up the system properly for
certain environments.
These evaluations could also reveal how to prevent situations (if they are
preventable) in which
the probability of a seamless first handoff is actually damn close to zero
(i.e., identifying pathological 
situations).

It all boils down to the fact that it is unclear right now how the claimed
P(failure of timely delivery of answer)=1 with "proper configuration"
is actually achieved in the server approach. Until then, P(.) less than one
is a valid assumption until proven otherwise, and the question 
remains whether or not it is worth going through the whole server thing for
this. 

Thanks,

Dirk

---

From: Singh Ajoy-ASINGH1 <[email-masked]>
Date: Wed, 12 Mar 2003 10:39:21 -0600

-----Original Message-----
From: [email-masked] [mailto:[email-masked]]
Sent: Wednesday, March 12, 2003 9:02 AM
To: Ajoy Singh; [email-masked]; [email-masked];

Hi Ajoy,

Thanks,

Dirk

---

From: [email-masked]
Date: Wed, 12 Mar 2003 11:52:05 -0500

>Sent: Wednesday, March 12, 2003 11:39 AM
>To: Trossen Dirk (NRC/Boston); Singh Ajoy-ASINGH1; 
>Krishnamurthi Govind (NRC/Boston); [email-masked]; 

And that's exactly the point. The "sufficient overlap" you need to support fast handoff as such is different from the 
"sufficient overlap" you need in order to perform the server-based L2-L3 mapping before, followed by said fast handoff. 
So you require a different "sufficient overlap" than in the plain fast handoff. How much more overlap is that? How would 
you minimize this additional overlap? 

As a consequence, your "sufficient" still doesn't tell me enough to dimension my system correctly. 
What are the design principles you would give to your engineering department that deploys the server-based system in order 
to ensure the seamless handoff (with your CARD solution) in any case, as you claim?? For that, you usually apply models or 
simulations for network planning that gives you details about where to place the server in order to achieve what you claim. 
"Sufficient overlap" is certainly not a design guideline that the engineering guys would accept for their network planning. As 
long as these design guidelines are not available, it is fair to assume that there is still a probability of failure since I might 
misdimension my system due to the lack of said design guideline.

Dirk

---

From: [email-masked]
Date: Wed, 12 Mar 2003 11:52:05 -0500

Dirk

---

From: Singh Ajoy-ASINGH1 <[email-masked]>
Date: Wed, 12 Mar 2003 10:53:14 -0600

-----Original Message-----
From: [email-masked] [mailto:[email-masked]]
Sent: Wednesday, March 12, 2003 7:37 AM
To: Ajoy Singh; [email-masked]; [email-masked]; seamoby@ietf.
org

> loss of cached information, dycard will not be able to support 
[Govind] I agree that cache entries have a lifetime. I think handovers are
enough to update these
entries. Handovers will happen in real life.

[Govind] Writing up a spec that is constrained on the assumptions on
the  physical layer scenario is not the correct approach IMO. 
But, lets leave this at that. I think you say it can be guaranteed most of
the
time, while I don't think so.

AJOY-> Please note that fast handoff work is based on this fact. We are
proposing 
something to help fast handoff . In CARD, the update message is sent as
soon the 
a new L2 id is detected during L2 scan. It does not wait till the L2
handoff is imminent.
Whereas in fast handoff, L3 handoff is initiated when mobile node or AR
detects that L2 handoff
is imminent based upon some L2 trigger. So, CARD is done prior to
initiation of L3 handoff.  If you believe 
in fast handoff work, then I am having hard time to digest your comment in
this
context. 
_______________________________________________
Seamoby mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/seamoby

---

From: Singh Ajoy-ASINGH1 <[email-masked]>
Date: Wed, 12 Mar 2003 10:53:14 -0600

-----Original Message-----
From: [email-masked] [mailto:[email-masked]]
Sent: Wednesday, March 12, 2003 7:37 AM
To: Ajoy Singh; [email-masked]; [email-masked]; seamoby@ietf.
org

---

From: [email-masked]
Date: Wed, 12 Mar 2003 12:17:37 -0500

Ajoy,
> in fast handoff work, then I am having hard time to digest 
[Govind] All I pointed out was that it takes more time to get information from the cache than from the server. 
The server will probably be busy, right since this is an important part of your protocol. If it is busy answering queries
from all ARs, apart from time sharing with other functions depending on what you are time sharing with, it will take time
to respond, because there is just  one per domain. Your claim is  that there is sufficient time inspite of all this, always!. 
 Well I beg to differ and I don't think it is true in all cases. 

On a related note, if the server is very lightly loaded whenever you are accessing it then 
 would'nt it  mean that the server is not contacted most of the time, which again begs the discussion why
would you need it? 

All these points seemingly attempt to justify the servers because it is deemed necessary. The original point of this topic
 is why need a servre when you can get comparable service in an alternative scheme without one?
_______________________________________________
Seamoby mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/seamoby

---

From: [email-masked]
Date: Wed, 12 Mar 2003 12:17:37 -0500

Ajoy,

---

From: Singh Ajoy-ASINGH1 <[email-masked]>
Date: Wed, 12 Mar 2003 11:20:56 -0600

Hello Hemant, 

-----Original Message-----
From: [email-masked] [mailto:[email-masked]]
Sent: Wednesday, March 12, 2003 10:23 AM
To: Ajoy Singh; [email-masked]; [email-masked];

Hi Ajoy:

-----Original Message-----
From: ext Singh Ajoy-ASINGH1 [mailto:[email-masked]]
Sent: Tuesday, March 11, 2003 6:59 PM
To: Krishnamurthi Govind (NRC/Boston); [email-masked]; eunsoo@nec-
labs.com; [email-masked]
Subject: RE: [SeaMoby] Topic #2:Do we need a server for CARD

Govind,

-----Original Message-----
From: [email-masked] [mailto:[email-masked]]
Sent: Tuesday, March 11, 2003 5:39 PM
To: [email-masked]; [email-masked]; [email-masked]
Subject: RE: [SeaMoby] Topic #2:Do we need a server for CARD
Hi James,
> Why are these approaches mutually exclusive?

[Govind] As I pointed out in my first email, I don't think they are
mutually exclusive.
One approach works with just a cache, second with a cache and server. 

[Govind] dycard, as is in the 01 draft now, needs one handover between ARs.
 I would rather put it that way than open ended as "learning period". In a
real life scenario,
 this handover will happen quite soon. In the future, if there are pico-
cellular environments
I would guess it may be more frequent. Note, until a handover happens you
don't need 
to know about the other AR. Once a handover happens you will know about the
other AR in dycard.

AJOY-> I am not sure even this is acceptable for voice user. 

The correct choice of lifetimes of cache entries should be able to take
care of the rest. 
AJOY->  What is the correct choice of lifetime? Because if you have longer
lifetime, 
the probability of fast handoff failure due to cache timeout is minimized,
but  you have other problem due to cache contamination. 

> the ISP can hire somebody to walk around and seed the cache, 
[Govind] I don't think the ISP really needs to do it. I don't think the
loss of
ability to provide one seamless handover between ARs is a big deal in the 
long run.

Hemant -> I am trying to do some back of the envelope calculation here.
There are two ARs and first handoff happens between them. Let us say cache
lifetime is few hours. If another handoff occurs during those few hours,
cache gets refreshed for another few hours. If no handoff occurs between
those two ARs in few hours, why do we need to care of about seamlessness in
the first place. Probably ARs are placed in the middle of the ocean. Of
course assumption is that AR geographical closeness is static over few
hours time scale.

sense also, but in all honestly I don't think that one handover is that big
of a deal,

AJOY->This is not correct and should be removed from design team draft.
Whenever 
there is sufficient overlap between coverage area of adjacent ARs,  server
based 
approach should not have any problem. 

[Govind] Well this causes an increase in traffic between ARs that are
not GAARs (using a defunct term) which I think is more problematic
than loosing one handover. I'm not saying that in dycard you cannot have
incorrect entries in the cache. This is an issue that both the protocols
need to address in detail.  But dycard handles this quite similarly. The
other 
issue is how easy it is to get these entries into the AR's cache in either
scheme. 
This is something that probably needs some more thought. 

[Govind] I don't know what you are implying by this statement. But
if you are stating that ISPs need to do this in dycard, then it is
incorrect. 
If you are talking about the scope-id approach which would need some
classification, I agree. 

> would be propagated directly by CARD.

[Govind] I don't think we need a server initially to propagate the cache. I
think handovers
between ARs, that will happen anyways, can be used to maintain the cache.
We have
done some study in this scenario and in the steady state the chances of a
cache miss is
quite low, even with incorporating some of the security schemes to prevent
contamination
of cache.  

-Govind.

---

From: Singh Ajoy-ASINGH1 <[email-masked]>
Date: Wed, 12 Mar 2003 11:20:56 -0600

Hello Hemant, 

-----Original Message-----
From: [email-masked] [mailto:[email-masked]]
Sent: Wednesday, March 12, 2003 10:23 AM
To: Ajoy Singh; [email-masked]; [email-masked];

Hi Ajoy:

-----Original Message-----
From: ext Singh Ajoy-ASINGH1 [mailto:[email-masked]]
Sent: Tuesday, March 11, 2003 6:59 PM
To: Krishnamurthi Govind (NRC/Boston); [email-masked]; eunsoo@nec-

Govind,

-----Original Message-----
From: [email-masked] [mailto:[email-masked]]
Sent: Tuesday, March 11, 2003 5:39 PM
To: [email-masked]; [email-masked]; [email-masked]
Subject: RE: [SeaMoby] Topic #2:Do we need a server for CARD
Hi James,

-Govind.

---

From: [email-masked]
Date: Wed, 12 Mar 2003 15:03:48 -0500

Jim,
If you read the dycard draft carefully you would notice that dycard assumes that a list of authorized APs
 are available at each AR. Checks are made to compare L2 ids reported w.r.t authorized L2 ids.
The L2 ids put in the cache comes from other trusted ARs. Why can't we assume that they know
what L2 devices are connected to the ARs?   
We don't discuss how this authorized list is put there explicitly. 
This could be by any existing network management procedure.

 If Iam not wrong, in the DT draft, I  think some L2 mechanism is assumed to exist that lets
 the AR know about its APs and this is conveyed to the server. Can't the same 
L2 mechanism be used? 

Having said that no L2 mechanism is assumed in dycard. 
It is a learning procedure too. But if something can be assumed for this we can do the same.

Thanks,
Govind.
> Sent: Wednesday, March 12, 2003 1:31 PM
> The server will allow an AR to determine which APs are 
> authorized. The dycard
> draft has nothing about this. This is an important security 
> measure, though not
> directly related to exchanging the CAR information.
> 
>         jak
> 
> To: "James Kempf" <[email-masked]>; <[email-masked]>
> Sent: Wednesday, March 12, 2003 1:00 PM
> > > One of the drawbacks of Dycard is that it needs a learning period.
> > Naturally,
> > > expensive. A server could prime the cache in the router 
> with a collection
> > of
> > > AP/AR mappings that may not be geographically adjacent, 
> but over time the
> > ones
> > > that aren't would drop out. Thus, the ISP would not have 
> to go through the
> geographically
> > adjacent.
> cache, any
> > changes
> > [eunsoo] As Govind and Dirk pointed out, the first handoff 
> between two ARs
> > leads to populating the cache with an entry for the newly 
> discovered CAR in
> > Dycard.
> > If you claim that the server will be used only for initial 
> populating the
> > cache at ARs, please clarify difference from the DT draft. 
> The DT draft does
> > not say each AR will download a bunch of L2-L3 mapping 
> information from the
> > server in the beginning of its operation. It will download 
> one by one as MN
> > requests the mapping or reports a new BS L2 address.
> >
> > The only difference between Dycard and the server approach 
> in the learning
> > period is that MN may be able to do fast handoff for the 
> very first handoff
> > between two ARs in the server approach while MN will have 
> to do slow handoff
> > in Dycard. Well, if we are talking about ISP, I don't think 
> they just
> > install a box and start commercial services. They will go 
> through many
> > stages of network tests including roaming support. So most 
> likely initial
> > discoveries will be done during the process and thus they 
> would not feel any
> > concern for the impact of the learning period for 
> consumers. If we are
> > talking about more ad-hoc and casual network deployment, I 
> am not sure the
> > slow handoff for the very first handoff is such a big 
> concern, let say, for
> > corporate networks or campus networks. I don't think it justifies
> > introducing a sever.
> >
> > Also even if an ISP wants populating the cache by the 
> information from the
> > server, they cannot tell exactly which entry should be 
> inserted into a cache
> > unless they know exactly the radio map of the base 
> stations. Well, all this
> > work is to remove such requirement. Then what they do only 
> is just copying a
> > bunch of entries from the server to the cache as you 
> suggested. If really
> > they want to do such a thing, they can use many existing 
> tools. For example,
> > we can simply define MIB for CARD and they can use SNMP for 
> setting the
> > values for CARD. This should not affect the fundamental 
> structure of the
> > protocol. Actually it should be independent of the CARD 
> protocol. Thus it
> > should not be a part of the CARD protocol except MIB 
> definitions. Defining
> > MIB does not bring in any need of a server, of course.
> >
> > Eunsoo
> >
> >
> >
> >
> >

---

From: [email-masked]
Date: Wed, 12 Mar 2003 15:22:24 -0500

Hi:

There seems to be some disconnect. The current DT draft does NOT intend solve the problem of enabling AR to determine which APs are authorized. APs are brought up/down and connected to/disconnected from AR. Some L2 layer mechanism between AR-AP enables AR to learn about new/removed AP. AR reports that AP is up/down to CARD server and CARD server stores the mapping. In other words, AR is in control of knowing what APs are attached to it and CARD server relies on information provided by AR regarding this.

Hemant 

-----Original Message-----
From: ext Eunsoo Shim [mailto:[email-masked]]
Sent: Wednesday, March 12, 2003 4:48 PM
To: James Kempf; [email-masked]
Subject: Re: [SeaMoby] Topic #2:Do we need a server for CARD

> The server will allow an AR to determine which APs are authorized. The
dycard
> draft has nothing about this. This is an important security measure,
though not
> directly related to exchanging the CAR information.
[eunsoo] The routing protocol (for the wired Internet) has a similar
problem. They want to know whether a router is authorized to participate in
the route discovery. So for intra-domain routing protocols, usually shared
secret is proposed. Also Dycard assumes it in the expression that there
should be a security association between ARs. If we consider only
intra-domain communication between ARs, shared secret would be sufficient
for authorization and message authentication. If you consider central NMS
system that allows remote configuration of ARs, it would be very easy to
configure the shared secret among ARs. If there is no such thing, people do
the configuration by remotely logging into ARs. This one time configuration
removes concerns about scalability and reliability. You don't need a server
running up 24/7 for this authorization since you don't expect a new AR that
often.

Eunsoo

---

From: [email-masked]
Date: Wed, 12 Mar 2003 15:31:29 -0500

Hi James:

Numbers are good way to analyze. (DT hat off), for dyCARD it is easy calculation. Sending one piggybacked message (= at least 126 bytes for IPv6 address + few header bytes) is the overhead per handoff on uplink. Here I make similar assumption to server based approach (AR knows its APs via L2 mechanisms). This does not matter at all for 802.11. For paid spectrum technologies argument can be made either way.

Hemant 

-----Original Message-----
From: ext James Kempf [mailto:[email-masked]]
Sent: Wednesday, March 12, 2003 1:29 PM
To: Eunsoo Shim; Marco Liebsch; Krishnamurthi Govind (NRC/Boston)
Cc: [email-masked]
Subject: Re: [SeaMoby] Topic #2:Do we need a server for CARD

I am not suggesting anything about which approach is better. I am saying that
there is an opinion being expressed here by you, namely that bytes don't matter.
Putting on my operator hat, operators pay lots of money for spectrum and to us,
bytes do matter. A protocol that minimizes the number of bytes over the air is
important. Even for free spectrum like 802.11, it is not possible to
overprovision the air. Putting more access points into a room after a certain
point only leads to more interference. So reducing the load on the wireless link
is always a concern.

Removing my operator hat and putting on my WG co-chair hat, the way to resolve
the question is for someone to come up with some numbers about how many bytes it
takes for the Dycard approach v.s. the DT approach. That should be entered into
the discussion about which approach is better. Thus, some of the handwaving that
I am seeing around this issue from both sides (DT and Dycard) will be removed.
The number of bytes won't of course be the only concern, but it will be an
important one.

If you don't want to do that calculation, perhaps someone from the DT or someone
else in the WG would like to do it?

            jak

----- Original Message -----
From: "Eunsoo Shim" <[email-masked]>
To: "James Kempf" <[email-masked]>; "Marco Liebsch"
<[email-masked]>; <[email-masked]>
Cc: <[email-masked]>
Sent: Wednesday, March 12, 2003 1:13 PM
Subject: Re: [SeaMoby] Topic #2:Do we need a server for CARD

> > > [eunsoo] The question I raised was what is the server's function. You
> have
> > > not specified what the server function is. Can you please specify what
> the
> > > server function is if it is different from what James mentioned, that
> is,
> > > initial population of the cache?
> > > Also please note that the cache population requires reports from MN in
> both
> > > approaches. In the server approach, MN reports L2 address of BS to the
> > > current AR. In Dycard, MN reports IP address of the previous AR to the
> > > current AR. You may say the number of bytes in the report in Dycard is
> > > larger than the server approach. Well, I don't think the difference is
> so
> > > significant in the overall performace of the air link. Thus I don't
> think
> > > Dycard is more expensive than the server approach.
> > >
> >
> > Your opinions are interesting, but numbers are the way to answer this
> question.
> > How about coming up with a byte count of the number of bytes needed over
> the air
> > for Dycard v.s. the DT approach? That would help the WG judge which
> approach is
> > more spectrally efficient.
> >
> [eunsoo] I don't think you want to judge any protocol by just simply
> counting the number of bytes transmitted over the air. Are you suggesting
> that the need for the server is to reduce the number of bytes over the air?
> If we want to count the number of bytes seriously, we should list all the
> messages and count the sizes and how often each message should be
> transmitted. If everything else is the same between the two approaches, the
> server approach sends L2 address to the AR and Dycard sends L2 address and
> IP address to the AR. So we are talking about the size of one IP address in
> a message which is sent once per handoff. What is your numerical criteria in
> judging a protocol with the number of bytes?
>
> Eunsoo
>
>

---

From: [email-masked]
Date: Wed, 12 Mar 2003 15:31:29 -0500

Hi James:

Hemant 

-----Original Message-----
From: ext James Kempf [mailto:[email-masked]]
Sent: Wednesday, March 12, 2003 1:29 PM
To: Eunsoo Shim; Marco Liebsch; Krishnamurthi Govind (NRC/Boston)
Cc: [email-masked]
Subject: Re: [SeaMoby] Topic #2:Do we need a server for CARD

            jak

---

From: [email-masked]
Date: Wed, 12 Mar 2003 15:36:03 -0500

> assumed for this we can do the same.

Just to clarify this earlier sentence in my  earlier email. dycard assumes an authorized list of APs exist at each AR that
determines which APs are allowed to  connect to the AR. However no L2 mechanism is assumed to tell the AR
 which APs are currently connected.
Soft states are maintained for AP information also, and MN updates are used to figure this out. We use
this to take care of AP failures and change in topology etc..  However, if
an L2 mechanism exists that allows the AR to know which APs are currently connected we can reuse that here too.

Sorry for any confusion.
Thanks,
Govind.

---

From: [email-masked]
Date: Wed, 12 Mar 2003 15:35:01 -0500

Sorry, it was 128 bit for IPv6 address. I don't know what I was smoking. ;-) 

Hemant

-----Original Message-----
From: ext [email-masked] [mailto:[email-masked]]
Sent: Wednesday, March 12, 2003 3:31 PM
To: [email-masked]; [email-masked];
[email-masked]; Krishnamurthi Govind (NRC/Boston)
Cc: [email-masked]
Subject: RE: [SeaMoby] Topic #2:Do we need a server for CARD

Hi James:

Hemant 

-----Original Message-----
From: ext James Kempf [mailto:[email-masked]]
Sent: Wednesday, March 12, 2003 1:29 PM
To: Eunsoo Shim; Marco Liebsch; Krishnamurthi Govind (NRC/Boston)
Cc: [email-masked]
Subject: Re: [SeaMoby] Topic #2:Do we need a server for CARD

            jak

---

From: [email-masked]
Date: Wed, 12 Mar 2003 15:36:03 -0500

Sorry for any confusion.
Thanks,
Govind.

---

From: [email-masked]
Date: Wed, 12 Mar 2003 15:35:01 -0500

Hemant

-----Original Message-----
From: ext [email-masked] [mailto:[email-masked]]
Sent: Wednesday, March 12, 2003 3:31 PM
To: [email-masked]; [email-masked];

Hi James:

Hemant 

-----Original Message-----
From: ext James Kempf [mailto:[email-masked]]
Sent: Wednesday, March 12, 2003 1:29 PM
To: Eunsoo Shim; Marco Liebsch; Krishnamurthi Govind (NRC/Boston)
Cc: [email-masked]
Subject: Re: [SeaMoby] Topic #2:Do we need a server for CARD

            jak

---

From: [email-masked]
Date: Wed, 12 Mar 2003 16:07:01 -0500

Hi James,

I'm surprised to suddenly see AP authentication in the scope of CAR discovery. Where does this change of
scope come from? If a network operator requires AP authentication for each AR, network management
tools can be used to download the list of APs to the AR. I don't see anything in the issue draft putting 
this on the table of CAR discovery (we would have called it CAR and local AP discovery then).

So if you want to address this, let's define MIB entries and push mechanisms to download said AP entries to 
the AR MIB, and we're done. 

Dirk

>Sent: Wednesday, March 12, 2003 3:58 PM
>To: Chaskar Hemant (NRC/Boston); [email-masked]; [email-masked]
>No disconnect.
>My point was, this is a deficiency with both drafts. It is an 
>issue we need to
>resolve before we can consider the design complete.
>
>            jak
>
>From: <[email-masked]>
>To: <[email-masked]>; <[email-masked]>; 
><[email-masked]>
>Sent: Wednesday, March 12, 2003 12:22 PM
>> There seems to be some disconnect. The current DT draft does 
>NOT intend solve
>the problem of enabling AR to determine which APs are 
>authorized. APs are
>brought up/down and connected to/disconnected from AR. Some L2 
>layer mechanism
>between AR-AP enables AR to learn about new/removed AP. AR 
>reports that AP is
>up/down to CARD server and CARD server stores the mapping. In 
>other words, AR is
>in control of knowing what APs are attached to it and CARD 
>server relies on
>information provided by AR regarding this.
>>
>> Hemant
>>
>authorized. The

---

From: [email-masked]
Date: Wed, 12 Mar 2003 16:11:22 -0500

> 
> There is need for some mechanism, independent of any 
> interrouter exchange of
> information, for a router to determine whether a particular 
> AP is, in fact,
> authorized. This mechanism functions as a trust root, if you 
> will. That is what
> I was referring to.
[Govind]  Why is this an issue that has to be considered at the IETF? Isn't this the function
of the L2 mechanism or some other management mechanism to ensure this.
The DT draft also, I believe, clearly states that this is out of scope. Hemant's recent
mail also attests to this. 

> Or were you proposing a protocol between APs and ARs to allow 
> the AR to validate
> whether an AP is authorized?
> 
[Govind] dycard does not. Neither does the DT draft, I believe. Both assume
that this information is available.

---

From: [email-masked]
Date: Wed, 12 Mar 2003 16:11:22 -0500

---

From: [email-masked]
Date: Wed, 12 Mar 2003 16:16:13 -0500

James, 
I agree that this is an important issue, but not a difficult issue. Several
tools exist already to do this, SNMP for example. In cellular networks, adding
APs (base stations) is operator controlled too and it is quite easy for this to be accomplished.
Arbitrarily people cant introduce APs into a network domain. Since both the APs and ARs are
under operator control, any one of these existing tools can be used to maintain this list.

-Govind

> Sent: Wednesday, March 12, 2003 3:57 PM
> To: Krishnamurthi Govind (NRC/Boston); [email-masked]; 
> [email-masked]
> It's that assumption I am questioning.
> 
> For that to be made, there needs to be some reasonable idea 
> of mechanism,
> otherwise, the protocol is not deployable.
> 
> I'm suggesting that a server is one possible approach to providing the
> mechanism.
> 
>             jak
> 
> From: <[email-masked]>
> To: <[email-masked]>; <[email-masked]>; 
> <[email-masked]>
> Sent: Wednesday, March 12, 2003 12:03 PM
> > If you read the dycard draft carefully you would notice 
> that dycard assumes
> that a list of authorized APs
> >  are available at each AR. Checks are made to compare L2 
> ids reported w.r.t
> authorized L2 ids.
> > The L2 ids put in the cache comes from other trusted ARs. 
> Why can't we assume
> that they know
> >  If Iam not wrong, in the DT draft, I  think some L2 
> mechanism is assumed to
> exist that lets
> > It is a learning procedure too. But if something can be 
> assumed for this we
> can do the same.
> >
> >
> > Thanks,
> > Govind.

---

From: [email-masked]
Date: Wed, 12 Mar 2003 16:16:13 -0500

James, 

-Govind

---

From: [email-masked]
Date: Wed, 12 Mar 2003 16:23:44 -0500

Hi James:

In certain environments, let us say 3G, connecting base station to access network is quite an involved job. This cannot be done casually without operator's co-operation. So, here authorization can be done via physical means - operator will not open doors of the room where AR is located to connect AP wire to it. In some 802.11 which provides no physical level control, anybody can connect AP to AR. In others, where premium service is provided, Ethernet wires won't be run accessible to passerby. Of course, L2 layer digital authorization mechanism is also possible. In summary, the mechanisms for this can be varied ranging from (practical) physical security to digital security. Also, this is L2-layer issue. IMHO, this does not belong in CARD scope. 

Hemant

-----Original Message-----
From: ext James Kempf [mailto:[email-masked]]
Sent: Wednesday, March 12, 2003 3:58 PM
To: Chaskar Hemant (NRC/Boston); [email-masked]; [email-masked]
Subject: Re: [SeaMoby] Topic #2:Do we need a server for CARD

No disconnect.

My point was, this is a deficiency with both drafts. It is an issue we need to
resolve before we can consider the design complete.

            jak

----- Original Message -----
From: <[email-masked]>
To: <[email-masked]>; <[email-masked]>; <[email-masked]>
Sent: Wednesday, March 12, 2003 12:22 PM
Subject: RE: [SeaMoby] Topic #2:Do we need a server for CARD

> Hi:
>
> There seems to be some disconnect. The current DT draft does NOT intend solve
the problem of enabling AR to determine which APs are authorized. APs are
brought up/down and connected to/disconnected from AR. Some L2 layer mechanism
between AR-AP enables AR to learn about new/removed AP. AR reports that AP is
up/down to CARD server and CARD server stores the mapping. In other words, AR is
in control of knowing what APs are attached to it and CARD server relies on
information provided by AR regarding this.

---

From: [email-masked]
Date: Wed, 12 Mar 2003 16:23:44 -0500

Hi James:

Hemant

-----Original Message-----
From: ext James Kempf [mailto:[email-masked]]
Sent: Wednesday, March 12, 2003 3:58 PM
To: Chaskar Hemant (NRC/Boston); [email-masked]; [email-masked]
Subject: Re: [SeaMoby] Topic #2:Do we need a server for CARD

No disconnect.

            jak

---

From: [email-masked]
Date: Wed, 12 Mar 2003 19:21:31 -0500

Jim,
I honestly don't think we need to revisit the requirements again. First, there is 
no unacceptable security hole as you point out. The drafts have acknowledged
that an authorized list of APs  is needed, but have said that this has to be made available 
and it is out of scope for them. 
So once this is made available, in some way shape or form, where is the security hole? 
We have spent enough time on the requirements and Issues draft and they have passed WG last call.
 Calling it back is just going to delay the process unnecessarily. 
Further, I don't
think the current state of the protocol design warrants this. I think both
the protocols under question acknowledge that APs need to be authorized
and they defer it to the admin to use existing protocols to get this
authorized list down to the ARs or the server. I think a statement
to that effect in the final protocol spec is more than enough. I draw a parallel
to the FMIPv6 work, where they assume that someone provides the L2-L3 mapping.
Why isn't  this similar? Clearly if the L2-L3 mapping is not provided in a secure fashion
FMIPv6 will fail is it not?

 I don't think Dirk was
referring to  the requirements draft in his email. I think he was pointing out the issues draft.
I don't understand why you think he alluded to the requirements draft. Maybe
Dirk can correct me on this. 

 I don't think this problem is in the scope of CARD. This deals with L2 devices of different technologies
and to get a common way to get this authorized APs list in different technologies should be and is
beyond the scope of CARD. This is as if saying that CARD now should re-invent IKE to make sure 
that ARs have an SA. 

My 2 cents,
Govind.

> Sent: Wednesday, March 12, 2003 5:52 PM
> To: Trossen Dirk (NRC/Boston); Chaskar Hemant (NRC/Boston); 
> Dirk,
> You're right. This is a significant gap in our requirements.
> 
> We will have to recall them from the IESG and include it. It 
> is an unacceptable
> security hole for there to be no requirement that APs be 
> authorized. I'm
> suprised Steve Bellovin didn't find this.
> 
> Thanx for pointing out this serious hole.
> 
>             jak
> 
> From: <[email-masked]>
> To: <[email-masked]>; <[email-masked]>;
> <[email-masked]>; <[email-masked]>
> Sent: Wednesday, March 12, 2003 1:07 PM
> > I'm surprised to suddenly see AP authentication in the 
> scope of CAR discovery.
> Where does this change of
> > scope come from? If a network operator requires AP 
> authentication for each AR,
> network management
> > tools can be used to download the list of APs to the AR. I 
> don't see anything
> in the issue draft putting
> > this on the table of CAR discovery (we would have called it 
> CAR and local AP
> discovery then).
> >
> > So if you want to address this, let's define MIB entries 
> and push mechanisms
> to download said AP entries to

---

From: [email-masked]
Date: Wed, 12 Mar 2003 19:21:31 -0500

Jim,

 I don't think Dirk was

My 2 cents,
Govind.

---

From: "Paine, Richard H" <[email-masked]>
Date: Wed, 12 Mar 2003 21:08:05 -0800

In fact there is a secure layer 2 mechanism for communicating between APs and it is, in effect, a context transfer protocol; 802.11f.  You can even define the context.

Richard H. Paine
Success is getting what you want, happiness is liking what you get!
Work: 425-865-4921
Pager: 206-797-4580
Cell:  206-854-8199
IPPhone:  206-766-5808
Email:  [email-masked]

---

From: "Paine, Richard H" <[email-masked]>
Date: Wed, 12 Mar 2003 21:08:05 -0800

Richard H. Paine

---

From: [email-masked]
Date: Thu, 13 Mar 2003 09:44:17 -0500

Hi James,

thanks for giving me the merits for discovering this "security hole", but you greatly misinterpret my intentions.
Local AP-AR authentication is a problem concerned with security, and this will remain the only common point 
in our both thinking.

Beyond this, I do not believe that this is within the scope of CAR discovery. There exist easy solutions to solve this
problem (as pointed out by other emails), and both discussed solutions (dycard and DT draft) assume the existence of these 
mechanisms. 

I start wondering what you want to achieve by recalling requirements (and consequently issues) draft from the IESG. This
call comes a bit too early and too quickly for me so that I'm wondering whether you actually have the progress of the CAR
work in mind when you propose something like this.

Thanks,

Dirk

>> I'm surprised to suddenly see AP authentication in the scope 
>of CAR discovery.
>> So if you want to address this, let's define MIB entries and 
>push mechanisms

---

From: [email-masked]
Date: Thu, 13 Mar 2003 10:03:26 -0500

Hi Daichi,

>According to this results, if an operator deploys 127 ARs, the
>operator possibly receives 342 call-miss complaints from customers.
>They might include important emergency call handover misses.
>This is a nightmare to the operator.
>No one knows one call is less important than the other calls.
>Who can say this is not a big deal?

So the failure of CAR implies a failure of the entire handover, i.e., it results in
a call miss? I guess handover people in MIP WG will not like to hear this reasoning
regarding the dependence of handover on CAR discovery ;-) 

What we are talking about is that learning-based approach's first handover
is a break before make handover. But still, the handover will happen eventually.

More concretely, we talk about having a glitch in our first handover of a cell
compared to a probability of not having this glitch in the first handover. We believe 
that the removal of said glitch is not worth the overhead of a server in the solution.

Thanks,

Dirk

---

From: [email-masked]
Date: Thu, 13 Mar 2003 10:03:26 -0500

Hi Daichi,

Thanks,

Dirk

---

From: Singh Ajoy-ASINGH1 <[email-masked]>
Date: Thu, 13 Mar 2003 09:56:21 -0600

What we are talking about is that learning-based approach's first handover
is a break before make handover. But still, the handover will happen
eventually.

AJOY-> BTW, standard MIP handover may not acceptable for a voice 
user. 

-----Original Message-----
From: [email-masked] [mailto:[email-masked]]
Sent: Thursday, March 13, 2003 9:03 AM
To: [email-masked]; [email-masked]
Subject: RE: [SeaMoby] Topic #2:Do we need a server for CARD

Hi Daichi,

>Who can say this is not a big deal?

So the failure of CAR implies a failure of the entire handover, i.e., it
results in
a call miss? I guess handover people in MIP WG will not like to hear this
reasoning
regarding the dependence of handover on CAR discovery ;-) 

What we are talking about is that learning-based approach's first handover
is a break before make handover. But still, the handover will happen
eventually.

More concretely, we talk about having a glitch in our first handover of a
cell
compared to a probability of not having this glitch in the first handover.
We believe 
that the removal of said glitch is not worth the overhead of a server in the
solution.

Thanks,

Dirk

---

From: Singh Ajoy-ASINGH1 <[email-masked]>
Date: Thu, 13 Mar 2003 09:56:21 -0600

-----Original Message-----
From: [email-masked] [mailto:[email-masked]]
Sent: Thursday, March 13, 2003 9:03 AM
To: [email-masked]; [email-masked]
Subject: RE: [SeaMoby] Topic #2:Do we need a server for CARD

Hi Daichi,

Thanks,

Dirk

---

From: [email-masked]
Date: Thu, 13 Mar 2003 11:00:30 -0500

Hi Daichi:

(DT hat off)

Well, I can do another calculation and show you that this is not a big deal (definitely not a nightmare). The underline is that - first handoff between two ARs is not seamless (does not mean a failure). Also, you have not factored in issues like radio degradation, congestion on radio signaling channels etc. in this calculation. Then you have not considered the probability of first handoff between ARs being an emergency call. And then you have not considered the probability that server is loaded or down during emergency call in current protocol.

Hemant

-----Original Message-----
From: ext Daichi Funato [mailto:[email-masked]]
Sent: Wednesday, March 12, 2003 8:51 PM
To: [email-masked]
Subject: Re: [SeaMoby] Topic #2:Do we need a server for CARD

Hi Hemant,

> Hemant -> I am trying to do some back of the envelope calculation
> here. There are two ARs and first handoff happens between them. 
> Let us say cache lifetime is few hours. If another handoff occurs
> during those few hours, cache gets refreshed for another few hours.
> If no handoff occurs between those two ARs in few hours, why do 
> we need to care of about seamlessness in the first place. 

I don't think this calculation is enough...
A server is necessary to save the initial handover failures. 
Let me show you another caluculation.

Suppose there is an AR, which has a hexagon shape coverage.
If we surround this AR with other AR hexagons, there will be 
7 ARs. In this case, the total adjacent edges, which equals to 
the total CAR entries, are 12. This means we need 12 learning
reports from MNs with 12 handover failures in learning-based
approach.

If we continue surrounding this, we can get the numbers by
simple calculations.

#Surrounds,    #ARs,       #TotalEdges(CARs)
1,             7,          12
2,             19,         42
3,             37,         90
4,             61,         156
5,             91,         240
6,             127,        342

If we take learning-based approach, we can't avoid this problem by nature.
The server-based approach can provide a way to greatly improve this.
Placing a server will save hundreds of handover failures in initial stage.
Also the server will be used to save handover failures every time a 
CAR cache in an AR expires as well. It's not a trivial matter.

Operators won't take a solution, which doesn't provide a way to
improve quality to customers. Moreover, operators won't take any way,
which sacrifices users to improve their network operation efficiency.
The burden should not be shared with customers.

Regards,
Daichi

---

From: [email-masked]
Date: Thu, 13 Mar 2003 11:00:30 -0500

Hi Daichi:

(DT hat off)

Hemant

-----Original Message-----
From: ext Daichi Funato [mailto:[email-masked]]
Sent: Wednesday, March 12, 2003 8:51 PM
To: [email-masked]
Subject: Re: [SeaMoby] Topic #2:Do we need a server for CARD

Hi Hemant,

Regards,
Daichi

---

From: [email-masked]
Date: Thu, 13 Mar 2003 11:22:56 -0500

Daichi,
My responses embedded.

> reports from MNs with 12 handover failures in learning-based

First, can you explain to me why if you don't do CARD it is a
handover failure? Are you saying that calls will be dropped if there is no
seamless handovers? Do you have any basis for this argument? A couple
of years ago, we implemented a buffering protocol where most of the
packets got through, with base Mobile IPv6, even when we did a manual handover, i.e. 
disconnecting the wire from one router and plugging it into another router. No
CARD here, and probably lossless too. 

Second, are you guaranteeing seamless handovers always with the server approach, 
inspite of all that has been pointed out in the mailing list? 
Lastly, as Eunsoo pointed out if the network is tested during operator trials
 before getting it out to the customers the caches will 
anyways be filled up, before the network gets to the customers is it not? 
> #Surrounds,    #ARs,       #TotalEdges(CARs)

[Govind] You don't point out the success ratio at all. I think that
might be the main thing to consider. Loosing "hundreds" of seamless handovers
 over time, wherein millions and possibly billions of seamless handovers are made 
is actually not a big deal, IMHO. Because, handovers can fail even when everything works
right from the protocol point of view, due to the physical layer that we are
talking about.
 Maybe success ratio is the criteria that could be the benchmark, success ratio in steady
state. To put up a server for "hundreds" of calls is not anything a service provider, 
though I don't have any service provider hat to put on, 
will buy either. 

> The server-based approach can provide a way to greatly improve this.
[Govind] Can you give us some numbers for this? 

> CAR cache in an AR expires as well. It's not a trivial matter.

[Govind] I don't think the point that the server saves handover 
failures during CAR cache expirations can be validated 
very easily. If we are designing a protocol
for handovers, once they happen caches will be refreshed 
automatically. 

Further, you are missing an important point of extensibility to inter-domains.
Though it is a SHOULD now in the requirements, I would think this is a
very important feature of dycard. I don't think having servers is feasible
in inter-domain handovers.

Govind.

---

From: [email-masked]
Date: Thu, 13 Mar 2003 11:22:56 -0500

Daichi,
My responses embedded.

Govind.

---

From: [email-masked]
Date: Thu, 13 Mar 2003 13:21:38 -0500

Hi James,

my point is not about easy or not. It is whether AP authentication is something that
is in scope of CAR or not. Whether or not APs are authenticated towards their router
is not a particular problem of CAR, hence I argue for "out of scope". If you want to address
the problem, bring it up, define the scope of the problem, and the applicability of a solution
and go ahead. 

In the meanwhile, we can continue with the current work of CAR since both CAR solutions 
assume the existence of a solution for AP authentication. 

Dirk

>Sent: Thursday, March 13, 2003 12:45 PM
>The issue isn't whether there are easy solutions, the issue is 
>that a solution
>MUST be specified. If the solutions are easy, then specifying 
>them should be as
>well, no?
>
>            jak
>
>Sent: Thursday, March 13, 2003 6:44 AM
>> thanks for giving me the merits for discovering this 
>"security hole", but you
>greatly misinterpret my intentions.
>> Local AP-AR authentication is a problem concerned with 
>security, and this will
>remain the only common point
>> in our both thinking.
>>
>> Beyond this, I do not believe that this is within the scope 
>of CAR discovery.
>There exist easy solutions to solve this
>> problem (as pointed out by other emails), and both discussed 
>solutions (dycard
>and DT draft) assume the existence of these
>> mechanisms.
>>
>> I start wondering what you want to achieve by recalling 
>requirements (and
>consequently issues) draft from the IESG. This
>> call comes a bit too early and too quickly for me so that 
>I'm wondering
>whether you actually have the progress of the CAR

---

From: [email-masked]
Date: Thu, 13 Mar 2003 13:21:38 -0500

Hi James,

Dirk