Subject: Re: WG Review: Recharter of Internet Emergency Preparedness (ieprep)

From: Sam Hartman <[email-masked]>
Date: Wed, 01 Nov 2006 16:34:20 -0500

[I could not find the ITU's liaison to the IETF.  Scott, if such
exists, I'd appreciate you forwarding this to them.]

Hi.

I'm speaking here as an individual.  I'd like to build consensus for
my position both within the IESG and within the community, but I
realize that if I fail to build that consensus, I cannot make this
objection as a single IESG member.

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.

However the work that remains belongs somewhere else--probably the
ITU-T.  I propose that we work with ITU to see if they are interested
in the work and if so, use this as an opportunity to foster
cooperation with work going to the ITU.

In order for the proposed charter to be successful, the working group
will need to go far outside the IETF's normal technical mandate and
venture into the space of network design to come up with requirements
documents.  The technical aspects of this problem are only one of the
things going into successful requirements.

Based on my limited knowledge I believe that the ITU is in a better
position than the IETF to specify requirements and mechanisms for
national and government telecommunications networks.  I think we
should let them do their job just as we ask them to let us do our job
and to design the technical protocols that are increasingly being used
on those networks.

Naturally, the IETF should make any necessary modifications to IETF
protocols to implement IEPREP work regardless of where it takes place.

The main argument I've heard throughout the existence of ieprep for
why it needed to happen in the IETF is that if it happens elsewhere,
they'll do something we don't like or do it wrong.  Perhaps that was
once a valid argument.  However, I think we have enough of the details
of technical approaches that we find appropriate documented that we
can give sufficient input to another body on what approaches work on
the Internet.  I would assume we'd ask people working in this space to
take a look at the existing ieprep output, RFC 4542, RFC 4411,
draft-ietf-tsvwg-vpn-signal-preemption and other appropriate
documents.

I think that given this input another group could understand what
works well on the internet and could work both on requirements related
to the technology as well as the overall system architecture so we end
up with deployable solutions at national and governmental levels.

In addition, I believe that since the first part of the ieprep work
happened here, we would be in a good position to work with whatever
standards body did the work to scope the charter to favor technologies
that would work well on the Internet.

Thanks for your consideration,

--Sam

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

---

From: Pekka Savola <[email-masked]>
Date: Thu, 2 Nov 2006 12:41:17 +0200 (EET)

> to explain how it fits in the Internet context.  That was an important

I think I'll 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.  This should already provide 
sufficient information how to continue the work.

What isn't clear to me is what's the deployment level of these 
frameworks and various mechanisms.  We seem to have spent at least
~4 years on this.  Overprovisioning and intra-domain TE seems to
have been a popular approach, 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 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

---

From: Scott W Brim <[email-masked]>
Date: Thu, 2 Nov 2006 12:02:30 +0100

> exists, I'd appreciate you forwarding this to them.]

The ITU-T's liaison from SG13 to the IETF is Hui-Lan Lu.  CCed.

FYI SG13 is about to send something to the IETF asking for help on
technical issues in emergency telecommunications.  I'll ask them to
expedite it but you shouldn't expect it before the middle of next
week.  

swb

---

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:
>I think I'll agree with Sam.

I do not agree with Sam

>Having looked at the output of the WG,
>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

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

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

---

From: Sam Hartman <[email-masked]>
Date: Thu, 02 Nov 2006 14:30:43 -0500

>>>>> "James" == James M Polk <[email-masked]> writes:

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

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

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

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

Why does that belong in the IETF?  RFC 2418 gives a good set of things
to consider for determining whether work belongs in the IETF.  I will
try to write up a guideline by guideline analysis of this work,
although when I briefly examine the guidelines my continuing reaction
is that the work probably does not belong in the IETF.  If you have
time to write up such an analysis I'd be interested in what you come
up with.

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

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

My proposal is ITU-T--probably SG 13, although I don't understand ITU
internals enough to know for sure that's the right place.

Obviously, this assumes they want to do the work.

To propose concrete action, I think the IETF should draft a liaison
statement for action to the ITU asking for them to comment on whether
they see any current conflicts and on whether there are parts of this
work they would be interested in picking up.  Such liaisons are not
uncommon when appropriate; we had such an exchange with IEEE when the
trill working group was formed.

If the ITU says that they're not interested in these aspects of the
work, and no one else makes an alternative proposal, then I would not
object to the work being chartered in the IETF.  However if the ITU
would be interested in working on this problem space (or especially is
already work on this problem space), we need to carefully ask
ourselves why each aspect of the work being done in the IETF belongs
here.

--Sam

---

From: Pekka Savola <[email-masked]>
Date: Thu, 2 Nov 2006 23:16:01 +0200 (EET)

On Thu, 2 Nov 2006, James M. Polk wrote:
> the framework RFCs are for within a single public domain.  The other RFCs are
> requirements based.
> 

I guess by 'architecture guidelines' you refer to inter-domain 
guidelines as the framework RFCs already seem to deal at least to some 
extent with a single domain.  If you don't, you may mean something 
that operators would use.  It's not clear if one-size-fits-all 
guidelines could be made, or if this would be right place to try to 
seek it.

Is there already sufficient experience of getting multi-domain work?  
AFAICS, this hasn't generally been considered an easily solvable 
problem at an operational level.

Peering guidelines likely don't belong to the IETF, or has there been 
successful precendent for that kind of work in the past?  (I could say 
some examples, but I don't think those were very succesful, and those 
were from OPS area)

Even if this work was in the scope of IETF, at least these two seem 
more like subjects to be pursued in the Ops&Mgmt area.

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

Other SDOs if they're willing.  Organizations that actually want to 
deploy this stuff (if those exist in sufficient degree).  Vendors who 
want to push for this stuff.  That is to say -- is there enough 
deployment (and understanding what works and is deployable and what 
isn't) to justify more IETF work on the subject _right now_ ?

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

draft-ietf-ieprep-domain-frame-07.txt, RFC4190, RFC43745 to name a 
few.

> What "techniques" have been defined?

The framework documents talk a lot about certain kinds of DSCP PHBs, 
mappings between PSTN and VoIP, a particular end-to-end priority 
field, MPLS-like traffic engineering, access-controls to prevent 
DoSing priority treatment, active queue management techniques, drop 
priority techniques, etc. -- this already seems to be a significant 
toolbox.  It is not clear to me to what extent these have been used 
and do the job set out for IEPREP.  And if not, is the lack of use due 
to people solving the problem in other ways (or not at all) rather 
than the lack of mechanisms?

---

From: Brian E Carpenter <[email-masked]>
Date: Sat, 04 Nov 2006 20:31:46 +0100

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

---

From: Sam Hartman <[email-masked]>
Date: Sun, 05 Nov 2006 16:25:57 -0500

>>>>> "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: Pete Resnick <[email-masked]>
Date: Sun, 5 Nov 2006 14:38:59 -0800

On 11/4/06 at 4:04 PM -0800, Fred Baker wrote:

>sender...

That, in particular, seems like a relatively easy extension to RFC 
3461 (by adding some sort of additional parameter value to DELAY). 
Not exactly rocket science. Not exactly requiring spinning up a WG.

pr
-- 
Pete Resnick <http://www.qualcomm.com/~presnick/>
QUALCOMM Incorporated - Direct phone: (858)651-4478, Fax: (858)651-1102

---

From: Pete Resnick <[email-masked]>
Date: Sun, 5 Nov 2006 21:51:30 -0800

On 11/5/06 at 2:38 PM -0800, Pete Resnick wrote:

>>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 as someone kindly pointed out to me (thanks Philip), we already 
have that extension in RFC 2852 which defines said mechanism (thanks 
Chris).

pr

---

From: Pekka Savola <[email-masked]>
Date: Mon, 6 Nov 2006 19:16:47 +0200 (EET)

On Sat, 4 Nov 2006, Fred Baker wrote:
> 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.

Which seems to be an indication that even if this is pursued in the 
IETF, RAI area seems like a wrong place.  The better one would 
probably be Ops&Mgmt if there is general requirements gathering / 
framework work to be done.

However, it's not obvious whether this is necessarily the right thing 
to do in the IETF or in this manner.  It looks ieprep was chartered 
around IETF 53, and the deliverables were to be complete in 2002.  
Some of that work was completed relatively quick, some has taken a lot 
longer -- being still under evalution.  Initial charter also included 
'recommendations' but it's not clear to me what happened with that.

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

---

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

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

                                                                           

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.
>
them.
> 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: Sam Hartman <[email-masked]>
Date: Mon, 06 Nov 2006 13:19:33 -0500

>>>>> "Janet" == Janet P Gunn <[email-masked]> writes:

    Janet> It seems to me that there are two separate issues.

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

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

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

No.

I believe that the work specified in the new ieprep charter belongs in
ITU.

I believe that there is work that belongs in the IETF such as
extensions to IETf protocols like RSVP.  I don't think that work is
within the proposed ieprep charter

I acknowledged that extending IETF protocols belongs in the IETF.  But
IEPREP is not being chartered to do that.  I think the things in the
proposed IEPREP charter are not within the scope of what the IETF
should do.

---

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: "Dolly, Martin C, NPE" <[email-masked]>
Date: Mon, 6 Nov 2006 13:22:26 -0600

1) Should this work be done within the IETF?

Not all the work in this space is appropriate for the IETF (e.g.,
architecture dependent). The appropriate work (protocol
extension/definition) should be done in the IETF. If a protocol
extension or new capability is required, the protocol/capability work
MUST be done in the IETF. 

WRT, the problem definition and requirements: the initial analysis MAY
be done in another SDO (eg,. ATIS), and be brought to the IETF when a
gap/need has been identified. A service like ETS is supported and
deployed in certain architecture/deployment scenarios, whereby the
expertise is not in the IETF.

ETS Service Definition requirements are appropriate for ATIS. 

Side note: my focus is on the ETS service. All of the major players
(vendors, service providers, contractors,  and most importantly
CUSTOMER), attend and participate in the ATIS work.

2) If it is done within the IETF, where?

 I will save my opinion for a later time.

