Subject: [Seamoby] Comments on the requirements draft

From: Teemu Rinta-aho <[email-masked]>
Date: Fri, 22 Mar 2002 18:56:12 +0200 (EET)

Hi all,

I am new to this group but I got interested in
the draft-krishnamurthi-seamoby-car-requirements-01.txt
and decided to send in some comments.

I read through the mailing list archive and tried
to catch up with what's been going on lately in
this group so I am not sure how valuable or valid these 
comments are, but I think they might be of some use.

I have formatted the comments in some kind of
sections. It is not ready text to put directly
into draft but hopefully easier to read at this
point. Numbers 3.X mean they are suggestions
for new possible sections.

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.

3.X SECURITY

- CAR discovery protocol MUST NOT weaken network security.
  DoS, hijacking and other possible attacks must be taken
  into account when designing the protocol.

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.

3.X INTEROPERABILITY

- Interoperability MUST exist with non-CAR ARs.

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.

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.

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]

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

---

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

Hi Teemu,

see comments inline.

[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

[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

[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

[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:

[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

---

From: "Hemant Chaskar" <[email-masked]>
Date: Sun, 24 Mar 2002 20:40:57

Hi James:

Some comments inline:

>From: "James Kempf" <[email-masked]>
>To: <[email-masked]>, <[email-masked]>,        
><[email-masked]>
>Subject: Re: [Seamoby] Comments on the requirements draft
>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.

[HC] I agree that MN's requirements MUST always be considered during CAR 
discovery. I guess, that is why we have a requirement that: "MN's 
requirements MUST be made available to CAR discovery protocol." CAR 
discovery is about "comparing MN's requirements with capabilities of GAAR to 
identify CARs." As said in problem statement, CAR discovery does not make 
any decisions about handoffs or target access routers. It simply identifies 
CARs from GAARs by comparing MN's requirements with GAAR capabilities. 
Decisions are made by TAR selection which may reside in MN or in network or 
in both of them. TAR selection is outside the scope of CAR discovery. But 
the following additional requirement may help "Output of CAR discovery MUST 
be available for TAR selection algorithms wherever they are implemented (MN, 
network or hybrid)."

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

[HC] How will MN receive information over interface that is down? It has to 
receive trigger over another interface to first wake up the sleeping 
interface.

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

[HC]Even when other interface is awake, the capability discovery via Router 
Discovery is not always efficient and it is also time and power consuming. 
For this, MN needs to acquire link layer connectivity, then IP-layer 
connectivity and then receive capabilities over the new connection. You have 
to do this for every AP beacon that you hear. While MN is doing that its old 
connection may actually go down (moving into basement of building from 
cellular coverage) thereby causing disruption of service. Also, if the new 
access router does not meet MN's requirements, all this capability discovery 
effort (and associated power spent) goes waste. These can be avoided by 
doing AR_current-assisted CAR discovery while still considering MN's 
requirements.

BR,
Hemant

>
>             jak
>
>----- Original Message -----
>From: <[email-masked]>
>To: <[email-masked]>; <[email-masked]>
>Sent: Friday, March 22, 2002 11:55 AM
>Subject: RE: [Seamoby] Comments on the requirements draft
>
>
> > Hi Teemu,
> >
> > see comments inline.
> >
> >

_________________________________________________________________
Join the world’s largest e-mail service with MSN Hotmail. 
http://www.hotmail.com

---

From: "Govind Krishnamurthi" <[email-masked]>
Date: Mon, 25 Mar 2002 11:44:49 -0500

Hello Teemu,
My comments inline. Thanks for your comments.

Regards,
Govind.

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

[Govind] I agree
with your point. But I don't understand what interaction are you thinking 
about in your statement. As an example if an AR gets a message
from another AR that it is the former's GAAR. What should the former AR
do if it does not understand CAR discovery. The point that you raise
though important deals with handover decisions and is out of scope of CAR 
discovery right?

_________________________________________________________________
MSN Photos is the easiest way to share and print your photos: 
http://photos.msn.com/support/worldwide.aspx

---

From: "Govind Krishnamurthi" <[email-masked]>
Date: Mon, 25 Mar 2002 11:44:49 -0500

Hello Teemu,

Regards,
Govind.

[Govind] I agree

---

From: "Govind Krishnamurthi" <[email-masked]>
Date: Mon, 25 Mar 2002 12:32:10 -0500

James,

>It doesn't get info over a down interface, it gets it over the up
>interface. The protocol tells the MN what's available, including if the
>MN brought up the down interface. It avoids having to bring up the
>interface if there is nothing there.

[Govind] Agreed.
>
>If the interface is always up, then the MN can just do standard IPv6
>Neighbor Discovery and there is no need for CAR discovery.
>
> > >

[Govind] Again, this is possible, essentially what you are saying here
is explained in Example 2. But the fact is that if there are many such
APs then the process in Example 2 is expensive both in time as well
as bandwidth efficiency as well as power as pointed in my earlier mail.
[snip]

>CAR discovery is completely irrelevent if the MN brings up the
>interface. Neighbor Discovery is fine for discovering routers - the MN
>solicits router adverts, the routers send them. What's the problem?
>
>The only reason for CAR discovery is so that the MN doesn't need to
>bring up the interface to discover what's available. The sooner we can
>agree on that, the sooner we can get to the hard questions, like how to
>do it.

[Govind] I disagree. Again please see my previous answers.
I agree completely that we need
to get to the actual protocol designing process soon. But I don't
agree with your premise in the previous paragraph at all.

Regards,
Govind.

_________________________________________________________________
Send and receive Hotmail on your mobile device: http://mobile.msn.com

---

From: "Hemant Chaskar" <[email-masked]>
Date: Mon, 25 Mar 2002 17:34:19

Hi Teemu and James:

Just to be ultra clear - Luxury of two interfaces is not a generic 
assumption for CAR discovery problem formulation. Two-connection WLAN card 
is good for 2 APs, but what if there are 3 or 4 or 5 APs.

- Hemant

>To: "Teemu Rinta-aho" <[email-masked]>
>CC: <[email-masked]>
>Date: Mon, 25 Mar 2002 08:54:45 -0800
>
>
> > 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?
> >
>
>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: "Govind Krishnamurthi" <[email-masked]>
Date: Mon, 25 Mar 2002 12:45:20 -0500

Just to add to Hemant's comment. Having a twin connection WLAN card does
not imply that none of the problems described earlier, namely power issues, 
bandwidth issues and time issues, cease to exist.

Regards,
Govind.

---

From: "Govind Krishnamurthi" <[email-masked]>
Date: Mon, 25 Mar 2002 12:45:20 -0500

Regards,
Govind.

---

From: "Govind Krishnamurthi" <[email-masked]>
Date: Mon, 25 Mar 2002 17:23:29 -0500

>I don't understand this. If the MN's power is up for it getting a
>beacon, it presumably brought the interface up that far because it wants
>to use it. What's the bandwidth and power consideration?
>
>The harder case is how the MN finds out that it should bring up the
>interface in the first place.

[Govind]  Yes, it wants to use it. But it does not to waste power on CAR 
discovery and choosing among a plethora of beacons. Exactly my point.
If the MN is going to use it to connect to a beacon, get RtAdv, get 
capabilities etc and then reject it because it does not fit its profile
isn't there a wastage of bandwidth and power?

>Please explain.
>You seem to think the problem lies in finding an AR when the MN has
>already brought up an interface. I'm saying that that problem is already
>solved by IPv6 router discovery.
>
>I think the problem lies in the MN finding out that there is another
>wireless technology available, so that it can bring up the interface far
>enough to get the beacon.

[Govind] I think the main miscommunication here is that you say when
this interface is up it is connected to an AP and thats it. In my world,
when the interface is up it is scanning for possible APs and trying to
decide which one to connect to, but not actually connected to one. I agree 
that once L2 layer connectivity is established you can use standard router 
discovery. No argument there. But the only point I'm tryng to make rather 
unsuccessfully here so far is that the correct way to go MAY not be to 
accept the first L2 connection. However, if your
earlier point is true that only one WLAN AP can be found then we don't
have an argument as I agree CAR discovery is not of much use there, except 
probably to indicate to the MN that sticking with the other interface is 
better, in the event that the new AR does not have the
requisite capabilities.
>
>That and doing reverse address translation for router/access point L2
>identifiers to IP addresses.

Regards,
Govind.

_________________________________________________________________
Get your FREE download of MSN Explorer at http://explorer.msn.com/intl.asp.

---

From: [email-masked]
Date: Tue, 26 Mar 2002 08:18:25 -0500

Hi Teemu,

some comments inline...

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

[DOT] Yes, but it should be kept in mind that we don't have to design a 
protocol for picocells here since there might be better mechanisms. But again,
as I said, what counts are overlapping APs of different ARs. In most
of the cases of small picocells, I either assume many APs connected to
one AR (hence the overlapping APs of different ARs is rather small)
and/or APs with a small coverage area anyway (e.g., Bluetooth). It all
comes to the point if tens or even hundreds of APs of different ARs, overlapping a dedicated physical area is very likely. That's what I
doubt. But again, it has to scale to some extent, I agree.

[DOT] Remember, CAR discovery only determines a set of CARs,
it does not imply a certain handover decision. CAR discovery is only one of
maybe several inputs in the final decision, which is BTW called
TAR selection (and is defined out of scope for this work).
If your TAR selection, and therefore the handover algorithm, only relies 
on this set of CARs and totally neglects ARs that are not provided through 
CAR (since they do not implement the protocol), then the responsibility for 
that lies in your TAR selectio, not in the CAR discovery.  Hence,
it is the TAR selection that needs attention when considering
'non-CAR-compliant' ARs.

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

I agree.

[DOT] Does the agreement mean that we shouldn't consider this requirement
for CAR discovery, since it is related to TAR selection? 

Thanks,

Dirk

---

From: "Hemant Chaskar" <[email-masked]>
Date: Tue, 26 Mar 2002 17:37:14

Hi:

I think the main discussion issue that resulted in this email was:

What is the cost of scanning APs on other connection (this involves link 
establishment, authentication as you said, obtaining IP address, receiving 
capabilities). Note that, all this work (and associated power) will be 
wasted if the user does not like the capabilites at the end of day. Please 
let us know if you think this to be a relevant consideration at all.

Please ignore my comment about 3 or more APs.

Hemant

>From: "Michael A. Ramalho" <[email-masked]>
>To: "James Kempf" <[email-masked]>,        "Hemant Chaskar" 
><[email-masked]>, <[email-masked]>
>Date: Tue, 26 Mar 2002 11:14:13 -0500
>
>At 01:59 PM 3/25/2002 -0800, James Kempf wrote:
>
>This may sound like a stupid statement for some .... but even a single
>WLAN card can scan during periods of (relative) inactivity to search for
>beacons of other APs.
>
>Given this ability/possibility (depends on how the drivers were written),
>one would assume that two cards are more than enough to search
>for the (next) highest signal quality AP it can authenticate (or get
>required QoS) on. Thus while maintaining an existing session
>on one card  - you try to authenticate on the next best AP (in some
>sense, perhaps S/N, SSI, etc). Note that a "two association" SINGLE
>WLAN card may be possible in the future with "fast-retunable" WLAN
>cards - but it is clearly doable today with two cards. You only need
>to define heuristics for your MNs (e.g., default routes, etc.) to send
>the packets to/from the preferred association.
>
>So ... why exactly doesn't the two WLAN card case handle an
>arbitrary number of potential APs?
>
>
>>Does the MN have different interface cards for each or are they the
>>same?
>>
>>             jak
>>
>>
>>
>>
>Michael A. Ramalho, Ph.D.
>Office email: [email-masked]
>Personal email: [email-masked]
>Office: +1.732.449.5762
>Cell: +1.732.809.0188
>
>

---

From: "Hesham Soliman (ERA)" <[email-masked]>
Date: Wed, 27 Mar 2002 14:46:13 +0100

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

=> This is why the model needs to be revised. 
Why can't you see hundreds of coverage areas ?
Is tens better? What do you mean Bluetooth is not
large enough? It's large enough for a LAN
coverage. 
Anyhow, hundreds doesn't imply a 100 different 
technologies. Shops, houses, cellular...etc
can all overlap. I don't think 10 or a hundred
is the point here, the point is a bookshop installing
a WLAN will not go around telling everyone about
it, why would they ??

Hesham

---

From: "Hesham Soliman (ERA)" <[email-masked]>
Date: Wed, 27 Mar 2002 14:46:13 +0100

Hesham

---

From: "Govind Krishnamurthi" <[email-masked]>
Date: Wed, 27 Mar 2002 09:48:40 -0500

Michael,
>At 05:37 PM 3/26/2002 +0000, Hemant Chaskar wrote:
>>Hi:
>>
>>capabilities).
>No. The scanning only involves "listening". *IF* you decide that the 
>candidate
>is worth pursuing, then - and only then - do you waste (the more 
>significant)
>transmit power to associate/authenticate/etc...
>
>So ... if you are on an AP with strong S/N and you hear 4 other
>candidate APs that have poor S/N ... you will probably do nothing
>terribly power consuming .... perhaps a re-scan with relatively
>long inter-scan times. If the S/N is tanking on the link you are
>using ... then you may want to look harder (scan more
>often) ... and even try to associate with other APs before the
>one you are on dies.

[Govind] Michael, I believe the assumption that you are making is
that the SIR is the only criteria to attach get the capabilities etc.
That might not be the only criteria. We want to make sure that the
MN attaches to the right AR and not AP. The capabilities of the AR
are not transmitted in the L2 beacon. Though I agree with you
that scanning does not imply connecting. I was proposing a similar
scheme too. But the only difference being the MN does not connect to
the AP based on the SIR alone.

>
>>Note that, all this work (and associated power) will be wasted if the user
>>does not like the capabilites at the end of day.
>
>The heuristics driving the above decisions is simply an optimization
>problem that trades off the availability/seamlessness of your connection
>with the (optimization-based) "cost" of the extra power consumption. 
>Different
>strokes for different folks .... and thus another reason for the MN to 
>decide.

[Michael] Exactly, and thats why the MN should be able to decide
whether it wants to hear the capabilities or NOT and the statement
CAR Discovery MUST inform the MN of GAARs and their capabilities seems
to push the capabilities to the MN irrespective of whether the MN wants or 
not. I agree that if a particular solution needs this sure the requirements 
shouldn't prevent it. But if a particular solution does
not want it then the requirements must be flexible to do that too.
Saying that lets pump all the information to the MN and then the MN
can decide to use it or not is clearly a waste of time bandwidth and power.

Regards,
Govind.

_________________________________________________________________
Chat with friends online, try MSN Messenger: http://messenger.msn.com

---

From: "Govind Krishnamurthi" <[email-masked]>
Date: Wed, 27 Mar 2002 09:48:40 -0500

Michael,

Regards,
Govind.

---

From: "Hemant Chaskar" <[email-masked]>
Date: Wed, 27 Mar 2002 16:16:03

Hi:

We are not at all talking about scanning for strongest SNR. The assumption 
is that interface will not take further steps unless strong SNR is seen. 
There is not doubt about that.

After that however, the question is does it need to blindly go into steps of 
acquiring IP connectivity and getting capabilities to see if access router 
can offer the desired service.

Hemant

>To: "Hemant Chaskar" <[email-masked]>, [email-masked]
>Date: Tue, 26 Mar 2002 21:01:31 -0500
>
>I see very little extra power being consumed if you connection
>has relatively high S/N. Also remember that the receiver takes much
>less power than the transmitter (details vary ... but less than 1/3 of
>the total power I think is typical ... someone from a WLAN
>manufacturer, like Flarion, might want to provide a more
>precise estimate).
>
>>Please let us know if you think this to be a relevant consideration at 
>>all.
>>
>ACK
>Hope this helps,
>Michael Ramalho
>>Join the world's largest e-mail service with MSN Hotmail.
>>http://www.hotmail.com
>>
>>

---

From: "Hemant Chaskar" <[email-masked]>
Date: Wed, 27 Mar 2002 16:16:03

Hi:

Hemant