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

From: "Gary Kenward"<[email-masked]>
Date: Mon, 8 Apr 2002 13:54:20 -0400

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

> -----Original Message-----
> From: Rajeev Koodli [mailto:[email-masked]]
> Sent: April 5, 2002 17:46
> To: Nakhjiri Madjid-MNAKHJI1
> Cc: Kenward, Gary [WDLN2:AN10:EXCH]; [email-masked];
> [email-masked]; [email-masked]
> Subject: Re: [Seamoby] RE: [NSIS] Establishing QoS after handoff.
> 
> 
> 
> 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
> >
> > -----Original Message-----
> > From: Rajeev Koodli [mailto:[email-masked]]
> > Sent: Friday, April 05, 2002 11:01 AM
> > To: Gary Kenward
> > Cc: [email-masked]; [email-masked]; [email-masked]
> > 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
> 
>

---

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

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.

---

From: Rajeev Koodli <[email-masked]>
Date: Mon, 08 Apr 2002 11:42:16 -0700

> have to understand the semantics of Context transfer, etc.,

The MN does not have to know the CT semantics.
It only needs to understand a notification message
that provides the error condition related to its
context.

> I doubt that the latter is going to happen (e.g. authentication).

Well, the MN should use whatever protocol was
used that established the context in the first place,
including for authentication.

> how often will this happen?

This is a drastic idea! I think we can do better.
For one thing, you still have connectivity which
you could use to notify the MN so that the MN
can resort to re-establishing contexts (or not). Besides,
CT is a protocol, and like any other protocol has
error cases and failure modes. There must be a
notification message that provides protocol
robustness.
An example that has been brought up is where
the transferred context is not useful, either
partially or entirely. You would like to notify
the MN when this happens.

> more over-the-air signalling.

And, why are these any better when CT fails compared
to notifying a MN ? Seems to me that a notification message
would not encumber any of the above overheads. You
leave it up to the MN.

-Rajeev

---

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

> This is a drastic idea! I think we can do better.

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 be one big
cell
after another.  Its going to be connections two or three crappy cells and
making the best use of them.

---

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

----- Original Message -----
From: "James Kempf" <[email-masked]>
To: "Gary Kenward" <[email-masked]>; "'Rajeev Koodli'"
<[email-masked]>; "Nakhjiri Madjid-MNAKHJI1"
<[email-masked]>
Cc: <[email-masked]>; <[email-masked]>; <[email-masked]>
Sent: Monday, April 08, 2002 2:25 PM
Subject: Re: [Seamoby] RE: [NSIS] Establishing QoS after handoff.

> to create the context in the first place, in the event the AR was unable

Don't you agree that there will need to be several target ARs all receiving
the context
simultaneously, possibly via an anycast addressing structure?

> could re-do its QoS signaling.

Reword as, for example, suppose that QoS context is transferred to "a newly
added AR", but the new AR can not interpret it.  The MN could choose to skip
using this AR completely.

---

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

Phil,

> simultaneously, possibly via an anycast addressing structure?

Sure, in IPv6. But there is still no guarantee that the transfer will
succeed.

> using this AR completely.

Right, but it would have to know that so it could move to a different AR
(if it had a choice).

            jak