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

From: "Hancock, Robert" <[email-masked]>
Date: Wed, 17 Mar 2004 10:08:15 -0000

hi,

for the GIMPS doc:

I've posted a discussion response to Dave's comments
shortly after the meeting. I think they are all clarifications
or editorial issues, with two exceptions:
- the looping issue (which i'll write something separate about)
- the NAT traversal issue, on which we know more work needs to
  be done (but there wasn't really a specific comment here).
  watch this space...

For Alex's 'general' comments, I'm still waiting for some
confirmation that I've understood the concerns correctly and
then I'll look at fixing them (actually in the framework 
document). His comments on GIMPS are I think again clarification
matters, specifically:
- Q: why per-flow routing info at the NTLP level? 
  A: the same reason NHOP/PHOP state is held per flow in RSVP;
     and also that messaging associations which terminate more
     than one IP hop away cannot be selected only by looking at
     the local forwarding table (==> per flow routing is needed).
     We could put more in 3.1 about this (not too much I hope).

- Q: Suggests flow-based routing?
  A: this is probably a response to the naming of an object as
     'flow routing information'. But this is not information about
     how to route the flow, it is information about the flow to 
     ascertain how it is routed (so the signalling can go the 
     same way). In fact, we will probably change this object to
     'message routing information' in the next version anyway.

If people have further comments on the GIMPS review comments,
please send them.

One question from me about document scope and structure (partly
brought up by the nature of the review comments): a lot of the
comments (the bulk, in fact) are "why is this like this?" or
"what is this bit for?" or "why not do it that way?" - in other
words, requests for explanation and design rationale. How much 
of that type of information should be reflected in the actual protocol 
document, given the need to balance two conflicting concerns:
- a general concern in the IETF that we do a bad job of capturing
  such information for later use; and
- a general concern in the IETF that all documents are too long.

If there are examples of how this has been handled in similar
protocol development activities that people would care to recommend
as a model to follow, that would be interesting.

r.

> -----Original Message-----
> From: Allison Mankin [mailto:[email-masked]]
> Sent: Tuesday, March 16, 2004 16:42
> To: [email-masked]
> Cc: [email-masked]
> Subject: Re: [NSIS] Plans for the protocol drafts
> 
> 
> Hi, all,
> 
> There should be mailing list discussion for each 
> protocol draft of the Early Review comments and how they
> will be addressed.
> 
> Allison
> 
> _______________________________________________
> nsis mailing list
> [email-masked]
> https://www1.ietf.org/mailman/listinfo/nsis
> 

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

---

From: [email-masked]
Date: Thu, 18 Mar 2004 14:01:54 +0200

Hi Allison,

> protocol draft of the Early Review comments and how they

As mentioned, there have been some discussions already started,
and authors have been discussing the impact of some of the issues
off of the list. 

I would hope that we could get updated documents out in a reasonable
tine, with the results of the discussions based upon the reviews 
from IETF 59. I encourage WG members to comment on the reviews were
were made at IETF 59.

thanks,
John

---

From: Attila Báder (IJ/ETH)<[email-masked]>
Date: Thu, 18 Mar 2004 14:38:36 +0100

Hi All,

Just a short comment: I think, questions 2 and 3 and RSVP-like operation example will be discussed in more detail in Cornelia's control load draft after specifying receiver-initiated reservation in QoS-NSLP.

Best regards,  Attila

> From: [email-masked] [mailto:[email-masked]]On Behalf Of
> [email-masked]
> Sent: Thursday, March 18, 2004 10:37 AM
> To: Allison Mankin
> Cc: [email-masked]; [email-masked]; Georgios Karagiannis;
> McDonald, Andrew
> Hi Allison, John, all,
> We have had a first discussion of the comments among the 
> authors and this
> is how we see the current status (per comment).
> 
> Best regards,
> Sven
> 
> 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.
> 
> 2. How is receiver selection based on ADSPEC done if 
> resources are reserved
> in the forward direction with RESERVE?
> 
> In the current sender-initiated model you can do a 
> QUERY/RESPONSE/RESERVE.
> This costs 0.5xRTT more than a PATH/RESV. As possible 
> optimization here
> could be to do a QUERY send the RESERVE and RESPONSE in parallel. This
> would have no impact on the protocol (only intelligence on 
> the receiver
> side). We will provide an example on receiver-initiated 
> reservation in the
> next version.
> 
> 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.
> 
> 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).
> 
> 5. Ditto for fate-sharing across flows (if you tear one down 
> you tear the
> fate-shared ones down)
> 
> Within QoS NSLP, you could regard this as a policy decision 
> taken by a QNE.
> However, we could think about a SESSION_FATE_SHARED object similar to
> BOUND_SESSION_IP. Is there any interest in fate sharing 
> between different
> NSLPs (e.g. qos-nslp/natfw-nslp)?
> 
> 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, ...
> 
> 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.
> 
> 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.
> 
> 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.
> 
> 
> 
> 
> 
> 
> Allison Mankin <[email-masked]>@ietf.org on 16/03/2004 17:41:31
> 
> Sent by:    [email-masked]
> 
> 
> cc:    [email-masked]

