Subject: Re: [Ieprep] Re-charter?

From: Janet P Gunn <[email-masked]>
Date: Fri, 1 Jul 2005 15:31:50 -0400

Closely related to the question "what is a session" is the question"what is
pre-emption?"  In the circuit switched world, a connection is "nailed up"
and there is little confusion on what constitutes a "session" or
"pre-emption".

But in the IP world, even if we restrict our discussion to SIP related
sessions, it is not so clear. Once a session has been established, how many
packets need to be dropped, how bad does the "quality" need to get, before
we declare that the  session has "failed" or been "pre-empted"?

Looking at it from another perspective, If traffic engineering indicates
that a given (IP) interface or route can accept 100 simultaneous calls with
a given QoS, but there is a mechanism to allow "special" calls to be
accepted (without actually tearing down existing calls) above that
threshold, at what point do I declare that the "special" calls are
pre-empting "regular calls"? As soon as I exceed the engineered
capacity(typically a utilization less than 100%)?  Once I exceed the raw
capacity (even though all calls may continue to meet the specified QoS)?
When a single call drops below its QoS specification? For how long?

And so on.

While the CONCEPT of "pre-emption based" vs. "non-pre-emption based"
carries over from the circuit switched world, and is useful in the IP world
(especially when IP networks are operating under rules and regulations
developed for the circuit switched world), the specific definition do not
carry over with any intrinsic clarity.

If we are going to go down this path, I think the first step is to agree on
a consistent set of definitions.

Janet

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

This is a PRIVATE message. If you are not the intended recipient, please
delete without copying and kindly advise us by e-mail of the mistake in
delivery. NOTE: Regardless of content, this e-mail shall not operate to
bind CSC to any order or other contract unless pursuant to explicit written
agreement or government initiative expressly permitting the use of e-mail
for such purpose.
----------------------------------------------------------------------------------------

                      Henning                                                                                               
                      Schulzrinne <hgs         To:      "King, Kimberly S." <[email-masked]>                      
                      @cs.columbia.edu         cc:      "Jon Peterson \([email-masked]\)"                         
                      >                        <[email-masked]>, [email-masked], "Ieprep \([email-masked]\)"    
                      Sent by:                 <[email-masked]>                                                            
                      ieprep-bounces           Subject: Re: [Ieprep] Re-charter?                                            

                      06/30/2005 10:48                                                                                      
                      AM                                                                                                    

Brief remark: I'm not sure what "sessions" refers to in the snippet
below. Is this addressed to the application layer session (say, SIP), a
network layer session (RSVP, NSIS) or something else entirely?

In general, given the tortuous history of IEPREP discussions, more
specificity as to the types of mechanisms and protocols affected would
be helpful, in my opinion. Are there existing drafts that will be used
as baseline (or input) or this is a from-scratch effort?

King, Kimberly S. wrote:

> 3. Some countries require civil networks to preempt sessions
> under state circumstances, and preemption is considered an
> absolute requirement in governmental networks in most
> countries. Unless implementation of these requirements can
> be objectively shown to threaten network health (via
> simulation or in operations), then the requirement needs to
> be considered by IEPREP and specific solutions must be
> developed.
>

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

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

---

From: Janet P Gunn <[email-masked]>
Date: Fri, 1 Jul 2005 16:01:39 -0400

I have a generic, high level comment.

If we are extending the charter from “requirements only” to “requirements
and solutions where not covered elsewhere”,  I think the solution space
should include solutions for “the evolution of GETS/WPS to IP” as well as
solutions for “the evolution of MLPP to IP”.

Similarly, the requirements and frameworks that have been previously
produced cover the entire IEPREP scope, both "sort of like MLPP" and "sort
of like GETS".  So I think it would be appropriate to have deliverables
such as
 "Emergency Threats Analysis for Commercial/Public Networks"
 "Requirements for Emergency Preparedness in Commercial/Public Networks"
"Potential Solutions for Commercial/Public Networks"
"Mechanisms to be Used by Commercial/Public Networks"
as well as the ones proposed for "Government/Military Networks".

I think that would be more useful than "Differences between GETS and MLPP
networks", especially since some of the differences which are significant
in the circuit switched world may be less significant in the packet
switched world.  But maybe if I saw an abstract of what was intended for
the document, I would change my mind.

