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

From: [email-masked]
Date: Thu, 4 Apr 2002 22:32:48 -0500

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: [email-masked]
Date: Fri, 5 Apr 2002 10:48:23 +0300

Hi Hemant,

> [HC] Yes, NSIS protocol must have provisions to *accept* 
> session's QoS data (transferred by CT) from new AR during QoS 
>  signalling. Still, IMHO target selection and CT aspects as 
> such should be out of scope of NSIS.

Yes, and if NSIS list members have input for QoS issues into
SeaMoby, that would be good.  

John

---

From: [email-masked]
Date: Fri, 5 Apr 2002 14:55:26 +0300

Hi Xiaoming,

> Yes, I agree that target selection and CT aspects as such 
> should be out of scope of NSIS, instead, task of SEAMOBY. 
> 
> However, following req-draft "exclusions" section 4.3.2:
>    4.3.2. Specific mechanisms (APIs and so on) for interaction between
>    transport/applications and the network layer are not considered,
>    except to clarify the requirements on the negotiation capabilities
>    and information semantics that would be needed of the signaling
>    protocol. The same applies to application adaptation mechanisms.
> 
> and section 5.10.3 - Combination with Mobility management:
>    Combining mobility and QoS signaling should be supported for
>    economic signaling behavior (e.g., negotiation with the new access
>    network: Mobile IP message to acquire new care-of address and query
>    for QoS information could be combined, in order to preserve
>    bandwidth and reduce latency).
> 
> I think NSIS should clarify the interaction of negotiation 
> (via SEAMOBY or
> other mechanisms) and QoS signaling though. If we simply exclude other
> possibilities and only allow "QoS signaling after handoff", 
> we may get a QoS losing much beauty in mobility scenarios.

I think that interested parties should write up possibilities for
these interactions, so that they can be discussed.d  I don't think
we can put anything into the requirements for this, but perhaps
in the framework document.

John

---

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

John:

  Sorry, I may be just thick between the ears, but did you mean 
"QoS needs" or "QoS signalling needs"????

Gary

> From: [email-masked] [mailto:[email-masked]]
> Sent: April 4, 2002 23:28
> To: [email-masked]; [email-masked]
> Subject: RE: [NSIS] Establishing QoS after handoff.
> 
> 
> Hi all,
> 
> Just to follow on to Hemant's comment:
> 
> > 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. 
> 
> CAR discovery may be used to select handoff targets with
> correct QoS support / capabilities.  Context Transfer (CT)
> can be used with the handoff procedure to ensure proper
> QoS state gets transfered to the new access router.
> 
> If there is anyone interested in this work, please let me
> know.  The SeaMoby chairs asked me to see if NSIS can provide
> them any information about QoS needs.
  ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
> thanks,

---

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:
> > >
> > >   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
> > >
> > > > From: [email-masked] [mailto:[email-masked]]
> > > > Sent: April 4, 2002 22:33
> > > > To: [email-masked]
> > > > From: ext Shahrier, Sharif M.
> > > > [mailto:[email-masked]]
> > Seamoby mailing list
> > [email-masked]
> > https://www1.ietf.org/mailman/listinfo/seamoby
> >
> 
>

---

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
> > > > > arises out of a perceived need to determine at the MN the best
> link
> > > > > choice of channels available; for intra-technology handovers,
> there
> > > > > (please correct me if I have this wrong John), in which case I
> think
> > > > > of NSIS in QoS re-negotiation is still open, I believe, and
> clearly
> > > > >         - a handover takes place, and context 
> transfer has been
> used
> > > > > to
> > > > >        that there is a relationship, probabilistic perhaps,
> between
> > > > >      - 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
> > > > > > I think it was stated that NSIS should only be 
> concerned with
> the

---

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: "Shahrier, Sharif M." <[email-masked]>
Date: Fri, 5 Apr 2002 15:15:53 -0500

John,

	So you are saying that CARD may perform QoS negotiation (if
necessary) between ARs when selecting handoff targets?

If that decision is made, then all the QoS negotiation/renegotiation
requirements should be removed from the current NSIS requirements draft,
because it would be obsolete.

Sharif.

thanks,
John

