Subject: RE: [Ieprep] access links

From: "King, Kimberly S." <[email-masked]>
Date: Wed, 13 Nov 2002 12:16:04 -0500

> However, I believe that GETS service user (e.g., DISA) should tell
> this working group what constitues acceptable voice quality (i.e.,
> which codecs) and then it would be much easier to specify the
> requirements.  For example, cell phones, POTS lines and radio
>communications have different voice quality which translates to
>different network requirements.

Let's try to focus here.  

The "voice quality" discussion, I believe, is restricted to voice quality
over access links.  I take it we are assuming an ETS location has contracted
with an ISP and there is an access link between them.  It has been pointed
out that ISPs don't often control QoS on this link.  

Problem statement????  Everyone at the ETS location wants to make calls at
the same time and the access link can't handle all that voice traffic so
conversations degrade so much as to be unusable.  

Potential solutions for problem...define the appropriate codecs, get a big
enough access link, provision QoS on CPE or more drastically pay for QoS to
be deployed on ISP router that faces the customer site, etc.

Defining the problem to be solved with appropriate context information would
be helpful.

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

---

From: Bill Woodcock <[email-masked]>
Date: Wed, 13 Nov 2002 09:56:33 -0800 (PST)

> conversations degrade so much as to be unusable.

A case such as the above, where the local loop is saturated _purely with
voice_ seems like it might be quite an outlier, since the voice just
doesn't add up that fast relative to the size of local loops...  However
several people have postulated a problem when the combination increased
voice use (likely) and a simultaneous hypothetical increase in data use
(unlikely) combine to make the local loop unusable for voice.

    > be deployed on ISP router that faces the customer site, etc.

Yes, these are all appropriate responses.  Adding capacity dynamically
through a dial-on-demand link would fall under the "get a big enough link"
category.  Unplug non-voice VLANs would be a manual version of Qos...  I
can't think of any other solutions than those you've mentioned.

                                -Bill

---

From: "Steve Silverman" <[email-masked]>
Date: Wed, 13 Nov 2002 15:28:28 -0500

The problem is that in a sudden emergency, there may be no time to change
codecs (so you can't talk to anyone), no time to replace or upgrade the
access link, or no additional bandwidth to purchase.  In an emergency, you
may have minutes to react. Emergencies often happen to unexpected locations
at inopportune times.
In this situation, selected users require priority so their calls are
usable.  This is the focus of some of us.

Some locations do not have access to fiber optic trunks and have limited
bandwidth.

Steve Silverman

Kimberly

---

From: Bill Woodcock <[email-masked]>
Date: Wed, 13 Nov 2002 12:44:05 -0800 (PST)

On Wed, 13 Nov 2002, Steve Silverman wrote:
    > usable.

No, some users require priority so they can feel special.  Other users
require the best-effort Internet so their calls are usable.  Which camp do
you really want to be in?

    > Some locations do not have access to fiber optic trunks and have
    > limited bandwidth.

Yes, but those people don't seem to be in yoru camp, they seem to be in
the "we'd prefer our calls to complete" camp.

                                -Bill

---

From: RJ Atkinson <[email-masked]>
Date: Thu, 14 Nov 2002 19:19:40 -0500

On Wednesday, Nov 13, 2002, at 15:28 America/Montreal, Steve Silverman 

> usable.  This is the focus of some of us.

Then I'd urge that they use the reslient low-bandwidth CODECs all the 
time,
since that is the approach that is most robust.

Dynamic routing recovers in local areas within milliseconds to seconds,
so minutes seems like a really long period of time (more than ample) to 
me.

And the ISP can't do *anything* about the access link's configuration,
since it is under the control of the end customer.

Ran