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

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).
>
> 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
> > >
> >
> >
>

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

---

From: Rajeev Koodli <[email-masked]>
Date: Tue, 09 Apr 2002 14:27:36 -0700

> 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

---

From: Rajeev Koodli <[email-masked]>
Date: Tue, 09 Apr 2002 14:27:36 -0700

Regards,

-Rajeev