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

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

Hi Hesham:

I do not know what consensus you are talking about. There was one question 
asked which was not clearly stated, and for that too, I saw only three hands 
go up.

The requirement was posted after MPLS and there has not been any consensus 
on it yet.

What we have agreed in MPLS was "MN's requirements MUST be considered in CAR 
discovery, handoffs etc.". We all are in good agreement on that.

I don't think however that this means that it precludes executing processor 
level algorithms anywhere else than MN's processor, as long as those 
algorithms consider all MN's requirement. This is implementation-specific 
aspect.

More comments below.

Hemant

>From: "Hesham Soliman (ERA)" <[email-masked]>
>To: "'Hemant Chaskar'" <[email-masked]>,   "Hesham Soliman (ERA)"  
><[email-masked]>,   [email-masked], 
>[email-masked]
>Subject: RE: [Seamoby] Concensus call on new CAR Discovery Requirement (wa  
>s: Examples of CAR discovery)
>Date: Wed, 27 Mar 2002 17:45:52 +0100
>
>Hi Hemant,
>
>   > No RA is not what blasting is about. What this requirement
>   > is saying is to
>   > send to MN a volume of data = Number of GAARs times
>   > capability set of each.
>   > Number of GAARs itself could be large and capability set
>   > could be very large
>   > too. It might contain policies, supported IP protocols, any
>   > application
>   > specific functionality support and this set could be extensible.
>
>=> This is all based on an assumption: The scope
>of the GAAR discovery will scale to a very large number of GAARs.

[HC] What matters here is the product of number of GAARs and size of their 
capabilities". Even if you do not have large number of GAARs, capabilities 
of each one of them can be huge and extensible.

>I don't think this is realistic, and after Steve's presentation
>I thought the entire WG agreed with this.
>Why are we trying to reverse this concensus?
>
>   >
>   > Sending this volume of data to MN without any regard to
>   > whether it wants it
>   > or not is what I call blasting.
>
>=> See above.
>
>Hesham
>
>   >
>   > Hemant
>   >
>   > >From: "Hesham Soliman (ERA)" <[email-masked]>
>   > >To: "'George Tsirtsis'" <[email-masked]>,
>   > "'Hemant Chaskar'"
>   > ><[email-masked]>, [email-masked]
>   > >Subject: RE: [Seamoby] Concensus call on new CAR Discovery
>   > Requirement (wa
>   > >s: Examples of CAR discovery)
>   > >Date: Wed, 27 Mar 2002 17:32:30 +0100
>   > >
>   > >What is iths blöasting that people keep
>   > >bringing up? an extra option in an RA is blasting ????
>   > >What is the alternative: The magic AR that knows
>   > >everything ??????????????
>   > >
>   > >Seriously, let's keep it simple or this whole
>   > >protocol will start collapsing the moment
>   > >anyone starts deploying it. Of course if deployment
>   > >is not a concern then I'll just og back to sleep!
>   > >
>   > >Hesham
>   > >
>   > >   > -----Original Message-----
>   > >   > From: George Tsirtsis [mailto:[email-masked]]
>   > >   > Sent: Wednesday, March 27, 2002 5:21 PM
>   > >   > To: 'Hemant Chaskar'; [email-masked]
>   > >   > Subject: RE: [Seamoby] Concensus call on new CAR Discovery
>   > >   > Requirement
>   > >   > (wa s: Examples of CAR discovery)
>   > >   >
>   > >   >
>   > >   > So, is there anyone that seriously thinks that "blasting
>   > >   > GAAR IDs and all of
>   > >   > their capabilities to MN" is a good idea? If not (which I
>   > >   > hope so) then the
>   > >   > requirements document should not imply otherwise.
>   > >   >
>   > >   > George
>   > >   >
>   > >   > -----Original Message-----
>   > >   > From: Hemant Chaskar [mailto:[email-masked]]
>   > >   > Sent: Wednesday, March 27, 2002 4:08 PM
>   > >   > To: [email-masked]
>   > >   > Subject: RE: [Seamoby] Concensus call on new CAR Discovery
>   > >   > Requirement
>   > >   > (was: Examples of CAR discovery)
>   > >   >
>   > >   >
>   > >   > 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
>   > >   >
>   > >   > _______________________________________________
>   > >   > Seamoby mailing list
>   > >   > [email-masked]
>   > >   > https://www1.ietf.org/mailman/listinfo/seamoby
>   > >   >
>   >
>   >
>   > _________________________________________________________________
>   > Chat with friends online, try MSN Messenger:
>http://messenger.msn.com

_________________________________________________________________
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 19:15:08 +0100

> discovery, handoffs etc.". We all are in good agreement on that.

I disagree on this representation of Steve D's talk in Minneapolis. The consensus
there was much wider, and focused on the whole conceptual idea of Steve's talk.

	Henrik

---

From: "Henrik Levkowetz" <[email-masked]>
Date: Wed, 27 Mar 2002 19:15:08 +0100

Henrik