Subject: [Ieprep] WG Review: Recharter of Internet Emergency Preparedness (ieprep)

From: IESG Secretary <[email-masked]>
Date: Wed, 01 Nov 2006 13:59:52 -0500

A modified charter has been submitted for the Internet Emergency 
Preparedness (ieprep) working group in the Real-time Applications and
Infrastructure Area of the IETF. The IESG has not made any 
determination as yet. The modified charter is provided below for 
informational purposes only. Please send your comments to the IESG 
mailing list ([email-masked]) by November 7th.

+++

Internet Emergency Preparedness (ieprep)
=========================================

Current Status: Active Working Group

Chair(s):
Scott Bradner <[email-masked]>
Kimberly King <[email-masked]>

Real-time Applications and Infrastructure Area Director(s):
Jon Peterson <[email-masked]>
Cullen Jennings <[email-masked]>

Real-time Applications and Infrastructure Area Advisor:
Jon Peterson <[email-masked]>

Mailing Lists:
General Discussion: [email-masked]
To Subscribe: [email-masked]
In Body: subscribe ieprep
Archive: http://www.ietf.org/mail-archive/web/ieprep/index.html

Description of Working Group:

Effective telecommunications capabilities are imperative to facilitate
immediate recovery operations for serious emergency 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
operative in normal command and control operations of military services,
which often have timeliness requirements even in peacetime.

Disasters can happen any time, any place, unexpectedly. Quick response
for recovery operations requires immediate access to any
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.

The IEPREP WG will address proactive measures to congestion and recovery
from various outages using three perspectives:

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

2. An enterprise or governmental/military telecommunications
infrastructure that retains sole administration of its own network
resources

3. A governmental/military telecommunications infrastructure that
combines private resources and leverages public infrastructure. 

Now that the initial documents describing the broad problem space and its
salient characteristics have been completed, new efforts will focus on
specific requirements and solutions, such as those pertaining to the
governmental/military sector. The following are specific examples that can
satisfy the interests of governmental/military (and potentially,
commercial/public/enterprise) emergency communications: 

1. Under emergency circumstances, some countries require civil networks
to distinguish sessions based on the userA-s indication of precedence.
The network can use the precedence information to give priority to some
sessions over others, up to and including preemption of lower-precedence
sessions. In many countriesA- governmental networks, the capabilities
needed to support precedence-based preferential treatment are requirements
on the equipment and services used to build those networks.
As Internet-based technology continues to expand into civil and government
networks, requirements for precedence-based capabilities will need to be
developed. IEPREP will document these requirements as they pertain to
technologies of interest to IETF.

2. Specific countries may have additional considerations that define the
context in which they implement session precedence and preemption. For
example, network ownership constraints (which may differ from commercial
deployments), communities of interest including dial-plan considerations,
encryption assumptions and any limitations arising from differing security
levels, etc. that should be described before mechanisms can be proposed.
IEPREP should document the context for implementing solutions. In
addition, specific solutions must be developed when appropriate.

3. While voice was the driving application for IEPREP in the past,
preferential treatments will need to be applied to all applications
essential to emergency communications. Preferential treatment must address
robustness of both voice and non-real-time applications that share the
same infrastructure. The IEPREP WG should document the preferential
treatment mechanisms that are appropriate for any essential
communications.

In the IETF, considerations for treatment and security of emergency
communications stretch across a number of working groups, mostly in the
RAI Area, notably including the various voice/video signaling working
groups, instant messaging, and QoS signaling. IEPREP will cooperate
closely with these groups and with those outside of the IETF such as
various ITU-T study groups. In addition, IEPREP will pursue subject matter
experts (e.g., security) for specification review if such expertise does
not exist within the working group in order to ensure continued high
quality specifications.

If there is an existing group that can extend a protocol or mechanism,
IEPREP will generate only a requirements document for those groups to
evaluate. If there is not an existing group that can extend a protocol or
mechanism, IEPREP will prepare requirements and discuss the extension of
that protocol/mechanism or protocols/mechanisms within IEPREP. Before this
working group undertakes any new protocol development, a recharter is
required.

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 Produce an
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 06 Submit an initial I-D of Requirements of Government/Military
     Networks for Precedence and Preemption Dec 06 Submit an initial I-D