-

---

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

Thanks,
Bob

Fred Baker wrote:
> the standards done right, the experts on the topics need to be doing  them.
>

---

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

Before you all  jump all over me, I apologize for forgetting to remove the
corporate sig on my previous email.

---

From: Scott W Brim <[email-masked]>
Date: Fri, 3 Nov 2006 11:31:12 +0100

Excerpts from Sam Hartman on Thu, Nov 02, 2006 02:30:43PM -0500:
> work they would be interested in picking up.  

The liaison from ITU-T is supposed to be posted on the IETF liaison
site on Monday.  Watch for it.

---

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

no,it's quite a bit more than that.

So let's take the canonical hypothetical case. Nuclear-tipped pointy- 
end-of-the-spear things are coming over the horizon and one of a very  
small number of people (the president, a theatre commander, etc)  
needs to send a message to a larger-but-well-defined group of people  
(the set that wear 3-or-more stars perhaps plus certain civil  
authorities) that says "execute plan Z". This is the kind of thing  
that needs to be delivered within a few minutes to all concerned, and  
"I didn't get the email" and "but POP3 only polls every 15 minutes"  
aren't very good responses. A system used to exist that did this  
using some combination of telex machines and privates whose entire  
job in the military was to watch said machines for action, rip the  
message off, and put it in front of the intended recipient instantly  
regardless of what it took to do so. I'm told that it is now done  
using a certain commonly-deployed SMTP mail system.

