Re: CT-Notify, Was [Seamoby] RE: [NSIS] Establishing QoS after handoff.

[Rajeev Koodli <[e-mail]>]

Hello Madjid,

just got back from a break.. Thank you for your note.
Our proposal was to enhance basic MIP handover with
context transfers, and to do CT gratuitously (aka proactively).
Back then, there was no other proposal (e.g., fast handover)
to enhance MIP handovers.

The draft (then and now) is independent of MIP protocol
itself. However, we think that it is highly beneficial to
time-synchronize CT with IP handover. And, our implemenation
experience with performing CT along-with MIP supports this.

Regards,

-Rajeev


Nakhjiri Madjid-MNAKHJI1 wrote:

> 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:[e-mail]]
> Sent: Tuesday, April 09, 2002 4:28 PM
> To: Nakhjiri Madjid-MNAKHJI1
> Cc: 'James Kempf'; Gary Kenward; [e-mail];
> [e-mail]; [e-mail]
> Subject: Re: [Seamoby] RE: [NSIS] Establishing QoS after handoff.
>
> Nakhjiri Madjid-MNAKHJI1 wrote:
>
> > 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.
>
> 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
>
> >
> >
> > madjid
> >
> > -----Original Message-----
> > From: James Kempf [mailto:[e-mail]]
> > Sent: Monday, April 08, 2002 1:32 PM
> > To: Gary Kenward; Nakhjiri Madjid-MNAKHJI1; Rajeev Koodli
> > Cc: [e-mail]; [e-mail]; [e-mail]
> > 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" <[e-mail]>
> > To: "'James Kempf'" <[e-mail]>; "Nakhjiri
> > Madjid-MNAKHJI1" <[e-mail]>; "Rajeev Koodli"
> > <[e-mail]>
> > Cc: <[e-mail]>; <[e-mail]>; <[e-mail]>
> > 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:[e-mail]]
> > > > Sent: April 8, 2002 11:42
> > > > To: Nakhjiri Madjid-MNAKHJI1; Rajeev Koodli
> > > > Cc: Kenward, Gary [WDLN2:AN10:EXCH]; [e-mail];
> > > > [e-mail]; [e-mail]
> > > > 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" <[e-mail]>
> > > > To: "'James Kempf'" <[e-mail]>; "Rajeev Koodli"
> > > > <[e-mail]>
> > > > Cc: "Gary Kenward" <[e-mail]>;
> > > > <[e-mail]>; <[e-mail]>; <[e-mail]>
> > > > 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:[e-mail]]
> > > > > Sent: Friday, April 05, 2002 12:22 PM
> > > > > To: Rajeev Koodli
> > > > > Cc: Gary Kenward; [e-mail]; [e-mail];
> > > > > [e-mail]
> > > > > 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" <[e-mail]>
> > > > > To: "James Kempf" <[e-mail]>
> > > > > Cc: "Gary Kenward" <[e-mail]>;
> > > > > <[e-mail]>; <[e-mail]>; <[e-mail]>
> > > > > 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" <[e-mail]>
> > > > > > > To: "James Kempf" <[e-mail]>
> > > > > > > Cc: "Gary Kenward" <[e-mail]>;
> > > > > > > <[e-mail]>; <[e-mail]>;
> > <[e-mail]>
> > > > > > > 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" <[e-mail]>
> > > > > > > > > To: "Gary Kenward" <[e-mail]>
> > > > > > > > > Cc: <[e-mail]>; <[e-mail]>;
> > > > > <[e-mail]>
> > > > > > > > > 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: [e-mail]
> > > > > > > [mailto:[e-mail]]
> > > > > > > > > > > > Sent: April 4, 2002 22:33
> > > > > > > > > > > > To: [e-mail]
> > > > > > > > > > > > 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:[e-mail]]
> > > > > > > > > > > > Sent: Thursday, April 04, 2002 3:35 PM
> > > > > > > > > > > > To: Shahrier, Sharif M.
> > > > > > > > > > > > Cc: '[e-mail]'
> > > > > > > > > > > > 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
> > > > > > > > > > > > [e-mail]
> > > > > > > > > > > > https://www1.ietf.org/mailman/listinfo/nsis
> > > > > > > > > > > >
> > > > > > > > > > > > _______________________________________________
> > > > > > > > > > > > nsis mailing list
> > > > > > > > > > > > [e-mail]
> > > > > > > > > > > > https://www1.ietf.org/mailman/listinfo/nsis
> > > > > > > > > > > >
> > > > > > > > > >
> > > > > > > > > >
> > > > > > > > > > _______________________________________________
> > > > > > > > > > Seamoby mailing list
> > > > > > > > > > [e-mail]
> > > > > > > > > > https://www1.ietf.org/mailman/listinfo/seamoby
> > > > > > > > > >
> > > > > > > >
> > > > > > > >
> > > > > > > > _______________________________________________
> > > > > > > > Seamoby mailing list
> > > > > > > > [e-mail]
> > > > > > > > https://www1.ietf.org/mailman/listinfo/seamoby
> > > > > > > >
> > > > > >
> > > > > >
> > > > > > _______________________________________________
> > > > > > Seamoby mailing list
> > > > > > [e-mail]
> > > > > > https://www1.ietf.org/mailman/listinfo/seamoby
> > > > > >
> > > > >
> > > > >
> > > > > _______________________________________________
> > > > > Seamoby mailing list
> > > > > [e-mail]
> > > > > https://www1.ietf.org/mailman/listinfo/seamoby
> > > > >
> > > > > _______________________________________________
> > > > > Seamoby mailing list
> > > > > [e-mail]
> > > > > https://www1.ietf.org/mailman/listinfo/seamoby
> > > > >
> > > >
> > > >
> > >
> >
> > _______________________________________________
> > Seamoby mailing list
> > [e-mail]
> > https://www1.ietf.org/mailman/listinfo/seamoby
>
> _______________________________________________
> Seamoby mailing list
> [e-mail]
> https://www1.ietf.org/mailman/listinfo/seamoby


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