Subject: RE: [seamoby] I-D ACTION:draft-hamid-seamoby-ct-fwk-00.txt

From: "Hamid Syed" <[email-masked]>
Date: Thu, 7 Jun 2001 14:59:03 -0400

Hello Rajeev,

see my comments below.

cheers

-Hamid
> -----Original Message-----
> From:	Rajeev Koodli [SMTP:[email-masked]]
> Sent:	Thursday, June 07, 2001 2:03 PM
> To:	Syed, Hamid [WDLN2:AN22:EXCH]
> Cc:	'Charles E. Perkins'; Kenward, Gary [WDLN2:AN10:EXCH]; Seamless
> Mobility Working Group
> Subject:	Re: [seamoby] I-D ACTION:draft-hamid-seamoby-ct-fwk-00.txt
> 
> 
> Hello Hamid,
> 
> some comments below.
> 
> Regards,
> 
> -Rajeev
> 
> 
> Hamid Syed wrote:
> 
> >
> >
> > Hello Charlie,
> >
> > I am glad that you read the draft. Please see my comments below.
> >
> >      -----Original Message-----
> >      From:   Charles E. Perkins [SMTP:[email-masked]]
> >      Sent:   Wednesday, June 06, 2001 1:39 PM
> >      To:     Syed, Hamid [WDLN2:AN22:EXCH]
> >      Cc:     Kenward, Gary [WDLN2:AN10:EXCH]; Seamless Mobility
> >      Working Group
> >      Subject:        Re: [seamoby] I-D
> >      ACTION:draft-hamid-seamoby-ct-fwk-00.txt
> >
> >      Hello Hamid,
> >
> >      We previously published a framework document for consideration
> >      within [seamoby].  Our emphasis was on context feature
> >      classification
> >      and message flows.  Your document (which I reckon is to be
> >      considered
> >      an individual submission) does not have much about feature
> >      classfication, and at first glance seems to be a lot more
> >      emphasis
> >      on groupings of access routers.
> >      [Syed, Hamid [WDLN2:AN22:EXCH]]  I disagree. Infact the draft
> >      attempts to cover a broader range of the over all problem. We do
> >      not believe that just shipping the context from one access router
> >      to another can provide a "seamless"
> >
> "Shipping" contexts (some folks call it transferring contexts BTW) is an
> integral part of the Context Transfer Protocol. Indeed, you need to know
> the target router, which is a separate protocol/mechanism. Once you do
> know the target router, I guess you would be interested in transferring
> contexts in CT. It seems intuitively obvious to do CT along with
> handovers.
	[Syed, Hamid [WDLN2:AN22:EXCH]]  I agree that handoff candidate
discovery could be done through a separate protocol (and btw that is what
our framework is suggesting) but I disagree isolating the two problems or
making assumptions about their interworking. How the other protocol would
work with any context transfer protocol?. which entity would determine or
enable a suitable candidate discovery?. what are the related triggers or
events?. All this is the part of context transfer problem domain and we
cannot deny it. Any framework for context transfer must address all the
issues. We cannot go making assupmtions about phenomenon that are closely
realted to the context transfer. 

> >      handover. Identifying the potential context candidates and a
> >      close interworking with the mobility mechanism are equally
> >      important to be addressed in the context transfer framework. Our
> >      draft is focused on distributing the functional roles to the ct
> >      entities and defining interfaces between them. The context
> >      transfer protocol is only one
> >
> 
> In the CT problem statement draft, we have identified the entities: AR,
> AP, MN, MH
	[Syed, Hamid [WDLN2:AN22:EXCH]]  Well..i do not disagree but AR is a
an entity that contains more than one function in it (see the definition of
AR). While our framework identifies the entities that are specific to
context transfer and actively participates in the context transfer process.

> >      aspect of the over all problem domain and that is what your draft
> >      is proposing, a solution for shipping context from one AR to the
> >      other. I may consider your submission as a candidate solution for
> >      context trasnfer protocol but this is not a framework. I believe
> >      that frameworks should focus on functional models and interface
> >      definitions and the details of individual protocols must be taken
> >      ouitside the framework document.
> >
> 
> By interface defintions do you mean protocol messages ? Or do you have
> 3G interfaces in mind ?
	[Syed, Hamid [WDLN2:AN22:EXCH]]  IETF protocols. which are
