Subject: RE: [ippm] metric requirements

From: Grotefeld Glenn-cecl03 <[email-masked]>
Date: Tue, 15 Oct 2002 14:41:52 -0500

"However, loss is very different from delay for the purposes of VoIP."

Begging to differ, but above a certain time delay for VoIP, loss and delay are equivalent.  And for any reasonably interactive system, how would you know of loss before you crossed that delay threshold?

> Glenn Grotefeld
> Motorola, Inc.
> [email-masked]
> US  847 435-0730
>       847 632-6800 FAX

-----Original Message-----
From: stanislav shalunov [mailto:[email-masked]]
Sent: Tuesday, October 15, 2002 2:30 PM
To: [email-masked]
Subject: Re: [ippm] metric requirements

"Dvorak, Charles A (Chuck), ALASO" <[email-masked]> writes:

> Recommendation Y.1541 of the ITU-T defines 6 IP layer QoS classes,
> NI-to-NI. All classes except best effort have a 0.1% packet loss
> objective, measured over an interval of a minute.

It is fine to define objectives such as this one.  This objective
would be better if loss correlation were considered.

However, loss is very different from delay for the purposes of VoIP.
High latency cannot be compensated for, and therefore, there are
objective thresholds that psychologists can ascertain and that can
further be codified in standards and recommendations; any given loss,
on the other hand, can be compensated for by an appropriate error
correction technique, and therefore, any numbers one comes up with are
simply arbitrary design goals.

It is possible to build codecs that will compensate for 0.1% packet
loss (these codecs will require certain resiliency to packet loss,
hence, they will be redundant to a certain extent).  By changing the
extent of redundancy, one can compensate for 1% packet loss or any
other given number.

This difference (objective law of human perception vs. arbitrary
design goal) between latency and loss is important.

-- 
Stanislav Shalunov		http://www.internet2.edu/~shalunov/

This message is designed to be viewed at 600 dpi.
_______________________________________________
ippm mailing list
[email-masked]
http://mailhost.advanced.org/mailman/listinfo/ippm
_______________________________________________
ippm mailing list
[email-masked]
http://mailhost.advanced.org/mailman/listinfo/ippm

---

From: stanislav shalunov <[email-masked]>
Date: 15 Oct 2002 16:02:03 -0400

Grotefeld Glenn-cecl03 <[email-masked]> writes:

> Begging to differ, but above a certain time delay for VoIP, loss and
> delay are equivalent.  And for any reasonably interactive system,
> how would you know of loss before you crossed that delay threshold?

Point taken; I should have been more clear.  For any given timeout
(and resulting from it definition of loss) and any loss level (other
than 100%, of course) one can compensate for loss with redundancy with
arbitrarily high probability of success.

Contrast this with latency: If latency of the packet stream is too
high (even if jitter and loss are low), one cannot compensate for it
with any amount of clever codec design.

With latency, one can have objective numbers ascertained in
experiments on human perception that have nothing to do with a
particular technology of sound transmission (say, 150ms for
conversation and 20ms for musicians' collaboration or whatever are the
fashionable numbers these days).  With loss, one can hide 0.1% just as
well as 1% or 10% -- given the right extent of redundancy.

"The power of accurate observation is commonly called cynicism by
those who have not got it."			-- G. B. Shaw
_______________________________________________
ippm mailing list
[email-masked]
http://mailhost.advanced.org/mailman/listinfo/ippm

---

From: Al Morton <[email-masked]>
Date: Tue, 15 Oct 2002 23:30:58 -0400

At 04:02 PM 10/15/2002 -0400, stanislav shalunov wrote:
>With loss, one can hide 0.1% just as

But adding redundancy usually increases some other
factor, such as BW or delay to process the redundant info.
Also, keep in mind that packet loss of 0.1% satisfies a system
that can handle 1% loss.

Al

---

From: stanislav shalunov <[email-masked]>
Date: 16 Oct 2002 03:30:09 -0400

Al Morton <[email-masked]> writes:

> But adding redundancy usually increases some other factor, such as
> BW or delay to process the redundant info.

Redundancy certainly means more bits on the wire.

