RE: proposed charter

Folks,

=20

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

=20

Stuart Goldman

Lucent Technologies

[email protected]

602 493 8438

=20

=20

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

=20

=20

In message <[email protected]>

Fred Baker writes:

> =20

> =20

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

> =20

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

> > transfer it might.

> =20

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

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

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

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

> 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, =20

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

> accomplishes that the preferred traffic competes more effectively and


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

> construct scenarios in which even the preferred traffic gets bombed =20

> off the link.

=20

=20

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.

=20

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.

=20

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.

=20

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.

=20

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.

=20

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

=20

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.

=20

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.

=20

Curtis

=20

ps - Am I reopenning a can of worms?

=20

_______________________________________________

Ieprep mailing list

[email protected]

https://www1.ietf.org/mailman/listinfo/ieprep