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: [email-masked]
Date: Wed, 27 Mar 2002 10:54:16 -0500

Hi James,

[DOT] Can you explain to me where requirement 3.4 states that AR is in control?
You should realize that the expression of requirements to do the job of CAR
discovery is simply necessary to do the matching. Even if the MN is doing 
the matching, you still needs means to express requirements.

Regards,

Dirk

---

From: [email-masked]
Date: Wed, 27 Mar 2002 10:55:54 -0500

Hi Henrik,

	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?

[DOT] Avoiding flooding of MN with unnecessary information might complicate
the design but might also be a worthwhile goal of a protocol design?

Dirk

---

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

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:
>
>	Henrik
>Hemant wrote:

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

---

From: [email-masked]
Date: Wed, 27 Mar 2002 11:27:36 -0500

Hi James,

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

[DOT] So it is not premature to enable transfer of data of which we don't 
know what it is about and how much it is? The "optimization" you're refering
to restricts possible flooding, in particular since we are at a premature
state of knowing what information is to be transferred. Hence, what I want to 
avoid is having a premature decision of transfering a bunch of data that might 
be worthless in large parts. I don't understand why this is a bad idea?

Dirk

---

From: [email-masked]
Date: Wed, 27 Mar 2002 11:27:36 -0500

Hi James,

Dirk

---

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

James:

And formulating a generic requirement without studying its performance 
impact on all possible cases is even worse, IMHO.

I explicitly make my "disagreement" known over this requirement in its 
current form, in case you are counting votes. It needs some extension.

At least this one:

"The impact of this on power, wireless bandwidth and mobile terminal's 
interface capabilities MUST be considered".

BR,
Hemant

>To: "Hemant Chaskar" <[email-masked]>, <[email-masked]>
>Subject: Re: [Seamoby] Concensus call on new CAR Discovery Requirement 
>Date: Wed, 27 Mar 2002 08:20:02 -0800
>
>Hemant,
>
>----- 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

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

---

From: [email-masked]
Date: Wed, 27 Mar 2002 10:48:23 -0500

Hi all,

just to have another opinion on record. 

Firstly, I disagree with keeping the requirement in the current wording. Hemant
already pointed out the major flaw of this requirement, namely the 
pushing of unnecessary information to the MN. James comment about
"keeping it simple" neglects a simple fact. It is not about making it
more complicated (how, just by adding "if required"???), it is about 
avoiding unnecessary flooding and therefore wasting power of the MN for
receiving information it does not need or, even worse, does not want.