This communication is confidential and intended solely for the addressee(s). Any unauthorized review, use, disclosure or distribution is prohibited. If you believe this message has been sent to you in error, please notify the sender by replying to this transmission and delete the message without disclosing it. Thank you.

E-mail including attachments is susceptible to data corruption, interruption, unauthorized amendment, tampering and viruses, and we only send and receive e-mails on the basis that we are not liable for any such corruption, interception, amendment, tampering or viruses or any consequences thereof.

---

From: Kappler Cornelia <[email-masked]>
Date: Fri, 19 Mar 2004 12:16:18 +0100

Hi Attila and all, 

well, in principle the IntServ Controlled-Load Service and RSVP are independent. However when receiver-ini is specified in qos-nslp, I'll provide an example in my draft of how to use it for controlled-load. This would also include a description of the receiver selecting QoS parameters - basically bandwidth in this case - based on the "AdSpec" (or whatever the corresponding object is in NSIS - we'll work on this when specifying the QSpec)

Regarding RESERVE /COMMIT may be the right place to put this is in one of the Common Control Informations since it is going to be usable (potentially) by all QoS -signaling- models. I see this as borderline between qos-nslp and qos signaling models. 

[For people familiar with the control info details: RESERVE/COMMIT could also be located in the QoS signaling model specific control info, i.e. stackable, however defined as part of the "tool box", i.e. reusable by several models]

Cornelia

> -----Ursprüngliche Nachricht-----
> Von: Attila Báder (IJ/ETH) [mailto:[email-masked]] 
> Gesendet: Donnerstag, 18. März 2004 14:39
> An: [email-masked]; Allison Mankin
> Cc: [email-masked]; [email-masked]; Georgios 
> Karagiannis; McDonald, Andrew; Kappler Cornelia
> Betreff: RE: [NSIS] Plans for the protocol drafts
> 
> 
> Hi All,
> 
> Just a short comment: I think, questions 2 and 3 and 
> RSVP-like operation example will be discussed in more detail 
> in Cornelia's control load draft after specifying 
> receiver-initiated reservation in QoS-NSLP.
> 
> Best regards,  Attila
> 
> This communication is confidential and intended solely for 
> the addressee(s). Any unauthorized review, use, disclosure or 
> distribution is prohibited. If you believe this message has 
> been sent to you in error, please notify the sender by 
> replying to this transmission and delete the message without 
> disclosing it. Thank you.
> 
> E-mail including attachments is susceptible to data 
> corruption, interruption, unauthorized amendment, tampering 
> and viruses, and we only send and receive e-mails on the 
> basis that we are not liable for any such corruption, 
> interception, amendment, tampering or viruses or any 
> consequences thereof.
>

---

From: Attila Báder (IJ/ETH)<[email-masked]>
Date: Fri, 19 Mar 2004 12:31:26 +0100

Hi Cornelia,