Stepping a bit away from apocalyptic scenarios, there are other  
groups of people and far less dramatic scenarios to consider.

Now ask yourself how you would solve this. First, there has to be  
some form of trust system in which when an authorized person wants to  
send one of these messages all of the systems along the way are going  
to recognize that authority. In the military, that's easy - everyone  
knows what a "commander in chief" is. In the civilian sector, it  
becomes a matter of transitive trust - "I think so-and-so is  
authorized and you should too" across an administrative boundary of  
some sort. It requires some way to say in the email that the person  
is authorized to assert the status, assert the status, and provide  
appropriate credentials to allow the recipient MTA (because each MTA  
will have to do something about this) to verify the identity and  
apply the relevant policy. As with any email system, the big delays  
are the queues in the MTAs - what happens if a SYN is lost? we resend  
in an hour, four hours, tomorrow, and the next day, right? We need to  
resend in 30 seconds, perhaps, and if mumble time units elapse  
without successful delivery we need to initiate a response to the  
sender indicating that s/he should try another communication channel  
while we continue to retry this one. And oh by the way, there might  
be network bandwidth available to traffic of this category that we  
need to appropriately take advantage of.

Who do you want doing all of this? Not me, I'll betcha. I could  
contribute to the architecture, but there are security issues, SMTP  
issues, system-engineering (as in "use SMTP on the last hop" or "set  
POP/IMAP to poll every ten seconds") issues to address, and so on  
that you really want the experts in those areas addressing.

Those experts aren't in the ITU, and the ITU at this point doesn't  
have the expertise to even say what was said in my long paragraph  
above. Hand ieprep off to the ITU and one of two things will happen:  
(a) they will try to analyze the problem and get it wrong, or (b)  
they will send us a liaison saying "please go think about this". Good  
grief. We need to collectively go think about this. Let's not bury  
our heads in the sand and pretend we're the wrong people for the job.

I do believe that having a requirements-generating working group is a  
good thing. A point of frustration has been that in trying to discuss  
the matter around the IETF, we have our meetings and then have to not  
only convince other working groups to go solve them but convince each  
individual person in each individual working group that it has to be  
addressed. In tsvwg, for example, I developed solutions that were  
discussed in ieprep for over a year, moved to tsvwg and discussed  
there for over a year, ieprep in November 2003 formally told its ADs  
that they should accept the INFORMATIONAL DRAFT that described them,  
that waited for over another year, and was finally last called - and  
published as an RFC just a few months ago. When the only way to get  
anything accomplished is to threaten an appeal over management  
incompetence or obstinacy (neither of which I would like to believe  
were actually the case, but yes the appeal was threatened and only  
subsequently did glacial action start to happen). Excuse me, but that  
is not a good example of "rough consensus and running code". We need  
a means by which we can do something about these problems that  
includes the right community of experts and doesn't involve waiting  
to see who gets exhausted last.

---

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?

---

From: Sam Hartman <[email-masked]>
Date: Thu, 09 Nov 2006 16:48:45 -0500

>>>>> "Fred" == Fred Baker <[email-masked]> writes:

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

It's hard for me to do that because everything I have been able to
learn to date suggests that the work being chartered in ieprep should
not take place in the ietf.  I would be delighted to help make sure
that the work that you are doing in tsvwg proceeds well and that other
protocol extensions motivated by ETS and related requirements are
fairly considered in our process.  I'd be delighted to work to make
sure that the IETF works appropriately with other standards bodies.

But until I'm convinced that there is work that should be done in the
ieprep context, well, I'm not going to try and help you do it there.
What I will do is try to inform discussion by doing things like
suggesting we talk to ITU about how involved they want to be in this
space.  You'll probably believe that is putting obstacles in your way.

I can tell you that I'll listen to that input and that if I'm
convinced then I'll support you.  But no, I don't expect to be
convinced.

---

From: Scott W Brim <[email-masked]>
Date: Thu, 9 Nov 2006 17:29:04 -0800

> CUSTOMER), attend and participate in the ATIS work.