of ETS Terminology. This document should
     define ieprep related terms (e.g., ETS, GETS, MLPP) and explain their

     relationships and how they have been used in existing RFCs Dec 06
Submit an initial I-D of Deployment Considerations of Precedence
     and Preemption on Government/Military Networks. This document should
     clarify the context that Government/Military requirements must
operate.
Mar 07 Submit final I-D of Requirements of Government/Military Networks
     for Precedence and Preemption to IESG for publication as an
     Informational RFC
Mar 07 Submit final I-D of ETS Terminology to IESG for publication as an
     Informational RFC.
Jul 07 Submit an final I-D of Deployment Considerations of Precedence
     and Preemption on Government/Military Networks to IESG for
publication
     as an Informational RFC.
Aug 07 Submit an initial I-D of Mechanisms for Precedence and Preemption
     to be used by Government/Military Networks Sep 07 Submit final I-D of
Mechanisms for Precedence and Preemption to
     be used by Government/Military Networks to IESG for publication as a
BCP Dec 07 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).

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

---

From: "James M. Polk" <[email-masked]>
Date: Thu, 02 Nov 2006 13:02:26 -0600

At 12:41 PM 11/2/2006 +0200, Pekka Savola wrote:
>On Wed, 1 Nov 2006, Sam Hartman wrote:
> > I don't believe the new charter of ieprep working group belongs in the
> > IETF.  I understand why we chartered it here, and I believe that by
> > doing as much work as we have done so far in the IETF, we have done
> > something useful.  We've described the broad problem and have helped
> > to explain how it fits in the Internet context.  That was an important
> > thing for us to do.
>
>I think I'll agree with Sam.

I do not agree with Sam

>Having looked at the output of the WG,
>it already seems to include a couple of useful framework documents and
>about 4 requirements documents.

the framework RFCs are for within a single public domain.  The other RFCs 
are requirements based.

There is no architecture guidelines docs or peering guidelines or the like.

This is because the charter of the past didn't allow such work.

This new charter was supposed to allow such work AND investigate if 
protocol mods were needed to accomplish those arch and peering guideline 
efforts.

>This should already provide
>sufficient information how to continue the work.

continue the work.... where? by who? by another SDO?  Why?

>What isn't clear to me is what's the deployment level of these
>frameworks and various mechanisms.

there are no "various mechanisms" defined, there are only framework and 
requirements. Little can be accomplished with just that IMO.

>  We seem to have spent at least
>~4 years on this.

with both hands tied behind our backs, typing with with toes (so to speak).

>Overprovisioning and intra-domain TE seems to have been a popular approach,

in which IEPREP doc was "Overprovisioning" and "intra-domain TE " discussed?

>but apart from that, where has this been  deployed and how?
>
>Maybe we should let ITU, vendors, and/or deploying organizations to
>apply the existing techniques

What "techniques" have been defined?

I believe folks are assuming IEPREP has accomplished more than it was 
allowed to accomplish to date, and they ought to walk before they are 
allowed to run.  A framework doesn't allow IEPREP to even walk.

IEPREP was so constrained RFC 4542 had to be driven through another WG 
(TSVWG) because it wasn't allowed in IEPREP. Strike that, it would be 
allowed, but it would still be an individual ID because the charter 
wouldn't allow it to be a WG item even today.

SPeaking of RFC4542, it was a INFO instead of a BCP because of the IESG, 
which didn't want an explanation of more than a dozen EXISTING mechanisms 
and techniques to be considered a BCP (isn't that by definition a BCP 
<explaining how to put together a series of standards track RFCs>?).

>and frameworks, let this rest for 5 years and then come back to look if 
>there is something more to be said on the subject.
>
>--
>Pekka Savola                 "You each name yourselves king, yet the
>Netcore Oy                    kingdom bleeds."
>Systems. Networks. Security. -- George R.R. Martin: A Clash of Kings
>
>Ietf mailing list
>[email-masked]
>https://www1.ietf.org/mailman/listinfo/ietf

---

From: Fred Baker <[email-masked]>
Date: Sat, 4 Nov 2006 16:04:59 -0800