---

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
> > > > >      - CARD is used by the MN to influence the handover decision
> (it

---

From: [email-masked]
Date: Mon, 8 Apr 2002 06:26:16 +0300

Hi Gary,
 
Actually, it could be either - I'm suggesting folks write an individual 
draft on the subject.  
 
John

-----Original Message-----
From: ext Gary Kenward [mailto:[email-masked]]
Sent: 05 April, 2002 19:08
To: Loughney John (NRC/Helsinki); Chaskar Hemant (NRC/Boston); [email-masked]
Subject: RE: [NSIS] Establishing QoS after handoff.

John: 

Gary 

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

---

From: [email-masked]
Date: Mon, 8 Apr 2002 06:26:18 +0300

Hi Cedric

> how does the CAR know whether or not it is able to provide the QoS
> for the flows of the MN. If the question is QoS on the MN-CAR link,
> then it is easy, but what if the question is on the CAR-CN side?

I've always considered that CAR would work on the capabilities at the
AR.  So, in the scenario, the AR could know if it had the capabilities
to support an additional 'connection' at the QoS level.  That's all
I meant.

John

---

From: [email-masked]
Date: Mon, 8 Apr 2002 11:22:38 +0300

Hi Sharif,

> necessary) between ARs when selecting handoff targets?

What I think would be useful would be for interested parties
to study this & see if one way would be more useful than
another.

John

---

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.
> >
> > 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: "Gary Kenward"<[email-masked]>
Date: Mon, 8 Apr 2002 15:39:23 -0400

I concur with Cedric's observations. 
 
I think that there is still confusion as to where CAR leaves off and NSIS
begins. 
If CAR does QoS negotiation, then will it not require much of the same
signalling 
semantics and syntax as the NSIS solution requires to establish QoS? Is this

redundancy necessary?
 
Also, while I keep thinking I that understand where CT ends and CAR/NSIS
begin,
this think is constantly challenged by proposals such as the one made
recently
to have CT signal service feature incompatibilities/transfer failures. 
 
How many signalling protocols does one need to create and maintain QoS???
Wouldn't it be preferably to have "a" context transfer protocol and "a"
QoS signalling protocol and "a" discovery protocol?
 
We are not (as far as I know) talking about alternative solutions here, but
rather 
three protocols that may often be used together, hopefully with consistent
results.
 
Gary

-----Original Message-----
From: Cedric Westphal [mailto:[email-masked]]
Sent: April 5, 2002 21:43
To: [email-masked]
Cc: [email-masked]; [email-masked]
Subject: Re: [NSIS] Establishing QoS after handoff.

John, 

just one question:

[email-masked] <mailto:[email-masked]>  wrote:

Hi all,

It seems to me that in Seamoby, both CARD and CT could act as triggers
to NSIS (QI I guess). CARD to assess whether the CAR-CN is available,
using NSIS as a probing mechanism, and CT to make the NAR-CN QoS
re-establishment.

Then both CARD and CT would need NSIS input/interaction...
Cheers,

Cedric.

thanks,
John

_______________________________________________
nsis mailing list
[email-masked] <mailto:[email-masked]> 
https://www1.ietf.org/mailman/listinfo/nsis
<https://www1.ietf.org/mailman/listinfo/nsis>

---

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.
> 
> 
> > > > > > It can be applied to intra-technology handovers, 
> but the value
> > in
> > > > > > protocol, the implication is that the purpose is to 
> determine
> > the
> handovers,
> > > > > >        routers before the first packets need to be 
> forwarded.
> > This
> > > > > > implies
> > > > > > > So, NSIS signaling protocol development should be 
> concerned
> > > > > > > with activity
> > > > > > > before handoff occurs.
> > > > > > >
> > > > > > > Sharif.
> > > > > > >
> > > > > > >
> > > > > > >

---

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

redundancy necessary?

 
 
Gary

-----Original Message-----
From: Cedric Westphal [mailto:[email-masked]]
Sent: April 5, 2002 21:43
To: [email-masked]
Cc: [email-masked]; [email-masked]
Subject: Re: [NSIS] Establishing QoS after handoff.

John, 

just one question:

[email-masked] wrote:

Hi all,Just to follow on to Hemant's comment:
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. 
CAR discovery may be used to select handoff targets withcorrect QoS support
/ capabilities.  Context Transfer (CT)can be used with the handoff procedure
to ensure properQoS state gets transfered to the new access router.

If there is anyone interested in this work, please let meknow.  The SeaMoby
chairs asked me to see if NSIS can providethem any information about QoS
needs.
Then both CARD and CT would need NSIS input/interaction...
Cheers,

