RE: [Ieprep] proposed charter
"GOLDMAN, STUART O \(STUART\)" <sgoldman@lucent.com> Wed, 27 September 2006 00:21 UTC
Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GSNAv-0002K6-Gx; Tue, 26 Sep 2006 20:21:21 -0400
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GSNAu-0002IM-Ly for ieprep@ietf.org; Tue, 26 Sep 2006 20:21:20 -0400
Received: from ihemail2.lucent.com ([135.245.0.35]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GSNAr-0005Lx-Vr for ieprep@ietf.org; Tue, 26 Sep 2006 20:21:20 -0400
Received: from ilexp01.ndc.lucent.com (h135-3-39-1.lucent.com [135.3.39.1]) by ihemail2.lucent.com (8.13.6/IER-o) with ESMTP id k8R0LGOQ017493; Tue, 26 Sep 2006 19:21:16 -0500 (CDT)
Received: from ILEXC1U02.ndc.lucent.com ([135.3.39.3]) by ilexp01.ndc.lucent.com 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: <7D096A439A3D0D48A3D10872022CFD0920078A@ILEXC1U02.ndc.lucent.com>
In-Reply-To: <200609270103.k8R13vND005558@workhorse.brookfield.occnc.com>
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
Thread-Topic: [Ieprep] proposed charter
thread-index: Acbhyltc1MsSQ62ISxW5mGF9tkn6vwAAEqfw
From: "GOLDMAN, STUART O (STUART)" <sgoldman@lucent.com>
To: curtis@occnc.com, Fred Baker <fred@cisco.com>
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" <jmpolk@cisco.com>, ieprep@ietf.org
X-BeenThere: ieprep@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: Internet Emergency Preparedness Working Group <ieprep.ietf.org>
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/ieprep>, <mailto:ieprep-request@ietf.org?subject=unsubscribe>
List-Post: <mailto:ieprep@ietf.org>
List-Help: <mailto:ieprep-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/ieprep>, <mailto:ieprep-request@ietf.org?subject=subscribe>
Errors-To: ieprep-bounces@ietf.org
Folks, I thought there were no absolute guarantees in life or telecommunications. ;-) Stuart Goldman Lucent Technologies sgoldman@lucent.com 602 493 8438 -----Original Message----- From: Curtis Villamizar [mailto:curtis@occnc.com] Sent: Tuesday, September 26, 2006 6:04 PM To: Fred Baker Cc: James M. Polk; ieprep@ietf.org Subject: Re: [Ieprep] proposed charter In message <050CDE9C-E439-4381-8967-39F500D13C68@cisco.com> 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 efficiency. 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 considerations. Curtis ps - Am I reopenning a can of worms? _______________________________________________ Ieprep mailing list Ieprep@ietf.org https://www1.ietf.org/mailman/listinfo/ieprep _______________________________________________ Ieprep mailing list Ieprep@ietf.org https://www1.ietf.org/mailman/listinfo/ieprep
- [Ieprep] proposed charter Curtis Villamizar
- Re: [Ieprep] proposed charter James M. Polk
- Re: [Ieprep] proposed charter Fred Baker
- Re: [Ieprep] proposed charter Curtis Villamizar
- Re: [Ieprep] proposed charter Curtis Villamizar
- [Ieprep] liason & the 5 priorities ken carlberg
- Re: [Ieprep] proposed charter (Implementation) Janet P Gunn
- Re: [Ieprep] proposed charter 5 priority levels Janet P Gunn
- [Ieprep] Re: liason & the 5 priorities Curtis Villamizar
- [Ieprep] Re: liason & the 5 priorities ken carlberg
- Re: [Ieprep] proposed charter (Implementation) Curtis Villamizar
- Re: [Ieprep] proposed charter 5 priority levels Curtis Villamizar
- Re: [Ieprep] proposed charter 5 priority levels ken carlberg
- [Ieprep] Re: liason & the 5 priorities Curtis Villamizar
- Re: [Ieprep] proposed charter Fred Baker
- Re: [Ieprep] proposed charter Curtis Villamizar
- Re: [Ieprep] proposed charter 5 priority levels Janet P Gunn
- Re: [Ieprep] proposed charter 5 priority levels Janet P Gunn
- Re: [Ieprep] proposed charter Fred Baker
- Re: [Ieprep] proposed charter Curtis Villamizar
- RE: [Ieprep] proposed charter GOLDMAN, STUART O (STUART)
- Re: [Ieprep] proposed charter James M. Polk
- Re: [Ieprep] proposed charter Curtis Villamizar
- Re: [Ieprep] proposed charter Rex Buddenberg
- Re: [Ieprep] proposed charter Fred Baker
- Re: [Ieprep] proposed charter Janet P Gunn
- RE: [Ieprep] proposed charter Dolly, Martin C, ALABS
- ETS applicability, was Re: [Ieprep] proposed char… ken carlberg
- Re: [Ieprep] proposed charter Curtis Villamizar
- Re: [Ieprep] proposed charter Rex Buddenberg