Subject: RE: [Seamoby] Concensus call on new CAR Discovery Requirement (wa s: Examples of

From: "Govind Krishnamurthi" <[email-masked]>
Date: Wed, 27 Mar 2002 11:27:24 -0500

Thanks George!
Thats I have been  arguing against for what seems eternity.
Thanks,
Govind.
>
>So, is there anyone that seriously thinks that "blasting GAAR IDs and all 
>of
>their capabilities to MN" is a good idea? If not (which I hope so) then the
>requirements document should not imply otherwise.
>
>George
>
>-----Original Message-----
>From: Hemant Chaskar [mailto:[email-masked]]
>Sent: Wednesday, March 27, 2002 4:08 PM
>To: [email-masked]
>Subject: RE: [Seamoby] Concensus call on new CAR Discovery Requirement
>(was: Examples of CAR discovery)
>
>
>Hi Hernik:
>
>I did read your comment and responded as follows in my earlier email.
>Cut'n'Paste:
>
>-------------------------------
>If we honestly think that the requirement does not oblige AR to blast all
>GAAR IDs and all of their capabilities to MN, why not say so clearly. Why 
>do
>
>we need to hide this fact? We can come up with something else, if you do 
>not
>
>like on-demand extension. I think without such extension the solution
>satisfying this requirement may have serious shortcomings that I described
>in my other email to James.
>--------------------------------
>
>BR,
>Hemant
>
>
> >From: "Henrik Levkowetz" <[email-masked]>
> >To: "Hemant Chaskar" <[email-masked]>
> >Subject: RE: [Seamoby] Concensus call on new CAR Discovery Requirement
> >(was: Examples of CAR discovery)
> >Date: Wed, 27 Mar 2002 02:09:44 +0100
> >
> >Hemant,
> >
> >	You apparently did not read my recent posting. Cut'n'Paste:
> >
> >	No, the requirement is just fine. It does not require *all* GAAR
> >information, it does not require *on-demand operation*, it expresses
> >exactly
> >what we are in a position to say about the matter now:
> >
> >	The CAR discovery protocol MUST provide the MN with GAAR
> >	information, along with capabilities.
> >
> >
> >	I think that's the essence of it. Do you oppose this? Why? Do you
> >want to make things more complicated than they have to be?
> >
> >	Henrik
> >
> >Hemant wrote:
> > >
> > > Hi James:
> > >
> > > There are serious shortcomings of the solution satisfying this
> >requirement.
> > > They are described below. How can we finalise this requirement unless 
>it
>
> >is
> > > agreed that these pitfalls do not exist?
> > >
> > > For this, it might be good idea to visualise how the solution 
>satisfying
> > > this requirement looks like and violates basic tenets of engineering
> >design,
> > > namely efficiency. The solution satisfying this requirement is obliged
> >to
> > > blast GAAR IDs and their capabilities on MN when AR sees MN. This 
>might
> >be a
> > > big chunk of data (= number of GAARs times capability set of each). 
>This
> > > flood will occur either on active traffic connection which I call case
> >(i)
> > > (relevant for single interface MN and two-interface MN where second
> > > interface is sleeping) or on second interface which I call case (ii)
> > > (relevant for two interface MN with both interfaces awake). There are
> > > following effects of this flood:
> > >
> > > 1. Disruption in traffic: For case (i), it causes disruption in 
>traffic
> >over
> > > active traffic channel.
> > >
> > > 2. Power wastage: For both cases (i) and (ii), receiving this flood
> >causes
> > > power wastage. This is because, after receiving these capabilities MN
> >either
> > > rejects the new AR (which is worst), and even if it selcects one why
> >does it
> > > need to receive capabilities of GAARs that do not matter for it.
> > >
> > > 3. Bandwidth wastage: An AR needs to send this flood to every MN that 
>it
> > > sees. Which means the same information (which could be big enough) is
> > > transmitted on downlink so many times. This takes up considerable
> >fraction
> > > of downlink capacity.
> > >
> > > 4. Limit on capability definition: This requirement restricts the
> >definition
> > > of capabilities to a very small size, otherwise all ARs will only be
> > > transmitting GAAR capabilities to different MNs all the time. This 
>means
> > > capability set cannot be comprehensive and extensible.
> > >
> > > So, IMHO rather than counting who agrees to one statement requirement
> >that
> > > you proposed and who have not, we should first analyse above harmful
> >effects
> > > before deciding either way.
> > >
> > > Br,
> > > Hemant
> > >
> > >
> > > >From: "James Kempf" <[email-masked]>
> > > >To: "Govind Krishnamurthi" <[email-masked]>, <[email-masked]>
> > > >Subject: [Seamoby] Concensus call on new CAR Discovery Requirement
> >(was:
> > > >Examples of CAR discovery)
> > > >Date: Tue, 26 Mar 2002 15:40:36 -0800
> > > >
> > > >,
> > > > > So now you agree that the AR can hand over the list of GAARs and
> > > > > their capabilities to the MN (maybe only pass on those which 
>satisfy
> > > > > the MN requirements, which is what CAR discovery was originally
> > > >about).
> > > > >
> > > >
> > > >No, that it sends all, along with the capabilities. Let me repeat the
> > > >requirement I would like to see (and Henrik apparently agrees) so we
> >are
> > > >clear on this:
> > > >
> > > >     The CAR discovery protocol MUST provide the MN with GAAR
> > > >     information, along with capabilities.
> > > >
> > > >
> > > > > Which first implies that the network is taking care of CAR
> >discovery.
> > > > > This seems contradictory to your earlier mails saying that there 
>is
> > > > > no basis for network based CAR discovery. So are you now agreeing
> > > > > that network based CAR discovery has its place?
> > > > >
> > > >
> > > >Please see the requirement above. No contradiction. The protocol 
>allows
> > > >the MN to discover  the GAAR and capabilities, the MN decides which 
>one
> > > >it wants.
> > > >Nothing about the AR in control of anything. The MN may use a variant
> >of
> > > >IPv6 neighbor discovery, the AR may be involved somehow, but that's a
> > > >protocol design, not a requirement, choice. The requirement is 
>clearly
> > > >that the MN does the discovery.
> > > >
> > > >We now have two working group members who want this reqirement worded
> > > >just this way. Nothing about "as the MN expresses its preferences" or
> > > >"by the CAR discovery module" or anything else. And I believe Hesham
> >has
> > > >also expressed a preference for this requirement.
> > > >
> > > >Anybody else out there have an opinion on this? Should we include 
>this
> > > >requirement instead of requirement 3.4, which has the AR in control?
> > > >
> > > >             jak
> > > >
> > > >
> > > >_______________________________________________
> > > >Seamoby mailing list
> > > >[email-masked]
> > > >https://www1.ietf.org/mailman/listinfo/seamoby
> > >
> > >
> > > _________________________________________________________________
> > > MSN Photos is the easiest way to share and print your photos:
> > > http://photos.msn.com/support/worldwide.aspx
> > >
> > >
> > > _______________________________________________
> > > Seamoby mailing list
> > > [email-masked]
> > > https://www1.ietf.org/mailman/listinfo/seamoby
>
>
>_________________________________________________________________
>Join the world's largest e-mail service with MSN Hotmail.
>http://www.hotmail.com
>
>
>_______________________________________________
>Seamoby mailing list
>[email-masked]
>https://www1.ietf.org/mailman/listinfo/seamoby
>
>_______________________________________________
>Seamoby mailing list
>[email-masked]
>https://www1.ietf.org/mailman/listinfo/seamoby

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

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

---

From: "Govind Krishnamurthi" <[email-masked]>
Date: Wed, 27 Mar 2002 11:27:24 -0500

Thanks George!

---

From: "Govind Krishnamurthi" <[email-masked]>
Date: Wed, 27 Mar 2002 11:53:53 -0500

Hi Hesham,
Without knowing how many different GAARs are available (see Henriks mail 
about N interfaces) without knowing what the capabilities are I don't
understand how you have come to the conclusion that the pushing
the GAARs (all of them + their capabilities) to the MN is not blasting.
All we ask is the MN has an option to say no to this. Aren't you removing 
the MN's right not to want to proces this kind of information
by saying that GAARs and their capabilities MUST be sent over to the MN?

Govind.
>
>What is iths blöasting that people keep
>bringing up? an extra option in an RA is blasting ????
>What is the alternative: The magic AR that knows
>everything ??????????????
>
>Seriously, let's keep it simple or this whole
>protocol will start collapsing the moment
>anyone starts deploying it. Of course if deployment
>is not a concern then I'll just og back to sleep!
>
>Hesham
>
>   > From: George Tsirtsis [mailto:[email-masked]]
>   > Sent: Wednesday, March 27, 2002 5:21 PM
>   > To: 'Hemant Chaskar'; [email-masked]
>   > (wa s: Examples of CAR discovery)
>   >
>   >
>   > So, is there anyone that seriously thinks that "blasting
>   > GAAR IDs and all of
>   > GAAR IDs and all of their capabilities to MN, why not say
>   > so clearly. Why do
>   >
>   > we need to hide this fact? We can come up with something
>   > else, if you do not
>   >
>   > > > They are described below. How can we finalise this
>   > requirement unless it
>   >
>   > >is
>   > > > For this, it might be good idea to visualise how the
>   > solution satisfying
>   > > > blast GAAR IDs and their capabilities on MN when AR
>   > sees MN. This might
>   > >be a
>   > > > big chunk of data (= number of GAARs times capability
>   > set of each). This
>   > > > 1. Disruption in traffic: For case (i), it causes
>   > disruption in traffic
>   > >over
>   > > > active traffic channel.
>   > > >
>   > > > 3. Bandwidth wastage: An AR needs to send this flood to
>   > every MN that it
>   > > > transmitting GAAR capabilities to different MNs all the
>   > time. This means
>   > > > > > their capabilities to the MN (maybe only pass on
>   > those which satisfy
>   > > > > > This seems contradictory to your earlier mails
>   > saying that there is
>   > > > >Please see the requirement above. No contradiction.
>   > The protocol allows
>   > > > >the MN to discover  the GAAR and capabilities, the MN
>   > decides which one
>   > > > >it wants.
>   > > > >protocol design, not a requirement, choice. The
>   > requirement is clearly
>   > > > >Anybody else out there have an opinion on this? Should
>   > we include this

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

---

From: "Govind Krishnamurthi" <[email-masked]>
Date: Wed, 27 Mar 2002 11:53:53 -0500

Hi Hesham,

Govind.

---

From: "Hesham Soliman (ERA)" <[email-masked]>
Date: Wed, 27 Mar 2002 17:55:56 +0100

> the GAARs (all of them + their capabilities) to the MN is 

=> Because I'm narrowing the scope of AR-based
CAR to a couple of neighbouring routers within
the same domain and the access technology. 
This is as far as it should go IMHO.
That is, if you expect it to be seriously
deployed.

Hesham

---

From: "Hesham Soliman (ERA)" <[email-masked]>
Date: Wed, 27 Mar 2002 17:55:56 +0100

Hesham

---

From: "Govind Krishnamurthi" <[email-masked]>
Date: Wed, 27 Mar 2002 12:51:03 -0500

Hesham,

>   > GT> Personally i do not own or have any cellular deployment so it is
>   > certainly not mine :-) But seriously, how does it work in
>   > cdma? what I said
>   > probably applies to tdma systems I guess?
>
>=> Well, the only difference is that the AR coverage
>area includes several APs, so it's very unlikely
>that you would end up with 6 GAARs in the same
>technology.

[Govind] Well one example could be in a  large mall or airport
wherein you have
different APs connected to different providers (at least three of them can 
be in a vicinity according to the 802.11 spec). Second, the number
of different APs gets multiplied by the number of interface cards the
MN has.

Also a question, even if the APs belong to the same AR. Could you verify 
that just by looking at the L2 beacon or do you have to connect to them 
first and then to the associated AR first to determine that?

---

From: "Govind Krishnamurthi" <[email-masked]>
Date: Wed, 27 Mar 2002 12:51:03 -0500

Hesham,

---

From: "Hesham Soliman (ERA)" <[email-masked]>
Date: Wed, 27 Mar 2002 19:00:53 +0100

> of different APs gets multiplied by the number of interface 

=> As I said, limit it to one operator. None of these issues
will come up. I mean do you really believe that 
operators will give each other cost information ?
Or do you believe that they will continuously update
each other so honestly ? 

  > first and then to the associated AR first to determine that?

=> That's an interesting point. One thing you could
do is solicit. The RTT for this is about 4 ms on WLAN. 
Another way is that there are options in 802.11
to include the network identity as part of the 
beacon. So there are different ways of handling it.

Hesham

---

From: "Hesham Soliman (ERA)" <[email-masked]>
Date: Wed, 27 Mar 2002 19:00:53 +0100

Hesham

---

From: "Hemant Chaskar" <[email-masked]>
Date: Wed, 27 Mar 2002 18:00:38

Hi Hesham:

Then that has to be there in requirements too.

"CAR discovery solution MAY not consider more that two APs".

Isn't it. What is the problem in not explicitly stating in the requirements 
what the requirements are about.

Hemant

>From: "Hesham Soliman (ERA)" <[email-masked]>
>To: "'Govind Krishnamurthi'" <[email-masked]>,        "Hesham Soliman 
>(ERA)"  <[email-masked]>,        [email-masked]
>Subject: RE: [Seamoby] Concensus call on new CAR Discovery Requirement (wa  
>s: Examples of
>Date: Wed, 27 Mar 2002 17:55:56 +0100
>

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

---

From: "Hemant Chaskar" <[email-masked]>
Date: Wed, 27 Mar 2002 18:00:38

Hi Hesham:

Hemant

---

From: "Hesham Soliman (ERA)" <[email-masked]>
Date: Wed, 27 Mar 2002 19:05:54 +0100

Hemant,

  > "CAR discovery solution MAY not consider more that two APs".

=> This is why I prefer talking face to face !
So if the MN has 3 interfaces and listens to
ARs anyway then we should disallow that?
There are 2 problems here:

- You assume CAR discovery == AR looking for
GAARs, I think this is only one part of CAR
discovery. This is why we're having this 
discussion. There is a clear problem in the 
understanding of what CAR discovery means.

- I always said, limit it to the same operator
and the same access technology. I didn't say
one or two. I said it is unlikely to get more 
than two if you apply the limitation above. 
I might be wrong and more than happy to hear
that, but the discussion seems to be going towards
picking words rather than picking technical reasons. 

Hesham

---

From: "Hesham Soliman (ERA)" <[email-masked]>
Date: Wed, 27 Mar 2002 19:05:54 +0100

Hemant,

Hesham

---

From: "Govind Krishnamurthi" <[email-masked]>
Date: Wed, 27 Mar 2002 13:10:30 -0500

Hesham,

>picking words rather than picking technical reasons.

[Govind] Well this is new. Iam curious :)
Intertechnology part is a MUST and it was deemed an
uncontroversial requirement in MPLS and put towards the end
of the presentation as this requirement did not raise ANY
discussion prior to MPLS and even prior to today.
If you had an objection
always, why did you not raise any objection at MPLS? Nor
did you raise any in our quite extensive discussions in GPRS to WLAN
handovers.

Regards,
Govind.

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

---

From: "Govind Krishnamurthi" <[email-masked]>
Date: Wed, 27 Mar 2002 13:20:56 -0500

Hesham,
>each other so honestly?

[Govind] If it is in the MN's profile to do such a handover when it is
possible (the MN could have negotiated a deal with the other operator
before) then I think we can enforce it cant we? But cost is just
one issue, there are others which I pointed out in my earlier mail.

>beacon. So there are different ways of handling it.

[Govind] But to solicit you have to be connected to the other one,
and hence disconnect from the first one. Essentially this has
to be done for every AP right. And if each one of them is connected
to different ones. Also, does RTT depend on exactly where the AR is located 
or this is an upper limit that you mention?
Thanks,
Govind.

---

From: "Govind Krishnamurthi" <[email-masked]>
Date: Wed, 27 Mar 2002 13:20:56 -0500

Hesham,

---

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

Govind,

I was saying that the MN can do the CAR
in the intertechnology case because it 
is extremely trivial. If routers advertise
their capabilities and the MN has the interface
it doesn't need some other AR to tell it 
that there is a GGSN nearby does it?

What I think should be limited is my GGSN/PDSN/AR
looking for the AR in Starbucks. I really think
it's unreasonable since the MN will know it 
anyway.

I hope this clarifies my comment. 

Hesham

---

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

Govind,

Hesham

---

From: "Govind Krishnamurthi" <[email-masked]>
Date: Wed, 27 Mar 2002 12:26:02 -0500

>=> I think I wasn't too clear. In the anticipated
>mode, the assumption I make is that the triggers
>are at the AR, so the AR will do the discovery
>and forward the info to the MN. Just like
>the Prrtradv is FMIPv6.
>This is the problem with calling it anticipated,
>it gives the impression that anticipated must
>be network controlled. which is not the case
>of course.
>
>GT> What you are saying is that CAR discovery can be network controlled but
>the actual handoff may be MN controlled? In which case this is a bit weird
>in that the network knows exactly what the MN is going to do next but lets
>the MN do it...hmm anyway, I do not have a problem with that although I do
>not like it either.

[Govind]
CAR discovery does not know where the MN will actually handover to
TAR selection knows that. Yes, the TAR selection algorithm could
potentially choose from the CARs but it needn't too. Example:
the case wherein the MN forces a handover to a particular AP (this can
be done again either in the network or the MN)whose association is with say 
AR1 and AR1 not currently recognized as a GAAR by the CAR discovery process.

Hope this makes it clear.
-Govind.

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

---

From: "Govind Krishnamurthi" <[email-masked]>
Date: Wed, 27 Mar 2002 12:26:02 -0500

[Govind]

---

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

> one issue, there are others which I pointed out in my earlier mail.

=> Well I still anxously await the contents of 
this profile and how it is transferred. Also
why do you think that the capabilities will
change sooo often but the profile won't ?

  > to different ones.

=> As I said there are 2 options, RSs or use the 
network id in the beacon. If you're uncomfortable
with the (roughly) 20 - 30  ms delay to dicover a 
GAAR, then you can use the information in the 
beacon.

 Also, does RTT depend on exactly where 
  > the AR is located 

=> People don't usually put APs in the airport
and the AR in the city (in the WLAN case), so the 
RS RTT time will not vary that much. 

Hesham

---

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

Hesham

---

From: "Govind Krishnamurthi" <[email-masked]>
Date: Wed, 27 Mar 2002 13:37:38 -0500

Hesham,
Thanks for the clarification.
>that there is a GGSN nearby does it?

[Govind] Ofcourse, this assumes that the MN may have to connect
to each and every AP in the neighborhood and solicit.
This is fine with me.
>it's unreasonable since the MN will know it

[Govind] I totally agree that an extensive search process like what
you propose may include extensive searches over multiple
domains, which is quite infeasible.
But there may be other ways in which the MN and AR can
cooperate and help in such situations too, is it not?

All I want the requirement to allow is for people to explore such
cooperation if possible in solutions. I just want
requirements should be too restrictive. Is that acceptible to you?
Ofcourse you may always have the choice to reject it if some
one comes up with solutions that make too many impractical assumptions.
But why should we say no now before we know what solutions are possible.
Just my opinion thats all.

Regards,
-Govind

---

From: "Govind Krishnamurthi" <[email-masked]>
Date: Wed, 27 Mar 2002 13:37:38 -0500

Hesham,

Regards,
-Govind

---

From: "Hesham Soliman (ERA)" <[email-masked]>
Date: Wed, 27 Mar 2002 19:51:21 +0100

> to each and every AP in the neighborhood and solicit.

=> Just to extra clarify, in the intertechnology
case there is a separate interface per technology.
So this is done in parallel.

  > cooperate and help in such situations too, is it not?

=> i'm sure there are ways, but why? If there is 
a GAAR the MN will hear it, if it can't then it's
not relevant for the search. Isn't this nice and 
simple?
But I'm sure there can be more ways of doing it,
I just want the simplest one.

  > requirements should be too restrictive. Is that acceptible to you?

=> On a very high level, this statement is fine.
Right now the requirements are restrictive, but 
I think we agreed on that and you said you'll
update it.

  > one comes up with solutions that make too many impractical 

=> That's my concern, so if we think it's impractical
now, I'm not sure if it's woth allowing it.

  > Just my opinion thats all.

=> It might help if you give us some hints towards
a simple solution for this. 

Hesham

---

From: "Hesham Soliman (ERA)" <[email-masked]>
Date: Wed, 27 Mar 2002 19:51:21 +0100

Hesham

---

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

>So this is done in parallel.

[Govind] But within each interface you have to do this anyways if
you have multiple APs for each interface.
>I just want the simplest one.

[Govind] Yes whether something is simple or not comes from looking
at the solution right?
>I think we agreed on that and you said you'll

[Govind] Thanks.

>now, I'm not sure if it's woth allowing it.

[Govind] We don't know whether it is impractical unless people start
going into their proposed solutions in detail. Are we willing to go
into that direction right now?

---

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

[Govind] Thanks.

---

From: [email-masked]
Date: Wed, 27 Mar 2002 14:54:47 -0500

Hesham,

[DOT] The simplest solution is not only the one that has 
a simple RA extension. If the solution involves exchange
of data that is in large parts not necessary, then another
solution with more messages but less traffic might be better,
in particular over wireless interfaces. But again, which one
is the simplest (regarding several measures such as complexity
and efficiency) can be assessed once the solutions are there.

Dirk

---

From: [email-masked]
Date: Wed, 27 Mar 2002 14:54:47 -0500

Hesham,

Dirk