However, it is important that the IETF not *just* do protocols.  The
IETF needs to consider how proposed "architectures" fit in with all
the other requirements on the Internet.  The IETF doesn't do protocol
engineering, it does Internet engineering.  It is fine for other
organizations (not necessarily SDOs) to do service requirements and
scenarios.  They can *propose* architectures.  If the IETF can support
those architectures in ways that are consistent with overall Internet
design, then fine.  Otherwise the IETF should not be restricted to
just protocol extension/definition.  The IETF has to think of a bigger
picture.

swb

---

From: Scott W Brim <[email-masked]>
Date: Thu, 9 Nov 2006 17:29:04 -0800

swb

---

From: Fred Baker <[email-masked]>
Date: Thu, 9 Nov 2006 18:04:34 -0800

> CUSTOMER), attend and participate in the ATIS work.

yes, and for stuff that is limited to telephony services and will  
remain entirely within the borders of the United States, ATIS is a  
reasonable place to do it.

I observe that in the meeting you, Janet, and I (among many others)  
attended a few weeks ago, as Janet reported earlier in this thread,  
there were two representatives from non-US agencies. As a vendor, I  
have to sell product to both their agencies and to Janet's, and by  
extension to both their service providers and Janet's, which includes  
you. I'm looking for - and I think the non-US agencies are looking  
for - a service definition and feature definition that will be  
available in routers and switches regardless of vendor and will be  
defined in a trans-national manner.

ITU might define the service; in fact they have already done so, in  
giving us the famous fourteen glittering generalities, which Ken  
Carlberg and Ran Atkinson have gone to great lengths to turn into  
actionable objectives. I really think we need IETF expertise to help  
vendors like me have the right features for operators like you to  
implement it. We all have to be involved, and the IETF is an open  
forum in which that can happen.

What we don't need are glittering generalities.

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)

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)

---

From: Sam Hartman <[email-masked]>
Date: Thu, 09 Nov 2006 21:43:53 -0500

