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

From: "Gunn, Janet" <[email-masked]>
Date: Wed, 8 Oct 2003 11:02:47 -0400

Comments on draft-ietf-ieprep-framework-06.txt
Comments on substance first, then editorial.

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

1.2 fourth para
This is stated as the opposite of what I have always understood.  I have
always seen it that VoIP applications can tolerate a higher drop rate, and
even a moderate delay, as long as jitter is very small.  Conversely elastic
applications such as email and web browsing can tolerate high jitter and
delay, but need a low drop rate (because in email and web browsing the
dropped packets need to be retransmitted, but in VoIP, if they are dropped
you forget about them).  Even a drop rate of "5%" is considered a very high
drop rate in a (data) world where the starting point for drop rates is 10 to
the minus 6.

4.4 
first para

The statement that "the user authenticates himself... using a PIN" is true
for GETS but not for WPS, nor for line authentication, nor for other related
programs, and therefore not for "PSTN" in general.  If you said "the user
authenticates himself as usual to the network" it would be a valid
statement.

Editorial

Section 1
First para
" Best effort ...infers..." should be "Best effort ... implies ..."
("infers" = "deduces")

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

1.2
first para
It would be clearer if you said "... though not necessarily Voice over IP
which is not IP telephony" , instead of just "... though not necessarily
Voice over IP

Section 3
Last line
Should be "violate", not "violet".

Section 4.1.5
MEGACO (RFC 3015) has been "obsoleted" by Gateway Control Protocol Version 1
(RFC 3525)  The statement that priority 0 is the lowest and priority 15 is
the highest is in 3525 but not in 3015. 

4.4 last para 
says "IEPS" rather than "ETS".  Is this intentional?

4.5 last para
"meetings" should be "meeting"

Section 5, text after figure 1
Do you mean "Grade of Service" (= blocking probability based on Erlang's
formulae) or "Quality of Service" (= jitter, delay, drop rate)?

Janet

-----Original Message-----
From: Ken Carlberg [mailto:[email-masked]]
Sent: Wednesday, October 08, 2003 8:31 AM
To: [email-masked]
Subject: RE: [Ieprep] I-D ACTION:draft-ietf-ieprep-framework-06.txt

Barring objections from the group, I'd like to request that the chairs
announce a last call for this Telephony Framework draft.  I've purposely
delayed this request so that the requirements drafts could be advanced
up the standardization food chain.  With that process winding down, I'd
like to finish off the Framework draft.

Thanks,

-ken

_______________________________________________
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: Scott Bradner <[email-masked]>
Date: Wed, 8 Oct 2003 18:53:47 -0400 (EDT)

> 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: "Andrew Thiessen" <[email-masked]>
Date: Wed, 8 Oct 2003 17:23:57 -0600

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

-----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

Scott

---

From: "Ken Carlberg" <[email-masked]>
Date: Thu, 9 Oct 2003 10:00:43 -0400

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

The section you refer to focuses on published material relating to VoIP,
neither of which focuses on jitter.  So its not so much a case of my
choosing to not discuss jitter, but that those papers did not.  If there
is a paper with some stats that makes an argument for what you state
above, please send it to me and I'll fold it in the section.

In the meantime, I can add a comment later on in the diff-serv section
that mentions the use of EF as a mechanism for addressing jitter.

> you forget about them).  Even a drop rate of "5%" is considered a very
> high drop rate in a (data) world where the starting point for drop
rates
> is 10 to the minus 6.

Again, if there is a paper/publication that you can cite, that would be
very helpful.  

Many times there are caveats to each position taken.  The use of FEC,
transcoding (see the NRL work that Ran mentioned awhile back),
interleaving (purposely placing packets out of order), etc., can improve
the perceived quality of a VoIP flow.  The lack of additional mechanisms
or functions in those citations is probably an obvious thing that I
should state in that section.

As for elastic applications, there are two things to focus on:
congestion collapse and buffer overflow.  I've seen stats of TCP flows
operating (barely) at sustained loss rates of ~40%.  Buffer overflow is
application specific and can cause connections to break at even modest
levels of loss (ie, before congestion collapse).  But to be fair, if I
can't find suitable published stats, I will alter/remove the 4'th
paragraph.

> authenticates himself as usual to the network" it would be a valid

Ok, I'll remove the word "PIN".

> " Best effort ...infers..." should be "Best effort ... implies ..."

ok

> 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?

> which is not IP telephony" , instead of just "... though not
necessarily

I'll clarify the sentence

> Should be "violate", not "violet".

Ok
 
> Section 4.1.5
> MEGACO (RFC 3015) has been "obsoleted" by Gateway Control Protocol
Version
> 1

ok

> says "IEPS" rather than "ETS".  Is this intentional?

I'll switch it to ETS

> "meetings" should be "meeting"

ok

> formulae) or "Quality of Service" (= jitter, delay, drop rate)?

Should be QoS

-ken