Re: proposed charter

In message <[email protected]>
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?