Subject: Re: [Ieprep] access links

From: [email-masked]
Date: Wed, 13 Nov 2002 14:43:27 EST

In a message dated 11/13/2002 12:19:55 PM Eastern Standard Time, 
[email-masked] writes:

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

[MAP] Yes lets address the right issue. One issue for the IETF (not IEPREP) 
is "What constitutes acceptable voice quality for general telephony users?"

For IEPREP, there should then be an understanding that the emergency user 
would usually accept a worse quality (speech transmission, as well as other 
QoS factors as mentioned in my e-mail of Nov 12), rather than have a call 
blocked. One could ask "what constitutes acceptable voice quality" for an 
emergency, but I don't think the specific numbers have any impact on the work 
of IEPREP. Only the notion that it can be worse matters. My 
draft-pierce-ieprep-pref-treat-examples describes one method by which they 
could be provided better call setup probablity while possibly trading-off 
voice quality.

Mike Pierce
Artel

---

From: "Taylor, Carol-Lyn" <[email-masked]>
Date: Thu, 14 Nov 2002 09:37:30 -0500

Well said.

-----Original Message-----
From: Steve Silverman [mailto:[email-masked]]
Sent: Wednesday, November 13, 2002 3:28 PM
To: King, Kimberly S.; 'Dean'; RJ Atkinson
Cc: ieprep
Subject: RE: [Ieprep] access links 

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

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

_______________________________________________
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: "Gunn, Janet" <[email-masked]>
Date: Thu, 14 Nov 2002 15:27:27 -0500

Yes,

Not currently concerned about PRI, concerned about SIP.

If you add "IP to PSTN" (where we KNOW encapsulation can't help us) that is
a fair summary of the most immediate concern.

Longer term, I anticipate the need to do "something" about IP access
circuits and small private networks, but not sure just what "something" will
be.

-----Original Message-----
From: Bill Woodcock [mailto:[email-masked]]
Sent: Thursday, November 14, 2002 3:15 PM
To: Gunn, Janet
Cc: 'Dean'; RJ Atkinson; ieprep
Subject: RE: [Ieprep] access links 

      On Thu, 14 Nov 2002, Gunn, Janet wrote:
    > As I said in another message, I am MOST concerned with what happens at
the
    > interface between the IP and the circuit switched network.

Currently, that handoff is most commonly NxPRI, according to the
couple of people who've commented, and my own admittedly limited
experience.  I'm assuming that GETS-like information is not currently, or
cannot be contained in PRI signalling, just SS7?  Or is it there in PRI as
well?

In the future, that SS7-to-SIP conversion will happen inside the legacy
telcos, and they'll hand off to the rest of the network as pure IP...  At
that point, we (the IETF) only care that they implement existing protocols
properly, we don't care what they do internally.

But my understanding is that you have a specific need for them to have
some reliable, interoperable way of making that transition
(IP-to-PSTN-to-IP or PSTN-to-IP-to-PSTN) internally, while retaining and
conveying any priority information which may be needed to get the call
through the PSTN portions of the path.  Is that a fair summary?

Presumably that can be standardized in such a way that it could be used
subsequently in the rest of the network, if needed.  Nothing there should
require touching anything other than SIP.

                                -Bill

---

From: [email-masked]
Date: Mon, 18 Nov 2002 09:48:12 EST

In a message dated 11/17/2002 4:31:40 PM Eastern Standard Time, 
[email-masked] writes:

> I'd like to add some other things to agree on at this meeting:
> 
> (3) Congestion is not a problem within ISPs, even during natural disasters
> (e.g. Kobe earthquake, Northridge earthquake) or terrorist attacks (e.g. 
> 9/11/01).
> Instead, congestion is a concern focused on access links.
> 
> (4) No amount of money (or mandate) applied to ISPs can fully resolve the
> access link congestion issues, because the access link is controlled
> by the end-user, rather than being controlled unilaterally by the ISP.
> 
> (5) QoS deployment creates new vulnerabilities for the ISPs that deploy QoS.
> 

:
[MAP] Comments on above:

(3) I fail to see how this group, or anyone, could "agree" that absolutely no 
ISP currently or ever in the near future has or will have a problem with 
congestion.

(4) I don't think the issue here is whether or not an ISP can "control" the 
access link, and therefore, the congestion. The issue is whether or not we 
need standards to allow anyone to control it.

(5) Absolutely true, so it needs to be taken into account, but we don't 
refuse to do work just because it "creates new vulnerabilities". If we did, 
there would certainly be no Internet.

Mike Pierce
Artel