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

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

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

Madjid

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

---

From: "Charles E. Perkins" <[email-masked]>
Date: Fri, 05 Apr 2002 15:08:22 -0800

(I trimmed the mailing lists and some of the trailing messages)

Hello Madjid,

The problem is that the reliability needs depend on the context
feature type.   Some contexts should be transferred reliably, and
some are not so crucial.  Reliable transfer for header compression
context is not as crucial as, say, security context -- for
various reasons, but at least because retransmission for the
header compression state would take too long.

Regards,
Charlie P.

---

From: "Charles E. Perkins" <[email-masked]>
Date: Fri, 05 Apr 2002 15:08:22 -0800

Hello Madjid,

Regards,
Charlie P.

---

From: Rajeev Koodli <[email-masked]>
Date: Fri, 05 Apr 2002 16:06:34 -0800

Hello Madjid,

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

Regards,

-Rajeev

---

From: Rajeev Koodli <[email-masked]>
Date: Fri, 05 Apr 2002 16:06:34 -0800

Hello Madjid,

Regards,

-Rajeev

---

From: "James Kempf" <[email-masked]>
Date: Mon, 8 Apr 2002 08:41:39 -0700

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.

---

From: "James Kempf" <[email-masked]>
Date: Mon, 8 Apr 2002 08:41:39 -0700

Madjid,

            jak

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

---

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

Charlie,

The other part of this is that header compression context can get
re-initialized automatically if it is lost, whereas security context,
for example, would require the participation of the MN. Thus, the
consequences of losing the header compression context are not as severe.

            jak

---

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

Charlie,

            jak

---

From: "James Kempf" <[email-masked]>
Date: Mon, 8 Apr 2002 09:08:37 -0700

Yes, exactly.
            jak

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

---

From: "James Kempf" <[email-masked]>
Date: Mon, 8 Apr 2002 09:08:37 -0700

Yes, exactly.
            jak