I have to say that my discussions with US DoD and DHS/NCS, and with  
their counterparts in other countries, doesn't suggest that the set  
of technical mechanisms is all specified. If we're looking only at  
voice, it is maybe so, but they're not looking only at voice.  
Questions abound around the mechanisms for sending an email and  
ensuring that it is delivered in a stated time interval on the order  
of minutes or that an indication of failure is returned to the  
sender, and other things.

I am also not at this point convinced that the ITU is the right place  
to have standards discussions regarding the Internet. There is not  
the demonstrated expertise, in my opinion.

So this is not all about mailing liaisons back and forth. If you want  
the standards done right, the experts on the topics need to be doing  
them.

On Nov 4, 2006, at 11:31 AM, Brian E Carpenter wrote:

> Hi,
>
> We now have a fair amount of guidance on how to work with other
> SDO's in general, which would certainly include ITU-T. Just to
> summarise:
>
>  "IAB Processes for Management of IETF Liaison Relationships,"
>  BCP 102, RFC 4052, April 2005.
>
>  "Procedures for Handling Liaison Statements to and from the IETF,"
>  BCP 103, RFC 4053, April 2005.
>
>  "Guidelines for Acting as an IETF Liaison to Another Organization,"
>  RFC 4691, October 2006.
>
> We also have some specific guidance on extensions, when another
> SDO sees a need for IETF protocols to be extended to meet their
> system requirements:
> draft-carpenter-protocol-extensions-04.txt (approved as a BCP, in  
> RFC queue).
> A lot of IEPREP work seems to belong in the extensions category.
>
> The question in my mind is whether the IEPREP work items are in the
> category where we can be confident that these mechanisms are  
> sufficient
> (i.e., we can rely on another SDO to provide realistic requirements
> in the form of liaisons) or whether we need the requirements to be
> developed in the IETF to get them right (i.e., realistic in terms of
> what Internet technology can actually achieve). I think the history
> of work related to IEPREP shows that it's all too easy for people
> steeped in the connection-oriented world to come up with unrealisable
> requirements for a packet network.
>
>     Brian
>

---

From: "Robert G. Cole" <[email-masked]>
Date: Mon, 06 Nov 2006 10:20:23 -0500

I whole-heartedly agree.  I believe the DoD must extend its notions of 
Precedence and Preemption to all applications, voice, video, web, ftp, 
mail, etc.  Mechanisms/protocols must be defined and consistent across 
applications and their interactions with services, e.g., DNS, SIP, etc., 
and with their interactions with transport protocols, e.g., TCP, and IP. 
  Mechanisms must apply for session and non-session based applications 
and therefore cannot solely be handled through extensions to SIP 
signaling.  Mechanisms/protocols must provide the necessary security, 
authentication and access controls for all of the applications types as 
well.

I strongly believe that the IETF is the place to address these issues. 
And I think they are best served in a coordinated fashion within the 
guidance of a single working group with liaisons to other working groups 
and organizations.

Thanks,
Bob

Fred Baker wrote:
> their counterparts in other countries, doesn't suggest that the set  of 
> technical mechanisms is all specified. If we're looking only at  voice, 
> it is maybe so, but they're not looking only at voice.  Questions abound 
> around the mechanisms for sending an email and  ensuring that it is 
> delivered in a stated time interval on the order  of minutes or that an 
> indication of failure is returned to the  sender, and other things.
> 
> to have standards discussions regarding the Internet. There is not  the 
> demonstrated expertise, in my opinion.
> 
> the standards done right, the experts on the topics need to be doing  them.
> 
>> draft-carpenter-protocol-extensions-04.txt (approved as a BCP, in  RFC 
>> queue).
>> category where we can be confident that these mechanisms are  sufficient

---

From: ken carlberg <[email-masked]>
Date: Mon, 6 Nov 2006 09:40:38 -0800

> It's not clear whether going on this way will achieve useful results
> in a useful amount of time.

the first part of the above is a matter of opinion, which I'll  
respect but disagree with.

the second is a red herring.  if you wish a more detailed explanation  
of the timeline of milestones in IEPREP, I'll be happy to take this  
offline with you and the working group chairs.  the timeline reflects  
poorly on several people (I'll objectively include myself in one  
instance) and groups and really doesn't need to be brought up here on  
the ietf list.

