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

Curtis Villamizar <> Thu, 16 November 2006 23:51 UTC

Received: from [] ( by with esmtp (Exim 4.43) id 1Gkr0z-0000R7-7c; Thu, 16 Nov 2006 18:51:29 -0500
Received: from [] ( by with esmtp (Exim 4.43) id 1Gkr0x-0000Qz-V9; Thu, 16 Nov 2006 18:51:27 -0500
Received: from [] ( by with esmtp (Exim 4.43) id 1Gkr0w-0000HI-Aw; Thu, 16 Nov 2006 18:51:27 -0500
Received: from (localhost []) by (8.13.4/8.13.4) with ESMTP id kAH02rtC065633; Thu, 16 Nov 2006 19:02:53 -0500 (EST) (envelope-from
Message-Id: <>
To: Fred Baker <>
Subject: Re: [Ieprep] Re: WG Review: Recharter of Internet Emergency Preparedness (ieprep)
In-reply-to: Your message of "Tue, 14 Nov 2006 12:01:59 PST." <>
Date: Thu, 16 Nov 2006 19:02:53 -0500
From: Curtis Villamizar <>
X-Spam-Score: 0.1 (/)
X-Scan-Signature: 244a2fd369eaf00ce6820a760a3de2e8
Cc: "Robert G. Cole" <>, Pekka Savola <>,, Kimberly King <>, Brian E Carpenter <>, 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: <>, <>

In message <>
Fred Baker writes:
> 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.
> _______________________________________________
> Ieprep mailing list

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

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.


Ieprep mailing list