> 
> Hi Attila and all, 
> 
> well, in principle the IntServ Controlled-Load Service and 
> RSVP are independent. However when receiver-ini is specified 
> in qos-nslp, I'll provide an example in my draft of how to 
> use it for controlled-load. This would also include a 
> description of the receiver selecting QoS parameters - 
> basically bandwidth in this case - based on the "AdSpec" (or 
> whatever the corresponding object is in NSIS - we'll work on 
> this when specifying the QSpec)

It would be nice. I tried to propose this because in Seoul we agreed that our application drafts should be focused more on signaling models than QoS models.

> 
> Regarding RESERVE /COMMIT may be the right place to put this 
> is in one of the Common Control Informations since it is 
> going to be usable (potentially) by all QoS -signaling- 
> models. I see this as borderline between qos-nslp and qos 
> signaling models. 
> 

I agree 

Best regards, Attila

> [For people familiar with the control info details: 
> RESERVE/COMMIT could also be located in the QoS signaling 
> model specific control info, i.e. stackable, however defined 
> as part of the "tool box", i.e. reusable by several models]
> 
> Cornelia
>

---

From: "Ash, Gerald R (Jerry), ALABS" <[email-masked]>
Date: Wed, 24 Mar 2004 09:17:07 -0600

Hi Sven,

Dave> 6. Reservation priority is declared out of scope
Dave> but is critically important. We can't just punt
Dave> this. One thought is to have it be part of a set
Dave> of "common facilities" that go across all the
Dave> GIMPS applications. I bet there are a number of
Dave> such common things which are not part of the
Dave> transport but aren't specific to a particular
Dave> signaling application.

Sven> We would like to receive input on this from the
Sven> WG. Why do they think it is needed, what are the
Sven> requirements, ...

I agree with Dave that 'reservation priority' is critically important to add.  IMO there should be a requirement for reservation priority (i.e., for emergency services/ETS/E911, etc.) for the NSLP QoS signaling.  The 'standard Qspec' being worked now by the QoS model draft teams can be the vehicle to introduce this.  As requested by John (and the WG), we will work out a common Qspec across models, and maximize commonality.

To maximize commonality, I think it preferable to make reservation priority a part of the common QoS NSLP rather than part of the individual QoS model (opaque to QoS NSLP).  

As discussed in 'NSIS Network Service Layer Protocol QoS Signaling Proof-of-Concept' http://www.ietf.org/internet-drafts/draft-ash-nsis-nslp-qos-sig-proof-of-concept-01.txt, reservation priority is a way to differentiate emergency services flows, and assign them a higher priority than normal or best-effort priority flows.  Requirements for reservation priority are suggested in Section B.4 'Support of Priority & Reliability Attributes':
a. Reliability can be requested in the form of a Priority Class for a specific network function, such as CAC priority.
b. There are a limited number of Priority Classes to ensure scalability (e.g., 3 classes), such as:
- CAC Priority Class: The urgency with which a service connection is desired (e.g., High, Normal, Best Effort).
- Restoration Priority Class: The urgency with which a service requires successful restoration under failure conditions (e.g., High, Normal, Best Effort).

Regards,
Jerry

---

From: Tschofenig Hannes <[email-masked]>
Date: Fri, 26 Mar 2004 13:08:40 +0100

hi cheng, 

you find a small comment inline:

> From: Cheng Hong [mailto:[email-masked]]
> Sent: Friday, March 26, 2004 3:02 AM
> To: [email-masked]
> Cc: [email-masked]; [email-masked]; 'Georgios Karagiannis';
> 'McDonald, Andrew'; 'Allison Mankin'
> Subject: RE: [NSIS] Plans for the protocol drafts
> 
> 
> 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.
> > 
> > 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.
> 
> 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
> > "less unique" across NSLPs than within one NSLP?
> 
> 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. 

i tried to address issues of the session id construction for a long time.
unfortunately, i haven't received too many comments yet. 
a discussion of the importance of a security property called sender
invariance can be found in the current mobility id and also in separate
draft: 
http://www.tschofenig.priv.at/drafts/draft-tschofenig-nsis-sid-00.txt