>>>>> "Scott" == Scott W Brim <[email-masked]> writes:

    Scott> However, it is important that the IETF not *just* do
    Scott> protocols.  The IETF needs to consider how proposed
    Scott> "architectures" fit in with all the other requirements on
    Scott> the Internet.  The IETF doesn't do protocol engineering, it
    Scott> does Internet engineering.  It is fine for other
    Scott> organizations (not necessarily SDOs) to do service
    Scott> requirements and scenarios.  They can *propose*
    Scott> architectures.  If the IETF can support those architectures
    Scott> in ways that are consistent with overall Internet design,
    Scott> then fine.  Otherwise the IETF should not be restricted to
    Scott> just protocol extension/definition.  The IETF has to think
    Scott> of a bigger picture.

Completely agree.  I'd rather see architectures and systems proposed
elsewhere, reviewed by the ietf, and then us develop the protocols.
There may be some cases where we do architecture work; I don't think
this is one of them.

---

From: [email-masked]
Date: Fri, 10 Nov 2006 12:17:43 +0000

> We need to 
> while we continue to retry this one.

Waiting 30 seconds would be unwise in the scenario described.
Instead of waiting, the sending application should be sending
2 or 3 copies of the message via different routes to ensure
that it gets there as quickly as possible.

For existing models on how to accomplish this in IP, you 
should look at the financial services industry where tickers
and other market datafeeds must get to the recipient as fast
as possible because millions of dollars are at stake. In this
environment, datafeeds are sent via multicast. Each packet is
duplicated and sent via two different multicast trees which 
travel over infrastructure which is entirel discontiguous, 
i.e. separacy is enforced right down to the physical layer.

It works well and something like this is likely to be the
right way to handle critical emergency communications. Note
that an important aspect of this type of solution is that it 
defeats IP routing's concept of the single best path for a packet.
This means that if you don't need the multiple recipients that
a market data feed requires, you might find a way to do something
similar with MPLS TE that is more suited to emergency comms.

> above. 

And the ITU does not have applications layer experts which
is what you need to design a communications solution for some
very specific and very important applications layer requirements.
Some people are assuming that lower level protocols need to
be *fixed* to enable this but I do not agree that is the case.

> good thing.

Yes. And get some other applications domain experts to contribute
such as people from the financial industry or SIAC. IMHO, the
financial industry treats this matter with much greater care
and importance than the defense and security sector because in
the financial services industry, the impact of communications
failures is immediate and can be severe. Unlike the defense and
security sector who must deal with events sporadically, in financial
services the events are numbered in transactions per second.

--Michael Dillon

---

From: "Dolly, Martin C, ALABS" <[email-masked]>
Date: Fri, 10 Nov 2006 11:33:04 -0600

WRT ETS: 
1. Architecture  and service definition/requirements is better fit in
ATIS, with some ITU work.
2. Refinement of requirements for definition of Internet protocols in
the IETF
3. ATIS Standards/Implementation requirements to further ensure
interworking/interoperability

Internet Protocol expertise is clearly here in the IETF, but by the same
token Service and deployed network architecture expertise is where the
service providers "actively" participate, which is ATIS (and where
needed the ITU).

---

From: Scott W Brim <[email-masked]>
Date: Fri, 10 Nov 2006 18:31:29 -0800

> There may be some cases where we do architecture work; I don't think

Please help me figure out the essential differences between
"architecture" that should be done in the IETF and "architecture" that
can be done elsewhere.

---

From: "Dolly, Martin C, ALABS" <[email-masked]>
Date: Sat, 11 Nov 2006 00:10:51 -0600

For one, I have yet to see a B2BUA (SBC) in any IETF document. They are
in every service provider network. So, not to reflect them is an
illusion as best. 

-----Original Message-----
From: Scott W Brim [mailto:[email-masked]] 
Sent: Friday, November 10, 2006 9:31 PM
To: Sam Hartman
Cc: Dolly, Martin C, ALABS; Janet P Gunn; Robert G. Cole; [email-masked];
[email-masked]; Scott Bradner; Fred Baker; Pekka Savola
Subject: Re: [Ieprep] Re: WG Review: Recharter ofInternet Emergency
Preparedness (ieprep)

---

From: Sam Hartman <[email-masked]>
Date: Sat, 11 Nov 2006 19:59:32 -0500

>> 
    >> 
    >> Completely agree.  I'd rather see architectures and systems
    >> proposed elsewhere, reviewed by the ietf, and then us develop
    >> the protocols.  There may be some cases where we do
    >> architecture work; I don't think this is one of them.

    Scott> Please help me figure out the essential differences between
    Scott> "architecture" that should be done in the IETF and
    Scott> "architecture" that can be done elsewhere.

