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

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
(was: Examples of CAR discovery)

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

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

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

---

From: "James Kempf" <[email-masked]>
Date: Wed, 27 Mar 2002 09:51:16 -0800

Dirk,

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.

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.

            jak

---

From: "James Kempf" <[email-masked]>
Date: Wed, 27 Mar 2002 09:51:16 -0800

Dirk,

            jak