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

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

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

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.

 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. 

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. 

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

---

From: Daichi Funato <[email-masked]>
Date: Wed, 12 Mar 2003 17:51:26 -0800

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

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?

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: Daichi Funato <[email-masked]>
Date: Wed, 12 Mar 2003 17:51:26 -0800

Hi Hemant,

Regards,
Daichi

---

From: "Xiaoming Wang" <[email-masked]>
Date: Fri, 14 Mar 2003 10:48:15 +0900

please find the inline comment.

> #Surrounds,    #ARs,       #TotalEdges(CARs)
[xiaoming] I think this can be improved by static configuration at the
initial stage. Initial data can be computed with the geographical and
topological information of access network, which is used during the network
planning and construction stage. Based on it, learning-based approach will
not experience failure at the initial stage and will learn by itself
dynamically when there is a change of the topology of the access network,
and thus performs well at any time.

xiaoming

---

From: "Xiaoming Wang" <[email-masked]>
Date: Fri, 14 Mar 2003 10:48:15 +0900

xiaoming

---

From: "James Kempf" <[email-masked]>
Date: Thu, 13 Mar 2003 20:26:18 -0800

Xiaoming,

> and thus performs well at any time.

Where does the router get the static information from?

            jak

---

From: "James Kempf" <[email-masked]>
Date: Thu, 13 Mar 2003 20:26:18 -0800

Xiaoming,

            jak

---

From: "Xiaoming Wang" <[email-masked]>
Date: Fri, 14 Mar 2003 13:49:49 +0900

James,

> Where does the router get the static information from?

These static information can be defined as profile for configuation, which
can be maitained by management entity. It is as natural as initial
configuration of routing table from some predefined information.

xiaoming

---

From: "Xiaoming Wang" <[email-masked]>
Date: Fri, 14 Mar 2003 13:49:49 +0900

James,

xiaoming

---

From: "Dirk Trossen" <[email-masked]>
Date: Fri, 14 Mar 2003 08:11:23 -0500

Hi Xiaoming,

-----Original Message-----
From: [email-masked] [mailto:[email-masked]]On Behalf
Of
ext Xiaoming Wang
Sent: Thursday, March 13, 2003 8:48 PM
To: Daichi Funato; [email-masked]
Subject: RE: [SeaMoby] Topic #2:Do we need a server for CARD

[xiaoming] I think this can be improved by static configuration at the
initial stage. Initial data can be computed with the geographical and
topological information of access network, which is used during the
network
planning and construction stage. Based on it, learning-based approach
will
not experience failure at the initial stage and will learn by itself
dynamically when there is a change of the topology of the access
network,
and thus performs well at any time.

xiaoming

[DOT] We never assumed this, since as I explained also to James, we
did not assume an operator knowledge and configuration of the ARs
regarding the exact overlapping coverage areas. This is even more
important since dycard always targetted intra- as well as inter-domain
CAR. Even though we want to make the latter case forgotten by defining
it out of scope, we have to keep in mind that the learning works for
inter-domain as well.

[DOT] However, if we assumed such knowledge and pre-configuration of
the routers by the operator, we could at least have a certain initial
state for the domain (in inter-domain, entries could still be missing)
as you explained, if we downloaded the appropriate information as
cache entries to the ARs during booting.

Dirk

---

From: "Dirk Trossen" <[email-masked]>
Date: Fri, 14 Mar 2003 08:11:23 -0500

Hi Xiaoming,

-----Original Message-----

xiaoming

Dirk

---

From: "Eunsoo Shim" <[email-masked]>
Date: Fri, 14 Mar 2003 11:40:05 -0800

So far, what I heard about the necessity of the server for CARD were two
things:
1) Initial population of the cache
2) AP authorization

1) Initial population of the cache
There are lots of arguments about whether we really need such initial
population of the cache. Personally I doubt the need.
Anyway, as Xiaoming and other folks already pointed out, if it is really
necessary, such initial population can be done using any existing management
tool. We don't need to reinvent the wheel for initial router configuration.
That is, we don't need to introduce any server or protocol for that.

2) AP authorization
AP authorization is a very general problem. I think this should be handled
separately from CARD. How AP should be authorized is a L2 issue and thus is
not even in the scope of the IETF. We cannot devise a general protocol based
on IP for AP-AR since such communication depends on the L2 technology and we
cannot assume IP between AP and AR. What we can do is we assume each AR
knows the list of APs associated with it. Such information can be configured
at each AR also using any existing management tool.  Thus again, I don't
think we need to introduce the server of the DT draft for this purpose
either.

Was there any other item as the necessity of the server for CARD?
Or does anyone want to propose anything else?

Eunsoo

----- Original Message -----
From: "Xiaoming Wang" <[email-masked]>
To: "James Kempf" <[email-masked]>; "Daichi Funato"
<[email-masked]>; <[email-masked]>
Sent: Thursday, March 13, 2003 8:49 PM
Subject: RE: [SeaMoby] Topic #2:Do we need a server for CARD

---

From: "Eunsoo Shim" <[email-masked]>
Date: Fri, 14 Mar 2003 11:40:05 -0800