Scott, we discussed this in person.  I think that when I say
architecture that can be done elsewhere, I'm thinking of things you
would call service descriptions and service requirements.

Some people might also consider a document that took a technical
architecture, described deployment and operational considerations for
it, and described a framework for business agreements to deal with
intra-domain aspects of the technology an architecture.

--Sam

---

From: Brian E Carpenter <[email-masked]>
Date: Tue, 14 Nov 2006 17:36:40 +0100

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

>      TXT=17037 bytes) (Status: INFORMATIONAL)

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

>      Real-Time Services in the Internet Protocol Suite. F. Baker,  
> J. Polk.
> 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: Sam Hartman <[email-masked]>
Date: Wed, 15 Nov 2006 20:30:26 -0500

>>>>> "Fred" == Fred Baker <[email-masked]> writes:

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

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

Fred, first I've argued all along that the standardization of IETF
protocols belonged in the IETF.

As this discussion has moved along, it has become clear that I simply
do not understand the work being proposed.  That only really hit me
with this message, although I've had a growing suspician that I'm
failing to understand the charter for about a week.

I really appreciate your efforts to show me that.  I'd like to work
with you and the chairs to help understand what ieprep proposes to do.
I'm likely to claim at the end of that discussion that the current
charter's scope is unclear and to try and propose more clear text.

I still do have major reservations about ieprep.  Perhaps some of
those will go away as we discuss what the group is doing.

For IESG process reasons, I need to enter a position tonight or
tomorrow that is a superset of any formal objection I will have.  I
can remove objections though and will be happy to work with you to do
that.

I appreciate your continued help in understanding this issue.

---

From: Pekka Savola <[email-masked]>
Date: Thu, 16 Nov 2006 09:32:16 +0200 (EET)

On Wed, 15 Nov 2006, Fred Baker wrote:
> We also specifically addressed their requirements (in tsvwg) operationally:
> 
> >     Babiarz, K. Chan, F. Baker. August 2006. (Format: TXT=144044 bytes)
> >     (Status: INFORMATIONAL)
> >

All of these documents are, or are aimed at Informational.  I do not 
see how those could define DSCP codepoints or behaviour -- doing so 
requires Standards Action and certain codepoint pools are reserved for 
local/private use (which specifying them is not).  I wonder how wide 
IETF or operator consensus is behind this work.

---

From: Brian E Carpenter <[email-masked]>
Date: Thu, 16 Nov 2006 11:10:59 +0100

Fred,

Fred Baker wrote:
> 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's exactly why I disagree with Sam - I think that writing up
these functional requirements in a way that relates technically to
how the Internet works can be done best in the IETF. I do believe
the charter needs more work to make it clear to newcomers that this
is the job to be done. Probably, there are too many words in the
draft charter, not too few.

     Brian

> 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: "Dolly, Martin C, ALABS" <[email-masked]>
Date: Thu, 16 Nov 2006 06:00:53 -0600

Pekka,

At least two carriers, AT&T and Verizon support, "An EF DSCP for
Capacity-Admitted Traffic", Fred Baker, 6-Oct-06

Martin  

-----Original Message-----
From: Pekka Savola [mailto:[email-masked]] 
Sent: Thursday, November 16, 2006 2:32 AM
To: Fred Baker
Cc: Sam Hartman; [email-masked]; [email-masked]; Scott Bradner
Subject: Re: WG Review: Recharter of Internet Emergency Preparedness
(ieprep)

> >     Babiarz, K. Chan, F. Baker. August 2006. (Format: TXT=144044
bytes)

---

From: "Dolly, Martin C, ALABS" <[email-masked]>
Date: Thu, 16 Nov 2006 06:00:53 -0600

Pekka,

Martin  

-----Original Message-----
From: Pekka Savola [mailto:[email-masked]] 
Sent: Thursday, November 16, 2006 2:32 AM
To: Fred Baker
Cc: Sam Hartman; [email-masked]; [email-masked]; Scott Bradner
Subject: Re: WG Review: Recharter of Internet Emergency Preparedness
(ieprep)

bytes)

---

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: 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: [email-masked]
Date: Thu, 16 Nov 2006 15:20:17 +0000

calls.

