Re: [Tsvwg] [NSIS] WG last call on draft-ietf-tsvwg-emergency-rsvp-05

[Gerald Ash <[e-mail]>]

All,
   
  Here are some last call comments on draft-ietf-tsvwg-emergency-rsvp-05.
   
  General comments:
   
  1. The emergency-rsvp approach does not prescribe end-to-end cross-domain consistent treatment of admission priority.  As stated in Section 2 (Overview of RSVP extensions and Operations):    
    "As an example of operation across multiple administrative domains, a 
   first domain might decide to provide network layer admission priority 
   to calls of a given Application Level Resource Priority and map it 
   into a high RSVP admission control priority inside the Admission 
   Priority Policy Element; while a second domain may decide to not 
   provide admission priority to calls of this same Application Level 
   Resource Priority and hence map it into a low RSVP admission control 
   priority."
   
  So in this approach an emergency telecommunications service (ETS, e.g., GETS) might *not* get uniformly high admission priority treatment across administrative domains (ADs), depending on how the policy decision points (PDPs) in each AD decide to populate the RSVP Admission Priority element.  
   
    This is in sharp contrast to the approach used in practice today for ETS/GETS, where high admission priority is applied end-to-end across domains.  One reference as to how this approach operates in practice today for ETS/GETS can be found in http://www.amazon.com/Traffic-Engineering-Optimization-Integrated-Networks/dp/0123706254/ (Chapter 9 also presents extensive modeling & simulation analysis/case studies to show how today's end-to-end approach can operate across domains in the Internet).
   
  It would be good to motivate the rationale for the emergency-rsvp approach and why it makes sense to *not* ensure high end-to-end admission priority across domains for ETS/GETS services.
   
  2. Presumably the emergency-rsvp admission priority approach is implemented (or planned to be implemented) in real network applications.  It would be nice to reference such implementations, existing or planned, if possible.
   
  3. The admission priority approach taken in nsis-qspec (http://www.ietf.org/internet-drafts/draft-ietf-nsis-qspec-19.txt) is consistent with today's practice of providing high admission priority for ETS/GETS end-to-end across administrative domains.  It does this by standardizing the admission priority values for the qspec object in an IANA registry, as specified in Section 7 (IANA considerations):    
    "Admission Priority Parameter (8 bits):
   The following values are allocated by this specification:
   0-2: assigned as specified in Section 6.2.9:
   Admission Priority 0: best-effort priority flow
                      1: normal priority flow
                      2: high priority flow
   The allocation policies for further values are as follows:
   3-63: Standards Action
   64-255: Reserved"

   
      It has been agreed on the nsis list to rename <Admission Priority> to <Y.2171 Admission Priority> in the qspec draft.  To be consistent with this change, the emergency-rsvp approach should also be renamed (e.g., to <RSVP Admission Priority>) to distinguish it from <Y.2171 Admission Priority>, and so that neither approach should be considered a 'generic' approach.

   

  Specific comments:
   
  4. Section 3.1 (Admission Priority Policy Element) of emergency-rsvp states:
   
    "Adm. Priority (Admission Priority): 8 bits (unsigned) 
   The admission control priority of the flow, in terms of access to 
   network bandwidth in order to provide higher probability of call 
   completion to selected flows. Higher values represent higher  
   Priority. A given Admission Priority is encoded in this information 
   element using the same value as when encoded in the Admission 
   Priority parameter defined in section 6.2.9 of [NSIS-QSPEC], or in 
   the Admission Priority parameter defined in section 4.10 of [DIME-
   PARAM]. In other words, a given value inside the Admission Priority 
   information element defined in the present document, inside the 
   [NSIS-QSPEC] Admission Priority parameter or inside the [DIME-PARAM] 
   Admission Priority parameter, refers to the same Admission Priority."
   
  The text is very unclear as to what it means that admission priority values are encoded 'using the same value' in the 3 different drafts?  Perhaps an example would help, but in any case it should be clarified.  Further, the text should be updated to note that the <rsvp admission priority> field is not directly comparable to the <Y.2171 Admission Priority> field in the qspec draft so as to avoid confusion.
   
  5. Sections A.1 and A.2 illustrate how the DSTE Maximum Allocation Model (MAM) and the DSTE Russian Dolls Model (RDM) can be used for support of rsvp admission priority.  http://www.amazon.com/Traffic-Engineering-Optimization-Integrated-Networks/dp/0123706254/ presents extensive modeling & simulation analysis/case studies to show how the DSTE maximum allocation with reservation (MAR) model (http://www.ietf.org/rfc/rfc4126.txt?number=4126) performs for ETS/GETS services and how MAR performance compares very favorably to MAM performance.  It would be appropriate to reference MAR as the third DSTE bandwidth constraints model available for consideration and perhaps also to reference the MAR/MAM performance analysis pertinent to emergency services.
   
  Jerry




Magnus Westerlund <[e-mail]> wrote:   This announces the second WG last call on "Resource ReSerVation Protovol 
(RSVP) Extensions for Emergency Services" with the intended status of 
proposed standard:

http://tools.ietf.org/id/draft-ietf-tsvwg-emergency-rsvp-05.txt

This is the second one due to changes and the interaction with documents 
in the NSIS and DIME WG. Please provide any comments on the TSVWG 
mailing list no later than 28th of March. (Yes, it is long but that is 
due to the meeting and that we have several other WG last calls ongoing).

Magnus Westerlund

IETF Transport Area Director & TSVWG Chair
----------------------------------------------------------------------
Multimedia Technologies, Ericsson Research EAB/TVM
----------------------------------------------------------------------
Ericsson AB | Phone [phone]
Torshamsgatan 23 | Fax [phone]
S-164 80 Stockholm, Sweden | mailto: [e-mail]
----------------------------------------------------------------------

_______________________________________________
nsis mailing list
[e-mail]
https://www.ietf.org/mailman/listinfo/nsis


       
---------------------------------
Never miss a thing.   Make Yahoo your homepage.