2) AP authorization

Eunsoo

---

From: "James Kempf" <[email-masked]>
Date: Fri, 14 Mar 2003 10:00:21 -0800

Eunsoo,

So as I understand your argument:

1) How the cache gets filled is irrelevent to the router to node CARD,
2) How the router authorizes what is an authorized GAAP or not is irrelevent to
the router to node CARD.

Is that right? If so, I accept your argument.

Furthermore, I would add:

3) How a router determines what is and is not an *authorized* GAAP is intimately
intertwined with what is or is not a GAAP, since a GAAP that is not on the AAPL
MUST not be used by the router. This will differ depending on the deployment
situation. For example, in my home network, I want to be able to use a Web page
to configure the routers with a list of authorized GAAPs, and not have to use a
server *or* not have to deal with PNE messages flying around my network. On the
other hand, operators like Docomo want to have easy centralized managment of
many APs and ARs, so a server. Enterprise networks might want to have easy self
configuration, so Dycard's PNE messages. Like Xiaoming said, the configuration
information can come from anywhere.

This suggests splitting the protocol into to separate parts:

1) A router to node protocol that provides an MN with CARD information and
allows the MN to report potential GAAPs,
2) Configuration and validation of authorized GAAPs.

How 2) is done can be the subject of a separate specification. This is the point
of Issue 2, Proposal 2, but perhaps we should separate this out into a different
issue.

            jak

----- Original Message -----
From: "Eunsoo Shim" <[email-masked]>
To: "Xiaoming Wang" <[email-masked]>; "James Kempf"
<[email-masked]>; "Daichi Funato" <[email-masked]>;
<[email-masked]>
Sent: Friday, March 14, 2003 11:40 AM
Subject: Re: [SeaMoby] Topic #2:Do we need a server for CARD

---

From: "James Kempf" <[email-masked]>
Date: Fri, 14 Mar 2003 10:00:21 -0800

Eunsoo,

            jak

---

From: "Eunsoo Shim" <[email-masked]>
Date: Sat, 15 Mar 2003 09:07:07 -0800

James,

I think you are distinguishing two things clearly: discovering GAAP/GAAR and
checking authorization of AP/AR.
Authorizing an AP/AR as a GAAP/GAAR does not make a sense because GAAP is
not identified in advance. It is what the protocol should discover. So we
can only say an AP/AR is authorized to participate in the CARD protocol or
the discovery process.
One of the main functionalities of the CARD protocol is to discover
GAAP/GAAR and that is what we have to focus on at this moment.

How to check an AP/AR is authorized to participate in the CARD protocol can
be separated from CARD since it is a kind of general authorization problem.
It is almost the same problem with what is in the IP routing protocol. So we
can take a look at existing solutions and can take one.

Please notice that node<->router protocol has two aspects: discovery process
and information distribution process.
For the discovery process, we are seeing that we need interaction between
router and MN and between router and router in Dycard. Also the server
approach requires interaction between router and MN and between router and
the server. So simply separating communication between router and MN and
between router and router is not appropriate.

Anyway, it seems you agree that we don't need the server for CARD. Am I
right?

Eunsoo

----- Original Message -----
From: "James Kempf" <[email-masked]>
To: "Eunsoo Shim" <[email-masked]>; "Xiaoming Wang"
<[email-masked]>; "Daichi Funato" <[email-masked]>;
<[email-masked]>
Sent: Friday, March 14, 2003 10:00 AM
Subject: Re: [SeaMoby] Topic #2:Do we need a server for CARD

---

From: "Eunsoo Shim" <[email-masked]>
Date: Sat, 15 Mar 2003 09:07:07 -0800

James,

Eunsoo

---

From: "Eunsoo Shim" <[email-masked]>
Date: Sat, 15 Mar 2003 09:40:10 -0800

Below I missed one word "NOT". To clarify the meaning, please let me copy
the text with "NOT".

> James,
>
> I think you are NOT distinguishing two things clearly: discovering
GAAP/GAAR and

----- Original Message -----
From: "Eunsoo Shim" <[email-masked]>
To: "James Kempf" <[email-masked]>; "Xiaoming Wang"
<[email-masked]>; "Daichi Funato" <[email-masked]>;
<[email-masked]>
Sent: Saturday, March 15, 2003 9:07 AM
Subject: Re: [SeaMoby] Topic #2:Do we need a server for CARD

> > intertwined with what is or is not a GAAP, since a GAAP that is not on
the
> AAPL
> > situation. For example, in my home network, I want to be able to use a
Web
> page
> > to configure the routers with a list of authorized GAAPs, and not have
to
> use a
> > other hand, operators like Docomo want to have easy centralized
managment
> of
> > many APs and ARs, so a server. Enterprise networks might want to have
easy
> self
> > How 2) is done can be the subject of a separate specification. This is
the
> point
> > > separately from CARD. How AP should be authorized is a L2 issue and
thus
> is
> > > > > > [xiaoming] I think this can be improved by static configuration
at
> the
> > > > > > initial stage. Initial data can be computed with the
geographical
> and

---