-ken

---

From: Janet P Gunn <[email-masked]>
Date: Mon, 6 Nov 2006 13:10:02 -0500

It seems to me that there are two separate issues.

First, should this work be done within IETF, or would it be better done in
ITU (or ATIS, etc.)?

Second, if it is done within IETF, should it be done in IEPREP, or some
other working group?

In Sam's earlier emails, he seemed to be saying that this work belonged in
ITU.  However his latest email accepts that a large amount of the work DOES
belong in IETF.

So that leaves the question of where (within IETF)  the work should be
done.  Since most of the "pieces" are related to existing IETF protocols,
in principle, the various extensions could each be addressed in the
relevant (non IEPREP) working group.

There are two problems with this.  The FIRST is that there is a need to
coordinate and "system engineer" the different "pieces" so that they will
work together, both at the requirements level and at the deployment level .
That fits well within the original charter of IEPREP, in terms of both
Requirements documents, and BCP documents.

In the particular case of SIP RPH, IEPREP served us well  in generating the
requirements document, which were passed on to SIPPING and SIP.  Now that
RPH has become RFC4412, and as we attempt to deploy it in the field, it is
clear that there will be a need for at least one BCP addressing the best
way to USE RFC4412 to meet each set of objectives.  (It is already clear
that there will be some distinct differences in the deployment of RFC4412
in the DoD "preemption-based" namespaces, and in the "public carrier"
"non-preemption-based" namespaces.)

There will also be new requirements.  Long term plans include the expansion
from voice to other  SIP-related services such as video conferencing, as
well as to non-SIP services such as email, file transfer, and even web
access.  IEPREP is the right place to work through these requirements.
The IEPREP working group needs to continue (even if restricted to the
original charter) to address these points.

The SECOND problem is logistics.  Every working group in IETF has limited
human resources to do the actual work.  The ones where the IEPREP "pieces"
COULD be pursued seem to be particularly  overworked.  As a result, the
IEPREP-related IDs tend to be viewed as the "poor stepchild" and have
difficulty getting working group status.  Even when they do get working
group status, they tend to progress rather slowly, because the working
group as a whole does not consider them high priority.  IEPREP, however,
provides a context in which these "pieces" DO have the critical mass to
progress at a more reasonable rate.   Coordination with  all other relevant
working groups is, of course, essential.

There are also IEPREP related IDs (both requirements related and solution
related) that have been unable to find a "home" in any other working
groups.  The ID addressing email priority in MTA to MTA transfer is such an
example.

It is for this reason (new work that  cannot find a home in any of the
current working groups, as well as work that is the "poor stepchild" in
current working groups) that the IEPREP charter needs to be extended to
include "mechanisms" as well as just requirements and BCPs.

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

             "Robert G. Cole"                                              
             <robert.cole@jhua                                             
             pl.edu>                                                    To 
                                       Fred Baker <[email-masked]>         
             11/06/2006 10:20                                           cc 
             AM                        Pekka Savola <[email-masked]>,   
                                       [email-masked], Kimberly King      
                                       <[email-masked]>, Brian E 
                                       Carpenter <[email-masked]>,     
                                       Scott Bradner <[email-masked]>,    
                                       Sam Hartman                         
                                       <[email-masked]>,            
                                       [email-masked]                       
                                                                   Subject 
                                       Re: [Ieprep] Re: WG Review:         
                                       Recharter of Internet    Emergency  
                                       Preparedness (ieprep)               

                                                                           

Thanks,
Bob

them.

---

From: Janet P Gunn <[email-masked]>
Date: Mon, 6 Nov 2006 13:31:22 -0500

There has also been a change in the external factors affecting the urgency
of this work.

 At one time the perspective (from at least some of us) has been "We know
we are going to need this stuff sometime in the future".

That perspective has changed to "There are deadlines in place.  If we don't
have solutions in place, our existing services are going to be degraded, or
fail".

This will tend to accelerate the rate of completion of the work.

Janet

---

From: Fred Baker <[email-masked]>
Date: Thu, 9 Nov 2006 13:19:43 -0800