Janet

                                                                                                                            
                      "King, Kimberly                                                                                       
                      S."                      To:      "Ieprep ([email-masked])" <[email-masked]>                        
                      <KIMBERLY.S.KING         cc:      [email-masked], "Jon Peterson \([email-masked]\)"        
                      @saic.com>               <[email-masked]>                                                   
                      Sent by:                 Subject: [Ieprep] Re-charter?                                                
                      ieprep-bounces                                                                                        

                      06/30/2005 10:24                                                                                      
                      AM                                                                                                    

Scott and I have asked for a 1 hour meeting slot at
the Paris IETF meeting to discuss a possible re-charter
of ieprep.  A provisional new charter is included below.

Kimberly

*****************************************
Draft revision
Internet Emergency Preparedness (ieprep) Charter

Description of Working Group:

Effective telecommunications capabilities are imperative to
facilitate immediate recovery operations for serious
disaster events including natural disasters (e.g.,
hurricanes, floods, earthquakes) and those created by man
(e.g., terrorist attacks, combat situations or wartime
events).  In addition, related capabilities should be usable
in normal command and control operations of military
services, which often have timeliness requirements even in
peacetime.  The IEPREP WG will address proactive and
reactive robustness and recovery from various outages using
three perspectives:

1. A commercial (i.e., or public) telecommunications
infrastructure

2. A governmental/military telecommunications infrastructure
that may retains sole ownership and administration of its
own resources

3. A governmental/military telecommunications infrastructure
that combines private resources and leverages public
infrastructure.  This scenario may be subject to local
policies, laws, and regulations.

Disasters can happen any time, any place, unexpectedly.
Quick response for recovery operations requires immediate
access to any public telecommunications capabilities at
hand. These capabilities include: conventional telephone,
cellular phones, and Internet access via online terminals,
IP telephones, and wireless PDAs. The commercial
telecommunications infrastructure is rapidly evolving to
Internet-based technology.  Therefore, the Internet
community needs to consider how it can best support
emergency management and recovery operations.

Potential disasters for governmental/military
infrastructures can extend beyond what might be experienced
by the commercial/public sector and can be anticipated to
some degree.  Thus, proactive mechanisms to address would-be
outages are required for these scenarios.

The IEPREP WG will work on these three perspectives
(commercial, governmental/military, and the combination) and
synergize common mechanisms and requirements into other
groups where possible, while maintaining a separate track of
IEPREP documents for the unique mechanisms and requirements
of each perspectives.

Now that the initial documents describe the broad problem
space and its salient characteristics, new efforts will
focus on specific requirements and solutions such as those
pertaining to the governmental/military sector.  One
document exists in the Transport Area working group of
interest to IEPREP that could satisfy a governmental
framework/BCP is draft-ietf-tsvwg-mlpp-that-works-XX.  This
document will progress to completion in that WG, yet be the
basis of more work in this IEPREP WG.  Some additional
efforts on the governmental/military track within IEPREP
will focus on this TSVWG document, analyze gaps, and provide
input where needed.

The following are four specific examples that can satisfy
the interests of governmental/military (and potentially,
commercial/public) emergency communications:

1. Conveying information about the priority of specific
flows (or sessions) that originate in a VoIP environment.
This could include a requirements effort to describe
extensions to NSIS or RSVP. Requirements for NSIS would be
forwarded to the NSIS working group. Requirements for RSVP
could be forwarded to tsvwg or worked on in IEPREP.

2. Nested VPNs require special considerations for routing
and QoS if nodes in the path that make these decisions
generally have limited information.

4. Non-real-time applications require measures of QoS and
other preferential treatments, as voice will not be the only
application used by IEPREP.

In the IETF, considerations for treatment and security of
emergency communications stretch across a number of Areas
and Working Groups, notably including the various telephony
signaling working groups, Protocol for carrying
Authentication for Network Access (pana), the open Transport
Area for path-coupled signaling and various operational
groups. IEPREP will cooperate closely with these groups and
with those outside of the IETF such as various ITU-T study
groups.

If there is an existing WG that can discuss the requirements
for extending their protocol or mechanism, IEPREP will
generate only a requirements document for that group to
discuss.

If there is not an existing WG that can discuss the
requirements for extending their protocol or mechanism,
IEPREP will prepare requirements and discuss the extension
of that protocol/mechanism or protocols/mechanisms within
IEPREP.

Goals and Milestones:

Done   Submit initial I-D of Requirements

Done   Submit initial I-D of Framework

