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

---

From: "Henrik Levkowetz" <[email-masked]>
Date: Wed, 27 Mar 2002 17:43:46 +0100

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.

	Henrik

---

From: "Henrik Levkowetz" <[email-masked]>
Date: Wed, 27 Mar 2002 17:43:46 +0100

Hemant,

	Henrik