Subject: [Tsvwg] Starting WGLC: Implementing an ETS for Real-Time Services in the Internet Protocol Suite

From: Allison Mankin <[email-masked]>
Date: Tue, 15 Nov 2005 18:30:50 +0000

TSVWGers,

This is the start of the WGLC on draft-ietf-tsvwg-mlpp-that-works-02.txt

Note that James "Experiment" :) Polk, as one of the authors, recuses
himself from co-chair duty on this document.

The WGLC will go until Wednesday, November 30.

This action is from the previous determinations of the group.

Thanks,

Allison and Jon

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

---

From: ken carlberg <[email-masked]>
Date: Wed, 23 Nov 2005 08:43:54 -0500

Fred & James,

here are some comments on the draft.  part of it is a bit detailed in  
the hopes of articulating things reasonably well, but hopefully its  
constructive.

Happy Thanksgiving.

-ken

======================================

nits:
-----

page 4, Section 1, first paragraph.  You'll need to change "Internet  
Emergency Preference Service" to "International Emergency Preference  
Scheme".

page 13 of Section 2 (list of questions).  You may want to add the  
question of "Am I authorized to make this call?" -- which is  
conveniently addressed later on in section 2.4.  One could argue that  
the first question on administrative policy covers the subject of  
authorization, but my feeling is that linking the two is a bit of a  
weak argument.

page 15, first paragraph.  you start the sentence with "Figure X".   
you'll need to replace it with (I presume) "Figure 2"

Other Comments:
-----------------------

Item 1:  IEPS

This is a term/acronym that is mentioned in the following sections:  
Abstract, 1. Overview,  1.1 ETS,  1.2 Definition of Call Admission,   
2.1 Call Admission,  2.3.3 RSVP Operation,  and Appendix A.  In  
several cases, I think it would be better to swap out IEPS with  
MLPP.  In some other cases, you may need to change some text.

First, a quick comment on IEPS.  Systems like GETS in the US and  
eMLPP in GSM nets in the UK (and other countries) are considered  
national preference schemes.  IEPS, as presented in ITU E.106 (most  
recently updated in 10/03), is an extension of these national PSTN  
based systems to an international one where international PSTN  
gateways become part of the picture -- and of course, we don't have  
the notion of national/international boundaries in IP networks.   A  
short discussion on IEPS is mentioned in rfc-3689 and rfc-4190.

The concern I have in your document is that the context in which you  
use IEPS seems borderline correct at best.  Here is a blow-by-blow  
set of comments/suggestions.

- Abstract, 2'nd para, 1'st sentence.  I'd suggest changing "IEPS  
requires..." with
"MLPP requires...".  I explain why below because you repeat this in  
Section 1.

- Section 1, 1'st para, 1'st sentence.  Its easier to just remove the  
IEPS text.  The sentence is technically correct, but the following  
sentences gives the initial impression that IEPS deals with things  
like call preemption, which is not really the case.

- Section 1, 2'nd para, 1'st sentence.  I'd suggest changing the  
original text of

"IEPS requires a Call Admission Control procedure..."   to
"MLPP type systems over IP networks requires a Call Admission Control  
procedure...".

The reason for the suggested change is that IEPS assumes a CAC  
already exists.  E.106 (the ITU standard for IEPS) talks of  
extensions/requirements to circumvent the CAC to some degree for  
emergency type users.  In addition, your draft is primarily aimed at  
MLPP instead of IEPS.

- Section 1.1.  The original text is:

    "Before doing so, however, let us discuss the problem that ETS (and
    therefore IEPS) is intended to solve and the architecture of the
    system.  The Emergency Telecommunications Service [ITU.ETS.E106]  
is a
    successor to and generalization of two services used in the United
    States: Multilevel Preemption and Precedence (MLPP), and the
    Government Emergency Telecommunication Service (GETS).
    <snip>"

I'd suggest the following.

    "Before doing so, however, let us discuss the problem that ETS is
    intended to solve and the architecture of the system.  Emergency
    Telecommunications Service is a generalization of systems like
    the Government Emergency Telecommunications Service (GETS),
    and those based on Multilevel Preemption and Precedence (MLPP)."

Again, the use of IEPS seems a bit out of place in the original text.

- section 2.1, end of 4'th paragraph.  The term "IEPS domain" should
be changed to "MLPP domain", since the concept of domain doesn't
really apply to IEPS.

-----------------------------------------------------------------

Item 2: Multicast

I think it would be helpful to have a subsection in the end of your  
main document stating that the subject of multicast in the context of  
MLPP is a topic for a more in-depth discussion in a future document.

I understand that taken on its own, SIP and RSVP are designed to  
support multicast.  However, as part of your solution, you place a  
dependency on rfc-3312 (a framework for preconditions, such as bi- 
directional reservations and capacity admission using RSVP with  
SIP).  The headache with rfc-3312 is that it was written for unicast  
sessions -- I recently checked this with the primary author, who  
suggested a new draft for multicast :-)

But even outside of this, the implications of applying MLPP to a  
multicast type of application like push-to-talk are not clear.  Can  
one have different branches of the tree support different levels of  
priority?  Or do all branches need to be system high priority based  
on the source.  And does the type of tree (bi-directional versus  
single-source) play a role in the pre-conditions that are established?

None of the above questions are insurmountable, but I would feel  
better if the subject of multicast was addressed outside of your  
document.

-ken