Subject: RE: [Ieprep] Qualitative statement about quality

From: "Nguyen, An" <[email-masked]>
Date: Thu, 14 Nov 2002 21:13:39 -0500

I would imagine 600ms was for the route trip delay, not a one-way at all.
Because, otherwise, it would have a longer delay than satellite, which is
500ms it would take for the signal to bounce off a transponder (satellite
hop). Most of us notice that delay on TV when a news reporter speaks to a
news anchor back in the headquarters studio. There is always a long pause
between a caller and a callee; if they don't wait for each other to pause,
there will be a problem with the audio. According to the ITU recommendation
on voice, G.711 one-way delay does not exceed 200ms. Some codec experts need
to correct me if I am wrong on this.

By the way, 600ms is just the delay between San Luis Obispo and Berkley and
I assume this voice traffic stays within one AS.  The delay of this voice
call would go up if it has to traverse from 3 to 6 AS's (the average number
of AS's a call would go through.)

Regards,

An

-----Original Message-----
From: Bill Woodcock [mailto:[email-masked]]
Sent: Thursday, November 14, 2002 1:55 PM
To: [email-masked]
Cc: [email-masked]
Subject: Re: [Ieprep] Qualitative statement about quality

      On Thu, 14 Nov 2002 [email-masked] wrote:
    > We really need a clarification of this claim. What do you mean be
"latency"?
    > Do you mean one-way or round-trip delay of the voice? Or something
else.

Round-trip, same as anyone else means when they say latency.

    > Based on the same definition, what was the "latency" on the PSTN call
between
    > San Luis Obispo and Berkeley?

Who knows.  Presumably there are audio time-domain reflectometers, but I
doubt the CALREN2 guys had one.

                                -Bill

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

---

From: Henning Schulzrinne <[email-masked]>
Date: Thu, 14 Nov 2002 21:29:56 -0500

G.114 says 150 ms one way delay as upper limit for "regular" service; 
see my earlier note on this. The domestic PSTN delay is pretty much 0.6 
times speed of light, plus a few ms. There's nowhere for the voice to be 
buffered, except on the way to the geosync satellite... It's longer for 
PSTN wireless (we've measured up to 80 ms one way), due to transcoding 
and media access delays.

You probably won't notice 300 ms delay during a remote presentation, but 
it is very obvious during a true two-way interactive conversation. 
(Interestingly, humans adjust - apparently, talk spurts get longer as 
the delay increases, until the conversation becomes alternating monologues.)

Long delays significantly complicate the life of echo cancellers.

If you're interested: we've measured the one-way voice delay of a number 
of commercial VoIP phones (just the end-system induced part). There's a 
large difference across vendors.

---

From: Scott Madley <[email-masked]>
Date: Fri, 15 Nov 2002 06:47:05 +0000 (GMT)

If any one has an interest, I'll see if I can dredge up some PSQM/MOS
results from about a year ago that I complied that compare/contrast voice
quality on both the PSTN and a dedicated VoIP network, and the associated
results when off-loading to either the PSTN or a NGN network.

-Scott

---

From: Bill Woodcock <[email-masked]>
Date: Fri, 15 Nov 2002 01:02:19 -0800 (PST)

> I would imagine 600ms was for the route trip delay, not a one-way at all.

Correct.  Latency on packet-switched networks is nearly universally
measured and denoted as round-trip times, since measuring one-way delay
requires active measurement equipment at both endpoints, which nearly
never exists.

    > of AS's a call would go through.)

I can't quite make out what you're saying here.  600ms was the observed
latency between San Luis Obispo and Nairobi, at the time of the call.  The
observed latency between San Luis Obisbo and Berkeley was about 200ms
across four ASes.  As I trace Berkeley to Nairobi right now, I get about
950ms, 42% drop, and seven ASes in the path.  It's not peak use hours in
either location at the moment, and this is a path which we use many times
each day for routine calls, when it's qualitatively much worse than it is at
the moment.  The quality of the VoIP calls is much, much higher than that
of PSTN calls, and it's difficult to keep the PSTN calls up...  Initial
call-completion rate is only about 80%, and most calls are dropped within
twenty minutes.  We've never had a failed connection or a dropped call
between this pair of VoIP phones, by contrast.

router.brk#trace nbi.ispkenya.com
Translating "nbi.ispkenya.com"...domain server (131.161.3.1) [OK]

Type escape sequence to abort.
Tracing the route to nbi.ispkenya.com (212.49.87.2)

  1 131.13.22.157.zocalo.net (157.22.13.131) [AS715] 4 msec 4 msec 8 msec
  2 gige-g2-0.gsr12008.pao.he.net (64.71.128.117) [AS 6939] 4 msec 4 msec 0 msec
  3 interconnect-eng.SanJose1.Level3.net (209.245.146.201) [AS 3356] 0 msec 20 msec 4 msec
  4 GigabitEthernet3-0.core1.SanJose1.Level3.net (209.244.3.245) [AS 3356] 4 msec 4 msec 4 msec
  5 ae0-51.mp1.SanJose1.Level3.net (64.159.2.1) [AS 3356] 4 msec 4 msec 4 msec
  6 so-3-0-0.mp1.NewYork1.Level3.net (64.159.1.41) [AS 3356] 80 msec 80 msec 80 msec
  7 gige9-0-53.hsipaccess1.NewYork1.Level3.net (64.159.17.71) [AS 3356] 76 msec 76 msec 76 msec
  8 unknown.Level3.net (209.244.160.242) [AS 3356] 81 msec 92 msec 80 msec
  9 host-66-133-0-22.verestar.net (66.133.0.22) [AS 11908] 156 msec 156 msec 157 msec
 10 unknown.Level3.net (64.158.116.117) [AS 11908] 188 msec 184 msec 185 msec
 11 host-66-133-6-2.verestar.net (66.133.6.2) [AS 11908] 184 msec 184 msec 185 msec
 12  * host-66-133-6-10.verestar.net (66.133.6.10) [AS 11908] 725 msec 725 msec
 13 212.49.70.109 [AS 12455] 745 msec 741 msec 753 msec
 14  * 10.10.2.10 781 msec *
 15 64.86.231.2 [AS 6453] 978 msec 901 msec 1859 msec
router.brk#ping
Protocol [ip]:
Target IP address: 212.49.87.2
Repeat count [5]: 100
Datagram size [100]:
Timeout in seconds [2]:
Extended commands [n]:
Sweep range of sizes [n]:
Type escape sequence to abort.
Sending 100, 100-byte ICMP Echos to 212.49.87.2, timeout is 2 seconds:
.!!!!!.!..!!!!.!!...!!!!.!!!.!!...!!!!!.!!...!...!.!!.!...!!.!!!!...!.
..!..!!.!.!!!!!!.!.!!!!!.!..!.
Success rate is 58 percent (58/100), round-trip min/avg/max = 774/959/1262 ms
router.brk#

                                -Bill

---

From: RJ Atkinson <[email-masked]>
Date: Fri, 15 Nov 2002 21:36:55 -0500

> results when off-loading to either the PSTN or a NGN network.

More data is almost always better.  URL would be helpful,
or email if it is ASCII and reasonable length.

Ran