I didn't write the proposed charter, and I don't intend to manage the  
next instance of the working group either. I will collaborate with  
the chairs on a charter if you like.

The key thing, though, is actually not this charter, as important as  
it is. It is the IETF leadership taking it upon itself to enable the  
work to progress in a timely fashion rather than having an infinite  
series of hurdles and road-blocks thrown in the way. Can you help us  
with that?

On Nov 5, 2006, at 1:25 PM, Sam Hartman wrote:

>>>>>> "Fred" == Fred Baker <[email-masked]> writes:
>
>     Fred> I have to say that my discussions with US DoD and DHS/NCS,
>     Fred> and with their counterparts in other countries, doesn't
>     Fred> suggest that the set of technical mechanisms is all
>     Fred> specified. If we're looking only at voice, it is maybe so,
>     Fred> but they're not looking only at voice.  Questions abound
>     Fred> around the mechanisms for sending an email and ensuring that
>     Fred> it is delivered in a stated time interval on the order of
>     Fred> minutes or that an indication of failure is returned to the
>     Fred> sender, and other things.
>
> Fred, if there are parts of the problem that clearly fall within the
> IETF, can you work on a narrowly focused charter that clearly says
> what you're going to work on and shows:
>
> 1) Why it is within the IETF's scope
>
> 2) What you plan to do?
>
> From the current charter I would have no idea at all that you were
> talking about email.
>
> --Sam

---

From: "Robert G. Cole" <[email-masked]>
Date: Wed, 15 Nov 2006 09:39:32 -0500

Brian,

I do not think anyone is suggesting the DoD drives IETF requirements. 
But, as a customer of IP services, networks and equipment, it should be 
treated as other customers and have their requirements considered into 
the overall IETF requirements for these services.

IMO, customer requirements should be written from a high-level 
capabilities/services perspective, not at the level of mechanisms or 
box-level functions.  Functional architectures, protocols, etc should be 
discussed and developed within the IETF.  And I think having an IEPREP 
WG in the IETF is the right venues for this type of work and coordination.

Thanks,
Bob

Brian E Carpenter wrote:
> Robert G. Cole wrote:
>> mail, etc.  
> ...
> This illustrates some of my concerns about this requirements work being
> done outside the IETF.
> 
> 1. The DoD doesn't determine IETF requirements. It's one stakeholder
> in one country; the IETF looks at things globally.
> 
> 2. The notion that solutions such as precedence and preemption
> are (a) requirements and (b) applicable to all applications just
> doesn't compute for me. We'd actually need to understand at a more
> basic level what the functional requirements are, in terms that are
> meaningful for a datagram network. I don't believe that will
> happen in ATIS or ITU-T.
> 
> Brian (personal opinion)

---

From: Fred Baker <[email-masked]>
Date: Wed, 15 Nov 2006 15:46:29 -0800

> I don't believe the new charter of ieprep working group belongs in  
> the IETF... the work that remains belongs somewhere else--probably  
> the ITU-T.

Let's address this directly.

ITU-T gave us a set of requirements in
    [3]  "Description of an International Emergency Preference Scheme
         (IEPS)", ITU-T Recommendation  E.106 March, 2000.

    [4]  "Description for an International Emergency Multimedia  
Service",
         ITU Draft Recommendation F.706, February, 2002.

    [5]  "Call Priority Designation for H.323 Calls", ITU Recommendation
         H.460.4, November, 2002.

    [6]  ITU, "Multi-Level Precedence and Preemption Service, ITU,
         Recommendation, I.255.3, July, 1990.

We had to rewrite them, resulting in

