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

From: "Gary Kenward"<[email-masked]>
Date: Mon, 8 Apr 2002 16:08:42 -0400

Rajeev:

  A user starts up an application that requests a "gold service".
The protocol stack (perhaps an NSIS protocol stack) sends in a
request from MN to AN for gold service". A handover occurs, and 
(according to your scenario), the QoS context transfer fails (for some 
inexplicable reason). Some entity (the CT protocol stack according to 
your proposal) sends an indication to the MN that the QoS context transfer 
has failed (according to your proposal). How does the MN know what to do 
with this notice? The MN has to understand:
    
   - what a handover is at the IP level
   - what an IP context transfer is
   - that QoS context is (sometimes) transferred separately from other
     context
   - what the nature of the failure was, and thus, what action to take.
   - how and with what entity to initiate QoS re-negotiation.

  The knowledge for all of the above is either explicitly or implicitly
built into the MN. If the intent were for the MN to receive back a message 
that indicating "Gold service not available" then this is simply a session
disconnect. If the intent is for the MN to be told that "the QoS associated
with Gold service" has failed, then the MN has to know that Gold service
is actually a combination of features (AAA, security, HC), and to initiate 
negotiation, it has to be able to talk to the individual network entities
- entities which may not even exist within a given network (e.g. a provision
model).

 So, how is the MN ignorant of CT? Service models?

 Keep in mind, according to the CT requirements, CT does not know what
is contained in the data chunks it transports. Thus, at best, it can
only forward to the MN that data chunk or another, opaque data chunk.
Even this capability is a major modification to what should be
a simple state machine for the CT protocol.

Gary

> -----Original Message-----
> From: Rajeev Koodli [mailto:[email-masked]]
> Sent: April 8, 2002 14:42
> To: Kenward, Gary [WDLN2:AN10:EXCH]
> Cc: Nakhjiri Madjid-MNAKHJI1; [email-masked]; [email-masked];
> [email-masked]
> Subject: Re: [Seamoby] RE: [NSIS] Establishing QoS after handoff.
> 
> 
> Gary Kenward wrote:
> 
> >
> >
> > Rajeev:
> >
> > In order for the MN to "recreate the context", the MN would
> > 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.
> 
> >
> > 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).
> >
> 
> Well, the MN should use whatever protocol was
> used that established the context in the first place,
> including for 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?
> >
> 
> 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.
> 
> 
> >
> > 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.
> >
> 
> 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
> 
> 
> >
> > 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
> > >
> > >
> 
> 
> _______________________________________________
> nsis mailing list
> [email-masked]
> https://www1.ietf.org/mailman/listinfo/nsis
>

---

From: "Phil Neumiller" <[email-masked]>
Date: Mon, 8 Apr 2002 21:00:53 -0400

RE: [Seamoby] RE: [NSIS] Establishing QoS after handoff.Aaarrghgh!  See
below....
>----- Original Message -----
>From: Gary Kenward
>To: 'Rajeev Koodli'
>Cc: Nakhjiri Madjid-MNAKHJI1 ; [email-masked] ; [email-masked] ;
[email-masked]
>Sent: Monday, April 08, 2002 4:08 PM
>Subject: RE: [Seamoby] RE: [NSIS] Establishing QoS after handoff.

>  A user starts up an application that requests a "gold service".

Define "gold service"?  Define SeaMoby?  What on earth are we talking about.
The starting place
is seamless handover and always has been.  If we win that battle the rest is
relatively easy.  Why do
we focus on the chrome when we  need to work on the engine?

>request from MN to AN for gold service".

Nice.  Why don't we get UDP/TCP/SCTP to work first?

---

From: "Phil Neumiller" <[email-masked]>
Date: Mon, 8 Apr 2002 21:00:53 -0400

[email-masked]