Subject: Re: [Seamoby] Concensus call on new CAR Discovery Requirement (was: Examples of CAR discovery)

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

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

---

From: "Henrik Levkowetz" <[email-masked]>
Date: Wed, 27 Mar 2002 02:10:14 +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:

	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

---

From: "Henrik Levkowetz" <[email-masked]>
Date: Wed, 27 Mar 2002 02:10:14 +0100

Hemant,

	Henrik

---

From: "Eunsoo Shim" <[email-masked]>
Date: Wed, 27 Mar 2002 18:01:28 -0800

Hi, I hope I am not too late for this thread of discussion.
My comments are inline.
Thanks.

Eunsoo
----- Original Message -----
From: "Henrik Levkowetz" <[email-masked]>
To: <[email-masked]>
Sent: Tuesday, March 26, 2002 5:10 PM
Subject: RE: [Seamoby] Concensus call on new CAR Discovery Requirement (was:

> information, along with capabilities.

[eunsoo] I think the difference here is whether the AR MUST provide the MN
with GAAR information along with capabilities REGARDLESS of what the MN
wants. That is, even if the MN does not have CAR discovery stack in its
kernel, the AR will send the MN the GAAR information. As Govind pointed out,
if the transmitted information is large, we may not be happy if the
transmitted information could be reduced. Right, it is about efficiency and
thus optimization. Certainly optimization is not a bad thing. James
expressed his concern that premature optimization may put more trouble down
the road. Right. Also we might want to change the protocol pretty shortly
after the spec is set and tried because of its obvious inefficiency, if any.
Which is not desirable either.
I'd like to suggest we discuss what could be the undesirable side-effects of
the optimization. If they are obvious, the issue becomes easier. If not, I
am not sure it is good just trashing an obvious optimization idea from the
beginning because it is about optimization. I don't think we should not
focus on optimization of every details from the beginning. But I think it is
good if we can leave a room for optimization if possible.

And about being MN-centric.
I am not sure whether the MN's expressing its requirements is NOT
MN-centric. One may say the AR may not understand the requirements very
well. Right. I think we need better implementation in such a case. Regarding
how an AR knows which interfaces are available with a MN, certainly that
information should be provided by the MN to the AR. Is the job complex? It
seems subjective to me. I think we can design at least a not-too-complex way
doing it.

GAAR->CAR is a filtering operation. Some folks say the MN should do TAR
selection and thus the MN should do GAAR->CAR filtering. If some folks say
ONLY the MN should be able to do GAAR->CAR->TAR filtering, I am not sure
whether it is a technical argument or somewhat philosophical one. Couldn't
we open a room for other cases? If not, why not? Let say, a network provider
runs a WWAN and a WLAN and she wants to control load on each access network.
Thus the network wants to be able to recommend a TAR to the MN. Is it a bad
thing?

BTW, even the above requirement does not prohibit the network from getting
involved in handoff decision or selecting the TAR. It depends on really the
handoff mechanism. I understood that the CAR discovery protocol should NOT
be bound to any specific mobility management scheme. I think now some folks
are trying to put constraints on CAR discovery based on a certain picture of
mobility management scheme.

Last thing:
I think CAR discovery consists of two tasks: GAAR discovery and GAAR->CAR
filtering.
In a larger picture, we have the following tasks for handoff decision:
    a. GAAR discovery
    b. distribution of GAAR information (with capabilities) or accessing the
information
    c. GAAR -> CAR filtering
    d. distribution of CAR information or accessing the information
    e. CAR -> TAR filtering
It seems that we all agree that CAR->TAR filtering is out of scope of the
CAR discovery protoocol. But some folks have an idea about where CAR->TAR
filtering should happen and thus they want to pur constraints on
"distribution of CAR information of access the information" or other
previous steps.
I have two questions: what are in scope of the CAR discovery protocol among
a, b, c, and d in the above?
Then what are the assumptions we agree on about those tasks out of scope of
the protocol such as e in the above? Or should we have such agreements?

Thanks.

Eunsoo

1) Is it undesirable

---

From: "Eunsoo Shim" <[email-masked]>
Date: Wed, 27 Mar 2002 18:01:28 -0800

Eunsoo
----- Original Message -----
From: "Henrik Levkowetz" <[email-masked]>
To: <[email-masked]>
Sent: Tuesday, March 26, 2002 5:10 PM
Subject: RE: [Seamoby] Concensus call on new CAR Discovery Requirement (was:

Last thing:

Thanks.

Eunsoo

1) Is it undesirable

---

From: "James Kempf" <[email-masked]>
Date: Wed, 27 Mar 2002 08:20:02 -0800

Hemant,

Like I said, premature optimization is always a bad idea.

            jak

----- Original Message -----
From: "Hemant Chaskar" <[email-masked]>
To: <[email-masked]>
Sent: Wednesday, March 27, 2002 12:40 AM
Subject: Re: [Seamoby] Concensus call on new CAR Discovery Requirement
(was: Examples of CAR discovery)

---

From: "James Kempf" <[email-masked]>
Date: Wed, 27 Mar 2002 08:20:02 -0800

Hemant,

            jak