Subject: RE: [seamoby] I-D ACTION:draft-hamid-seamoby-ct-qos-context-00.tx t

From: "Gary Kenward" <[email-masked]>
Date: Thu, 7 Jun 2001 14:53:09 -0400

Cedric:

  There has been an open issue about AR capability, and there
are five (at least) schools of thought:

   o One approach would rely upon a capability discovery phase to
     determine which ARs have compatible capabilities (this would
     imply some sort of information model as well as information
     distribution, maintenance and access mechanisms or protocols
     as well as a discovery protocol).

   o The second approach would rely on admission control that would
     based upon: authorization, policy decisions, resource availability,
     and AR capability.

   o The third approach would rely upon a negotiation phase during
     the ct; this would seem to slow down ct, but it may not be
     a problem for proactive ct, and the feature could be used
     for partial traffic handovers, and to downgrade service if
     resources were not available. This is an enhancement of the
     admission control approach.

   o The fourth approach relys on engineering the network so
     that the ARs are compatible (this probably won't work in an
     all-wireless network).
 
   o The fifth approach does not care: if the ct fails because the
     receiving AR could not use the context, so what? At least you
     tried ;^}.

Sorry for delving into solution space. Clearly some of these approaches
have impact on the ct requirements, and some do not. I haven't figured
out how to address all possibilities with a set of generic requirements
(other then to say that *some* mechanism must exist, which is fatuous).

Thanks,
Gary

> -----Original Message-----
> From: Cedric Westphal [mailto:[email-masked]]
> Sent: Thursday, June 07, 2001 10:37 AM
> To: Syed, Hamid [WDLN2:AN22:EXCH]
> Cc: Seamless Mobility Working Group
> Subject: Re: [seamoby] I-D
> ACTION:draft-hamid-seamoby-ct-qos-context-00.txt
> 
> 
> Hamid,
> 
> here are a couple comments on 
> draft-hamid-seamoby-ct-qos-context-00.txt.
> 
> First, I think the title 'QoS (Diffserv) Context Transfer' is somewhat
> misleading,
> 'Requirements for...' would be more appropriate.
> 
> Otherwise, I am quite confused by what you mean. About the timing
> requirement:
> why is 7.2.2 a MUST NOT and 7.2.3 a SHOULD. If you allow for 
> packets to
> go
> unaccounted, then they go unaccounted at oldAR as well as newAR?
> 
> Also, configuration context MUST be transferred before state 
> context, so
> that newAR
> can make sense of the state context.
> Also, configuration context MUST be transferred to newAR before first
> packet arrival at the newAR, so that newAR can start metering, marking
> and such even though state context
> is missing.
> 
> Now if you allow the metering to start before state context 
> has arrived,
> then you assume
> the router has the ability to merge two states (the new state at newAR
> with the old (transferred)
> state), and thus 7.2.2 should be rephrased as something like: A state
> context transfer
> MUST be sent after the last packet arrival at the oldAR.
> 
> Transport reliability section does not distinguish between state and
> config, and thus it is
> hard to know what you mean.
> 
> Now, these are details. What I am confused about is this: you make the
> assumption that
> both oldAR and newAR are DS capable routers in the same domain. Which
> means that
> first the newAR has to tell this to the oldAR. So CT becomes
> oldAR ------> newAR: request for QoS CT classification
>           <-------            : QoS CT classification: DS/same domain:
> ok, so I'll use the QoS CT
> requirements
>           ------->            : config
>           -------->          : state
> 
> which also means that a contest transfer context transfer (or meta-CT)
> has to be defined :)
> 
> In the framework document
> (http://search.ietf.org/internet-drafts/draft-koodli-seamoby-c
tv6-00.txt)
is described a
general framework to transfer QoS that does not requires a preliminary
handshake between
oldAR and newAR.

Take care,

Cedric.

---

From: James Kempf <[email-masked]>
Date: Thu, 7 Jun 2001 12:01:11 -0700 (PDT)

I'm unclear about when the AR discovery protocol is intended to operate.
Is this envisioned to occur during MN handover or is it envisioned
to occur beforehand? Also, is it intended that the protocol operate
MN to AR or AR to AR?

Depending on this, the performance characteristic could be quite
different.

		jak

>Delivered-To: [email-masked]
>From: "Gary Kenward" <[email-masked]>
>To: "'Cedric Westphal'" <[email-masked]>, "Hamid Syed" 
<[email-masked]>
>Cc: Seamless Mobility Working Group <[email-masked]>
>Subject: RE: [seamoby] I-D ACTION:draft-hamid-seamoby-ct-qos-context-00.tx t
>Date: Thu, 7 Jun 2001 14:53:09 -0400
>
>Cedric:
>

---

From: "Hamid Syed" <[email-masked]>
Date: Thu, 7 Jun 2001 15:05:33 -0400

Hello James,

Perhaps you might want to look at the scenarios at the end of the draft. It
will answer your concerns.

cheers

-Hamid

> From:	James Kempf [SMTP:[email-masked]]
> Sent:	Thursday, June 07, 2001 3:01 PM
> To:	[email-masked]; Syed, Hamid [WDLN2:AN22:EXCH]; Kenward, Gary
> [WDLN2:AN10:EXCH]
> Cc:	[email-masked]
> Subject:	RE: [seamoby] I-D
> ACTION:draft-hamid-seamoby-ct-qos-context-00.tx t
> 
> >Subject: RE: [seamoby] I-D
> ACTION:draft-hamid-seamoby-ct-qos-context-00.tx t

---

From: "Hamid Syed" <[email-masked]>
Date: Thu, 7 Jun 2001 15:15:43 -0400

hello Cedric,

Thanx for the comments. see my response below.

cheers

-Hamid

> From:	Cedric Westphal [SMTP:[email-masked]]
> here are a couple comments on draft-hamid-seamoby-ct-qos-context-00.txt.
> 
	[Syed, Hamid [WDLN2:AN22:EXCH]]  Dont disagree with you but the
draft is not only capturing requirements but identifying the Qos context
data as well.

> why is 7.2.2 a MUST NOT and 7.2.3 a SHOULD. If you allow for packets to
> go
> Also, configuration context MUST be transferred before state context, so
> that newAR
	[Syed, Hamid [WDLN2:AN22:EXCH]]  Correct. In proactive context
transfer, this is how it should be done but for reactive, I would say the
configuration context must be processed first but could be transferred at
the same time. 
> Now if you allow the metering to start before state context has arrived,
> then you assume
	[Syed, Hamid [WDLN2:AN22:EXCH]]  Again dont disagre with you here.
It just another way of presenting the requirements and may be a better way.
thanx.

> which also means that a contest transfer context transfer (or meta-CT)
	[Syed, Hamid [WDLN2:AN22:EXCH]]  I do not know how you did get this
impression. The draft is intended to capture the QoS context data and the
specific requirements. It does not say that the qos context needs a separate
transfer protocol or negotiation mechansim. infact, the transfer protocol
for all the contexts types is the same. I agree that all the feature
contexts must be transferred in a generic way. 

> (http://search.ietf.org/internet-drafts/draft-koodli-seamoby-ctv6-00.txt)
> is described a

---

From: "Gary Kenward" <[email-masked]>
Date: Thu, 7 Jun 2001 15:04:58 -0400

Yes. You are absolutely correct James.

Gary

> From: James Kempf [mailto:[email-masked]]