It is unexceptionable that it would be preferable for the application
to never experience any packet loss; however, if loss is present, it
can be compensated for.  Constrast this with latency: If 500ms latency
is present, one cannot use a clever codec trick to make it appear to
the user as 150ms latency.  There exist objective levels of latency
that are tolerable for particular interactive media applications (they
will be different for VoIP, playing music together, haptic feedback,
remote control of a certain scientific instrument such as a telescope,
etc., but they exist); there are no corresponding loss levels.

> Also, keep in mind that packet loss of 0.1% satisfies a system that
> can handle 1% loss.

Could you elaborate on the point?  Why does it make any particular
cast-in-stone loss goal better than another?  Either 0.1% or 1% remain
arbitrary.

All revolutions are bloody.  The October Revolution was bloodless,
but it was only the beginning.               -- Dmitri Volkogonov
_______________________________________________
ippm mailing list
[email-masked]
http://mailhost.advanced.org/mailman/listinfo/ippm

---

From: Al Morton <[email-masked]>
Date: Wed, 16 Oct 2002 08:03:18 -0400

>cast-in-stone loss goal better than another?  Either 0.1% or 1% remain
The 0.1% loss objective successfully supports a larger fraction
of user needs in combination with their application capabilities.
More support is better.

Al

---

From: stanislav shalunov <[email-masked]>
Date: 16 Oct 2002 11:35:07 -0400

> of user needs in combination with their application capabilities.

This doesn't make 0.1% loss special in the same way 150ms latency is.
Why not 0.01%?

---

From: Al Morton <[email-masked]>
Date: Wed, 16 Oct 2002 17:17:03 -0400

>This doesn't make 0.1% loss special in the same way 150ms latency is.

The user application support view is very similar for these two objectives.
150ms 1-way delay is "Acceptable for most user applications," but not all,
according to G.114. The same is true for 0.1% loss, few applications benefit
from lower loss levels, it seems to be a point of diminishing returns
for now. If significant applications emerge that require 0.01% loss
or lower, then the "cast-in-stone" loss goal could be revised,
or more classes added with the lower loss (evolution is/was anticipated).

more on rationale in Atlanta if you want to discuss it there,
Al

---

From: Victor Reijs <[email-masked]>
Date: Thu, 17 Oct 2002 13:26:22 +0100

Hello all of you,

> or more classes added with the lower loss (evolution is/was anticipated).

Looking at Y.1541 (ftp://ftp.t1.org/Pub/T1S1/T1S1.0/2002/2s101490.pdf)
it is always talking about PER=10^-4.
The Packet loss Rate (PLR) is 10^-3, but I think we should take the
smallest figure of the two for a service like voice or tcp (a ping e.g.
answers to both and I think a owe way active measurement will both look
at the contant and the losses). So I would stimulate the figure 10^-4
instead of 10^-2 (or 10^-3) looking fro general IP networks (so oke for
voice).

Remember also that an tcp session is much more depending on the PER/PLR
than voice... Using the formula of Padhye
(http://www.heanet.ie/Heanet/projects/nat_infrastruct/tcpcalculations.htm)
an error rate of 10^-3 (buffersize 64 kByte) or 10^-6 (biffersize 2
MByte) will redure the goodput of an TCP with 50% (over a
intercontinental link, say RTT=100 msec).

All the best,

Victor

---

From: stanislav shalunov <[email-masked]>
Date: 17 Oct 2002 12:19:14 -0400

Al Morton <[email-masked]> writes:

> 150ms 1-way delay is "Acceptable for most user applications," but
> not all, according to G.114.

The quoted statement is true only if your view of the world is
telephone-centric.  Plenty of applications (games, remote equipment
control, etc.) benefit from lower latency.  Some classes of
applications require it.

> The same is true for 0.1% loss, few applications benefit from lower
> loss levels, it seems to be a point of diminishing returns for now.

You forgot TCP.  (Performance of TCP on a path with RTT of 70ms and
MSS of 1460B would be limited to 3-5Mb/s -- lower than even
low-performance end-attachments of corporate and campus users and
woefully inadequate for end stations connected at 100Mb/s.)  But TCP
is only a minor `application' on the Internet, right?

http://netflow.internet2.edu/weekly/longit/perc-protocols6-octets.png

Religion is the opium of them asses.		--Karlm Arx
_______________________________________________
ippm mailing list
[email-masked]
http://mailhost.advanced.org/mailman/listinfo/ippm