Subject: RE: [NSIS] Submission of draft-ietf-nsis-qos-nslp-03.txt + early review comments update

From: Attila Báder (IJ/ETH)<[email-masked]>
Date: Wed, 12 May 2004 17:03:52 +0200

Hi Sven, Andrew and Georgios,

I went through the QoS-NSLP doc. and I have two main comments:

The first one is editorial: There are a lot of information that are repeated more times in the document: first in the Overview part then in the Design Decision and also in the Func. Spec. part, sometimes with very similar details. I know that there are a lot of aspects that should be described and it is difficult to handle it but I think the doc. would be much easier to read if this fractal-like structure could be eliminated. 

The second is related to bi-directional and receiver-initiated reservation. In both case it can happen that the receiver does not have the resource info for the reverse reservation but the sender has this info. There is a discussion in the open issues mentioning that this info may should be provided by a different application. However, QoS-NSLP provides two natural mechanisms to transmit this info: a) stacking two QSpec like in case of local QoS model example and b) sending a separate reserve message with a QSpec for the reverse path directly to the receiver (like in case of aggregation or reduced state examples). So I would suggest that QoS-NSLP support this function. 

Best regards, Attila

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]]On Behalf Of
> [email-masked]
> Sent: Tuesday, May 11, 2004 1:55 PM
> To: [email-masked]
> Cc: [email-masked]; McDonald, Andrew; Georgios Karagiannis
> Subject: [NSIS] Submission of draft-ietf-nsis-qos-nslp-03.txt + early
> review comments update
> 
> 
> Hi all,
> 
> We have submitted draft-ietf-nsis-qos-nslp-03.txt. While it 
> is working its
> way through the repositories you can find it at:
> http://nsis.srmr.co.uk/~adm/draft-ietf-nsis-qos-nslp-03.txt
> 
> Please find below a point-by-point discussion of how the early review
> comments were addressed.
> 
> Best regards,
> Sven
> 
> Comments on NSLP
> 
> - in general this doc is not as well written as NTLP and needs some
> editorial work. Parts are pretty hard to understand.
> 
> Sven>> We tried to clarify the document. Section 5 (message 
> formats and
> processing) is restructured.
> 
> - Policy control may involve "envelope resource utilitzation" 
> policy in
> addition to simple AAA. This means that hard synchronization 
> with the AAA
> policy state and the NSLP element may be necessary.
> - Is there a need for explicit teardown invoked by the AAA element?
> 
> Sven>> We updated section 1.2 to The 'local application case' 
> includes not
> only user applications (e.g. multimedia applications) but also network
> management (e.g. initiating a tunnel to handle an aggregate, or
> interworking with some other reservation protocol - such as 
> RSVP) and the
> policy control module (e.g. for explicit teardown triggered by AAA).
> 
> - How is receiver selection based on ADSPEC done if resources 
> are reserved
> in the forward direction with RESERVE?
> 
> Sven>> The draft describes receiver-initiated reservations in section
> 3.5.3. It basically uses QUERY as PATH. The QUERY message
> (sender->receiver) contains a QSPEC to can be used to provide 
> ADSPEC to
> receiver.
> 
> - some talk about 2-phase operation for RSVP. Any thought of 
> the same for
> NSLP?
> 
> Sven>> Section 8.2 states that we assume reserve/commit 
> functionality to be
> implemented by the QoS model.
> 
> - Didn't see any way to do resource sharing across flows.
> 
> Sven>> Section 4.2.4 discusses state handling. It states that resource
> sharing between flows within a session and between sessions (with
> BOUND_SESSION_ID) is assumed to be the responsability of the 
> QoS model.
> This is captured in section 8.1.
> 
> - Ditto for fate-sharing across flows (if you tear one down 
> you tear the
> fate-shared ones down)
> 
> Sven>> Section 4.2.6 discusses session binding. It introduces a
> NO_FATE_SHARING flag that enables/disables fate sharing between flows
> within a session and between sessions (with BOUND_SESSION_ID)
> 
> - 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.
> 
> Sven>> This was raised as a question to the mailing list. We 
> received 3
> views, mainly stating that reservation priority (preemption) 
> was not a QoS
> NSLP function. This is captured in section 4.5. Message priority is in
> scope for the QoS NSLP but relies on GIMPS. This is captured 
> in a GIMPS
> requirement (section 7.7). We will seek to confirm this 
> position at the
> interim meeting.
> 
> - 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.
> 
> Sven>> This issue was raised on the mailing list. The answers were not
> conclusive although the main stream seems to be that this 
> would require a
> charter extension. The proposal is to summarize pros and cons at the
> interim and decide on a way forward there.
> 
> - how does bi-dir reservation enforce symmetric routing?
> 
> Sven>> It doesn't. Bidirectional reservations are explained in section
> 3.5.4.
> 
> 
> 
> _______________________________________________
> nsis mailing list
> [email-masked]
> https://www1.ietf.org/mailman/listinfo/nsis
> 

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