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

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.
_______________________________________________
Seamoby mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/seamoby

---

From: Marco Liebsch <[email-masked]>
Date: Wed, 12 Mar 2003 12:00:20 +0100

Hi Govind and all,

please see inline for comments.

Regards,
marco

>One approach works with just a cache, second with a cache and server. 
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? 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?

>compared to putting up a server. 
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.
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. 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.

>This is something that probably needs some more thought. 
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?

marco

--

---

From: Marco Liebsch <[email-masked]>
Date: Wed, 12 Mar 2003 12:00:20 +0100

Hi Govind and all,

Regards,
marco

marco

--

---

From: "Eunsoo Shim" <[email-masked]>
Date: Wed, 12 Mar 2003 11:17:26 -0800

Hi, Macro,

My comments are inline.
> much more expensive link-costs between ARs and the push function. What
[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.

> could update caches regularly and maintain wrong information in caches,
[eunsoo] As Govind pointed out in his email, the scope-ID does not prevent
cache contamination. I repeatedly request a scenario of how the scope-ID
prevents cache contamination. I'd appreciate if you provide one.
Dividing a domain into sub-domains or scopes does not solve the problem.
Actually it brings another problem because the server approach does not
support inter-domain operation or inter-scope operation. That is, now
handoffs across small scopes cannot take advantage of CARD and thus they
would be slow, inefficient, etc.
In Dycard, the MN also can try to inject a wrong entry into the cache. But
Dycard allows preventing by identifying the MN providing the IP address of
the previous AR and checking the handoff history. That is, by checking
whether the MN was really with the previous AR very recently, the report
about the previous AR's IP address can be verified. That's why I said two
cooperating ARs can make cache contamination very difficult. It is very
different from the server approach where there is no way to verify whether
the MN received the beacon (thus L2 address of an AR) at the location or
not. This is a fundamental security problem of the server approach. I guess
we should open the third topic, cache contamination, soon.

Regards,

Eunsoo

---

From: "Eunsoo Shim" <[email-masked]>
Date: Wed, 12 Mar 2003 11:17:26 -0800

Hi, Macro,

My comments are inline.

Regards,

Eunsoo

---

From: "James Kempf" <[email-masked]>
Date: Wed, 12 Mar 2003 09:44:47 -0800

Eunsoo,

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

            jak

---

From: "James Kempf" <[email-masked]>
Date: Wed, 12 Mar 2003 09:44:47 -0800

Eunsoo,

            jak

---

From: "Eunsoo Shim" <[email-masked]>
Date: Wed, 12 Mar 2003 13:13:45 -0800

> 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: "Eunsoo Shim" <[email-masked]>
Date: Wed, 12 Mar 2003 13:13:45 -0800

Eunsoo

---

From: "James Kempf" <[email-masked]>
Date: Wed, 12 Mar 2003 10:29:04 -0800

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

---

From: "James Kempf" <[email-masked]>
Date: Wed, 12 Mar 2003 10:29:04 -0800

jak