Done   Submit initial I-D of Recommendations BCP

Done   Submit Requirements I-D to IESG for publication as an
       Informational RFC

Done   Submit Framework I-D to IESG for publication as an
Informational RFC

Dec 03 Submit Recommendations I-D to IESG for publication as
a BCP

Oct 05 Submit an initial I-D of Emergency Threats Analysis
of Government/Military Networks

Dec 05 Submit an initial I-D of Differences between GETS and
MLPP Networks

Feb 06 Submit an initial I-D of Requirements of
Government/Military Networks

Mar 06 Submit an initial I-D of Considerations for potential
solutions of Government/Military Networks

Apr 06 Submit an initial I-D of Mechanisms to be used by
       Government/Military Networks

Oct 05 Submit final I-D of Emergency Threats Analysis of
       Government/Military Networks to IESG as Informational
RFC

Feb 06 Submit final I-D of Requirements of
Government/Military Networks to IESG as Informational RFC

Apr 06 Submit final I-D of Mechanisms to be used by
       Government/Military Networks to IESG as BCP RFC

The working group will discuss re-chartering if additional
efforts are agreed upon by the WG (for example, work items
related to protocols outside existing WGs).

---

From: "Jason Michael Canon" <[email-masked]>
Date: Fri, 1 Jul 2005 16:54:05 -0400

I have a generic, high level question.

As a civilian in an emergency situation I call 9-1-1 to report some life 
threatening situation in my
house.  While the call is in progress a sufficient number of government 
officials evoke a GETS/WAS
or MOP capability and my call is effectively preempted or degraded to a 
level that is not tolerable.
My question is did a public policy debate result in a Congressional law or 
FCC Regulation that permits
the ITEM to craft enabling technology?  If so, a reference to the document 
would be greatly
appreciated.

Thanks,
Jason

----- Original Message ----- 
From: "Janet P Gunn" <[email-masked]>
To: "King, Kimberly S." <[email-masked]>
Cc: <[email-masked]>; <[email-masked]>; 
<[email-masked]>; <[email-masked]>
Sent: Friday, July 01, 2005 4:01 PM
Subject: Re: [Ieprep] Re-charter?

>                      <KIMBERLY.S.KING         cc:      [email-masked], 
> "Jon Peterson \([email-masked]\)"

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

---

From: "Jason Michael Canon" <[email-masked]>
Date: Fri, 1 Jul 2005 16:58:00 -0400

Sorry, I meant GETS/WPS and MLPP.

----- Original Message ----- 
From: "Jason Michael Canon" <[email-masked]>
To: "King, Kimberly S." <[email-masked]>; "Janet P Gunn" 
<[email-masked]>
Cc: <[email-masked]>; <[email-masked]>; 
<[email-masked]>; <[email-masked]>
Sent: Friday, July 01, 2005 4:54 PM
Subject: Re: [Ieprep] Re-charter?

Thanks,
Jason

---

From: Fred Baker <[email-masked]>
Date: Fri, 1 Jul 2005 14:20:06 -0700

On Jul 1, 2005, at 1:54 PM, Jason Michael Canon wrote:

> My question is did a public policy debate result in a Congressional 
> law or FCC Regulation that permits
> the ITEM to craft enabling technology?

Someone has to pass a law before we get to develop a protocol?

What law permitted us to develop the Internet?

Please. We are not permitted to do things that law/regulation 
precludes. If law/regulation doesn't preclude something, we don't have 
to bow and scrape in front of a regulator to get permission to think 
about it.

---

From: "Steve Silverman" <[email-masked]>
Date: Fri, 1 Jul 2005 18:17:18 -0400

MLPP is not intended for the public network.  If you're on the DoD private network, the fact that you're using
it means you have accepted the terms of service. Given the number of high priority users, there is minimal impact on routine traffic. 

One (I think ) outstanding question is whether 911 on the public net gets any special priority. Right now we don't have a way to give
priority to a call.  So your 911 call would be equally unintelligible.    

Steve Silverman

> -----Original Message-----
> From: [email-masked] 
> [mailto:[email-masked]]On Behalf
> Of Jason Michael Canon
> Sent: Friday, July 01, 2005 4:58 PM
> To: Jason Michael Canon; King, Kimberly S.; Janet P Gunn
> Cc: [email-masked]; [email-masked]; 
> [email-masked];
> [email-masked]
> > bind CSC to any order or other contract unless pursuant 
> to explicit 
> > written