From: "Eunsoo Shim" <[email-masked]>
Date: Sat, 15 Mar 2003 09:40:10 -0800

GAAP/GAAR and

----- Original Message -----
From: "Eunsoo Shim" <[email-masked]>
To: "James Kempf" <[email-masked]>; "Xiaoming Wang"

the
Web
to
managment
easy
the
thus
at
geographical

---

From: "James Kempf" <[email-masked]>
Date: Sat, 15 Mar 2003 13:02:53 -0800

> can only say an AP/AR is authorized to participate in the CARD protocol or

The two are distinct, but they are not disconnected. That is, before an AP can
even be considered as a GAAP, it must be authorized. Thus, checking whether an
AP is authorized is a prerequesite for determining if it is a GAAP.

> can take a look at existing solutions and can take one.

The problem is that there are currently *no* existing solutions to dynamically
determining whether an AP is authorized. Since our goal is to enable
autoconfiguration, there's a problem. CARD is dependent on something that
doesn't exist.

Static configuration of the AAPL is always possible, of course. But, at that
point, one must ask why not also statically configure the information on
geographical adjacency? If a new AP is added, the authorization list must be
changed anyway, so the geographical adjacency information could be added too. So
a fully statically configured back end is one possibility.

At the next level, one could just statically configure the authorization list,
and have the geographical check be dynamic, presumably because the geographical
information was harder to configure. But I am somewhat skeptical of this.

The next level is fully dynamic autoconfiguration for both authorization and
geographical check. This is, of course, the ideal.

> between router and router is not appropriate.

I think separating it might make it easier to fit CARD onto the existing
handover protocol work, which is my primary concern. There is too much
duplication currently in both drafts of protocol that FMIP and ND provide.

> Anyway, it seems you agree that we don't need the server for CARD. Am I

I hope at the working group meeting we can get some agreement about problems of
the server approach, how much geographical accuracy is enough, and whether we
should use a server or a router to router approach.

In either case, I think an authorization technique other than static
configuration is necessary, else why bother with autoconfiguration in the first
place? I'm sure the security ADs will insist on an authorization technique being
available.

            jak

---

From: "James Kempf" <[email-masked]>
Date: Sat, 15 Mar 2003 13:02:53 -0800

jak

---

From: "Eunsoo Shim" <[email-masked]>
Date: Sun, 16 Mar 2003 14:58:47 -0800

James,

My comments are inline.

> autoconfiguration, there's a problem. CARD is dependent on something that
As you said below, we can proceed assuming static configuration for this.
The fast handoff proposal of the MobileIP WG also proceeded without a
solution for dynamic L2-L3 mapping. As we wee, that problem can be solved
independently of the rest of the fast handoff proposal.

> a fully statically configured back end is one possibility.
[eunsoo] As I said below, it is rarely practical to use geographical
information in general situations. Do you know exact coverage of an 802.11
AP in your officie building? Also it is affected by the environment which
may change without your notice.

> information was harder to configure. But I am somewhat skeptical of this.

[eunsoo] I remember that you said using geographical information for CARD
was not practical. Now you say differently.
I think your previous opinion is correct. It is not practical in many
situations.
Just configuring whether an AP connected to an AR is authorized is not such
a difficult job at all. It is clear to the admin from the beginning when he
connected the AP to the AR.

> duplication currently in both drafts of protocol that FMIP and ND provide.

[eunsoo] You cannot rely on something that is not fixed yet. Mixing two
things while both are under change will make any decision very difficult.
Once two things are fixed, then we can think about possible merge scenario
or adjustment. It is not an ideal situation but it is what we have today.

> should use a server or a router to router approach.

[eunsoo] Can you please confirm my understanding or answer my question in
the above?

Eunsoo

---

From: "Eunsoo Shim" <[email-masked]>
Date: Sun, 16 Mar 2003 14:58:47 -0800

James,

My comments are inline.

Eunsoo

---

From: "James Kempf" <[email-masked]>
Date: Sun, 16 Mar 2003 20:01:50 -0800

> connected the AP to the AR.

Sorry, I meant the IP address to AP L2 id mapping for neighboring subnets. I was
not talking about GPS co-ordinates, or something like that. Suppose I have a
small office with two or three subnets, with maybe 6 AP per subnet. Seems like
it would be simple enough to log into each router and configure.

But scaling this up to an enterprise level or ISP is where the problems occur.

> or adjustment. It is not an ideal situation but it is what we have today.

But we want to end up with one thing on the front end, not two. So the issue is
how to make that work. With PrxyRtAdv/PrxyRtAdvSol moved away from handover in
FMIP, it now serves essentially the same function as CARD's front end, except
that it doesn't provide all the functionality. I think it might make sense to
define the necessary functionality for CARD in that context, to avoid having
duplication.

> [eunsoo] Can you please confirm my understanding or answer my question in

The working group has the final decision. I want to have the advantages and
disadvantages of both on the table, in a clear and objective way, so that people
who are not invested in either approach can express an opinion. At that point,
Pat and I will judge concensus.

                jak

---

From: "James Kempf" <[email-masked]>
Date: Sun, 16 Mar 2003 20:01:50 -0800

jak