your comments are highly appreciated. 

ciao
hannes

> 
> 
> <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.
> > 
> > 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)?
> 
> 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?
> > 
> > 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?
> 
> 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
> 
> 
>

---

From: [email-masked]
Date: Fri, 26 Mar 2004 15:42:22 +0100

Hi Jerry,

Sorry for the delayed reply. Please find some comments inline.

Best regards,
Sven

"Ash, Gerald R (Jerry), ALABS" <[email-masked]> on 24/03/2004 16:17:07

To:    Sven VAN DEN BOSCH/BE/ALCATEL@ALCATEL, <[email-masked]>
cc:    "Ash, Gerald R (Jerry), ALABS" <[email-masked]>
Subject:    RE: [NSIS] Plans for the protocol drafts

Hi Sven,

I agree with Dave that 'reservation priority' is critically important to
add.  IMO there should be a requirement for reservation priority (i.e., for
emergency services/ETS/E911, etc.) for the NSLP QoS signaling.  The
'standard Qspec' being worked now by the QoS model draft teams can be the
vehicle to introduce this.  As requested by John (and the WG), we will work
out a common Qspec across models, and maximize commonality.

To maximize commonality, I think it preferable to make reservation priority
a part of the common QoS NSLP rather than part of the individual QoS model
(opaque to QoS NSLP).

As discussed in 'NSIS Network Service Layer Protocol QoS Signaling
Proof-of-Concept'
http://www.ietf.org/internet-drafts/draft-ash-nsis-nslp-qos-sig-proof-of-concept-01.txt
, reservation priority is a way to differentiate emergency services flows,
and assign them a higher priority than normal or best-effort priority
flows.  Requirements for reservation priority are suggested in Section B.4
'Support of Priority & Reliability Attributes':
a. Reliability can be requested in the form of a Priority Class for a
specific network function, such as CAC priority.
b. There are a limited number of Priority Classes to ensure scalability
(e.g., 3 classes), such as:
- CAC Priority Class: The urgency with which a service connection is
desired (e.g., High, Normal, Best Effort).
- Restoration Priority Class: The urgency with which a service requires
successful restoration under failure conditions (e.g., High, Normal, Best
Effort).

Sven>> I agree with you that reservation priority is needed and I believe
that the proposals that you mention are probably a good way of implementing
it if you want to support it. What I am not sure about is whether it should
be part of the QoS NSLP. Even if it is common to multiple QoS models, it
still would only affect the Resource Management Function (RMF) (unlike the
message priority) which makes it outside of the QoS NSLP scope in my
opinion. Anyway, I think it is good that the concept and the potential
solution matures in the QoS model draft team. We can decide when we see
what it turned out to be whether we still want to put it in the QoS NSLP
spec.

Regards,
Jerry

---

From: [email-masked]
Date: Fri, 26 Mar 2004 15:47:56 +0100

Hi Cheng Hong,

Thanks for your reply. Please see some more comments inline.

Sven

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

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,

<Snip>

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?

<snip>

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.

Sven>> OK, that would be a possibility: A node SHOULD NOT reuse the same
session ID for different NSLPs.

<snip>
> Sven>> OK. Do you see it as part of the QoS NSLP or as part of the QoS

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.

Sven>> In either case, I think the topic is now taken up by the QoS model
draft team which would be the right place for either of these outcomes. We
can decide where to put it based on the solution they propose.

<snip>
> "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?

Sven>> It can be listed as a case for future investigation.

best regards

Cheng Hong

---

From: "Tarapore, Percy S, ALABS" <[email-masked]>
Date: Fri, 26 Mar 2004 09:40:03 -0600

Sven,

Here is another reason why reservation priority should be given strong
consideration for inclusion in the QoS NSLP. Suppose an emergency
service session is being initiated through SIP. Currently, SIP does not
support the prioritization of session initiation and hence, some work
needs to be done in SIP to permit this (e.g., inclusion of resource
priority headers). Once this is defined, the interaction between SIP and
other protocols such as RSVP-TE will need to transfer the priority level
of the initiated session. Having reservation priority as an integral
part of QoS NSLP will greatly facilitate such interactions.