definitely interfaces between entities.

> >
> >
> >      I would like to suggest that establishing communities or
> >      neighborhoods
> >      or groups of access routers could be handled by a protocol which
> >      would
> >      be separate than the protocol for doing the context transfer, and
> >
> >      further that in many instances it wouldn't be necessary to make
> >      the
> >      access router groups at all.
> >      [Syed, Hamid [WDLN2:AN22:EXCH]]   This is what the framework has
> >      captured, a separate protocol for context group management and
> >      another protocol for context transfer. I would say, identifying a
> >      suitable candidate for handover amongst the context group members
> >      will help minimizing the service disruption during handover.
> >      Defining a handover candidate discovery protocol is already part
> >      of Seamoby WG charter and our framework shows how the functional
> >      entities interact with each other through the standard
> >      interfaces.
> >
> >
> >
> You are right that target router discovery is part of seamoby work. We
> all have our views on how this would work with CT. Once we have that
> work (target router selection) done, we will be able to better relate to
> it. Until then, I think it suffices to say that some seamoby entity
> provides us the target router address.
	[Syed, Hamid [WDLN2:AN22:EXCH]]  Again..why try solving problems by
making assumptions about the important details. Why not work on a framework
that covers all the problem areas with no assumptions. Try a high level
design first and then go for individual protocol definition. I do not
understand the need for a shortcut approach.

> >
> >      I wondered whether you had taken a look at our previous framework
> >
> >      draft, and if so whether you think meet the requirements.  If you
> >
> >      didn't see it yet, and if you'd like to take a look, here is the
> >      URL:
> >
> >
> http://search.ietf.org/internet-drafts/draft-koodli-seamoby-ctv6-00.txt
> >
> >      Regards,
> >      Charlie P.
> >      [Syed, Hamid [WDLN2:AN22:EXCH]]  Thanx for your comments.
> >
> >      > Hamid Syed wrote:
> >      >
> >      > Hello CT Folks,
> >      >
> >      > I have submitted a framework draft for context transfer. I
> >      would appreciate
> >      > and welcome any comments on the draft.
> >      >
> >      > A URL for this Internet-Draft is:
> >      >
> >
> http://www.ietf.org/internet-drafts/draft-hamid-seamoby-ct-fwk-00.txt
> >
> >      >
> >      > cheers
> >      >
> >      > -Hamid
> >
>

---

From: Rajeev Koodli <[email-masked]>
Date: Thu, 07 Jun 2001 19:55:46 -0700

Hamid Syed wrote:

>      discovery could be done through a separate protocol (and btw that
>      is what our framework is suggesting) but I disagree isolating the
>      two problems or making assumptions about their interworking. How
>      the other protocol would work with any context transfer
>      protocol?. which entity would determine or enable a suitable
>      candidate discovery?. what are the related triggers or events?.
>      All this is the part of context transfer problem domain and we
>      cannot deny it. Any framework for context transfer must address
>      all the issues. We cannot go making assupmtions about phenomenon
>      that are closely realted to the context transfer.
>
>
>

Well, I don't deny that there are problems to consider in target router
selection. Indeed, because the space is open and yet unknown, we cannot
go into speculation. That's the point. The CT protocol work can continue
without having to speculate on target router selection. I hope you would
agree.

>      [Syed, Hamid [WDLN2:AN22:EXCH]]  Well..i do not disagree but AR
>      is a an entity that contains more than one function in it (see
>      the definition of AR). While our framework identifies the
>      entities that are specific to context transfer and actively
>      participates in the context transfer process.
>

I guess I don't have the same terminology as you do. I cannot think of a
protocol as an interface between two entities (which BTW sounds lot like
the 3G jargon). To me, a protocol is an understanding (formal rules)
between communicating peers, whereas an interface is a boundary between
two entities.
[this is purely academic, but has some value to clear confusion in the
future]

>      [Syed, Hamid [WDLN2:AN22:EXCH]]  Again..why try solving problems
>      by making assumptions about the important details. Why not work
>      on a framework that covers all the problem areas with no
>      assumptions. Try a high level design first and then go for
>      individual protocol definition. I do not understand the need for
>      a shortcut approach.
>
>
>

Why create a complex problem space when you can work on modular problems
? When there is better visibility, things will unfold.

Regards,

-Rajeev