Note that this scenario gives so-called *IMPORTANT* traffic
the priority that is *DESIRED* while still allowing other
traffic to get through. In a disaster scenario like the
New Orleans hurricane, the official command and control
structure was not the sole organization doing useful work.

In such a chaotic scenario, common in war and in disasters,
it would be unwise to only have the option of shutting off
everybody else's service by preemption. The low priority
traffic could still be carrying mission critical messages
that are crucial to dealing with the disaster scenario.

This reminds me of an anecdote that a friend of mine recounted
some years ago. During the a war in some African country,
maybe Angola, the international phone lines were usually so
noisy that it was impossible for the embassy to hold a conversation
with their leaders back in Africa. Faxes were also virtually
impossible to transmit. He solved this problem by installing a 
UUCP email system that communicated back to Africa using Telebit
PEP modems. Unlike other modems of the day, the PEP protocol
divided the potential bandwidth of the communications channel 
into 256 frequency ranges, tested each range and used as many
ranges as were functional. This testing and choosing process was
repeated periodically so that as the noise pattern shifted, PEP
would search out the cleanest parts of the channel and use those.
The bursts of data that succeeded in reaching their destination
are analogous to packets and the channel seeking behaviour is
analogous to routing/failover.

The end result was a reliable email communications channel. It
could and often did take many minutes to transmit just a few
lines of text, but it did function and this allowed the embassy
to function where before they were paralyzed.

IP networks allow this same possibility, that of finding a low
bandwidth end-to-end path amidst a cacophony of cross-traffic.
The IETF should do some more education on how the existing 
protocol set could be used in disaster/war scenarios without
needing any new features tacked on to it.

--Michael Dillon

---

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:
> (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: "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)...
>
> Even for hard preemption, there is at worst a fall back to IP and  
> 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.

---

From: Fred Baker <[email-masked]>
Date: Thu, 16 Nov 2006 20:22:29 -0800

What you're describing, in general terms, is MPLS TE. Yes, MPLS TE  
will allow you to use your capacity a little more efficiently.

As I said, not all networks are MPLS, and not all MPLS networks do  
traffic engineering.

The scenario in question is *after* those things have been done.

On Nov 16, 2006, at 7:13 PM, Curtis Villamizar wrote:

>
> In message <[email-masked]>
> Fred Baker writes:
>>
>> preemption is occurring is the only path to the destination. [...]
>
> One vendor, lets call them vendor A, has solved this using a feature
> they call metric-bias which is a better alternative to soft
> preemption.  MPLS CSPF is influenced so that an effort is made to
> avoid highly utilized links.  If there is no other way, thats where it
> goes.  If there is other traffic (BE) thats what gets clobberred.
>
> But we're way off topic so I won't go into details.
>
>> [big snip]
>>
> Plain IP solutions based on queueing alone work fine if allowing  
> the ETS
> traffic to take the shortest IGP path never congests the ETS traffic
> and never gets too painful for the BE traffic.
>
> Generally MPLS shines relative to plain IP where there is a network
> fault, or many network faults, and capacity remains but may be quite
> limited in part of the topology.  That would be expected to be the
> case in certain situation where an ETS is most needed.
>
> For example, multiple faults occurred and capacity was very
> substantially reduced during and for quite a while after Katrina.
> Some automatic means of best using whatever capacity is available at
> any give time (such as MPLS does) would be a good thing IMHO.
>
> Do you disagree?
>
> Curtis

---

From: Curtis Villamizar <[email-masked]>
Date: Thu, 16 Nov 2006 10:59:51 -0500

In message <[email-masked]>
"Brian F. G. Bidulock" writes:
>  
> Janet,
>  
> On Thu, 16 Nov 2006, Janet P Gunn wrote:
>  
> > 
> 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

.... except that everything is different wrt PSTN and VOIP.

For example, not getting a dial tone (your example above) is due to
not enough cards in the local switch to convert DTMF to call attempts.
SIP doesn't use DTMF and so that bottleneck From [email-masked] Mon Nov 20 08:52:08 2006
To: [email-masked]
Date: Thu, 16 Nov 2006 10:59:51 -0500
From: Curtis Villamizar <[email-masked]>
Cc: "Robert G. Cole" <[email-masked]>, Pekka Savola <[email-masked]>,
	[email-masked], Scott Bradner <[email-masked]>,
	Fred Baker <[email-masked]>, Sam Hartman <[email-masked]>,
	[email-masked]
Subject: Re: [Ieprep] Re: WG Review: Recharter of Internet Emergency
	Preparedness (ieprep) 
Reply-To: [email-masked]

In message <[email-masked]>
"Brian F. G. Bidulock" writes:
>  
> Janet,
>  
> On Thu, 16 Nov 2006, Janet P Gunn wrote:
>  
> > 
> 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

.... except that everything is different wrt PSTN and VOIP.

For example, not getting a dial tone (your example above) is due to
not enough cards in the local switch to convert DTMF to call attempts.
SIP doesn't use DTMF and so that bottleneck doesn't exist for a SIP
originated call.

A well designed VOIP based 911 could eliminate many technical
bottlenecks leaving only the number of available 911 dispatchers as
the bottleneck and do a lot to make their job eaier.

There may be a lack of forward thinking in ITU since all VOIP ideas
there tend to mirror PSTN capability rather than allow PSTN to
gradually become an antiquated subset of VOIP capability.

VOIP has yet to reach critical mass.  Deployment is quite significant.
Its still mostly a gateway to PSTN with small but growing pure VOIP
connections.  In a sense PSTN is already almost a subset capability
since full service features and voice mail for free and extras like
free or very cheap fax to email gateway come bundled with VOIP
services but not PSTN, plus abilities like managing your voice mail
queue using your computer screen and keyboard rather than voice
prompts and DTMF pressing plus ability to archive voice mail on a PC.

Of course, IEPREP is just about priority treatment for emergency calls
and not extra VOIP features above and beyond the PSTN.

Curtis

---

From: Curtis Villamizar <[email-masked]>
Date: Thu, 16 Nov 2006 22:13:25 -0500

goes.  If doesn't exist for a SIP
originated call.

Curtis

---

From: Curtis Villamizar <[email-masked]>
Date: Thu, 16 Nov 2006 22:13:25 -0500

> "Armageddon") might be pretty difficult to predict in detail.

