RE: [Ieprep] proposed charter

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