> http://www.ietf.org/rfc/rfc3523.txt
> 3523 Internet Emergency Preparedness (IEPREP) Telephony Topology
>      Terminology. J. Polk. April 2003. (Format: TXT=10190 bytes)  
> (Status:
>      INFORMATIONAL)
>
> http://www.ietf.org/rfc/rfc3689.txt
> 3689 General Requirements for Emergency Telecommunication Service
>      (ETS). K. Carlberg, R. Atkinson. February 2004. (Format:  
> TXT=21680
>      bytes) (Status: INFORMATIONAL)
>
> http://www.ietf.org/rfc/rfc3690.txt
> 3690 IP Telephony Requirements for Emergency Telecommunication Service
>      (ETS). K. Carlberg, R. Atkinson. February 2004. (Format:  
> TXT=13919
>      bytes) (Status: INFORMATIONAL)
>
> http://www.ietf.org/rfc/rfc4190.txt
> 4190 Framework for Supporting Emergency Telecommunications Service
>      (ETS) in IP Telephony. K. Carlberg, I. Brown, C. Beard. November
>      2005. (Format: TXT=69447 bytes) (Status: INFORMATIONAL)
>
> http://www.ietf.org/rfc/rfc4375.txt
> 4375 Emergency Telecommunications Services (ETS) Requirements for a
>      Single Administrative Domain. K. Carlberg. January 2006. (Format:
>      TXT=17037 bytes) (Status: INFORMATIONAL)

We also specifically addressed their requirements (in tsvwg)  
operationally:

> http://www.ietf.org/rfc/rfc4542.txt
> 4542 Implementing an Emergency Telecommunications Service (ETS) for
>      Real-Time Services in the Internet Protocol Suite. F. Baker,  
> J. Polk.
>      May 2006. (Format: TXT=99770 bytes) (Status: INFORMATIONAL)
>
> http://www.ietf.org/rfc/rfc4594.txt
> 4594 Configuration Guidelines for DiffServ Service Classes. J.
>      Babiarz, K. Chan, F. Baker. August 2006. (Format: TXT=144044  
> bytes)
>      (Status: INFORMATIONAL)
>
> http://tools.ietf.org/html/draft-ietf-tsvwg-diffserv-class-aggr
>   "Aggregation of DiffServ Service Classes", Kwok Ho Chan, 22-Oct-06
> and
> http://tools.ietf.org/html/draft-baker-tsvwg-admitted-voice-dscp
>   "An EF DSCP for Capacity-Admitted Traffic", Fred Baker, 6-Oct-06

The last two are in last call and in discussion in tsvwg respectively.

The remaining requirements, as I understand them, relate to more  
traditional internet applications: the delivery of email within a  
stated interval, reliable file transfer at a stated rate in the  
presence of imperfect links and competing traffic deemed by the  
administration to be of lower importance, instant messaging, and so on.

What is the argument by which you come to believe that traditional  
internet transports and applications that are standardized in the  
IETF are properly moved to other standards bodies?

---

From: Janet P Gunn <[email-masked]>
Date: Thu, 16 Nov 2006 08:03:11 -0500

> meaningful for a datagram network. I don't believe that will
Exactly.

In the circuit switched world, a circuit is either up or down, and
"preemption" means taking the circuit down.

But in the IP world, there is a full continuum of states in between. Some
of these are candidates for a useful service, and some of which aren't.
The understanding of this continuum, and of the (intended and unintended)
consequences is much stronger in the IETF than in the
historically-circuit-switched world.

Some of the possibilities in that continuum include (in no particular
order):
- Allowing extra sessions in, and permitting degradation in QoS across all
sessions.
- Allowing a higher packet drop rate across all the "lower priority" calls.
- Negotiating a lower bandwidth allocation, possibly accompanied by a
changing to a lower rate bandwidth codec when a higher priority session
needs to "preempt".
- Negotiating (or arbitrarily imposing) a different PHB (e.g. AF or BE
rather than EF) for lower priority sessions when a higher priority session
needs to "preempt".
- Different Capacity Admission Control mechanisms for different priority
sessions.

The analysis/understanding of these (and other) alternatives is much better
done in the IETF than in the historically-circuit-swiched SDOs.

Janet

---

From: "Dolly, Martin C, ALABS" <[email-masked]>
Date: Thu, 16 Nov 2006 07:29:59 -0600

Janet,

I agree that the items you listed below are best analyzed/discussed in
the IETF, for as long as real-life architecture deployment scenarios are
taken into account.

Martin
 