Secondly, I even stronger disagree with REPLACING requirement 3.4 with
this requirement, even in a re-worded manner. Requirement 3.4 deals with
a different problem, namely the expression of MN requirements. Even though
some people apparently think that this involves complicated AAA transactions
(let's simply see what the solutions will bring), it just actually says that
you need ANY means to express what the MN's requirements are. This is even
important in an MN-based case, which could be realized in a simple user interface
or something else. The proposed requirement though deals with information provision.
Even if you get the information at the MN, you still need means to express your
requirements so that you can do the match from GAARs to CARs.

Regards,

Dirk

-----Original Message-----
From: ext Henrik Levkowetz [mailto:[email-masked]]
Sent: Tuesday, March 26, 2002 8:10 PM
To: [email-masked]
Subject: RE: [Seamoby] Concensus call on new CAR Discovery Requirement

Hemant,

	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:

	Henrik

---

From: [email-masked]
Date: Wed, 27 Mar 2002 11:45:02 -0500

Henrik,

	We seem not to be communicating here. You snipped out the part of
my posting where I point out that this requirement does *not* imply that
the MN needs to bee flooded, and then you point out that to avoid flooding
might be worthwile.

	The point I was trying to make here was:
					This requirement 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 am starting to wonder why people protest and debate this requirement
so much, even when it seems to allow for all variations that people have
advocated, exactly as it stands?

	Henrik

[DOT] apart from the greetings I left the mail now unchanged. What I don't understand is,
if we are so much in line that it is not required to send ALL GAAR information, why is it
so controversial to state this explicitly? Apparently, the current text is controversial among
a set of people to the extent that it might be interpreted that you have to send ALL GAARs+capa
to the MN. Because of this controversial interpretation, the requirement should be changed in a way 
that it is not anymore. So if we agreed that not ALL GAAR information needs to be transferred, we would
make a step forward. But I still see a disagreement even in this discussion. But if we agreed, 
we should put that in a wording that reflects it properly and makes the requirement non-controversial 
in its understanding to someone who wants to design the protocol.

Dirk

---

From: [email-masked]
Date: Wed, 27 Mar 2002 11:52:38 -0500

Hemant,

	The requirement as first proposed does not imply that *all*
GAAR information must be sent. The requirement as first proposed also
does not require that a filtering mechanism must be part of the solution.

The revised requirement requires a filtering mechanism. I do not believe
we know that this is the right way to go yet. Therefore I do not believe
that it is good to add this restriction.

[DOT] I don't understand why it makes filtering mandatory. If the final
solution requires to send ALL information to the MN, the filtering ("as required")
is simply not present, since all data is required (which makes filtering unnecessary). 
But if we figure out that sending all the stuff to the MN shouldn't be done, the "as required"
option avoids a mandatory transfer of this data.

Dirk

---

From: [email-masked]
Date: Wed, 27 Mar 2002 11:52:38 -0500

Hemant,

Dirk

---

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

Hi Hernik:

If we do not know, we should say "we do not know". I have difficulty putting 
in MUST requirement about which we do not know for sure. If it means that 
all GAARs and all their capabilities need not be sent, it must say so.

Hemant

>From: "Henrik Levkowetz" <[email-masked]>
>Date: Wed, 27 Mar 2002 17:43:46 +0100
>
>Hemant,
>
> > > > They are described below. How can we finalise this requirement 
>unless it
> > >is
> > > > 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
> > > > flood will occur either on active traffic connection which I call 
>case
> > >(i)
> > > > 1. Disruption in traffic: For case (i), it causes disruption in 
>traffic
> > >over
> > > > active traffic channel.
> > > >
> > > > power wastage. This is because, after receiving these capabilities 
>MN
> > >either
> > > > So, IMHO rather than counting who agrees to one statement 
>requirement
> > >that
> > > > >requirement I would like to see (and Henrik apparently agrees) so 
>we
> > >are
> > > > >clear on this:
> > > > >
> > > > >Nothing about the AR in control of anything. The MN may use a 
>variant
> > >of
> > > > >"by the CAR discovery module" or anything else. And I believe 
>Hesham
> > >has

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

---

From: [email-masked]
Date: Wed, 27 Mar 2002 13:04:26 -0500

James,

And I pointed out the flaw in Hemant's argument: premature optimization.
The requirements are supposed to say what the protocol will do, not
specify it in detail. We need a strong statement that it is MN centered.
Later, there may be need for optimization, but if we put the
optimization in up front, we constrain the solution too much or open it
up to nonviable solutions.

[DOT] Assume we had a requirement saying that GAAR+capa must be sent to MN. This is a strong
requirement (MUST) without knowing what's the amount of said data. Personally believing that it is
not that much is not enough to justify this. Maybe, you have more clearer idea of the
data we're talking about. Then please share it with the WG. 

[DOT] All I'm saying is that there must a possibility for the MN to say which information
it wants to receive to avoid a mandatory transmission of data that might be unnecessary
in large parts. If we had this addition, it would be still be MN-centered (it is the MN that
says what to receive). And it does not restrict, since if the MN decides to receive
everything, it can still say so. So it contains actually the original requirement (ALL
information) plus it mandates possibilities for the MN to restrict the information
it wants to receive. So I don't see why this constrains the solution? And I wouldn't call
it opening up to nonviable solution, when I raise the concern that there should be the
possibility for the MN to restrict information delivery, in particular in a stage where
we actually don't know how the data looks like.

I also have a hard time buying that there will be sooo much GAAR
information. We are not talking about a complete list of the NASDAQ
here, just whatever routers happen to be in the vicinity.

[DOT] I can buy nothing from guessing, James. As long as we didn't really study
what are the capabilities, what is the format, what are the scenarios, I'd like
to see transmission of said data to the MN being able to limit BY THE MN. That's
what I'm asking for.

Dirk

---

From: [email-masked]
Date: Wed, 27 Mar 2002 13:16:47 -0500

Hi James,

Here's the requirement:

    The other fundamental function of CAR discovery protocols is that of
    identifying the capabilities of GAARs. The protocol MUST provide
    functionality to allow ARs to discover their GAAR's capabilities.
These
    capabilities MUST be communicated in a secure fashion.

[DOT] Sorry, I mixed up some numbers, you're right with this one. But this addresses
another problem, and Govind already sent this to list, namely to remove certain
AR-biased wordings. The above requirement is entirely possible without mentioning
the AR, and I assumed after Govind's comment that this will happen in the revised
version. But even if you did this, you still need means to express MN's requirements
in the sense I described. That was my point. 

Dirk

---

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

> If this is such a big issue then why not a simple 
  > requirement that says
  > the protocol should make optimal use of network bandwidth, with no
  > wording in it about whether the network or MN is in control?

=> Exactly!

Hesham

---

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

=> Exactly!

Hesham

---

From: [email-masked]
Date: Wed, 27 Mar 2002 13:23:07 -0500

James,

> the design but might also be a worthwhile goal of a protocol design?

If this is such a big issue then why not a simple requirement that says
the protocol should make optimal use of network bandwidth, with no
wording in it about whether the network or MN is in control?

[DOT] What is "optimal use"? If we demanded for sending all information to
MNs, then the optimal use would be bounded to maybe compressing the content, but
the optimal use would not consider sending unwanted information if another
requirement demanded it, right?

Dirk

---

From: [email-masked]
Date: Wed, 27 Mar 2002 13:04:26 -0500

James,

Dirk

---

From: [email-masked]
Date: Thu, 28 Mar 2002 10:22:48 +0200

Hi James,

A small suggestion on the requirement

> requirement I would like to see (and Henrik apparently 
> agrees) so we are clear on this:
> 

See the text between the *'s:

     The CAR discovery protocol MUST *be able to provide* the MN with GAAR
     information, along with capabilities.

I think this might make the requirement acceptable to all parties.

John