Subject: RE: [Ieprep] I-D ACTION:draft-ietf-ieprep-framework-06.txt

From: "Dvorak, Charles A (Chuck)" <[email-masked]>
Date: Thu, 9 Oct 2003 00:37:59 -0500

Are you talking about random loss or bursty loss? (The former is a curiosity but only the latter is realistic)

-----Original Message-----
From: Andrew Thiessen [mailto:[email-masked]]
Sent: Wednesday, October 08, 2003 7:24 PM
To: 'Scott Bradner'; [email-masked]; [email-masked];
[email-masked]
Subject: RE: [Ieprep] I-D ACTION:draft-ietf-ieprep-framework-06.txt

Right...

Jitter is important in that the size of the jitter buffer adds to the
overall mouth-to-ear delay and that an accurate jitter buffer size
selection is critical. If the jitter buffer size is smaller than the
delay variation on the network, voice traffic will necessarily be
dropped. If the jitter buffer is appropriately sized, the only impact
jitter should have is the delay that the buffer adds.

Whether or not a voice application can sustain a higher drop rate is
fairly dependent on the codec that is used. For instance, a G-711 codec
is more resilient to loss than a G-729 codec. The drop rate of a cloud
has a direct impact on the quality of the voice traffic. For instance,
we have lab tests that show with certain codecs that the estimated MOS
score drops by 1 for every 5% increase in loss.

Drop rates in elastic applications are typically more tolerant of drop
due somewhat to the protocols that are used. For instance, TCP has a
built in mechanism to retransmit lost packets, where UDP does not. Email
and web browsing would therefore be much more resilient to loss in that
a session with loss is easier to maintain with TCP than UDP. Would it
take forever to get email and see a web page with high loss? Yes, but
you would see it eventually. With VoIP, you may be able to maintain some
type of conversation, but the quality could be so bad that there
wouldn't be any point.

Andy

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

---

From: "Gunn, Janet" <[email-masked]>
Date: Thu, 9 Oct 2003 10:26:52 -0400

Drop rates.

It all depends on where you are looking.

I agree that from an end-user or end-application perspective, you can say
that VoIP needs a lower drop rate than say email or web access (using TCP).
The dropped VoIP packets are gone forever, but the dropped TCP packets will
be retransmitted, and will get there "eventually".

But from a network congestion perspective, the "ranking" is reversed.  The
dropped VoIP packets  are gone and do not contribute to additional
congestion.  The retransmitted TCP packets add to the traffic volume, and
make the congestion worse.  From a simplified perspective, you could say
that a 5% drop rate for TCP packets results is at least (because you have to
"compound" that 5% on each retransmission) 5% additional TCP traffic offered
to the network.  Not something that is desirable in an already congested
network.  

I think my concerns can be addressed by minor rewording, or a parenthetical
comment. 

Janet 

-----Original Message-----
From: Andrew Thiessen [mailto:[email-masked]]
Sent: Wednesday, October 08, 2003 7:24 PM
To: 'Scott Bradner'; [email-masked]; [email-masked]; Gunn, Janet
Subject: RE: [Ieprep] I-D ACTION:draft-ietf-ieprep-framework-06.txt

Right...

Andy

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of
Scott Bradner
Sent: Wednesday, October 08, 2003 3:54 PM
To: [email-masked]; [email-masked]; [email-masked]
Subject: RE: [Ieprep] I-D ACTION:draft-ietf-ieprep-framework-06.txt

> Substance
> 1.2 third para
> I have always understood that jitter was more important than delay for
VoIP,
> but you do not mention it.

I'm not sure that jitter per se is a big issue - the distribution of 
delay is - most of the packets need to get to the other end within 
a reasonable limit - that can be because the basic delay is near the
limit and there is no jitter or the basic latency is less and the jitter
brings the delay to thye limit.

Scott

---

From: "Gunn, Janet" <[email-masked]>
Date: Thu, 9 Oct 2003 11:58:45 -0400

"Bridging" as in James's topology paper.  Where the "call" originates and
terminates in the CSN, but passes through a single IP domain in between.  SO
not a "stub" because it is neither source nor destination.  But possessing
the other "single domain" characteristics.
 
-----Original Message-----
From: Ken Carlberg [mailto:[email-masked]]

> 4.4

> Third para
> Do you mean "stub domain" or "single domain"? The statement would seem
to
> also apply to a single domain "bridging" scenario.

I meant stub domains.  I'm not exactly sure what you mean by a 'single
domain "bridging" scenario'.  What is being bridged?

---

From: [email-masked]
Date: Thu, 9 Oct 2003 14:29:37 EDT

> brings the delay to thye limit.

Problem seems partly to be "What is your definition of jitter?" I believe 
jitter is the same as "the distribution of delay".

In any case, "jitter" (or packet delay variation, as I'd rather call it, as 
ITU-T SG13 does) is an important issue. Delay is an important isses. Packet 
loss is an important issue. It's kind of hard to say that one is "more important" 
than the other.

Mike