Subject: [Seamoby] RE: [NSIS] Establishing QoS after handoff.

From: "Gary Kenward"<[email-masked]>
Date: Fri, 5 Apr 2002 11:06:04 -0500

Hemant:

  Just a point of clarification, but as I understand CARD (and
I don't understand it well), it is not a QoS negotiation 
protocol. The main application that you are referring to primarily
arises out of a perceived need to determine at the MN the best link
layer to handover over to when inter-technology handovers are involved.
It can be applied to intra-technology handovers, but the value in
that situation is highly questionable (e.g. since it is a discovery 
protocol, the implication is that the purpose is to determine the 
choice of channels available; for intra-technology handovers, there 
are many, many reasons why this "choice" may not be available).

  There is a requirement, 5.1.2, which seems to imply NSIS involvement
during/after a handover. John has stated that this is not the intention
(please correct me if I have this wrong John), in which case I think
5.1.2 needs to be clarified. 

  Specifically, is NSIS to be used to negotiated new QoS for an 
existing flow after a handover, or is it specifically for establishing
QoS for a new flow? I don't think the answer is boolean: the role
of NSIS in QoS re-negotiation is still open, I believe, and clearly
handover is a dynamic situation that could cause the QoS provided to change.

  I have been told there is no issue, but here's a frightening scenario:

	- a handover takes place, and context transfer has been used to
       move the QoS context to the new routers (by the requirements for
       CT this could be intra-, or inter- technology. Some of us believe
       that for "seamless" handovers, the context will be available at
       routers before the first packets need to be forwarded. This implies
       that there is a relationship, probabilistic perhaps, between
       the handover process and the target ARs for CT.

     - CARD is used by the MN to influence the handover decision (it
       is not clear to me how this happens, but it seems clear that
       for a more "seamless" handover, the MN should chose an AR that 
       has received the appropriate context; if not, then what?

     - NSIS kicks in and starts re-negotiating QoS because of changes
       introduced by the handover; 

  How do these three protocols interact to produce predictable outcomes? 
Or, perhaps, the question is, how do the functional entities associated 
with the three protocols interact before, during and after a handover? 
If it the interaction is within the functional entities, the respective 
wg's could declare the issue out of scope, but this approach does not 
sit well with me, for it seems to defer the problem to the people who
have to implement this "stuff".

  Am I imagining things?

Cheers,
Gary

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]]
> Sent: April 4, 2002 22:33
> To: [email-masked]
> Subject: RE: [NSIS] Establishing QoS after handoff.
> 
> 
> Hi Sharif:
> 
> There is currently a debate going on in Seamoby as to whether 
> this QoS negotiation be covered by NSIS or Seamoby (CAR 
> discovery protocol). 
> 
> IMHO it should be covered by CAR discovery and not NSIS. CAR 
> discovery is supposed to identify candidate access routers 
> for handoff and QoS is an important property for candidacy. 
> 
> Br,
> Hemant
> 
> -----Original Message-----
> From: ext Shahrier, Sharif M. 
> [mailto:[email-masked]]
> Sent: Thursday, April 04, 2002 3:35 PM
> To: Shahrier, Sharif M.
> Cc: [email-masked]'
> Subject: [NSIS] Establishing QoS after handoff.
> 
> 
> 
> I have a question for clarification.
> 
> I think it was stated that NSIS should only be concerned with the
> establishment of QoS after handoff.
> 
> This is inconvienent with respect to IP-level QoS 
> negotiation, which ideally
> should be done before handoff has taken place.
> 
> QoS negotiation is in the current requirements draft.
> 
> So, NSIS signaling protocol development should be concerned 
> with activity
> before handoff occurs.
> 
> Sharif.
> 
> 
> 
> _______________________________________________
> nsis mailing list
> [email-masked]
> https://www1.ietf.org/mailman/listinfo/nsis
> 
> _______________________________________________
> nsis mailing list
> [email-masked]
> https://www1.ietf.org/mailman/listinfo/nsis
>

---

From: "Gary Kenward"<[email-masked]>
Date: Fri, 5 Apr 2002 12:25:11 -0500

Rajeev, James:

  This is how I see it also. I think that some work
is required to identify the conditions under which each
protocol is invoked. E.g. NSIS is not invoked with every
handover, but is certainly there to be invoked if CT
fails, or if there is a QoS disruption for whatever reason.

Thanks.
Gary

> From: James Kempf [mailto:[email-masked]]
> Sent: April 5, 2002 12:07
> To: Rajeev Koodli; Kenward, Gary [WDLN2:AN10:EXCH]
> Cc: [email-masked]; [email-masked]; [email-masked]
> Subject: Re: [Seamoby] RE: [NSIS] Establishing QoS after handoff.
> 
> 
> There is an issue if CT fails. In that case, some kind of negotiation
> after handover would be required.
> 
> So, I'd say that some indication of CT failure is needed.
> 
> As for CAR, I don't see the relevance for QoS negotiation, 
> though it may
> be useful for finding a new wireless medium. I also see it 
> primarily for
> intertechnology handover, or, at best, interprovider handover.
> 
>             jak
> ----- Original Message -----
> From: "Rajeev Koodli" <[email-masked]>
> To: "Gary Kenward" <[email-masked]>
> Cc: <[email-masked]>; <[email-masked]>; <[email-masked]>
> Sent: Friday, April 05, 2002 9:01 AM
> Subject: Re: [Seamoby] RE: [NSIS] Establishing QoS after handoff.
> 
> 
> >
> > Hello,
> >
> > well, if the issue is QoS establishment after handover,
> >
> > - CT is applicable for establishing QoS state at the AR
> > - if further signaling is desired beyond the AR, NSIS may
> >     consider it. I don't see how _signaling_ for QoS establishment
> >     beyond AR is relevant for seamoby.
> >
> > CAR _discovery_ could exchange QoS capability as one of the
> > parameters that might then be fed to a selection algorithm. Any
> > signaling for actually establishing QoS itself beyond the AR
> > should be outside the scope of seamoby..
> >
> > Regards,
> >
> > -Rajeev
> >
> >
> > Gary Kenward wrote:
> >
> > >
> > >
> > > Hemant:
> > >
> > > handover is a dynamic situation that could cause the QoS 
> provided to
> > > change.
> > >
> > >         - a handover takes place, and context transfer 
> has been used
> > > to
> > >        move the QoS context to the new routers (by the 
> requirements
> > > for
> > >        that for "seamless" handovers, the context will be 
> available
> at
> > >
> > Seamoby mailing list
> > [email-masked]
> > https://www1.ietf.org/mailman/listinfo/seamoby
> >
> 
>

---

From: "Gary Kenward"<[email-masked]>
Date: Fri, 5 Apr 2002 12:25:11 -0500

Rajeev, James:

Thanks.
Gary

---

From: "Gary Kenward"<[email-masked]>
Date: Fri, 5 Apr 2002 13:08:14 -0500

Well, as far as I see it, if CT fails it is due to one of three reasons:
 
 - the "network" is not aware that a handover to that AR is taking place
   (and the AR is forced to deal with the situation locally).

 - the context is not useable by the AR.

 - the AR cannot admit the flows.

CT does not address the first two of these issues. The first is a handover 
issue; CT allows for the AR to attempt to fetch context (aka "reactive CT"),
however, it is possible that the AR may choose to signal the MN rather then 
attempt to acquire old context). The second issues would seem to be a CARD 
issue (albeit, a network centric CARD issue).

The third reason is, in my view, also a handover issue. The handover
algorithm
cannot handover flows to ARs that have no free resources. There are issues 
here resource reservation versus over-booking and timing. Is CARD an
admission
control protocol? Does it request resource reservation, or is it timely
enough
to assure that the resource availability does not change before the handover
actually occurs?

Regards,
Gary

PS I cross-posted the first email because the issue seemed to be relevant to
both groups. If this is untrue, I will endeavour to take the issue to only
one of the two lists.

> Sent: April 5, 2002 12:39
> To: Rajeev Koodli
> Cc: Kenward, Gary [WDLN2:AN10:EXCH]; [email-masked];
> [email-masked]; [email-masked]
> Rajeev,
> I agree, but there is still an issue of how the AR would notify the MN
> if CT fails. Is this covered by CT or not?
> 
>             jak
> 
> To: "James Kempf" <[email-masked]>
> Cc: "Gary Kenward" <[email-masked]>;
> <[email-masked]>; <[email-masked]>; <[email-masked]>
> Sent: Friday, April 05, 2002 9:19 AM
> > Hello Jim,
> > James Kempf wrote:
> > Yes, but this is between AR and MN. If CT fails, the AR should
> > notify the MN to engage in context re-creation.
> >
> > My point was specific to signaling _beyond_ AR (i.e., upstream
> signaling)
> > independent of failure/success of CT.
> >
> > Hope this is clearer..
> >
> > -Rajeev
> >
> >
> > >
> > > As for CAR, I don't see the relevance for QoS 
> negotiation, though it
> may
> > > be useful for finding a new wireless medium. I also see 
> it primarily
> for
> > > > >         - a handover takes place, and context 
> transfer has been
> used
> > > > > to
> > > > >        CT this could be intra-, or inter- technology. 
> Some of us
> > > > > believe
> > > > >        routers before the first packets need to be forwarded.
> This
> > > > > implies
> > > > >      - CARD is used by the MN to influence the 
> handover decision
> (it
> > > > >        for a more "seamless" handover, the MN should 
> chose an AR
> > > that
> > > > > wg's could declare the issue out of scope, but this approach
> does
> > > not
> > > > > sit well with me, for it seems to defer the problem to the
> people
> > > who
> > > > > > I think it was stated that NSIS should only be 
> concerned with
> the

---

From: "Gary Kenward"<[email-masked]>
Date: Fri, 5 Apr 2002 13:08:14 -0500

Regards,
Gary

---

From: "Gary Kenward"<[email-masked]>
Date: Fri, 5 Apr 2002 13:34:56 -0500

Well yes and no.

First, CT is required to do everything it can to get the
context across intact, as fast as possible, which, it was decided, meant
that there was realistically only one opportunity to attempt to transfer
the context. The emphasis was placed on requiring that a given transfer of
context would not fail (e.g. the context integrity should be preserved
through
error control, etc.). Then, if the transfer failed it was because of
something 
other then the transfer process itself. 

If CT fails, it is more likely then not that handover will not be seamless
anyways, and there is nothing that CT can do, per se, to recover. 
Having said this, CT can be re-invoked by another entity, perhaps the
handover
control function, for recovery purposes. 

I'm trying to be brief, so I hope this captures what was a looooong
discussion.

Gary

> Sent: April 5, 2002 13:22
> To: Rajeev Koodli
> Agree.
> But I don't see anything in the CT requirements about handling CT
> failure.
> 
> ???
> 
>             jak
> 
 >
> 
>

---

From: [email-masked]
Date: Fri, 5 Apr 2002 14:12:47 -0500

Gary,

The third reason is, in my view, also a handover issue. The handover algorithm 
cannot handover flows to ARs that have no free resources. There are issues 
here resource reservation versus over-booking and timing. Is CARD an admission 
control protocol? Does it request resource reservation, or is it timely enough 
to assure that the resource availability does not change before the handover 
actually occurs?  

[Govind] IMHO, CARD can help an admission control protocol by giving some relavant information about the AR. 

But, I don't think it is an admission control protocol. Atleast I feel this is true for CARD as it is described now.

Best regards,

Govind.

---

From: [email-masked]
Date: Fri, 5 Apr 2002 14:12:47 -0500

Gary,

Best regards,

Govind.

---

From: Nakhjiri Madjid-MNAKHJI1 <[email-masked]>
Date: Fri, 5 Apr 2002 15:57:42 -0600

Agreed. I don't think reliability in signaling, which by the way
neither CT requirements, nor nsis requirements are covering, has to 
do with failure in QoS negotiation. I don't think you can count
the case, where the QoS information that CT has given the AR is not
applicable, as a CT failure.

Madjid

-----Original Message-----
From: Rajeev Koodli [mailto:[email-masked]]
Sent: Friday, April 05, 2002 12:03 PM
To: James Kempf
Cc: Gary Kenward; [email-masked]; [email-masked];
[email-masked]

> if CT fails. Is this covered by CT or not?

This notification should be covered by CT.  We should offer
seamless handover to NSIS :-) Seriously, this concerns
robustness of CT protocol.

-Rajeev

> > > As for CAR, I don't see the relevance for QoS negotiation, though it
> may
> > > be useful for finding a new wireless medium. I also see it primarily
> for
> > > > >         - a handover takes place, and context transfer has been
> used
> > > > > to

---

From: Nakhjiri Madjid-MNAKHJI1 <[email-masked]>
Date: Fri, 5 Apr 2002 15:57:42 -0600

Madjid

-----Original Message-----
From: Rajeev Koodli [mailto:[email-masked]]
Sent: Friday, April 05, 2002 12:03 PM
To: James Kempf
Cc: Gary Kenward; [email-masked]; [email-masked];
[email-masked]

-Rajeev

---

From: Nakhjiri Madjid-MNAKHJI1 <[email-masked]>
Date: Fri, 5 Apr 2002 15:54:04 -0600

Hello Rajeev,

I agreed with everything you say below, except one thing:
CT can only transfer whatever QoS state that is usable at the newAR.
If the new network is using a different QoS technology with different
QoS parameters, then I am not sure if CT by itself can do the job, unless
you add your own mapping functionality.

BR,
Madjid

-----Original Message-----
From: Rajeev Koodli [mailto:[email-masked]]
Sent: Friday, April 05, 2002 11:01 AM
To: Gary Kenward
Cc: [email-masked]; [email-masked]; [email-masked]
Subject: Re: [Seamoby] RE: [NSIS] Establishing QoS after handoff.

Hello,

Regards,

-Rajeev

---

From: Nakhjiri Madjid-MNAKHJI1 <[email-masked]>
Date: Fri, 5 Apr 2002 16:00:32 -0600

Well, you are opening a can of worm that took seamoby 3 months
to close without any results. People could not agree on the 
reliability needs of CT. We added a reliability mechanism to our
CT proposal that covered both retransmission and updates.

Madjid

-----Original Message-----
From: James Kempf [mailto:[email-masked]]
Sent: Friday, April 05, 2002 12:22 PM
To: Rajeev Koodli
Cc: Gary Kenward; [email-masked]; [email-masked];
[email-masked]

Agree.

???

            jak

----- Original Message -----
From: "Rajeev Koodli" <[email-masked]>
To: "James Kempf" <[email-masked]>
Cc: "Gary Kenward" <[email-masked]>;
<[email-masked]>; <[email-masked]>; <[email-masked]>
Sent: Friday, April 05, 2002 10:02 AM
Subject: Re: [Seamoby] RE: [NSIS] Establishing QoS after handoff.

> > > > As for CAR, I don't see the relevance for QoS negotiation,
though it
> > > > be useful for finding a new wireless medium. I also see it
primarily
> > > > > > arises out of a perceived need to determine at the MN the
best
> > link
> > > > > > layer to handover over to when inter-technology handovers
are
> > > > > > involved.
> > > > > > It can be applied to intra-technology handovers, but the
value
> > in
> > > > > > protocol, the implication is that the purpose is to
determine
> > the
> > > > > > choice of channels available; for intra-technology
handovers,
> > there
> > > > > > during/after a handover. John has stated that this is not
the
> > > > > > intention
> > > > > > (please correct me if I have this wrong John), in which case
I
> > think
> > > > > >   I have been told there is no issue, but here's a
frightening
> > > > > > scenario:
> > > > > >        CT this could be intra-, or inter- technology. Some
of us
> > > > > >      - CARD is used by the MN to influence the handover
decision
> > (it
> > > > > >        is not clear to me how this happens, but it seems
clear
> > that
> > > > > >        for a more "seamless" handover, the MN should chose
an AR
> > > > > >      - NSIS kicks in and starts re-negotiating QoS because
of
> > > > changes
> > > > > >   How do these three protocols interact to produce
predictable
> > > > > > outcomes?
> > > > > > > I think it was stated that NSIS should only be concerned
with

---

From: "Gary Kenward"<[email-masked]>
Date: Mon, 8 Apr 2002 13:39:26 -0400

Rajeev:

This was discussed extensively within the design team, and,
I believe, also in the working group.

CT is a transfer protocol. If the target AR is able to detect
that the transfer has failed (e.g a CRC error, a timeout), then 
the target AR simply decides if it still wants to transfer 
context from the source, and, if it does, it issues a new request
for context transfer.

No special message is required.

Gary

> Sent: April 5, 2002 16:44
> To: Kenward, Gary [WDLN2:AN10:EXCH]
> Cc: 'James Kempf'; [email-masked]; [email-masked];
> [email-masked]
> CT is a protocol, and as such would have failure
> modes. For instance, transferred context is not
> useful at the target router. You could say that CARD
> should never let this happen. Does that mean that
> CT cannot be used where CARD is not available ?
> I hope not!
> 
> In any case, I don't know of a protocol that does not
> have failure modes. We need a notification
> message in CT to inform when such a thing happens.
> 
> Regards,
> 
> -Rajeev
> 
> 
> Gary Kenward wrote:
> 
> >
> >
> > Well yes and no.
> >

---

From: "Gary Kenward"<[email-masked]>
Date: Mon, 8 Apr 2002 13:39:26 -0400

Rajeev:

Gary

---

From: "Gary Kenward"<[email-masked]>
Date: Mon, 8 Apr 2002 13:54:20 -0400

Rajeev:

In order for the MN to "recreate the context", the MN would
have to understand the semantics of Context transfer, etc.,
and, more important, there would have to be a protocol or
protocols that would allow the MN to recreate contexts at an AR.
I doubt that the latter is going to happen (e.g. authentication).

IF and when a CT fails, the easiest way to "recreate" context
is for the sessions to be dropped. This may seem drastic,
but in reality, what is going to cause CT to fail and
how often will this happen? 

There may be mitigating actions that could be taken to re-establish
certain sessions. But these decisions are must be driven by the policy
of the network administration (explicit or implicity), and comply
with the security, resource management and accounting requirements
for the network. Hopefully, none of these mitigating actions requires
more over-the-air signalling.

Gary

> Sent: April 5, 2002 17:46
> To: Nakhjiri Madjid-MNAKHJI1
> Hello Madjid,
> Nakhjiri Madjid-MNAKHJI1 wrote:
> 
> > Hello Rajeev,
> >
> This would be an example where the new AR sends a
> notification to the MN so that the MN can take
> appropriate action (for instance, attempt to
> re-create the context).
> 
> Regards,
> 
> -Rajeev
> 
> 
> >
> > BR,
> > Madjid
> >
> best link
> handovers, there
> available at
> decision (it
> clear that
> chose an AR that
> concerned with the

---

From: "Gary Kenward"<[email-masked]>
Date: Mon, 8 Apr 2002 14:02:15 -0400

Charlie:

  Agreed. But, as was discuss at length over the last year, 
the actual failure points and their frequency are very limited, 
and there are reasonable and not-so-reasonable mitigating responses.

  If someone really wants to provide CT over an all wireless
ad hoc network, for example, then, yes, additional reliability 
will probably be required. In most wired infrastructure scenarios, 
the link reliability is more then sufficient. 

To allow for this flexibility in reliability, this type of 
reliability needs to be provided in the transport layer, not 
with CT. Specific reasons for building additional reliability
into the CT protocol that are generally applicable to a majority
of scenarios, and cannot be resolved by substituting a more
robust transport protocol, have yet to be offered.

Gary

> From: Charles E. Perkins [mailto:[email-masked]]
> Sent: April 5, 2002 18:08
> Cc: 'James Kempf'; [email-masked]
> (I trimmed the mailing lists and some of the trailing messages)
> 
> 
> Hello Madjid,
> 
> The problem is that the reliability needs depend on the context
> feature type.   Some contexts should be transferred reliably, and
> some are not so crucial.  Reliable transfer for header compression
> context is not as crucial as, say, security context -- for
> various reasons, but at least because retransmission for the
> header compression state would take too long.
> 
> Regards,
> Charlie P.
> 
> 
> > > > I agree, but there is still an issue of how the AR 
> would notify the
> > MN

---

From: "Gary Kenward"<[email-masked]>
Date: Mon, 8 Apr 2002 15:46:32 -0400

Can anyone offer an explaining of how or why CT would add significantly
to the already unreliable physics of handover?

What failure modes for CT would be noticeable above the unavoidable 
rate of handover failures due the vagaries of wireless coverage and 
wireless link layer performance????

If CT fails, then the handover fails. It is that simple. If CT were
to fail with every 2nd handover attempt, then there would be a problem.
But, I cannot seriously see CT failing more then every one in a million
handover attempts, or less.

CT should not be attempted if there is an incompatibility between source
and destination ARs. And, I HAD thought that it was the purpose of CAR
to identify those incompatibilities and thus avoid doing CT when it is
clear it would fail. How to mitigate those incompatibles is not a
CT issue, it is a service adaptation issue, which can be resolved in
a number of ways, some of which would imply signalled negotiation either
between the ARs or between the ARs and the MN. 

Gary

> From: Nakhjiri Madjid-MNAKHJI1 [mailto:[email-masked]]
> Sent: April 5, 2002 16:58
> To: 'Rajeev Koodli'; James Kempf
> Subject: RE: [Seamoby] RE: [NSIS] Establishing QoS after handoff.
> 
> 
> > > > > > arises out of a perceived need to determine at the 
> MN the best
> > link
> > > > > > layer to handover over to when inter-technology 
> handovers are
> > > > > > involved.
> > > > > > It can be applied to intra-technology handovers, 
> but the value
> > in
> > > > > > during/after a handover. John has stated that this 
> is not the
> > > > > > intention
> > > > > > (please correct me if I have this wrong John), in 
> which case I
> > think
> > > > > >        CT this could be intra-, or inter- 
> technology. Some of us
> > > > > > believe
> > > > > >        is not clear to me how this happens, but it 
> seems clear
> > that
> > > > > >        for a more "seamless" handover, the MN 
> should chose an AR
> > > > that
> > > > > >      - NSIS kicks in and starts re-negotiating QoS 
> because of
> > > > changes

---

From: "Gary Kenward"<[email-masked]>
Date: Mon, 8 Apr 2002 15:46:32 -0400

Gary

---

From: "Gary Kenward"<[email-masked]>
Date: Mon, 8 Apr 2002 15:49:16 -0400

"Re-create" was Rajeev's term, not mine. I think that it is an appropriate
term if one considers other mechanisms besides session setup signalling.
Either way, it is not a CT function.

As I outlined in one of my other posts, why would you perform CT to an
AR that did not have the necessary capabilities. Is this actually about
CAR failure??

Gary

> Sent: April 8, 2002 14:26
> To: Kenward, Gary [WDLN2:AN10:EXCH]; 'Rajeev Koodli'; Nakhjiri
> Madjid-MNAKHJI1
> I don't think the issue is having the MN re-create the context. Is is
> allowing the MN to recover by re-running the actions that 
> were necessary
> to create the context in the first place, in the event the AR 
> was unable
> to interpret it.
> Thus, for example, suppose that QoS context is transferred from old to
> new AR, but new AR for some reason can't interpret it, 
> perhaps there is
> no bandwidth left or perhaps the new AR uses a different 
> representation
> for QoS context. The MN would need to be informed somehow so that it
> could re-do its QoS signaling.
> 
>             jak
> 
> From: "Gary Kenward" <[email-masked]>
> To: "'Rajeev Koodli'" <[email-masked]>; "Nakhjiri
> Madjid-MNAKHJI1" <[email-masked]>
> Sent: Monday, April 08, 2002 10:54 AM
> > > because of changes

---

From: "Gary Kenward"<[email-masked]>
Date: Mon, 8 Apr 2002 16:08:42 -0400

Rajeev:

  A user starts up an application that requests a "gold service".
The protocol stack (perhaps an NSIS protocol stack) sends in a
request from MN to AN for gold service". A handover occurs, and 
(according to your scenario), the QoS context transfer fails (for some 
inexplicable reason). Some entity (the CT protocol stack according to 
your proposal) sends an indication to the MN that the QoS context transfer 
has failed (according to your proposal). How does the MN know what to do 
with this notice? The MN has to understand:
    
   - what a handover is at the IP level
   - what an IP context transfer is
   - that QoS context is (sometimes) transferred separately from other
     context
   - what the nature of the failure was, and thus, what action to take.
   - how and with what entity to initiate QoS re-negotiation.

  The knowledge for all of the above is either explicitly or implicitly
built into the MN. If the intent were for the MN to receive back a message 
that indicating "Gold service not available" then this is simply a session
disconnect. If the intent is for the MN to be told that "the QoS associated
with Gold service" has failed, then the MN has to know that Gold service
is actually a combination of features (AAA, security, HC), and to initiate 
negotiation, it has to be able to talk to the individual network entities
- entities which may not even exist within a given network (e.g. a provision
model).

 So, how is the MN ignorant of CT? Service models?

 Keep in mind, according to the CT requirements, CT does not know what
is contained in the data chunks it transports. Thus, at best, it can
only forward to the MN that data chunk or another, opaque data chunk.
Even this capability is a major modification to what should be
a simple state machine for the CT protocol.

Gary

> Sent: April 8, 2002 14:42
> Cc: Nakhjiri Madjid-MNAKHJI1; [email-masked]; [email-masked];
> [email-masked]
> The MN does not have to know the CT semantics.
> It only needs to understand a notification message
> that provides the error condition related to its
> context.
> 
> >
> Well, the MN should use whatever protocol was
> used that established the context in the first place,
> including for authentication.
> 
> >
> This is a drastic idea! I think we can do better.
> For one thing, you still have connectivity which
> you could use to notify the MN so that the MN
> can resort to re-establishing contexts (or not). Besides,
> CT is a protocol, and like any other protocol has
> error cases and failure modes. There must be a
> notification message that provides protocol
> robustness.
> An example that has been brought up is where
> the transferred context is not useful, either
> partially or entirely. You would like to notify
> the MN when this happens.
> 
> 
> >
> And, why are these any better when CT fails compared
> to notifying a MN ? Seems to me that a notification message
> would not encumber any of the above overheads. You
> leave it up to the MN.
> 
> -Rajeev
> 
> 
> >
> > Gary
> >

---

From: "Gary Kenward"<[email-masked]>
Date: Mon, 8 Apr 2002 16:21:26 -0400

James:

> Sent: April 8, 2002 15:55
> Yes and no.
> Suppose the MN is expecting CT to be performed and it is not 
> because the

A nit, but the MN does not expect CT. The MN expects continuous
service (i.e. seamless service), and knows nothing about how it is 
supported (it could be provisioned).

> new AR can't interpret the context.
> The old AR may discover this via CAR, but if there is no way to
> communicate it to the MN, then the MN can't know to perform the
> signaling from scratch on the new AR.  One could either inform the MN
> beforehand to do the signaling, as is done with FMIPv6/BETH, or signal
> the MN on the new AR.
> 
> For dynamic failures, such as when the AR runs out of Gold Class
> service, the signaling could only be done afterwards.

I understand these scenarios, but I do not understand what they have
to do with CT. CT has never intended to be an MN signalling protocol.
Let me try a counter example: the service authorization fails. Would
a CT message saying the AA context transfer failed be of much use
to the MN? No, because the problem wasn't with the context, it was with
a disconnect between the service request and authorization profile for
that MN. 

There is a need for a "handover failure" indication message to the
MN (indicating full or partial handover failure), but this message should
be part of a different protocol from CT.

Gary

---

From: "Gary Kenward"<[email-masked]>
Date: Mon, 8 Apr 2002 16:30:23 -0400

Rajeev: 

model). 

Gary 

*snip*

>  <https://www1.ietf.org/mailman/listinfo/nsis>

---

From: "Gary Kenward"<[email-masked]>
Date: Mon, 8 Apr 2002 17:34:26 -0400

Regards,
Gary 

*snip*

---

From: "Gary Kenward"<[email-masked]>
Date: Tue, 9 Apr 2002 13:55:49 -0400

Charlie:

 Thanks for the $0.02. Some comments/questions:

> Sent: April 8, 2002 17:58
> Cc: [email-masked]; [email-masked]
> Hello Gary,
> I have $0.02 to add to the discussion:
> 
> Since I took physics in college, I can answer this.  It would not
> add significantly to handover unreliability.

Then why should we worry about it? The ultimate question is, given
that you detect a failure, can you make a significant improvement
on the handover performance?

> Congestion at intermediate routing points comes to mind.
> Just because two access points are both within range of a mobile node
> does not mean that they are neighbors to each other.  They may even
> be attached to completely different physical media.

Could you not avoid this with traffic engineering? It would seem to me
to be a bad choice, regardless, to throw your CT traffic in with your
BE traffic. The impact on delay of transfer alone would be enough reason
to provide special treatment for CT. And, if the CT is failing because
of congestion, why would any signalling messages indicating failure and
attempting recovery not also be congested?

> I quite disagree with this statement.  It depends on very many things.
> For instance, we have to be able to run CT without CARD.  So, the
> destination access router might not offer header compression at all,
> for instance.  Thus, the handover would succeed, but the 
> context transfer
> (or, part of it) would fail. 

Ok. I wasn't clear. I did not mean to imply that all handovers require CT.
I meant that if a handover of a flow requires context to work, and the
CT fails, then the flow handover fails. Since this is, as you agree, a
rare event insignificant amongst all the other reasons handovers fail,
why worry about it?

> Cool!  This could be good news.

I am as nervous as anyone in pushing requirements onto the people
who engineer a working network. There job is hard enough. However,
I just do not see running signalling and signalling related traffic
such as CT, through the same congested paths as BE traffic. Even for
wireless ad-hoc networks, I would presume that there will be a need
identified for some special traffic treatment over the air to facilitate
signalling between nodes.

> > and destination ARs.
> As noted above, I quite disagree with this statement.

I don't see the relationship between your disagreement and
your notes above. 

If CARD is present, then the network should know ahead of time
what the capabilities of a target router are, and what mitigating
action needs to be taken to effect a useful CT.

If CARD is not present, then the solution is to configure the
network appropriately. This may include facilities at ARs
for context translation ("may" - I think this is getting ahead
of the current state of the art).

The only other scenario I can think of is where the network configuration
is dynamic, and thus the capabilities of the ARs can change dynamically.
This is one reason why I mentioned wireless ad-hoc networks. It is not
clear to me that we should be attempting to solve this very complex
problem within SEAMOBY, as there are any number of assumptions that
must be made to make the problem tractable.

> 
> >                       And, I HAD thought that it was the 
> purpose of CAR
> > clear it would fail.
> But, we have to be allowed to do CT without ever running CARD.
> For instance, we have reactive mode.

Reactive mode does not mean no CARD. 

What you are suggesting is a collection of ARs with different capabilities,
unknown during configuration time, and where CARD is not used. I would
propose
that this is an unrealistic scenario.

Said another way, I propose that if the capabilities of the ARs are known
and unchanging, the network can be engineered for CT without CARD to work.
Note that this statement applies to wireless ad-hoc networks and mobile
ARs as well as fixed, wired ARs.

If the capabilities of the ARs at the time of a handover are not
pre-determinable,
then I suggest that this is where CARD is used with the greatest import.

Any other scenarios can be deemed poor network engineering practice. 

> 
> >                        How to mitigate those incompatibles is not a
> Sometimes, the service cannot be adapted, and the feature context is
> just plain lost, because the feature is unavailable.  
> Suppose, for example,
> that the contexts transferred include header compression, 
> QoS, security,
> and other features.  Now suppose that _only_ the security 
> context can be
> transferred.  That's still better than nothing!  Maybe the 
> QoS application
> will have to terminate, or go into degraded mode, but the 
> other applications
> that need security will still be able to go on undisturbed.  Why not?

Sure, but what does this have to do with CT? There may be many reasons
why a particular feature might fail, including malformed, missing or
incompatible context. My position is this is not a ct issue, but rather
an issue with the service entities themselves, which may mean the service
entities perform some mitigating action, including informing the MN.

Example: if the security context transfer fails, should a CT entity inform
the MN, or should it be the responsibility of the security service entities?
I think the latter.

> 
> Regards,
> Charlie P.
> 
> PS. I relucantly left NSIS on the CC: list, but shouldn't it 
> be pruned?

Perhaps. I haven't seen any complaints from NSIS as yet. I think some of
us are trying to figure out what the respective roles of each protocol are
and, most important, the inter-relationships. E.g. if QoS re-negotiation is
to happen as a result of handover, in my view, it makes sense that we should
use the capabilities of the NSIS protocol to do this re-negotiation, rather
then replicate similar functionality in CARD or CT. The difficulty I suspect
with this, is that none of the protocols exist yet, so it is hard for many
of us to see what the trade-offs are.

Perhaps the answer is to decide now where the divisions between the problem
spaces (via requirements and objectives), and worry about trade-offs later.
(Requirements drafts are not legal documents: they can be revised with
sufficient
reason.)

Cheers,
Gary

---

From: "Gary Kenward"<[email-masked]>
Date: Tue, 9 Apr 2002 13:55:49 -0400

Charlie:

Cheers,
Gary

---

From: "Gary Kenward"<[email-masked]>
Date: Tue, 9 Apr 2002 14:10:34 -0400

Phil:

> From: Phil Neumiller [mailto:[email-masked]]
> Sent: April 8, 2002 20:49
> To: Kenward, Gary [WDLN2:AN10:EXCH]; 'Charles E. Perkins'; Nakhjiri
> Madjid-MNAKHJI1
> RE: [Seamoby] RE: [NSIS] Establishing QoS after handoff.
> From: Gary Kenward 
> pdn> There is not that much difference between an ad hoc network and
> a wireless network that doesn't support soft handover.  I 
> would argue that
> a wireless infrastructure network with hard handover is less 
> reliable than
> an ad hoc nework with hard handover.

Ok.

> pdn>That's funny.  Why don't you like more robust handoffs to 
> begin with???

Not my point Phil. I was referring to CT Transport, not over-the-air
transport.

BTW: robust handovers are only needed when robust service is required.
what would be sufficient for handover of BE traffic?

Cheers,
Gary

---

From: "Gary Kenward"<[email-masked]>
Date: Tue, 9 Apr 2002 14:10:34 -0400

Ok.

Cheers,
Gary

---

From: "Gary Kenward"<[email-masked]>
Date: Tue, 9 Apr 2002 14:12:20 -0400

*snip*

> 
> Yes, stay connected to multiple ARs.  You will need it anyway for
> log normal shadow fading in outdoor environments.  People on this
> list don't realize that frequencies are going up and these things will
> deployed
> outdoors where shadow fading is the killer.  Its not going to 

Don't forget the pain of rain!

> be one big
> cell
> after another.  Its going to be connections two or three 
> crappy cells and
> making the best use of them.
> 
> 
>

---

From: "Gary Kenward"<[email-masked]>
Date: Tue, 9 Apr 2002 14:12:20 -0400

*snip*

---

From: "Gary Kenward"<[email-masked]>
Date: Tue, 9 Apr 2002 14:30:51 -0400

James:

  Sorry, but I am a bit confused (as usual), are you saying
then that doing these functions with the CT protocol is less
heavyweight, and thus preferable?

  The default action, always, is for the session to be dropped.
This will ultimately force the MN to take action (oh, ok, some
MNs will simply halt and catch fire). Anything more then dropping
the session is simply to improve the handover performance under
various conditions. Typically, when one gets into exception scenarios,
the solutions become too complex or degrade performance too much 
to be justified against the potential gains. A classic example is
run time type/value checking in C/C++. 

  If there are no recovery mechanisms for the potential faults 
you describe, then does it make sense to build one into CT?
On the other hand, if these mechanisms are built into the handover
algorithm, or into the session support, then putting it into CT
would be redundant, would it not?

Gary

> Sent: April 8, 2002 21:12
> When you say "handover failure" I think Mobile IP, and there 
> is already
> some signaling available in FMIPv6/BETH to do this. This 
> signaling does
> not extend to attributes of the IP service like whether or not the MN
> can connect to the network, what class of QoS service it gets, and any
> other security, etc.. There is currently no way to signal that the
> network expects the MN to reestablish these, except to say that the MN
> has entered a new AAA domain and should therefore perform 
> network entry
> from scratch. This seems a little too heavyweight to me.
> 
>             jak
> 
> To: "'James Kempf'" <[email-masked]>; "'Rajeev Koodli'"
> <[email-masked]>; "Nakhjiri Madjid-MNAKHJI1"
> <[email-masked]>
> Sent: Monday, April 08, 2002 1:21 PM
> > > > AR that did not have the necessary capabilities. Is 
> this actually
> > > about
> > > > CAR failure??
> > > >
> > >
> > > Yes and no.
> > >

---

From: "Gary Kenward"<[email-masked]>
Date: Tue, 9 Apr 2002 15:21:19 -0400

Phil:
 
  Yup, Phil, I have studied it. My point was that the unreliability of CT
should not
be noticeable with respect to the relative unreliability of handover. And
the 
latter is far from 100% reliable, even with all the advances.
 
  Of course, one could make CT grossly unreliable, but I contend that it is
easier
to make an information transfer between two (relatively close) nodes in a
wired
network reliable then it is to make anything in wireless more reliable.
 
Cheers,
Gary
-----Original Message-----
From: Phil Neumiller [mailto:[email-masked]]
Sent: April 8, 2002 20:43
To: Kenward, Gary [WDLN2:AN10:EXCH]; 'Nakhjiri Madjid-MNAKHJI1'; 'Rajeev
Koodli'; James Kempf

Hmm.  Gary have you studied the mechanics (i.e. the physics as you put it)
of 3G aka
CDMA handover?  Why do you say its unreliable?  Make before break won the
battle years
ago.  Why do people in the IETF incessently restrict themselve to legacy
handovers????

---

From: "Gary Kenward"<[email-masked]>
Date: Tue, 9 Apr 2002 15:21:19 -0400

Phil:

 
Cheers,
Gary
-----Original Message-----
From: Phil Neumiller [mailto:[email-masked]]
Sent: April 8, 2002 20:43
To: Kenward, Gary [WDLN2:AN10:EXCH]; 'Nakhjiri Madjid-MNAKHJI1'; 'Rajeev
Koodli'; James Kempf

---

From: "Gary Kenward"<[email-masked]>
Date: Tue, 9 Apr 2002 15:49:10 -0400

James:

> Sent: April 9, 2002 15:01
> No, I'm saying that "dropping the session" is more 
> heavyweight. And what

Agreed. It would be better to try and fix things first. The real
question is at what level.

> do you mean by a session anyway?
> IP is connectionless.

Well...sessions do not require connections. But I have a feeling
we both do not want to open up that can-of-worms debate.

When I say "session", I mean all the collection of services/resources
that have been set up to support an IP flow, QoS, AAA, HC, etc.
If you have a better word, I'll use it.

> 
> I think what you mean is that all feature contexts for the MN 
> revert to
> the startup state, namely gone.

Ok. Except, that it may be only the feature contexts for a given
microflow. E.g just because a new AR cannot support EF PHB, does
not mean that the BE flows need to be dropped.

> My point is, if the MN never finds out about this, then it can't take
> any action.

My points is that this is not a CT protocol function. There are any
number of failure points for a service feature, and it is the responsibility
of the control entity for that service feature to notify the MN. 

> I'm not saying that there should be recovery built into CT. What I am
> saying is
> that the MN has got to know when it has to redo signaling in order to
> reestablish
> stuff like it's AAA state or it's QoS state.

see comment above.

But, btw: how does the MN re-establish state without dropping the flow?
E.g. authentication? authorization? does re-establishing EF PHB make
any sense (if you cannot do it within a 100 ms, has the service not
been "dropped" anyway?) 

> 
> We went through this exact conversation on the MIP list with 
> respect to
> BETH. The
> MN doesn't get involved in handover with BETH, so it needs to be
> informed when
> BETH handover fails (in practice, we tell it when BETH 
> handover is about
> to fail).
> Then it can do standard MIP signaling in order to get a care 
> of address.
> 
> I'm willing to grant that having CT do feature by feature failure
> notification doesn't make sense,
> but I still think there needs to be some way to tell the MN that
> seamlessness has failed
> or is about to fail so it can take the right steps to restart the
> original network admission
> procedure.
> 
> I think this is needed if for no other reason than when the MN reaches
> the edge of the operator's
> domain, if the operator doesn't have the right business 
> agreements with
> the next operator, the MN
> has got to know to redo network entry, i.e. AAA from scratch, QoS from
> scratch, etc.

We agree on the first part of these two paragraphs. But, I am confused:
I am not aware of any current facilities within QoS/AAA that allows the MN
to repair AAA/QoS state as opposed to "building it from scratch". Certainly,
protocols can be extended, but then, they can also be extended to allow
for notification.

Consider:

   o CT fails for a specific context

   o CT somehow sends notification that the context for QoS has failed.

   o MN determines (somehow) what this failure message means (again,
consider that
CT can, at best, notify that a particular data chunk failed somehow at the
new AR, 
not why).

   o MN initiates a re-negotiation with the appropriate network entity (AAA
server
perhaps? an QoS Controller perhaps?)

Versus:

   o CT fails for a specific context

   o service feature entity at new AR determines that it is unable to
support 
     one or more of the MN flows either because it does not have the
context,
     or because it cannot support the context

   o new AR determines, perhaps using local policy decisions, what
mitigating
     action can to be taken locally (e.g. downgrade an AF flow to a BE flow
to 
     support forwarding until new negotiations can take place).

                                  - OR -

   o new AR determines, perhaps using local policy decisions, that the
control
     entity for the feature (e.g. the AAA server), needs to be notified
(e.g.
     the service lacks proper authorization), the control entity can then
take
     direct action (e.g. perhaps by some inter-system authorization
exchange).

                                  - OR -

   o new AR determines, perhaps using local policy decisions, that the MN is
     should fix the problem, and sends a notification.

Which scenario appears more flexible, more responsive, and more likely to 
support seamless handovers?

Gary

---

From: Nakhjiri Madjid-MNAKHJI1 <[email-masked]>
Date: Tue, 9 Apr 2002 15:48:05 -0500

Hi Rajeev,

Again sorry for the delay, I have been away from the list.
I guess such hook is a design issue, i.e. how complex or 
simple you want your CT to be.

Madjid

-----Original Message-----
From: Rajeev Koodli [mailto:[email-masked]]
Sent: Friday, April 05, 2002 6:07 PM
To: Charles E. Perkins
Cc: Nakhjiri Madjid-MNAKHJI1; 'James Kempf'; [email-masked]
Subject: Re: [Seamoby] RE: [NSIS] Establishing QoS after handoff.

Hello Madjid,

a clarification: I don't think that Jim and I were trying to
reformulate reliability requirements. They are, as Charlie
points out, feature-specific. We were trying to say that
the CT protocol must have a hook to inform the MN
when there is an error condition (including when it
is not possible to support the feature).
So, I am only trying to indicate that there needs
to be a notification message, since like any other
protocol, CT would have error cases and failure
modes.

Regards,

-Rajeev

---

From: Nakhjiri Madjid-MNAKHJI1 <[email-masked]>
Date: Tue, 9 Apr 2002 15:48:05 -0500

Hi Rajeev,

Madjid

-----Original Message-----
From: Rajeev Koodli [mailto:[email-masked]]
Sent: Friday, April 05, 2002 6:07 PM
To: Charles E. Perkins
Cc: Nakhjiri Madjid-MNAKHJI1; 'James Kempf'; [email-masked]
Subject: Re: [Seamoby] RE: [NSIS] Establishing QoS after handoff.

Hello Madjid,

Regards,

-Rajeev

---

From: Nakhjiri Madjid-MNAKHJI1 <[email-masked]>
Date: Tue, 9 Apr 2002 15:45:39 -0500

Hi Charlie,

Sorry for the delay.
Yes, and that was one the reasons we could not agree on
the reliability requirements. Other reasons were:
the uncertaintly about the underlying protocol, i.e. ICMP
or SCTP or UDP or something else, plus the timing effects
of retransmissions of context on handoff. 

BR,
Madjid
-----Original Message-----
From: Charles E. Perkins [mailto:[email-masked]]
Sent: Friday, April 05, 2002 5:08 PM
To: Nakhjiri Madjid-MNAKHJI1
Cc: 'James Kempf'; [email-masked]
Subject: Re: [Seamoby] RE: [NSIS] Establishing QoS after handoff.

Hello Madjid,

Regards,
Charlie P.

---

From: Nakhjiri Madjid-MNAKHJI1 <[email-masked]>
Date: Tue, 9 Apr 2002 15:55:33 -0500

James,

As I said, it depends on how complicated you want the CT
to be. I thought we were supposed to see CT as a container
and not look into contents.
Ideally the two networks communicating with each other have
some clue about each other (either part of same admin domain,
and hence all capabilities are known, or different admin domain, 
in which case, roaming agreements might be needed).
Why should CT itself care about whether what it is carrying 
make sense to the newAR or not, it can, like any other signaling
protocol (NSIS as an example) carry a lot of opaque info.
At the most maybe a notification like what Rajeev proposed.
Going further than that you need to be careful not to get into
specific feature issues.

BR,
Madjid

-----Original Message-----
From: James Kempf [mailto:[email-masked]]
Sent: Monday, April 08, 2002 10:42 AM
To: Nakhjiri Madjid-MNAKHJI1; Rajeev Koodli
Cc: Gary Kenward; [email-masked]; [email-masked];
[email-masked]

Madjid,

The issue isn't reliability, it is whether the target AR can interpret
the context intelligably. If not, the MN may need to recover by actually
re-initializing whatever feature the context was being transfered for.
But it cannot do this unless it knows that the CT has failed.

For some feature contexts, like header compression, this isn't a problem
because it will re-initialize automatically, but for AAA or QoS it
clearly will be.

            jak

----- Original Message -----
From: "Nakhjiri Madjid-MNAKHJI1" <[email-masked]>
To: "'James Kempf'" <[email-masked]>; "Rajeev Koodli"
<[email-masked]>
Cc: "Gary Kenward" <[email-masked]>;
<[email-masked]>; <[email-masked]>; <[email-masked]>
Sent: Friday, April 05, 2002 3:00 PM
Subject: RE: [Seamoby] RE: [NSIS] Establishing QoS after handoff.

> > > I agree, but there is still an issue of how the AR would notify
the
> > > > > > >   Specifically, is NSIS to be used to negotiated new QoS
for
> an
> > > > > > > QoS for a new flow? I don't think the answer is boolean:
the
> > > role
> > > > > > > of NSIS in QoS re-negotiation is still open, I believe,
and
> > > clearly
> > > > > > >        that there is a relationship, probabilistic
perhaps,
> > > between
> > > > > > > Or, perhaps, the question is, how do the functional
entities
> > > > > > > associated
> > > > > > > with the three protocols interact before, during and after
a
> > > > > handover?
> > > > > > >
> > > > > > > If it the interaction is within the functional entities,
the
> > > > > > > respective

---

From: Nakhjiri Madjid-MNAKHJI1 <[email-masked]>
Date: Tue, 9 Apr 2002 15:55:33 -0500

James,

BR,
Madjid

-----Original Message-----
From: James Kempf [mailto:[email-masked]]
Sent: Monday, April 08, 2002 10:42 AM
To: Nakhjiri Madjid-MNAKHJI1; Rajeev Koodli
Cc: Gary Kenward; [email-masked]; [email-masked];
[email-masked]

Madjid,

            jak

----- Original Message -----
From: "Nakhjiri Madjid-MNAKHJI1" <[email-masked]>
To: "'James Kempf'" <[email-masked]>; "Rajeev Koodli"
<[email-masked]>

the
for
the
and
perhaps,
entities
a
the

---

From: Nakhjiri Madjid-MNAKHJI1 <[email-masked]>
Date: Tue, 9 Apr 2002 16:06:13 -0500

James,

I think if the newAR does not have enough bandwidth for the MN,
there should not be a handover (that is why CAR needs to handle
capability issues as I said before).

I wonder in such a case, would it not be easier to just
redo QoS signaling based on some NSIS-like protocol.
We are not insisting on absolutely do CT until the end of
time, regardless of how many time it fails. The design
must be flexible enough to handle handover delays as much
as possible.

I must say that if you make a simple concept  such
as context transfer to be handled by a too complicate
protocol, people will not use it. So it is your choice.

I was not at the last IETF and the meeting minutes have
not been posted to the list, can you tell me when and
how the CT selection process is going to happen?

Regards,
Madjid

-----Original Message-----
From: James Kempf [mailto:[email-masked]]
Sent: Monday, April 08, 2002 1:26 PM
To: Gary Kenward; 'Rajeev Koodli'; Nakhjiri Madjid-MNAKHJI1
Cc: [email-masked]; [email-masked]; [email-masked]
Subject: Re: [Seamoby] RE: [NSIS] Establishing QoS after handoff.

Gary,

I don't think the issue is having the MN re-create the context. Is is
allowing the MN to recover by re-running the actions that were necessary
to create the context in the first place, in the event the AR was unable
to interpret it.
Thus, for example, suppose that QoS context is transferred from old to
new AR, but new AR for some reason can't interpret it, perhaps there is
no bandwidth left or perhaps the new AR uses a different representation
for QoS context. The MN would need to be informed somehow so that it
could re-do its QoS signaling.

            jak

----- Original Message -----
From: "Gary Kenward" <[email-masked]>
To: "'Rajeev Koodli'" <[email-masked]>; "Nakhjiri

> > and clearly
This
> > perhaps, between

---

From: Nakhjiri Madjid-MNAKHJI1 <[email-masked]>
Date: Tue, 9 Apr 2002 16:06:13 -0500

James,

Regards,
Madjid

-----Original Message-----
From: James Kempf [mailto:[email-masked]]
Sent: Monday, April 08, 2002 1:26 PM
To: Gary Kenward; 'Rajeev Koodli'; Nakhjiri Madjid-MNAKHJI1
Cc: [email-masked]; [email-masked]; [email-masked]
Subject: Re: [Seamoby] RE: [NSIS] Establishing QoS after handoff.

Gary,

            jak

----- Original Message -----
From: "Gary Kenward" <[email-masked]>
To: "'Rajeev Koodli'" <[email-masked]>; "Nakhjiri

This

---

From: Nakhjiri Madjid-MNAKHJI1 <[email-masked]>
Date: Tue, 9 Apr 2002 16:08:53 -0500

all you have to do is to add a CT-NACK, 
please, look at our TEXT proposal.
We even have a CT-NACK for each feature.

madjid

-----Original Message-----
From: James Kempf [mailto:[email-masked]]
Sent: Monday, April 08, 2002 1:32 PM
To: Gary Kenward; Nakhjiri Madjid-MNAKHJI1; Rajeev Koodli
Cc: [email-masked]; [email-masked]; [email-masked]
Subject: Re: [Seamoby] RE: [NSIS] Establishing QoS after handoff.

Gary,

I agree about session establishment, but the fact remains that if
failure of a context transfer for some reason leaves the MN without any
indication that it should proceed to re-establish the feature, then the
MN can't know when it should redo signaling to set up its new state. We
faced this issue with BETH/FMIPv6 and the solution we found there was to
have routers on the border of a fast handover coverage area inform the
MN what handover algorithm was supported by routers in the other
coverage area. While I think this could be done for the cases involving
router configuration, such as where the next access router can't
interpret the context, I am not so sure about failure due to dynamic
conditions, such as that the router currently has all its Gold Class
service bandwidth allocated (a QoS failure).

In any event, I think there is need for some kind of signaling to
indicate to the MN that context transfer has failed and that the MN
needs to redo signaling to re-establish feature contexts.

            jak

----- Original Message -----
From: "Gary Kenward" <[email-masked]>
To: "'James Kempf'" <[email-masked]>; "Nakhjiri
Madjid-MNAKHJI1" <[email-masked]>; "Rajeev Koodli"
<[email-masked]>
Cc: <[email-masked]>; <[email-masked]>; <[email-masked]>
Sent: Monday, April 08, 2002 11:08 AM
Subject: RE: [Seamoby] RE: [NSIS] Establishing QoS after handoff.

> James:
>
>   My main problem with the theme in this discussion is that
> CT is a context transfer protocol, not a session management protocol.
> In particular, when there are feature context specific issues, it is
> best to handle session re-establishment/re-negotiation/maintenance
using
> the protocol(s) that were designed to set up the services in the first
> place. CT should not be stretched into being a general signalling
protocol.
>
>   In addition, there is the perhaps greater argument that the most
> effective method of correcting handover issues is not through over
> the air signalling exchanges. Given the nature of the wireless link,
> it will almost always be faster and always be more cost effective, to
> correct any problems with signalling within the infrastructure (if it
is
> needed).
> > Sent: April 8, 2002 11:42
> > > > > > > > parameters that might then be fed to a selection
> > algorithm.
> > > Any
> > > > > > > > >   Just a point of clarification, but as I
> > understand CARD
> > > (and
> > > > > > > > > protocol. The main application that you are referring
to
> > handovers
> > > > > > > > > that situation is highly questionable (e.g.
> > since it is a
> > > > > discovery
> > > > > > > > >   There is a requirement, 5.1.2, which seems to
> > imply NSIS
> > > > > > > involvement
> > > > > > > > >
which
> > case
> > > > > > > > > existing flow after a handover, or is it
> > specifically for
> > > > > > > establishing
> > > > > > > > >
> > transfer has
> > > been
> > technology. Some
handover
> > > > > > > > >        is not clear to me how this happens, but it
seems
> > should chose
> > > > > > > > >        has received the appropriate context; if
> > not, then
> > > what?
> > > > > > > > >
> > > > > > > > > > There is currently a debate going on in Seamoby as
to
> > > whether
> > > > > > > > > > IMHO it should be covered by CAR discovery
> > and not NSIS.
> > > CAR

---

From: Nakhjiri Madjid-MNAKHJI1 <[email-masked]>
Date: Tue, 9 Apr 2002 16:23:10 -0500

Charlie,

I agree that the design of reliability mechanisms for CT
depends on the underlying transport protocol and that is 
exactly why, we could not agree on the reliability.
However, as we pointed out in our TEXT proposal,
some reliability issues cannot be handled even by reliable
transport such as SCTP. and one such issue is the need for
update. If your state (say header compression) has changed
since last CT, you cannot retx the old context, you need to
send an updated context, and we handled this with a flag in
our design.
I think we discussed many of the issues that are currently being
discussed on this list. But due to the delay in the selection
process, we have not updated or renewed the draft.
Anyway the 00 version is here (expiring soon).

ftp://ftp.isi.edu/internet-drafts/draft-nakhjiri-seamoby-text-ct-00.txt

We would be happy to get any comments.

Regards,
Madjid

-----Original Message-----
From: Charles E. Perkins [mailto:[email-masked]]
Sent: Tuesday, April 09, 2002 4:06 PM
To: Nakhjiri Madjid-MNAKHJI1
Cc: [email-masked]
Subject: Re: [Seamoby] RE: [NSIS] Establishing QoS after handoff.

Hello Madjid,

I think that the underlying protocol has to be selected in
order to meet the needs of the contexts that are going to
be transferred.  These needs ought to be encoded and discernible
as part of the definition of the context feature.  In our
framework, that would make it a property of the profile
type for the feature.

There are other details surrounding the aggregation of
various contexts for transfer as part of the same message
during handover.  Nevertheless, the process of figuring
out the detailed requirements is straightforward, and tedious.

My preference would be to allow several possibilities for
the transport protocol.  We might want to use SCTP for
context transfers that don't have time critical needs, or between
access routers that can maintain nailed-up connections.
We might want to use something else for context transfers
between access routers that have no such open connections,
or for transfers that exclude the possibility of retransmission
for the context feature data.  The underlying protocol could
itself be specified as part of the profile data for the
context feature.

Regards,
Charlie P.

---

From: Nakhjiri Madjid-MNAKHJI1 <[email-masked]>
Date: Tue, 9 Apr 2002 16:23:10 -0500

Charlie,

Regards,
Madjid

-----Original Message-----
From: Charles E. Perkins [mailto:[email-masked]]
Sent: Tuesday, April 09, 2002 4:06 PM
To: Nakhjiri Madjid-MNAKHJI1
Cc: [email-masked]
Subject: Re: [Seamoby] RE: [NSIS] Establishing QoS after handoff.

Hello Madjid,

Regards,
Charlie P.

---

From: Phillip Neumiller <[email-masked]>
Date: Wed, 10 Apr 2002 11:37:11 -0400

James,

Is SeaMoby CT getting reduced to duplicating what NASREQ wants to do?
What about AAA for MIPv4?  I "thought" the whole idea of discovering
the candidates, was to help the "mobile" find the best choice.  I must
admit I have been hard pressed to follow things closely here in SeaMoby
for some time now, so if you want to beat me up on previous consensus
calls thats OK...  

The mobile has the best pseudo-instantaneous perspective on a handover 
choice.  For example, a mobile should be able to request a workload
metric from its candidate ARs and make a handoff decision partially
based on that and other information acquired from its surrounding 
ARs (I am assuming everything trusts each other for the moment).

This brings in the concept of distributed bidding being possible for
handoffs.  This would likely drag AAA along (kicking and screaming 
of course).  I think SeaMoby CT could provide a nice spectrum management
tool if accountants want to auction their spectrum  in real time.  I saw 
CT facilitating this sort of context transfer, and of course QoS stuff
too.  What types of context are  other people thinking of using CT for
(I am really curious about some CT applications). 

Also, considering that more hosts will be multi-radio capable I see 
CT being useful to do a SeamLess radio change, perhaps via a temporary
multi-home or tunnel (BETH-like thingy).

-pdn

> Sent: Tuesday, April 09, 2002 5:47 PM
> I'd be happy with:
>         o CT is impossible to do with new AR for some reason, perhaps
> failure of a specific feature context,
>             perhaps new AR is in a different administrative 
> domain, etc.
> 
>         o New AR notifies MN that it must redo network 
> admission to get
> back up its state, i.e. go back to
>             the initial state before it entered the network.
> 
> but I would rather have:
> 
>         o CT fails for a specific feature context.
> 
>         o New AR notifies MN that it must redo signaling for that
> specific feature only.
> 
> I
****************************************************************************
This e-mail is intended only for the addressee named above and may contain
confidential, proprietary or privileged information. If you are not the
named addressee or the person responsible for delivering the message to the
named addressee, please inform us promptly by reply e-mail, then delete the
e-mail and destroy any printed copy. The contents should not be disclosed to
anyone and no copies should be made. We take reasonable precautions to
ensure that our emails are virus free. However we accept no responsibility
for any virus transmitted by us and recommend that you subject any incoming
e-mail to your own virus checking procedures.

---

From: Phillip Neumiller <[email-masked]>
Date: Wed, 10 Apr 2002 11:37:11 -0400

James,

-pdn

---

From: "Gary Kenward"<[email-masked]>
Date: Wed, 10 Apr 2002 12:05:17 -0400

Phil:

 All what you say makes sense, to me at least, with one nagging
doubt on my part: you say the mobile has the "best pseudo-instantaneous 
perspective on a handover choice", however, in truth, all the mobile
has, in contrast to what the network has, is a view of the availability
and, perhaps, quality, of the downlink channels to each AP. Everything
else, the network(s) has(have) to provide to the mobile. For me, there 
are very big issues with the idea of having the network specific information
downloaded to an MN for this decision.

 As you are aware, I "cut my teeth" in wireless data working for companies
that produced devices as well as network equipment. I believe that there
are some real device issues with having to process this capability
information,
in addition to the over the air bandwidth consumption of the signalling.
There is also the big issue that many network operators and AP/AR providers
may not want to disclose what the current state of an AP/AR/wireless link 
to an MN for competitive reasons.

 The big issue here that seems to be driving this focus on the MN as the 
primary in the handover decision seems to be inter-network handover. The
MN (IP layer) in this situation appears to be the common denominator in this
case. Particularly when it is assumed that the existence/nature of the
target AP/AR is not known a priori by the old network.

 The bottom line is that all of this makes me nervous because I do not
believe the solution is as simple as advertising the available bandwidth.
And the complexity and overhead builds up once you move beyond this
assumption.

 I've said my piece. Carry on.

Gary

> From: Phillip Neumiller [mailto:[email-masked]]
> Sent: April 10, 2002 11:37
> To: 'James Kempf'
> Cc: [email-masked]'

---

From: "Gary Kenward"<[email-masked]>
Date: Wed, 10 Apr 2002 12:05:17 -0400

Phil:

Gary

---

From: Nakhjiri Madjid-MNAKHJI1 <[email-masked]>
Date: Fri, 12 Apr 2002 11:08:48 -0500

Cool, a simple Nack might not hurt,
Was your proposal based on a different handover proposal than
the ones in MIP WG? I remember readin it long time ago and didn't
recognize some messages?

BR,
Madjid

-----Original Message-----
From: Rajeev Koodli [mailto:[email-masked]]
Sent: Tuesday, April 09, 2002 4:28 PM
To: Nakhjiri Madjid-MNAKHJI1
Cc: 'James Kempf'; Gary Kenward; [email-masked];

> We even have a CT-NACK for each feature.

Right. A simple notification message would suffice.

BTW, in our framework we call it CTIN-Ack now (Section 5.2);
earlier versions (going back to Pittsburgh IETF) called
it SHACK :-)

Regards,

-Rajeev