Janet Gunn wrote on 11/16:
Some of the possibilities in that continuum include (in no particular
order):
- Allowing extra sessions in, and permitting degradation in QoS across
all
sessions.
- Allowing a higher packet drop rate across all the "lower priority"
calls.
- Negotiating a lower bandwidth allocation, possibly accompanied by a
changing to a lower rate bandwidth codec when a higher priority session
needs to "preempt".
- Negotiating (or arbitrarily imposing) a different PHB (e.g. AF or BE
rather than EF) for lower priority sessions when a higher priority
session
needs to "preempt".
- Different Capacity Admission Control mechanisms for different priority
sessions.

The analysis/understanding of these (and other) alternatives is much
better
done in the IETF than in the historically-circuit-swiched SDOs.

Janet

---

From: "Brian F. G. Bidulock" <[email-masked]>
Date: Thu, 16 Nov 2006 07:01:38 -0700

Janet,

> "preemption" means taking the circuit down.

Well, no.   I think that I have mentioned here before in a previous
discussion on the topic of preemption that local telephone switches
often congest on the basis of line-side call attempts.  This often
happens during natural disasters than invoke a collective behaviour
and result in mass calling attempts (often to 911).  The result on
the switch is delayed dial tone (sometimes minutes depending on the
persistence of other callers).  It has always been technically possible
in the design of telephone exchanges (based on principles applied to
military switching systems) to preempt or further degrade service to
some lines to allow other lines a higher probability of completing a
call is a shorter interval of time.  Some local switches had a line
class option that would permit this.  Most jurisdictions, (and carrier
lawyers), deemed that, in the public telephony, the importance of a
telephone call cannot be determined by the line that it originates on,
as it surely can in the case of military telephony.  In public telephony
it is deemed only that the importance of a call can be determined by
its destination (e.g. 911) rather than its origin.  I think that the
same principles apply to public telephone calls regardless of whether
they traverse the so antiquited circuit switched network, or the new
fangled Internet.  I think most regulatory bodies responsible for
both agree with that too.  I don't think that whether idle capacity
is incremental in unit circuits or continous bandwidth really has
much to do with it.

--brian

-- 
Brian F. G. Bidulock    ¦ The reasonable man adapts himself to the ¦
[email-masked]    ¦ world; the unreasonable one persists in  ¦
http://www.openss7.org/ ¦ trying  to adapt the  world  to himself. ¦
                        ¦ Therefore  all  progress  depends on the ¦
                        ¦ unreasonable man. -- George Bernard Shaw ¦

---

From: Janet P Gunn <[email-masked]>
Date: Thu, 16 Nov 2006 10:03:17 -0500

Yes, we absolutely must  address them in the context of real-life
architecture deployment scenarios.

Janet

---

From: Fred Baker <[email-masked]>
Date: Tue, 14 Nov 2006 12:01:59 -0800

On Nov 14, 2006, at 8:36 AM, Brian E Carpenter wrote:
> 2. The notion that solutions such as precedence and preemption are  
> (a) requirements and (b) applicable to all applications just  
> doesn't compute for me.

They don't especially compute for me in the sense that the terms are  
used in the PSTN service; the Internet isn't the PSTN, and many of  
its applications operate in a very different sphere. That said, I  
among many others have worked with DoD to come up with something that  
actually does work in their environment. Basically, a PSTN-like  
service makes sense for applications that are PSTN-like, which would  
include voice, video, and certain kinds of sensor traffic. For  
elastic traffic, the point as elaborated by Col Tim Gibsen, then of  
DARPA, is that there are times when a file transfer or other  
transaction are mission critical in a certain sense and all other  
traffic is secondary, and there are certain communications that  
either are emails or are structurally similar to email (delay- 
tolerant store and forward messaging service) that none-the-less have  
to be delivered within a stated interval of time to a stated set of  
recipients. For these, the current NCID specified a traffic class  
that guarantees some amount of bandwidth to preferred traffic in a  
work-conserving manner (eg, the bandwidth is available to other  
traffic classes when not in use by its target traffic), and I think  
there are some application layer things to do as I mentioned in an  
email earlier in this thread.

Voice and video are, IMHO, largely a done deal, between RFC 4542, RFC  
4594, draft-baker-tsvwg-admitted-voice-dscp, and draft-ietf-tsvwg- 
diffserv-class-aggr. Francois has been working on related documents  
for the MPLS part of the network.