Percy S. Tarapore

-----Original Message-----
From: [email-masked]
[mailto:[email-masked]]
Sent: Friday, March 26, 2004 9:42 AM
To: Ash, Gerald R (Jerry), ALABS
Cc: [email-masked]; Ash, Gerald R (Jerry), ALABS
Subject: RE: [NSIS] Plans for the protocol drafts

Hi Jerry,

Best regards,
Sven

Hi Sven,

I agree with Dave that 'reservation priority' is critically important to
add.  IMO there should be a requirement for reservation priority (i.e.,
for
emergency services/ETS/E911, etc.) for the NSLP QoS signaling.  The
'standard Qspec' being worked now by the QoS model draft teams can be
the
vehicle to introduce this.  As requested by John (and the WG), we will
work
out a common Qspec across models, and maximize commonality.

To maximize commonality, I think it preferable to make reservation
priority
a part of the common QoS NSLP rather than part of the individual QoS
model
(opaque to QoS NSLP).

As discussed in 'NSIS Network Service Layer Protocol QoS Signaling
Proof-of-Concept'
http://www.ietf.org/internet-drafts/draft-ash-nsis-nslp-qos-sig-proof-of
-concept-01.txt
, reservation priority is a way to differentiate emergency services
flows,
and assign them a higher priority than normal or best-effort priority
flows.  Requirements for reservation priority are suggested in Section
B.4
'Support of Priority & Reliability Attributes':
a. Reliability can be requested in the form of a Priority Class for a
specific network function, such as CAC priority.
b. There are a limited number of Priority Classes to ensure scalability
(e.g., 3 classes), such as:
- CAC Priority Class: The urgency with which a service connection is
desired (e.g., High, Normal, Best Effort).
- Restoration Priority Class: The urgency with which a service requires
successful restoration under failure conditions (e.g., High, Normal,
Best
Effort).

Sven>> I agree with you that reservation priority is needed and I
believe
that the proposals that you mention are probably a good way of
implementing
it if you want to support it. What I am not sure about is whether it
should
be part of the QoS NSLP. Even if it is common to multiple QoS models, it
still would only affect the Resource Management Function (RMF) (unlike
the
message priority) which makes it outside of the QoS NSLP scope in my
opinion. Anyway, I think it is good that the concept and the potential
solution matures in the QoS model draft team. We can decide when we see
what it turned out to be whether we still want to put it in the QoS NSLP
spec.

Regards,
Jerry

---

From: "Roy, Radhika R, ALABS" <[email-masked]>
Date: Sat, 27 Mar 2004 16:30:06 -0500

Folks:

Here is the IETF draft what SIP is doing for the resources priority:

http://www.ietf.org/internet-drafts/draft-ietf-sip-resource-priority-03.
txt

Considering the above, NSIS WG can also decide what needs to be done for
development of NSIS protocols.

Best regards,
Radhika R. Roy

-----Original Message-----
From: [email-masked] [mailto:[email-masked]]On Behalf Of
Tarapore, Percy S, ALABS
Sent: Friday, March 26, 2004 10:40 AM
To: [email-masked]; Ash, Gerald R (Jerry), ALABS
Cc: [email-masked]
Subject: RE: [NSIS] Plans for the protocol drafts

Sven,

Percy S. Tarapore

-----Original Message-----

Hi Jerry,

Best regards,
Sven

Hi Sven,

Regards,
Jerry

---

From: [email-masked]
Date: Mon, 29 Mar 2004 07:26:00 +0300

Hi Percy,

> part of QoS NSLP will greatly facilitate such interactions.

At the TSVWG WG in Seoul, Fred Baker presented issues on Multi-Level 
Preemption and Precedence:

http://www.ietf.org/internet-drafts/draft-baker-tsvwg-mlpp-that-works-01.txt

I think we may like to consider similar functionality in the NTLP, as
this seems to be relevant to many applicaitons NSIS may serve.

John