Cedric.

thanks,John_______________________________________________nsis mailing
[email-masked]://www1.ietf.org/mailman/listinfo/nsis

---

From: "James Kempf" <[email-masked]>
Date: Mon, 8 Apr 2002 18:06:50 -0700

Gary,

Well, clearly we have a disagreement here. If it is not the CT protocol,
then I do not know how else it should be done. Basically, if the router
can't for some reason use the context to complete the handover, I
believe it has an obligation to inform the MN so that the MN can
recover.

            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 12:51 PM
Subject: RE: [Seamoby] RE: [NSIS] Establishing QoS after handoff.

> I agree that the MN must be notified (frankly, ulimitately, the MN
> will find out, even without a signalling message).
>
> I disagree that this has anything to do with the CT protocol.
>
> Gary
>
> > Sent: April 8, 2002 14:32
> > To: Kenward, Gary [WDLN2:AN10:EXCH]; Nakhjiri Madjid-MNAKHJI1;
Rajeev
> > Koodli
> > 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
> >
> > From: "Gary Kenward" <[email-masked]>
> > To: "'James Kempf'" <[email-masked]>; "Nakhjiri
> > Madjid-MNAKHJI1" <[email-masked]>; "Rajeev Koodli"
> > <[email-masked]>
> > Sent: Monday, April 08, 2002 11:08 AM
> > > 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).
> > >
> > > Gary
> > >
> > > > Sent: April 8, 2002 11:42
> > > > To: Nakhjiri Madjid-MNAKHJI1; Rajeev Koodli
> > > > 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.
> > > > From: "Nakhjiri Madjid-MNAKHJI1" <[email-masked]>
> > > > To: "'James Kempf'" <[email-masked]>; "Rajeev Koodli"
> > > > <[email-masked]>
> > > > Sent: Friday, April 05, 2002 3:00 PM
> > > > > 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
> > > > >
> > > > > Sent: Friday, April 05, 2002 12:22 PM
> > > > > To: Rajeev Koodli
> > > > > Sent: Friday, April 05, 2002 10:02 AM
> > > > > > > I agree, but there is still an issue of how the AR would
> > notify
> > > > the
> > > > > MN
> > > > > > > > > There is an issue if CT fails. In that case,
> > some kind of
> > > > > > > negotiation
> > negotiation,
> > > > > though it
> > > > > primarily
> > > > > > > > > Subject: Re: [Seamoby] RE: [NSIS] Establishing QoS
after
> > > > > handoff.
> > > > > > > > > > - if further signaling is desired beyond the AR,
NSIS
> > > > > > > > > > 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
> > > > > > > primarily
> > > > > best
> > > > > > > > > > > layer to handover over to when inter-technology
> > > > handovers
> > > > > are
> > > > > > > > > > > involved.
but
> > > > > value
> > > > > > > > > > > are many, many reasons why this "choice" may not
be
> > > > > available).
> > > > > > > > > > > during/after a handover. John has stated that
> > > > this is not
> > > > > the
> > > > > > > > > > > intention
> > > > case
> > > > > I
> > > > > > > > > > >   Specifically, is NSIS to be used to negotiated
new
> > QoS
> > > > > an
> > > > > > > > > > > QoS for a new flow? I don't think the answer is
> > boolean:
> > > > the
> > > > > > > role
> > > > and
> > > > > > > > > > > handover is a dynamic situation that could cause
the
> > QoS
> > > > transfer has
> > > > > been
> > > > > > > > > > >        CT this could be intra-, or inter-
> > > > technology. Some
> > > > > of us
> > > > > > > > > > > believe
> > > > perhaps,
> > > > > decision
> > > > > clear
> > > > > > > > > > >        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
> > > > > > > > > > > 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
> > > > > > > > > > > > There is currently a debate going on in Seamoby
as
> > > > > whether
> > > > > > > > > > > > IMHO it should be covered by CAR discovery
> > > > and not NSIS.
> > > > > CAR
> > > > > > > > > > > > discovery is supposed to identify candidate
access
> > > > routers
> > > > > > > > > > > > I think it was stated that NSIS should only
> > > > be concerned
> > > > > with
> > > > > > > the
> > > > > > > > > > > > This is inconvienent with respect to IP-level
QoS
> > > > > > > > > > > > negotiation, which ideally

---