"Another traffic class" for elastic traffic requires no further  
specification - this is well known and proven technology, diffserv.  
Delay-sensitive email mail does IMHO require further analysis, and  
some in this thread have suggested that it should be a different  
protocol.

---

From: Curtis Villamizar <[email-masked]>
Date: Thu, 16 Nov 2006 19:02:53 -0500

> some in this thread have suggested that it should be a different  

Preemption in MPLS can be soft preemption (setting aside differences
of opinion about how signaling of soft preempt should be done for the
moment).  Soft preemption can be almost completely non-disruptive to
the flow being preempted, creating only a very small delay
discontinuity due to the change in delay along the old path that was
preempted and the new path that is set up using MPLS make-before-break
semantics.  For voice, no call drop, probably not even a noticable
click.

Even for hard preemption, there is at worst a fall back to IP and
reroute.  If there are priorities levels of ETS plus BE taking the
majority of capacity, only the BE traffic is substantially affected
and only until the reroute.  This is more disruptive than soft
preempt, but still a brief disruption and may not cause a call drops
if carrying the fussiest of traffic - tunnelled PSTN trunks.

Curtis

---

From: "Dolly, Martin C, ALABS" <[email-masked]>
Date: Thu, 16 Nov 2006 19:55:42 -0600

We do not need a different PHB,   but a separate EF code point

-----Original Message-----
From: Fred Baker [mailto:[email-masked]] 
Sent: Tuesday, November 14, 2006 3:02 PM
To: Brian E Carpenter
Cc: Robert G. Cole; Pekka Savola; [email-masked]; Kimberly King; Scott
Bradner; Sam Hartman; [email-masked]
Subject: Re: [Ieprep] Re: WG Review: Recharter of Internet
EmergencyPreparedness (ieprep)

---

From: Fred Baker <[email-masked]>
Date: Thu, 16 Nov 2006 17:23:58 -0800

On Nov 16, 2006, at 4:02 PM, Curtis Villamizar wrote:
> Preemption in MPLS can be soft preemption (setting aside  
> differences of opinion about how signaling of soft preempt should  
> be done for the moment)...
>
> reroute...

Those are both options, but IMHO have issues. One can't, for example,  
fall back and reroute to a different path if the bottleneck where  
preemption is occurring is the only path to the destination. Further,  
MPLS is one of many ways we have of building the network. Some of us  
still use IP...

What I have suggested to DoD is simpler. Imagine one defines two  
elastic traffic classes for class 1 and class 2 (whatever DSCP and  
application might be implied). Assign half the capacity to class 1  
and 5% to class 2 (let's presume that the other 45% is taken up with  
other stuff, irrelevant to the present example). In normal use,  
though, presume that one in fact finds 99% class 2 and 1% class 1.

Guess what, class 1 will experience relatively low delay and class 2  
will in fact use the available bandwidth, as our queuing is work- 
conserving. Should suddenly a whole bunch of class 1 show up, it will  
get up to its assigned capacity and class 2 will get squeezed,  
experiencing greater delay and potentially loss momentarily. To class  
2, it will look a lot like a re-route event. Reroute happens.

To my small mind, that has the same characteristics as preemption,  
but does so in a manner that is pretty consistent with elastic  
traffic in the global internet. I can look at the technology, the  
algorithms, and the network, and say what the implications are. So  
define a traffic class (ten if it suits you) for your higher  
precedence traffic.

Other proposals have been offered, like introducing different min- 
thresholds for different preference levels. This has a problem - it's  
not predictable. Let's imagine just for fun that my low precedence  
traffic is already in trouble - I am seeing a 10% drop rate at the  
time the higher precedence traffic shows up [pick your reason]. TCP  
is already, in that case, deep in its back-off behavior, and isn't  
going to back off a whole lot more. What will happen to the higher  
precedence traffic? It will get dropped too. But using two classes,  
fine, I change 10% loss to 80% loss and get the higher precedence  
traffic through with little harm.

Yes, I'm being extreme, but this topic is about the end cases. And  
yes, adding more bandwidth is always helpful. It isn't always an  
option, and under the scenarios in question (in some cases, just say  
"Armageddon") might be pretty difficult to predict in detail.