Subject: RE: [NSIS] Plans for the protocol drafts

From: [email-masked]
Date: Wed, 24 Mar 2004 09:03:52 +0100

Hi,

Thanks for your comments. I have a few reactions inline.

Best regards,
Sven

"Cheng Hong" <[email-masked]> on 24/03/2004 03:26:19

To:    Sven VAN DEN BOSCH/BE/ALCATEL@ALCATEL
cc:    <[email-masked]>, <[email-masked]>, "'Georgios Karagiannis'"
       <[email-masked]>, "'McDonald, Andrew'"
       <[email-masked]>, "'Allison Mankin'" <[email-masked]>
Subject:    RE: [NSIS] Plans for the protocol drafts

Hi Sven,

Please see some comments below inline.

Best regards

Cheng Hong

<snip>
>
> NSLP comments
> =============
>
> 1. Need for explicit teardown invoked by the AAA element?
>
> I think aspect is already possible. To clarify, we can extend
> the description of what may trigger the NSLP handler with AAA
> in addition to e.g. RMF. Teardown by an external element can
> be handled by a combination of a NOTIFY and a tearing RESERVE.

I think the teardown decision has to be made with more than a single
information source. The AAA element could trigger the teardown, but other
issues also need to be considered. As what we discussed in the mailing
list, to support the multi-homing, indication from the end node should also
be considered in decision making.

Sven>> This is related to our earlier discussion on indication to
teardown/retain reservation state by an end node. It is a related but
slightly different issue than what was requested during the review:
explicit teardown invoked by AAA element, which is possible. To support the
end node indication we need to add a flag, as we discussed/agreed before.

<Snip>
> 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.

> 4. Didn't see any way to do resource sharing across flows.
>
> There is, but maybe not for a general case. Two flows with
> the same session ID but different flow ID will share
> resources. This is used in special cases of mobility and
> route changes. GIMPS does have some wildcarding of flow IDs,
> which would probably get you to the same level of resource
> sharing as RSVP (to be checked).

The resource sharing is only meaningful inside each individual NSLP.
Therefore, the GIMPS may not be able to provide the necessary function
unless it is mandated that the session-ID would be unique across all
the NSLPs.

Sven>> Since the session ID is a large random identifier, why would it be
"less unique" across NSLPs than within one NSLP?

<snip>
> 6. Reservation priority is declared out of scope but is
> critically important. We can't just punt this. One thought is
> to have it be part of a set of "common facilities" that go
> across all the GIMPS applications. I bet there are a number
> of such common things which are not part of the transport but
> aren't specific to a particular signaling appication.
>
> We would like to receive input on this from the WG. Why do
> they think it is needed, what are the requirements, ...

This could be useful if we want to differentiate the flows, and assign
different priority for different flows. In that case, reservation for
the corresponding flows could also be assigned with priority.

Sven>> OK. Do you see it as part of the QoS NSLP or as part of the QoS
model (opaque to QoS NSLP, handled by RMF)?

> 7. Is there any capability for make-before-break so that
> reservations can be installed on multiple paths at the same
> time to deal with graceful mobility? It seems that the notion
> of flow/session separation captures part of this, but I don't
> see how it solves the double-booking problems on the common links.
>
> We have thought about a possible extensions of the SII
> object, but reservations on future paths conflict with the
> current NSIS charter. With the current spec, it is not
> obvious how this functionality could be provided. An
> extension of the SII would conceivably impact the GIMPS
> requirements as well.

Similar to the first question, it also relates to the decision of the tear
down.
In this make-before-break case, the reservation over the old path should
not
be
torn down before the handover finished. Therefore, a method has to be
incorporated
into the signaling for that.

As what we discussed earlier, a notification from the MN could be useful
for
that.

Sven>> Agreed. See my earlier response.

> 8. How does bi-dir reservation enforce symmetric routing?
>
> At present, we imagine that it should not enforce symmetric
> routing but make assumptions on one-end being on the path for
> both directions (whether it is sender+receiver initiated
> reserve, or remote initiated model). Binding of both
> reservation would happen at the end points.

Does this imply that at least one end of the flow would be the QoS NSLP
node?

Sven>> Do you want to support bi-directional reservation for cases where
the first QoS NSLP node on the path is different for the forward and
reverse direction? Bi-directional reservation is mainly an optimization.
Wouldn't you rather leave these "strange" cases unoptimized?

> 9. State refresh reduction (a la rfc2961): this is vital.
>
> We agree with the comment. The current draft hints at a
> solution with RESPONSE message. We will make this explicit in
> the next version.
>
> 10. Don't like multiple qos models. (Complicated, and can't work.)
>
> The proposal here is to see what the QoS model draft teams
> come up with and clarify exactly what is achieved when the
> QoS model work has progressed a bit.
>

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

---

From: "Cheng Hong" <[email-masked]>
Date: Fri, 26 Mar 2004 10:01:51 +0800

Hi Sven,

Thanks for your reply. Please see some further comments below:

<Snip>
> 
> 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.
> 
> 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.

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. 

<snip>
> The resource sharing is only meaningful inside each 
> individual NSLP. Therefore, the GIMPS may not be able to 
> provide the necessary function unless it is mandated that the 
> session-ID would be unique across all the NSLPs.
> 
> Sven>> Since the session ID is a large random identifier, why 
> would it 
> Sven>> be

Statistically, it would not be very much "less unique". But since this
feature we want to introduce here depends on the uniqueness of the ID, it
should be made explicit. Maybe some guideline should be given in framework
stating that different NSLP should use different session-ID. Otherwise, in
implementation, a node could conveniently reuse the same session-ID for
different NSLP applications since nothing forbids that. 

<snip>
> This could be useful if we want to differentiate the flows, 
> and assign different priority for different flows. In that 
> case, reservation for the corresponding flows could also be 
> assigned with priority.
> 

It depends on how the priority would be used. Does it have meaning across
the QoS Models? Will there be multiple QoS Model at each node shareing the
same RMF? My feeling is that make it part of QoS NSLP may be better or it
could be a mandated part of QSPEC. 

<snip>
> Does this imply that at least one end of the flow would be 
> the QoS NSLP node?
> 
> the first QoS NSLP node on the path is different for the 
> forward and reverse direction? Bi-directional reservation is 
> mainly an optimization. Wouldn't you rather leave these 
> "strange" cases unoptimized?

Agree. This doesn't have to be the focus at this stage. But should we state
clearly that this case is for future development?

best regards

Cheng Hong