From: [email-masked]
Date: Tue, 9 Apr 2002 08:46:19 +0300

Hi Gary,

> I think that there is still confusion as to where CAR leaves off and NSIS begins. 
> If CAR does QoS negotiation, then will it not require much of the same signalling 

As I have been suggesting, perhaps it would be good to document these concerns
in an Internet Draft - emails can only go so far.

> Also, while I keep thinking I that understand where CT ends and CAR/NSIS begin,
> this think is constantly challenged by proposals such as the one made recently

My personal opinion (in this area) is that SeaMoby works on solutions that focus 
on what happens in & during a handover between ARs and NSIS is more focused on 
the end-to-edge or end-to-end signaling path.

John

---

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

Charlie:

 Thanks for the $0.02. Some comments/questions:

> From: Charles E. Perkins [mailto:[email-masked]]
> 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 14:12:20 -0400

Phil:

> From: Phil Neumiller [mailto:[email-masked]]

*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:51:08 -0400

John:

  I don't think it as simple as saying that Seamoby focuses on
handover. I agree that NSIS should not be "handover aware", however,
(and this may be explicitly a seamoby issue), CT/CARD should not,
in my view, be performing service re-negotiation. If for no other
reason then the redundant functionality that is implied (and the
difficulty in maintaining the two negotiation protocols).

  I will think about a draft, but I suspect it is premature/overkill.
In my mind, the issue is about which entity controls the QoS offered
to the MN, and is responsible for keeping the MN informed and reacting
to it's requests. In my simple view, that's NSIS (and certainly NOT
CT). 

  The issue from an NSIS point of view, I guess, is what entity in
the framework corresponds to a new AR that is having difficulty providing
QoS support, and how does it invoke an action that includes notification
of the MN?

Gary

> Sent: April 9, 2002 01:46
> To: Kenward, Gary [WDLN2:AN10:EXCH]; [email-masked]

---

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????
 
----- Original Message ----- 
From: Gary Kenward 
To: 'Nakhjiri Madjid-MNAKHJI1' ; 'Rajeev Koodli' ; James Kempf 
Cc: [email-masked] ; [email-masked] ; [email-masked] 
Sent: Monday, April 08, 2002 3:46 PM
Subject: RE: [Seamoby] RE: [NSIS] Establishing QoS after handoff.

> notify the MN

---

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

> reliability needs of CT. We added a reliability mechanism to our
> > > I agree, but there is still an issue of how the AR would notify
the
> > > > > > > It can be applied to intra-technology handovers, but the
> value
> > > in
case
> > > > > > >   Specifically, is NSIS to be used to negotiated new QoS
for
> > > > > > > QoS for a new flow? I don't think the answer is boolean:
the
and
perhaps,
> > > > > > > wg's could declare the issue out of scope, but this
approach
> > > > > > > > I think it was stated that NSIS should only be concerned
> with
> > > 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
Madjid-MNAKHJI1" <[email-masked]>
Cc: <[email-masked]>; <[email-masked]>; <[email-masked]>
Sent: Monday, April 08, 2002 10:54 AM
Subject: RE: [Seamoby] RE: [NSIS] Establishing QoS after handoff.

> 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,
> > >
> > > 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.
> > >
> >
> > 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
> > >
> > > Sent: Friday, April 05, 2002 11:01 AM
> > > To: Gary Kenward
> > > >   There is a requirement, 5.1.2, which seems to imply
> > NSIS involvement
> > > >
> > available at
> > > >        for a more "seamless" handover, the MN should
> > chose an AR that
> > > >      - NSIS kicks in and starts re-negotiating QoS
> > because of changes
> > > > with the three protocols interact before, during and
> > after a handover?
> > > >
> > approach does not
> > > > sit well with me, for it seems to defer the problem to
> > the people who
> > concerned with the

---

From: [email-masked]
Date: Wed, 10 Apr 2002 09:27:10 +0300

Hi Gary,

> difficulty in maintaining the two negotiation protocols). 

I don't think that CT/CARD should be involved with service (re)negotiation
either.

> to it's requests. In my simple view, that's NSIS (and certainly NOT 

There may be need for some text about this, when we get into framework
issues, so having some text in the form of a draft always helps (its
either than picking through emails from the mailing list).

> QoS support, and how does it invoke an action that includes notification 

I think that this could be discussed in the framework, if we go that way.

John