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

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

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

---

From: "David R. Oran" <[email-masked]>
Date: Mon, 29 Mar 2004 09:47:10 -0500

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.