Subject: RE: [Seamoby] Comments on the requirements draft

From: [email-masked]
Date: Fri, 22 Mar 2002 14:55:41 -0500

Hi Teemu,

see comments inline.

3.5 FORMAT OF CAPABILITIES

- The format of describing the capabilities MUST be
  extendable and flexible in a way that they support
  future needs that cannot be exactly defined
  at this stage.

[DOT] in addition to this, though not a requirement as such just
recalling what I said in MPLS, we should evaluate what descriptions
are on the table (as standards/research/products), and how they could
fit into the problem space. This would prevent the re-invention of
the wheel.

3.X SCALABILITY

- CAR/GAAR discovery MUST be scalable. In the future, there
  might be geographical locations with several (hundreds) 
  of overlapping access points, especially when PANs emerge. 
  This kind of situation might lead into problems when the
  ARs behind these APs have to constantly update their
  knowledge of their GAARs.

[DOT] I certainly agree with scalability, just some comments to
the number of several hundreds of overlapping access points. Even
when I consider PANs, I can hardly think of scenarios where actually 
hundreds of coverage areas overlap. Bluetooth coverage areas are not
large enough, and I doubt that we had so many WLAN APs. But even then, 
what counts is the number of ARs that have overlapping APs with APs of 
other ARs. I don't quite see that this number would reach several hundreds. 
Maybe you could elaborate a bit on the scenarios you have in mind.

3.X INTEROPERABILITY

- Interoperability MUST exist with non-CAR ARs.

[DOT] How do you mean this? If a non-CAR is (due to the lack of identification
and capability knowledge through CAR) not considered as a CAR, it should still
be possible to handover to this AR? This is indeed true but not within the scope
of CAR discovery. Since CAR discovery only gives you a set of CARs (which need to
be identified for that), it should be ok that a CAR solution does not include 
these non-CAR ARs (one reason might be that the non-CAR AR did not allow the 
CAR solution's GAAR identifitication - another reasons might be that the non-CAR 
did not reveal capabilities). However, if the MN (or the AR) would find any other 
means to identify this non-CAR AR, and the MN (or the AR) makes the decision to 
handoff to this non-CAR AR, that's fine and still possible. But this is TAR 
selection, which is not within the scope of CAR discovery. CAR discovery only 
gives you a list of CARs (i.e., ARs that match MN's requirements), which is ONE 
input to TAR selection (wherever latter is implemented). Another input might be 
the detection of non-CAR ARs which you might consider in your TAR selection algorithm 
as well.

3.X PERFORMANCE

- CAR/GAAR protocol MUST NOT add to handover times in
  cases when the connection to the old AR is lost and there
  are ongoing communication waiting for network access. In
  those cases the MN must get a new AR as fast as possible,
  not spending much time on the TAR algorithm.

[DOT] How do decide whether it is worthwhile to spend time on CAR or not?
If you have a TAR selection scheme that resides in the MN, it is fairly
easy to do so. If your signal strength fades for instance too fast, you just
skip CAR discovery and select one of the AR from which you receive a current
beacon. But again, this is TAR selection and not within the scope of the problem.
But if you choose to do CAR (wherever it is implemented), it will always add 
to your handover time since you have to run certain mechanisms. How this tradeoff
can be determined is not clear to me and looks like an implementation issue in
the entity that runs the TAR selection (which again use CAR discovery as an input).

General thoughts:

How can an AR recognize its GAARs without the help of the MN
or the link-layer protocols?

This means that the amount of packets sent over the air necessarily
increases, doesn't it? I mean, if the AR doesn't get the information about
GAARs from the MN, then it must somehow sense the GAARs presence through
the APs. But the latter is of course impossible between APs of different
link layers.

[DOT] Good question ;-) But is it mentioned somewhere that the
identification of GAARs must not be a combined job between AR and MN? Or it
might even be entirely based in the MN? Certainly, the AR-only solution
sounds kind of impossible for me, too.

Best Regards,

Dirk

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

---

From: "James Kempf" <[email-masked]>
Date: Sat, 23 Mar 2002 20:50:00 -0800

As per SteveD's presentation in the Minne-apple, the MN must be able to
make the decision on its own, particularly for intertechnology.

The MN must also be able to get the information through any interface,
even one that is currently not up. This allows the MN to keep an
interface powered down until it knows there is an active wireless
network in the area == power savings.

If the latter were not so, the MN could just use standard Router
Discovery on the interface and there would be no need for CAR discovery.

            jak

---

From: "James Kempf" <[email-masked]>
Date: Sat, 23 Mar 2002 20:50:00 -0800

jak

---

From: Teemu Rinta-aho <[email-masked]>
Date: Mon, 25 Mar 2002 13:39:40 +0200 (EET)

> fit into the problem space. This would prevent the re-invention of

I agree.

> Maybe you could elaborate a bit on the scenarios you have in mind.

