RE: [Ieprep] Re: WG Review: Recharter of Internet EmergencyPreparedness (ieprep)

"Dolly, Martin C, ALABS" <> Fri, 17 November 2006 01:56 UTC

Received: from [] ( by with esmtp (Exim 4.43) id 1GksxX-00087u-Uo; Thu, 16 Nov 2006 20:56:03 -0500
Received: from [] ( by with esmtp (Exim 4.43) id 1GksxW-00087a-K2; Thu, 16 Nov 2006 20:56:02 -0500
Received: from ([]) by with smtp (Exim 4.43) id 1GksxT-0000fQ-9y; Thu, 16 Nov 2006 20:56:02 -0500
X-VirusChecked: Checked
X-StarScan-Version:; banners=-,-,-
X-Originating-IP: []
Received: (qmail 24015 invoked from network); 17 Nov 2006 01:55:58 -0000
Received: from unknown (HELO ( by with SMTP; 17 Nov 2006 01:55:58 -0000
Received: from (localhost []) by (8.13.7/8.13.7) with ESMTP id kAH1nBHD008604; Thu, 16 Nov 2006 20:49:11 -0500 (EST)
Received: from ( []) by (8.13.7/8.13.7) with ESMTP id kAH1mt2k008543; Thu, 16 Nov 2006 20:48:59 -0500 (EST)
X-MimeOLE: Produced By Microsoft Exchange V6.5
Content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
Subject: RE: [Ieprep] Re: WG Review: Recharter of Internet EmergencyPreparedness (ieprep)
Date: Thu, 16 Nov 2006 19:55:42 -0600
Message-ID: <>
In-Reply-To: <>
Thread-Topic: [Ieprep] Re: WG Review: Recharter of Internet EmergencyPreparedness (ieprep)
Thread-Index: AccJ0xuYNvDO3mS9SsO/lXVSY3WydQAFy0kA
From: "Dolly, Martin C, ALABS" <>
To: Fred Baker <>, Brian E Carpenter <>
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 4d87d2aa806f79fed918a62e834505ca
Cc: "Robert G. Cole" <>, Pekka Savola <>,, Kimberly King <>, Scott Bradner <>, Sam Hartman <>,
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: Internet Emergency Preparedness Working Group <>
List-Unsubscribe: <>, <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>

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

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

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  

Ieprep mailing list

Ieprep mailing list