---

From: "James M. Polk" <[email-masked]>
Date: Tue, 05 Jul 2005 17:15:22 -0500

Henning

At 10:48 AM 6/30/2005 -0400, Henning Schulzrinne wrote:
>Brief remark: I'm not sure what "sessions" refers to in the snippet below. 
>Is this addressed to the application layer session (say, SIP), a network 
>layer session (RSVP, NSIS) or something else entirely?

I believe this needs to be defined, but is loosely the combination of the 
two since a SIP session can be a call, and a reserved flow can be a call, 
and the combination can be a call. If you only use something like SIP, that 
a SIP session is the definition.

IEPREP isn't likely going to only use RSVP or NSIS for flows, but either in 
combination with something like SIP.

>specificity as to the types of mechanisms and protocols affected would be 
>helpful, in my opinion.

"more specificity" would entail a deep analysis of the problem space - 
which the first 3 new deliverables will cover. You are asking for an ID to 
be written to justify the recharter?

>Are there existing drafts that will be used as baseline (or input)

draft-ietf-tsvwg-mlpp-that-works is mention is this new charter

>or this is a from-scratch effort?
>
>King, Kimberly S. wrote:
>
>>3. Some countries require civil networks to preempt sessions under state 
>>circumstances, and preemption is considered an absolute requirement in 
>>governmental networks in most countries. Unless implementation of these 
>>requirements can be objectively shown to threaten network health (via 
>>simulation or in operations), then the requirement needs to be considered 
>>by IEPREP and specific solutions must be developed.
>

cheers,
James

                                 *******************
                 Truth is not to be argued... it is to be presented.

---

From: "James M. Polk" <[email-masked]>
Date: Tue, 05 Jul 2005 17:22:27 -0500

>and there is little confusion on what constitutes a "session" or

If RSVP is used (or NSIS when it becomes a protocol), the coupling of SIP 
(for example) to the reservation protocol reduces this confusion, do you 
not agree?

>sessions, it is not so clear.

For SIP, RFC3261 defines what a session is. IEPREP doesn't need to redefine it.

>Once a session has been established, how many

Perhaps this is part of the first two deliverables:

We should not be considering the definition of IP traffic in this WG.

>pre-empting "regular calls"?

the above is asking for a solution - which is premature at this point IMO

>As soon as I exceed the engineered

this will be part of an early doc IMO

>                       06/30/2005 
> 10:48 

cheers,
James

                                 *******************

---

From: "James M. Polk" <[email-masked]>
Date: Tue, 05 Jul 2005 17:31:35 -0500

Steve

At 06:17 PM 7/1/2005 -0400, Steve Silverman wrote:
>MLPP is not intended for the public network.

but... I have talked to many non-military customers that want it in their 
networks, so if the capability becomes available in products, others will 
use it.

>If you're on the DoD private network, the fact that you're using
>it means you have accepted the terms of service.

true true

>Given the number of high priority users, there is minimal impact on 
>routine traffic.
>
>One (I think ) outstanding question is whether 911 on the public net gets 
>any special priority. Right now we don't have a way to give
>priority to a call.

SIP RPH does this (even if it's only in ID format now)

>So your 911 call would be equally unintelligible.
>
>Steve Silverman
>

cheers,
James

                                 *******************

---

From: "James M. Polk" <[email-masked]>
Date: Tue, 05 Jul 2005 17:27:56 -0500

Jason

At 04:58 PM 7/1/2005 -0400, Jason Michael Canon wrote:
>----- Original Message ----- From: "Jason Michael Canon" 
><[email-masked]>
>house.

IEPREP doesn't address 911 calling, ECRIT does - and currently has frowned 
upon the use of prioritizing sessions/flows/calls in its efforts to date.

>While the call is in progress a sufficient number of government

As Dennis and others pointed out, currently, there is no preemption on the 
public circuit-switched networks for GETS. I believe the E911 example is 
the reason for the rule of "no preemption" by GETS.

cheers,
James

                                 *******************

---

From: Janet Gunn <[email-masked]>
Date: Tue, 05 Jul 2005 22:55:35 -0400

James M. Polk wrote:
> but... I have talked to many non-military customers that want it in 
> their networks, so if the capability becomes available in products, 
> others will use it.
> 
  eMLPP IS in use in at least one non-military network (outside the US).

Janet