Subject: Re: FW: [Re: [Ieprep] ieprep-requirements-01 - reqs 6-10 - discussion request]

From: [email-masked]
Date: Mon, 11 Nov 2002 21:42:47 EST

In a message dated 11/9/2002 2:34:37 PM Eastern Standard Time, 
[email-masked] writes:

> Since we may have different expectations, it might be helpful to get 
> feedback on what people would consider reasonable reliability. Is it ok 
> if 1% of calls fail (where "fail" may mean "sufficient disruption to 
> cause users to abandon the call")? 0.1%? Even lower?
> 

[MAP] Yes, this is a major issue for VoIP (not even considering the 
needs/desires of IEPREP). There are clearly a set of participants of the IETF 
who expect that VoIP should provide the same performance in this regard as 
the currenttly accepted standards for telephony (sometimes called 
"toll-quality", although that term is usually only applied to the audio 
quality, not other things like lost call rate). The requirements (at least in 
the US) for lost call rate are a lot better than 1%. Other counties tolerate 
worse.

Interesting issue, since just 10 days ago, An Nguyen asked "is anyone aware 
of the ITU-T Y.1541 which defines QoS parameters in the IP networks" to which 
one of the usual participants in this IETF list responded: "Irrelevant. ITU 
does not have any role in defining IP".

(In fact, Y.1541 does not actually define IP, it defines parameters for 
services which use IP.)

There is no possibility of agreeing on the requirements for performance 
parameters (reliability and others) for VoIP unless there is an attempt by 
the IETF at cooperation with other recognized standards bodies that are very 
qualified to deal with this issue.

Y.1541 deals with the transmission parameters (packet loss, delay, variation, 
etc.) that would case "failure" of a conenction. Draft Y.1530 deals with 
failure to setup calls, premature disconnect, probability of wrong 
connections, etc. The SG13 meeting just last week revised this draft. So far, 
the numbers for these are "for further study".

MIke Pierce
Artel

---

From: Henning Schulzrinne <[email-masked]>
Date: Mon, 11 Nov 2002 23:17:58 -0500

http://www.softarmor.com/sipwg/meets/interim-nov-1999/991107%20dcs%20resource.pdf 
claims a permissible call defect rate of 0.00001%. Doesn't say whether 
this is an FCC requirement or just a business requirement. (Call 
blocking during busy hour is a different issue. From 
http://www.cis.state.mi.us/mpsc/comm/271/271attcorecomperformmeas.pdf, 
1% seems a common number; http://www.panix.com/~oppedahl/lads/mcc.htm 
confirms 1% as "busiest hour during the busiest day".)

[email-masked] wrote:
> needs/desires of IEPREP). There are clearly a set of participants of the 
> IETF who expect that VoIP should provide the same performance in this 
> regard as the currenttly accepted standards for telephony (sometimes 
> called "toll-quality", although that term is usually only applied to the 
> audio quality, not other things like lost call rate). The requirements 
> (at least in the US) for lost call rate are a lot better than 1%. Other 
> counties tolerate worse.
> 
> Interesting issue, since just 10 days ago, An Nguyen asked "is anyone 
> aware of the ITU-T Y.1541 which defines QoS parameters in the IP 
> networks" to which one of the usual participants in this IETF list 
> responded: "Irrelevant. ITU does not have any role in defining IP".
> 
> parameters (reliability and others) for VoIP unless there is an attempt 
> by the IETF at cooperation with other recognized standards bodies that 
> are very qualified to deal with this issue.
> 
> Y.1541 deals with the transmission parameters (packet loss, delay, 
> variation, etc.) that would case "failure" of a conenction. Draft Y.1530 
> deals with failure to setup calls, premature disconnect, probability of 
> wrong connections, etc. The SG13 meeting just last week revised this 
> draft. So far, the numbers for these are "for further study".
> 
> MIke Pierce
> Artel

_______________________________________________
Ieprep mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/ieprep

---

From: Scott Bradner <[email-masked]>
Date: Mon, 11 Nov 2002 23:33:40 -0500 (EST)

> a permissible call defect rate of 0.00001%

1/ I've not heard of an FCC requirement but maybe 

2/ what is a defect - in the context of the Internet?
	I would doubt that it is a dropped packet

Scott

---

From: Scott Bradner <[email-masked]>
Date: Mon, 11 Nov 2002 23:44:30 -0500 (EST)

>  a permissible call defect rate of 0.00001%

a search on the FCC web site does not find any thing with "call defect rate"
or "call defect" - 1189 hits for "defect"

google finds
http://www.informatik.unibw-muenchen.de/PMCCS5/papers/mendiratta.pdf
for "call defect rate"

this says that the "call defect rate" is the number of lost calls
per million calls

Scott

---

From: Sean Donelan <[email-masked]>
Date: Tue, 12 Nov 2002 03:50:41 -0500 (EST)

> or "call defect" - 1189 hits for "defect"

This is usually the province of NARUC and the state PUCs.  If you start
with the NARUC Telephone Service Quality Handbook or the Bell(Telcordia)
Notes on the Network they'll point you to the underlying requirements.
Of course this is very circular.  Which came first the tariff or the
practice?

And, by the way, the state legislation, regulation or tariff always
excludes operations during "emergency" conditions no matter what are
service quality requirements.

---

From: Henning Schulzrinne <[email-masked]>
Date: Tue, 12 Nov 2002 07:39:03 -0500

> 1/ I've not heard of an FCC requirement but maybe 

I'm inquiring with sources within the FCC.

> 	I would doubt that it is a dropped packet

There are at least three possible defects:
- Call rings, callee picks up and then there's no conversation (due to 
failure of local resource reservation; this is the problem the 
PacketCable folks worried about since they need to manage the very 
limited upstream bandwidth)

- sufficient duration of excessive packet drops that users abandon the 
call (somewhere around 10s, half of the callers are likely to drop the 
call, says a study)

- sufficient sustained packet loss that the MOS drops below an 
acceptable threshold for the call