Subject: RE: [NSIS] QoS-NSLP two-phase operation (was: RE: Plans for the p rotocol dra fts)

From: "Hancock, Robert" <[email-masked]>
Date: Mon, 29 Mar 2004 16:14:16 +0100

Dave,

(extracting from your text below): so far as I can tell,

> the reserve phase actually setting 
> the resources aside and doing admission control, but not actually 
> installing the state in the data plane. Only when the commit phase is 
> executed is data plane state installed.

is the same as my case (b), and 

> separate "how much resource is 
> available" and "please reserve resources" phases

is my case (a). I quite agree that these are totally different
(but sometimes I still can't tell which one people are referring to,
hence i put them both in). Or is there yet another possible meaning
which I have missed?

I agree also that (b) is the more interesting one (if it is the
same as what you are asking for).

On the question of whether the state handling to provide it interacts 
with the rest of the QoS-NSLP state handling (and has to be visible 
to it), at the moment I just don't see what the problems are - in 
fact, I only see problems doing it the other way. Maybe some
more examples would help (e.g. do you have pointers to the 
theft-of-service scenarios you mention?)

robert h.

> -----Original Message-----
> From: David R. Oran [mailto:[email-masked]]
> Sent: Monday, March 29, 2004 15:47
> To: Hancock, Robert; [email-masked]'; Cheng Hong
> Cc: [email-masked]
> Subject: Re: [NSIS] QoS-NSLP two-phase operation (was: RE: 
> Plans for the
> protocol dra fts)
> 
> 
> Terminology collision alert:
> 
> In most distributed systems, "two-phase operation" tends to 
> mean separate 
> reserve/commit phases, as opposed to what seems to be 
> discussed here. In 
> the NSIS universe, this translates into the reserve phase 
> actually setting 
> the resources aside and doing admission control, but not actually 
> installing the state in the data plane. Only when the commit phase is 
> executed is data plane state installed. (there are 
> elaborations where the 
> reserve phase installs some "negative" data plane state but I won't 
> complicate this thread by going into that).
> 
> Don't know quite what to do about this, other than to point 
> out that I 
> would like to make sure we can do reserve/commit phases in 
> NSIS since they 
> are arguably needed to avoid certain theft-of-serivce 
> scenarios. That said, 
> I suspect reserve/commit two-phase operation DOES affect the 
> NSLP protocol 
> state machines and can't be finessed with QoS models - the 
> state needs to 
> be explicitly modeled as part of the NSLP itself.
> 
> I don't have a strong opinion on whether separate "how much 
> resource is 
> available" and "please reserve resources" phases are needed 
> or not. We 
> don't have any implementation experience with the RSVP ADSPEC 
> scheme to 
> have a basis for comparison.
> 
> Dave.
> 
> --On Monday, March 29, 2004 3:00 PM +0100 "Hancock, Robert" 
> <[email-masked]> wrote:
> 
> > dear all,
> >
> > Basically I think I agree with Sven on this issue: two-phase
> > operation can/should be done in the QoS-Model (maybe in a generic
> > way); or, in any case, it doesn't need to be built into the
> > protocol operation.
> >
> > The specifics depend on what is really assumed to be the
> > semantic of the Phase-I-RESERVE.
> >
> > a) If it means "would resources be available right now?"
> > then this can be implemented quite happily with a QUERY of
> > some sort (I assume). The initiator has to take the chance
> > that the answer may change between the Phase-I message and
> > actually installing the reservation in Phase-II.
> >
> > b) If it means "I would like the following resources to be
> > guaranteed available when I ask for them" then this implies
> > creating some state in the network representing the guarantee.
> > But then the state installed by the Phase-I message has to
> > be managed just like any other reservation state, and that
> > includes e.g. handling path changes, teardown/rollback and
> > so on. So if you do decide to represent two phase operation
> > non-opaquely in the QoS-NSLP (e.g. as separate RESERVE and
> > COMMIT messages) then all these state handling rules will have
> > to be worked out for both (as well as the interactions between
> > the two). Keeping two-phase operation opaque to the NSLP would
> > seem to be much easier.
> >
> > There *are* some respects in which a Phase-I message could
> > usefully be processed differently from a Phase-II message.
> > Specifically, during Phase-I, you only need to know which
> > outgoing interface a reservation applies to, whereas in Phase-II
> > you need to know which specific packets are affected. If this
> > matters (e.g. you want to send a Phase-I message before you
> > know all the information about port numbers), this would imply
> > changing some information objects - even the flow identifier
> > at the GIMPS level - between messages. But it's precisely for
> > this sort of reason that we have the Session ID and that we
> > allow flow identifiers to change mid-session. (Maybe this use
> > case needs to be worked out in a bit more detail, but it seems
> > OK at first sight.)
> >
> > robert h.
> >
> > [partial reconstruction of thread follows]
> >
> >> > 3. some talk about 2-phase operation for RSVP. Any thought of
> >> > the same for NSLP?
> >> >
> >> > We discussed about a RESERVE/COMMIT model in QoS NSLP. At the
> >> > moment, we feel that this might be solved at the QoS model
> >> > level which is opaque to QoS NSLP.
> >>
> >> This may not be opaque to QoS NSLP.With this RESERVE/COMMIT model,
> >> QoS NSLP should include messages that could do the 
> roll-back action.
> >>
> >> Sven>> Can you clarify what the impact on QoS NSLP would 
> be? I would
> >> imagine the signalling to look exactly the same from QoS NSLP
> >> perspective
> >> with an additional indication to commit resources. It 
> seems that this
> >> difference mainly makes sense for the Resource Management
> >> Function (RMF),
> >> which does not participate in QoS NSLP processing anyway.
> >>
> >
> > [Cheng]
> >> I think this depends on whether we want to make the QoS 
> NSLP support
> >> RESERVE/COMMIT or letting individual QoS Model to support
> >> that. If the QoS
> >> NSLP needs to support it, some information element, e.g. a flag and
> >> corresponding RSN, should be included in the common header 
> of QoS NSLP
> >> messages.
> >>
> >> If the QoS Model is left to deal with it, the above
> >> information could be
> >> placed into QSPEC. Then, the QSPEC should contain an object
> >> defined for
> >> this
> >> purpose.
> >>
> >> Sven>> Agreed. But what did you mean with the rollback action?
> >
> > _______________________________________________
> > nsis mailing list
> > [email-masked]
> > https://www1.ietf.org/mailman/listinfo/nsis
> 
> 
> 
> 

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