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

From: "Gary Kenward"<[email-masked]>
Date: Tue, 9 Apr 2002 15:49:10 -0400

James:

> -----Original Message-----
> From: James Kempf [mailto:[email-masked]]
> Sent: April 9, 2002 15:01
> To: Kenward, Gary [WDLN2:AN10:EXCH]; 'Rajeev Koodli'; Nakhjiri
> Madjid-MNAKHJI1
> Cc: [email-masked]; [email-masked]; [email-masked]
> Subject: Re: [Seamoby] RE: [NSIS] Establishing QoS after handoff.
> 
> 
> Gary,
> 
> >   Sorry, but I am a bit confused (as usual), are you saying
> > then that doing these functions with the CT protocol is less
> > heavyweight, and thus preferable?
> >
> 
> No, I'm saying that "dropping the session" is more 
> heavyweight. And what

Agreed. It would be better to try and fix things first. The real
question is at what level.

> do you mean by a session anyway?
> IP is connectionless.

Well...sessions do not require connections. But I have a feeling
we both do not want to open up that can-of-worms debate.

When I say "session", I mean all the collection of services/resources
that have been set up to support an IP flow, QoS, AAA, HC, etc.
If you have a better word, I'll use it.

> 
> I think what you mean is that all feature contexts for the MN 
> revert to
> the startup state, namely gone.

Ok. Except, that it may be only the feature contexts for a given
microflow. E.g just because a new AR cannot support EF PHB, does
not mean that the BE flows need to be dropped.

> 
> >   The default action, always, is for the session to be dropped.
> > This will ultimately force the MN to take action (oh, ok, some
> > MNs will simply halt and catch fire). Anything more then dropping
> > the session is simply to improve the handover performance under
> > various conditions. Typically, when one gets into exception 
> scenarios,
> > the solutions become too complex or degrade performance too much
> > to be justified against the potential gains. A classic example is
> > run time type/value checking in C/C++.
> >
> 
> My point is, if the MN never finds out about this, then it can't take
> any action.

My points is that this is not a CT protocol function. There are any
number of failure points for a service feature, and it is the responsibility
of the control entity for that service feature to notify the MN. 

> 
> >   If there are no recovery mechanisms for the potential faults
> > you describe, then does it make sense to build one into CT?
> > On the other hand, if these mechanisms are built into the handover
> > algorithm, or into the session support, then putting it into CT
> > would be redundant, would it not?
> >
> 
> I'm not saying that there should be recovery built into CT. What I am
> saying is
> that the MN has got to know when it has to redo signaling in order to
> reestablish
> stuff like it's AAA state or it's QoS state.

see comment above.

But, btw: how does the MN re-establish state without dropping the flow?
E.g. authentication? authorization? does re-establishing EF PHB make
any sense (if you cannot do it within a 100 ms, has the service not
been "dropped" anyway?) 

> 
> We went through this exact conversation on the MIP list with 
> respect to
> BETH. The
> MN doesn't get involved in handover with BETH, so it needs to be
> informed when
> BETH handover fails (in practice, we tell it when BETH 
> handover is about
> to fail).
> Then it can do standard MIP signaling in order to get a care 
> of address.
> 
> I'm willing to grant that having CT do feature by feature failure
> notification doesn't make sense,
> but I still think there needs to be some way to tell the MN that
> seamlessness has failed
> or is about to fail so it can take the right steps to restart the
> original network admission
> procedure.
> 
> I think this is needed if for no other reason than when the MN reaches
> the edge of the operator's
> domain, if the operator doesn't have the right business 
> agreements with
> the next operator, the MN
> has got to know to redo network entry, i.e. AAA from scratch, QoS from
> scratch, etc.

We agree on the first part of these two paragraphs. But, I am confused:
I am not aware of any current facilities within QoS/AAA that allows the MN
to repair AAA/QoS state as opposed to "building it from scratch". Certainly,
protocols can be extended, but then, they can also be extended to allow
for notification.

Consider:

   o CT fails for a specific context

   o CT somehow sends notification that the context for QoS has failed.

   o MN determines (somehow) what this failure message means (again,
consider that
CT can, at best, notify that a particular data chunk failed somehow at the
new AR, 
not why).

   o MN initiates a re-negotiation with the appropriate network entity (AAA
server
perhaps? an QoS Controller perhaps?)

Versus:

   o CT fails for a specific context

   o service feature entity at new AR determines that it is unable to
support 
     one or more of the MN flows either because it does not have the
context,
     or because it cannot support the context

   o new AR determines, perhaps using local policy decisions, what
mitigating
     action can to be taken locally (e.g. downgrade an AF flow to a BE flow
to 
     support forwarding until new negotiations can take place).

                                  - OR -

   o new AR determines, perhaps using local policy decisions, that the
control
     entity for the feature (e.g. the AAA server), needs to be notified
(e.g.
     the service lacks proper authorization), the control entity can then
take
     direct action (e.g. perhaps by some inter-system authorization
exchange).

                                  - OR -

   o new AR determines, perhaps using local policy decisions, that the MN is
     should fix the problem, and sends a notification.

Which scenario appears more flexible, more responsive, and more likely to 
support seamless handovers?

Gary

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

---

From: "James Kempf" <[email-masked]>
Date: Tue, 9 Apr 2002 14:46:44 -0700

Gary,

I'd be happy with:

        o CT is impossible to do with new AR for some reason, perhaps
failure of a specific feature context,
            perhaps new AR is in a different administrative domain, etc.

        o New AR notifies MN that it must redo network admission to get
back up its state, i.e. go back to
            the initial state before it entered the network.

but I would rather have:

        o CT fails for a specific feature context.

        o New AR notifies MN that it must redo signaling for that
specific feature only.

I think 1) is unavoidable for cases such as when an MN goes from one
operator's domain to another, and the two have no business agreement
allowing CT between them. I think 2) would be nice to have to smooth
corner cases, such as new AR runs out of a particular QoS allocation.
But I am sensitive that 2) should be handled by the particular feature,
i.e. if CT fails to transfer session keys, then the specific AAA feature
context code could perform the notification.

            jak

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

>    o new AR determines, perhaps using local policy decisions, that the
MN is

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

---

From: "James Kempf" <[email-masked]>
Date: Tue, 9 Apr 2002 14:46:44 -0700

Gary,

I'd be happy with:

but I would rather have:

            jak

----- Original Message -----
From: "Gary Kenward" <[email-masked]>
To: "'James Kempf'" <[email-masked]>; "'Rajeev Koodli'"

MN is