RE: [Ieprep] proposed charter

"GOLDMAN, STUART O \(STUART\)" <> Wed, 27 September 2006 00:21 UTC

Received: from [] ( by with esmtp (Exim 4.43) id 1GSNAv-0002K6-Gx; Tue, 26 Sep 2006 20:21:21 -0400
Received: from [] ( by with esmtp (Exim 4.43) id 1GSNAu-0002IM-Ly for; Tue, 26 Sep 2006 20:21:20 -0400
Received: from ([]) by with esmtp (Exim 4.43) id 1GSNAr-0005Lx-Vr for; Tue, 26 Sep 2006 20:21:20 -0400
Received: from ( []) by (8.13.6/IER-o) with ESMTP id k8R0LGOQ017493; Tue, 26 Sep 2006 19:21:16 -0500 (CDT)
Received: from ([]) by with Microsoft SMTPSVC(6.0.3790.0); Tue, 26 Sep 2006 19:21:16 -0500
X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0
Content-class: urn:content-classes:message
MIME-Version: 1.0
Subject: RE: [Ieprep] proposed charter
Date: Tue, 26 Sep 2006 19:21:14 -0500
Message-ID: <>
In-Reply-To: <>
Thread-Topic: [Ieprep] proposed charter
thread-index: Acbhyltc1MsSQ62ISxW5mGF9tkn6vwAAEqfw
To:, Fred Baker <>
X-OriginalArrivalTime: 27 Sep 2006 00:21:16.0681 (UTC) FILETIME=[D8FE0F90:01C6E1CA]
X-Spam-Score: 0.0 (/)
X-Scan-Signature: fe6e20eef2d8927c50910823cd0d1c84
Content-Type: text/plain; charset="US-ASCII"
Content-Transfer-Encoding: quoted-printable
X-Content-Filtered-By: Mailman/MimeDel 2.1.5
Cc: "James M. Polk" <>,
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: Internet Emergency Preparedness Working Group <>
List-Unsubscribe: <>, <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>



I thought there were no absolute guarantees in life or
telecommunications.   ;-) 


Stuart Goldman

Lucent Technologies

602 493 8438



-----Original Message-----
From: Curtis Villamizar [] 
Sent: Tuesday, September 26, 2006 6:04 PM
To: Fred Baker
Cc: James M. Polk;
Subject: Re: [Ieprep] proposed charter 



In message <>

Fred Baker writes:



> On Sep 26, 2006, at 3:02 PM, Curtis Villamizar wrote:


> > For PSTN voice it doesn't but for elastic real time or elastic bulk

> > transfer it might.


> for them, it might but we need to discuss. It's not anywhere near as  

> obvious as it might sound. In the end, it's about what kinds of  

> guarantees they are asking for. In at least one scenario, the  

> relevant folks are asking to be able to download a file of a stated  

> size within a stated amount of time. To do that, I need to be able to

> predictably give the preferred traffic class, whatever it is called,  

> a stable bandwidth. Drop priority doesn't accomplish that; it only  

> accomplishes that the preferred traffic competes more effectively and

> therefore gets a larger subset of the traffic. I can fairly easily  

> construct scenarios in which even the preferred traffic gets bombed  

> off the link.



A decade ago we went through a similar argument (not you and I but the

technical community) regarding the Internet and QoS.  The whole point

of RFC1633 is to explain that you can have an absolute guarentee and

it will incur a given cost or you can have a service that from a

practical standpoint is indistinguishable but relies on an extremely

high statistical expectation of acheiving the same level of service

but at an order of magnitude less cost.


ETS brings up a similar question.  Will the market favor inefficiency

(much greater need to overprovision) for the purpose of an absolute

service guarentee, or will it favor a more efficient use of available

bandwidth but without absolute guarentees.


Even using voice based ETS as an example, consider the following.

When a disaster has occurred and a fraction of available

infrastructure remains operational, is it better to have N disaster

relief audio streams supportable with a 100% expectation of service

quality or is it better to have 10 * N disaster relief audio streams

supportable with 99.9% expectation of the same service quality.

Given that an occasional dropped packet in audio or video is almost

indistinguishable (and radio service is far less than a perfect audio

channel) I think that the latter would be far more useful.


The same for file transfer.  If it takes 10 sec but 0.0% of the time

takes 11 sec, but you can support 10 times as many sessions, then I'd

take the tiny risk and tremendous improvement in multiplexing



This tradeoff may depend on how many sessions are multiplexed on a

given resource, If N is a small integer then chance of collision slow

down increases.  If N is very large then guarenteed and predictive

service asymtotically approach indistinguishable.


But then again, I don't work for a phone company.  :-)


I do agree that if all that the ETS is doing is bridging two PSTN

segments, the multiplexing gain is not possible (its already TDM

traffic) and EF makes perfect sense.


In any case I do think starting with EF service or an alternate

EF-like codepoint for ETS makes sense.  Having this codepoint

recognized across providers may override any multiplexing efficiency





ps - Am I reopenning a can of worms?



Ieprep mailing list

Ieprep mailing list