Maybe "hundreds" is too much for near future, but I 
wanted to give a what-if scenario where the protocol must
also survive if there ever is such...?

> the detection of non-CAR ARs which you might consider in your TAR selection algorithm 

I agree with your comment. I should have written my comment:

"Interoperability MUST exist with ARs not implementing the 
CAR discovery protocol". 

What I don't know is whether interoperability is an implicit 
general requirement for all protocols or should it 
be explicitly written in the requirements draft? I guess
that even if it's not in the draft nobody will probably
make a solution where an MN can only handover to ARs
which support the CAR discovery protocol... 

> the entity that runs the TAR selection (which again use CAR discovery as an input).

I agree.

> sounds kind of impossible for me, too.

I just wanted to make sure that I've done correct conclusions ;-)
Thanks for the comments!

> Dirk

BR,
Teemu

-- 
Teemu Rinta-aho                    Tel: +358 9 299 3078
NomadicLab, Ericsson Research      Fax: +358 9 299 5055
Oy L M Ericsson Ab                 Mobile: +358 40 562 3066
FIN-02131 Espoo, Finland           E-mail: [email-masked]

---

From: Teemu Rinta-aho <[email-masked]>
Date: Mon, 25 Mar 2002 13:39:40 +0200 (EET)

I agree.

I agree.

BR,
Teemu

---

From: Teemu Rinta-aho <[email-masked]>
Date: Mon, 25 Mar 2002 13:48:41 +0200 (EET)

> Discovery on the interface and there would be no need for CAR discovery.

I am not a layer 2 expert, but wouldn't that require that the interface
first does a layer 2 handover from the old access point to the new one
before anything can be done at the IP layer? And at that point all
communications going through the old AP/AR would cease... At least I don't
know any WLAN card or other L2 device that could attach to several access
points simultaneously.

I thought CAR protocol was to be useful also in cases where you have only
one interface and you want to keep track of the CARs to make fast
handovers?

BR,
Teemu

---

From: Teemu Rinta-aho <[email-masked]>
Date: Mon, 25 Mar 2002 13:48:41 +0200 (EET)

BR,
Teemu

---

From: "James Kempf" <[email-masked]>
Date: Mon, 25 Mar 2002 08:54:45 -0800

> one interface and you want to keep track of the CARs to make fast

No, the assumption in this case is that the MN has *two* interfaces, for
example, a cellular interface and a Bluetooth or WLAN interface. It
could solicit the RA on one interface while the other had a full up
connection.

In the single interface case, you are right.

        jak

PS: there is a company in Japan that has announced a WLAN card allowing
the interface to be on two channels at once. But that is not relevent to
the current discussion.

---

From: "James Kempf" <[email-masked]>
Date: Mon, 25 Mar 2002 08:54:45 -0800

jak

---

From: "James Kempf" <[email-masked]>
Date: Mon, 25 Mar 2002 11:38:45 -0800

> also survive if there ever is such...?

Well, I'm skeptical of the realism of picocellular scenarios in the
intermediate
term future.

In our lab, we have 5 802.11b access points that costed $800 a piece
when
they were originally installed (now, they would be somewhat cheaper
but not by a factor of 10). These cover the lab.

Consider a picocellular scenario in which we increase the number of
access
points by a factor of 10. In order to keep the total system cost the
same,
the per access point would cost would have to drop to $80. If the
number of access points is increased by a factor of 100 (nanocellular?)
then it's $8.

Bluetooth originally had the intention of coming in at a cost point of
pennies
for the chip set, which, when combined with the rest of what's needed
to make an access point would conceivably add up to $80 per access
point,
but the last time I looked, their chip set costs were running about the
same
as 802.11. We therefore have at least one data point of an attempt to do
a
cost-effictive picocellular network that failed.

So, I don't see picocellular networks being cost effective in the near
to intermediate term future, even given Moore's law. The infrastructure
cost would make it prohibitive. Most cellular operators are going in
the opposite direction, toward larger cells, to avoid having to pay
the infrastructure cost.

> "Interoperability MUST exist with ARs not implementing the

I don't see this as being an issue. Why would an AR not implementing
the CAR discovery protocol even care?

> which support the CAR discovery protocol...

If there are any areas where interoperability is necessary, it
should be in the requirements.

            jak

---

From: "James Kempf" <[email-masked]>
Date: Mon, 25 Mar 2002 11:38:45 -0800

jak

---

From: Teemu Rinta-aho <[email-masked]>
Date: Tue, 26 Mar 2002 12:21:34 +0200 (EET)

> Well, I'm skeptical of the realism of picocellular scenarios in the

I don't disagree with that. I just wanted to bring this
issue into discussion. It all depends on whether or not
the requirements should cover the current and intermediate
future only or the possibly quite distant future also..

---

From: Teemu Rinta-aho <[email-masked]>
Date: Tue, 26 Mar 2002 12:21:34 +0200 (EET)