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

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

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

---

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

Hi Hmenat,

	If we mean "all", we should say "all". If we don't mean
"all", we should not say "all".

	We don't say "all". So we don't mean "all".

	Keep it simple.

	Sure, if I say:
		"There are black cats there",

	I could also say
		"There are black cats there. There may also be
other colours of cats. Or all the cats could be black. We don't
know today, because we have not looked yet. And tomorrow that
could change, so there could be that there are probably only
one black cats. As a matter of fact, some days ago, there was
exactly two black cats there. etc. etc. etc. ................"

	But I dont't think verbosity is the goal, I think correct
requirements are the goal.

	Isn't it fun to spend days discussing how we could change
a clearly formulated requirement to be "better" but still maybe
mean the same?

	Henrik

> -----Original Message-----
> From: Hemant Chaskar [mailto:[email-masked]]
> Sent: Wednesday, March 27, 2002 5:40 PM
> To: [email-masked]; [email-masked]

---

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

Hi Hmenat,

	Keep it simple.

	Sure, if I say:

	I could also say

	Henrik