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

>From: "James Kempf" <[email-masked]>
>To: "Hemant Chaskar" <[email-masked]>, <[email-masked]>
>Subject: Re: [Seamoby] Concensus call on new CAR Discovery Requirement 
>(was: Examples of CAR discovery)
>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)
>
>
> > 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
> >
>

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

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

---

From: "James Kempf" <[email-masked]>
Date: Wed, 27 Mar 2002 10:26:49 -0800

Hemant,

This is too radio specific. What about IR, where there may be no power
considerations?

How about:

    The CAR discovery protocol MUST make efficient use of network
bandwidth, particularly on the wireless link.

            jak

---

From: "James Kempf" <[email-masked]>
Date: Wed, 27 Mar 2002 10:26:49 -0800

Hemant,

How about:

            jak