Plain IP solutions based on queueing alone work fine if allowing the ETS
traffic to take the shortest IGP path never congests the ETS traffic
and never gets too painful for the BE traffic.

Do you disagree?

Curtis

there is other traffic (BE) thats what gets clobberred.

> "Armageddon") might be pretty difficult to predict in detail.

Plain IP solutions based on queueing alone work fine if allowing the ETS
traffic to take the shortest IGP path never congests the ETS traffic
and never gets too painful for the BE traffic.

Do you disagree?

Curtis

---

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

Janet,

--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: [email-masked]
Date: Mon, 20 Nov 2006 14:40:22 +0000

>  Most jurisdictions, (and carrier
> as it surely can in the case of military telephony. 

Sounds like a quaint 1960's concept.

In a modern warfare situation you may have many
battlefield analysts who are analyzing various forms
of intelligence in order to identify target coordinates
and prioritize those targets. It is entirely possible 
for these analysts to be communicating from the same
location as a general. It is often the case that messages
from these analysts, for instance calling for an airstrike
on an artillery position, are far more important that some
general's chat with his field officers.

Packet-switching offers the opportunity to allow both
of these parties to get their messages through. It also
offers the opportunity to make preemption decisions explicitly
based on some person specifying the priority level of
a message or a message channel. It doesn't need to rely
on primitive concepts as "message source" or "message
destination".

Disaster situations are even more like this, in that it
is rarely easy for an outsider to determine which messages
are the most important. A router/switch is an outsider
so any technical tricks that it uses to guess the priority
will likely only work part of the time. However, if there
is a way for involved parties to specify the importance of
their message, then routers/switches can do a nice job of
arbitrating among the various messages. That is broadly what
IP and MPLS are capable of assuming that the end-point applications
allow the users to specify priority levels on a message by
message basis. Unfortunately, end-point devices usually don't
do this today because they are bogged down in PSTN thinking.

Imagine a phone that allows you to dial up the priority
level of your call. The caller, being and involved party,
knows more about the calling context than the network does.
If the caller believes his targetting message is of a higher
priority than a general's call, then he can crank up the 
priority to level 10. (Insert Spinal Tap joke here). If the
general really doesn't believe that such calls should ever go
that high, he can order the network to be configured to remap
priority levels from that call source.

I think the job of IEPREP should be to look at the whole 
situation more wholistically, and identify where there are
gaps rather than assuming that specifying a preemption 
protocol will fix the supposed problems. IETF protocols
already have lots of good stuff that isn't being leveraged
by many networks because vendors don't make it easy or
because there is no support in the applications layer or
end devices (phones etc.).

--Michael Dillon