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

From: "James Kempf" <[email-masked]>
Date: Mon, 8 Apr 2002 11:32:07 -0700

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).
>
> Gary
>
> > -----Original Message-----
> > From: James Kempf [mailto:[email-masked]]
> > Sent: April 8, 2002 11:42
> > To: Nakhjiri Madjid-MNAKHJI1; Rajeev Koodli
> > Cc: Kenward, Gary [WDLN2:AN10:EXCH]; [email-masked];
> > [email-masked]; [email-masked]
> > Subject: Re: [Seamoby] RE: [NSIS] Establishing QoS after handoff.
> >
> >
> > 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.
> >
> >
> > > 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]
> > > Subject: Re: [Seamoby] RE: [NSIS] Establishing QoS after handoff.
> > >
> > >
> > > Agree.
> > >
> > > But I don't see anything in the CT requirements about handling CT
> > > failure.
> > >
> > > ???
> > >
> > >             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.
> > >
> > >
> > > > James Kempf wrote:
> > > >
> > > > > 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?
> > > > >
> > > >
> > > > This notification should be covered by CT.  We should offer
> > > > seamless handover to NSIS :-) Seriously, this concerns
> > > > robustness of CT protocol.
> > > >
> > > > -Rajeev
> > > >
> > > >
> > > > >
> > > > >             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 9:19 AM
> > > > > Subject: Re: [Seamoby] RE: [NSIS] Establishing QoS
> > after handoff.
> > > > >
> > > > > >
> > > > > > Hello Jim,
> > > > > >
> > > > > > James Kempf wrote:
> > > > > >
> > > > > > > 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.
> > > > > > >
> > > > > >
> > > > > > 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
> > > > > > > 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
> > > > > > > > >
> > > > > > > > > > -----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
> > > > > > > > > >
> > > > > > > >
> > > > > > > >
> > > > > > > > _______________________________________________
> > > > > > > > Seamoby mailing list
> > > > > > > > [email-masked]
> > > > > > > > https://www1.ietf.org/mailman/listinfo/seamoby
> > > > > > > >
> > > > > >
> > > > > >
> > > > > > _______________________________________________
> > > > > > Seamoby mailing list
> > > > > > [email-masked]
> > > > > > https://www1.ietf.org/mailman/listinfo/seamoby
> > > > > >
> > > >
> > > >
> > > > _______________________________________________
> > > > Seamoby mailing list
> > > > [email-masked]
> > > > https://www1.ietf.org/mailman/listinfo/seamoby
> > > >
> > >
> > >
> > > _______________________________________________
> > > Seamoby mailing list
> > > [email-masked]
> > > https://www1.ietf.org/mailman/listinfo/seamoby
> > >
> > > _______________________________________________
> > > Seamoby mailing list
> > > [email-masked]
> > > https://www1.ietf.org/mailman/listinfo/seamoby
> > >
> >
> >
>

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

---

From: "Phil Neumiller" <[email-masked]>
Date: Mon, 8 Apr 2002 20:56:32 -0400

> service bandwidth allocated (a QoS failure).

This is wishful thinking.  Lets finish the seamless handover over IP before
we get into "gold class service".  Convince me we have done just the
basics!