Subject: RE: [Ieprep] NCS contracts with voice IXCs

From: "Joel M. Halpern" <[email-masked]>
Date: Sat, 16 Nov 2002 10:07:02 -0500

If there is a service that (one or more) telephone companies want to 
deliver using IP,
and if that service requires additional standardization that is suitable 
for the IETF (ie not the API between SIP and TCP, but new interoperable 
fields in SIP or a new standardized behavior in diffserv),
then I would expect to see email from folks at that telephone company 
indicating that they are trying to build their infrastructure, they have 
specific unmet requirements, and would like to see progress.

To some degree, we have part of that.  I believe that the NCS requirements 
are actually about what they would like to do on their own 
network.  However, the requests currently mix issues that are best done by 
contract, issues that are fully covered by current RFCs, and some issues 
which could probably use discussion.  It is also very important in such 
documents to be clear about what requests are application requests (a 
probably reasonable request for a SIP header field) and what requests are 
network layer requests.

However, we have not heard from Voice IXCs.  Given that the service you 
describe is used today, and works today, with conventional IP services 
using commercial product, I would need to see a clear problem description 
before concluding that IXCs need new standards.

Yours,
Joel M. Halpern

At 02:21 AM 11/15/2002 -0500, Gunn, Janet wrote:
>Exactly my point.
>
>The (proposed, future) "IP packet switching core" within the VOICE IXC's
>network is NOT going to be the ISP that runs under the same corporate name.
>I am not talking about a contract with the ISP side of the business.  I am
>talking about a contract with the VOICE side of the business, that will
>include IP technology in its network.
>
>Who knows whether THAT (sub)network will be over provisioned or not?  Since
>it doesn't  exist yet, it WILL require new (now scarce) capital.
>
>Who knows what other performance characteristics it will have?

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

---

From: Bill Woodcock <[email-masked]>
Date: Sat, 16 Nov 2002 07:45:33 -0800 (PST)

> [email-masked]

Wow, that email address is a little scary to contemplate.  :-)

      On Sat, 16 Nov 2002, Joel M. Halpern wrote:
    > If there is a service that (one or more) telephone companies want
    > to deliver using IP, and if that service requires additional
    > standardization, then I would expect to see email from folks at that
    > telephone company indicating that they are trying to build their
    > infrastructure, they have specific unmet requirements, and would
    > like to see progress.

Actually, that's why Peter Lothberg and I are supposed to be here.  We're
the two folks operating international VoIP internetworks.  And we'd dearly
love to keep these folks from breaking them.

                                -Bill

---

From: Henning Schulzrinne <[email-masked]>
Date: Sat, 16 Nov 2002 11:03:10 -0500

> using commercial product, I would need to see a clear problem
> description before concluding that IXCs need new standards.
>
We don't know how many voice IXCs are on this list, but given the 
architecture discussions we've had, there are at least three possible 
interpretations:

(1) Voice IXCs mix voice and commodity Internet service ("data") on the 
same infrastructure, with no DiffServ, IntServ or other QoS (black) 
magic. They find no problem using existing technology. At best, it might 
be helpful to document operational experience if these carriers are 
willing to share it.

(2) Voice IXCs run a logically separate network for voice, probably via 
ATM VCs or MPLS paths at layer 2 or 2.5. Case A: They are happy with 
that and see no need to go to (1). Case B: If they'd like to go to (1), 
but are missing functionality, there's work to do.

On a separate L2/2.5 "network", the problem becomes much simpler, 
particularly if the capacity limit is primarily given by PSTN gateway 
capacity. Traditional Erlang-style engineering will do a pretty good job 
there, without worrying about the packet level.

(3) Voice IXCs run a completely separate network infrastructure, at 
fiber or wavelength level. Integration is at best at conduit level 
("layer 0"?). Again, they can either have decided that that's cheapest 
or would at least like to explore (2) or (1). I think most traditional 
IXCs currently full into this camp; almost all of them are exploring (1) 
or (2), from what I know.

We seem to have real-time integration at layer 1, 2/2.5 and 3. Ran seems 
to argue that carriers are well-advised to stay with (3), Bill says (1) 
works just find (but there's insufficient voice volume to care in any 
event) and I'm sure somebody else is a proponent of (2).

Given that all major telecom equipment vendors are active in NSIS, 
there's at least some indication of interest in moving from (2) to (1), 
even if primarily for the wireless access space. (Very few wireless 
carriers participate in the IETF, from what I can tell, regardless of 
the area.)

Henning

---

From: RJ Atkinson <[email-masked]>
Date: Sat, 16 Nov 2002 11:14:50 -0500

On Saturday, Nov 16, 2002, at 10:45 America/Montreal, Bill Woodcock 

> love to keep these folks from breaking them.

Bill,
	As you keep pointing out, your VoIP deployment does not interconnect
with the PSTN, so it does not qualify as an IXC.  Peter's kind of does
interconnect, but in a small and curious way that is definitely not an 
IXC network.

	So Joel's point was on target.  One thing we need here are folks 
equivalent
to "Long Lines folks with IP clue who are moving from phone switches to 
VoIP".

Ran

---

From: RJ Atkinson <[email-masked]>
Date: Sat, 16 Nov 2002 11:19:03 -0500

On Saturday, Nov 16, 2002, at 11:03 America/Montreal, Henning 
Schulzrinne wrote:
>  Ran seems to argue that carriers are well-advised to stay with (3), 
> ...

"Carrier" is ambiguous.  I agree with the sentence above iff one edits 
that
"carriers" to be "PSTN/Voice carriers".

And note that my position, while different from Bill's, does not 
contradict
Bill's position.  One can believe that (1) will work properly in a well 
engineered
network, while still believing that phone carriers will be more 
successful
if they run with (3) for a long while.  My root belief, based on 
deployment,
is that selecting the right codec is a large part of the engineering 
needed
for emergency voice services.

Ran

---

From: Bill Woodcock <[email-masked]>
Date: Sat, 16 Nov 2002 08:16:02 -0800 (PST)

On Sat, 16 Nov 2002, Henning Schulzrinne wrote:
    > there are at least three possible interpretations:
    > (1) Voice IXCs mix voice and commodity Internet service
    > (2) Voice IXCs run a logically separate network for voice
    > (3) Voice IXCs run a completely separate network infrastructure

Each of which are possible, but then there's the common case, which will
always outnumber all of those three put together, which is

(4) Voice IXCs don't do or know anything about data, since they ride
several layers higher in the stack, and the underlying data is
assumed to be present due to the customer's arrangement with an ISP.

                                -Bill

---

From: Bill Woodcock <[email-masked]>
Date: Sat, 16 Nov 2002 08:19:59 -0800 (PST)

On Sat, 16 Nov 2002, RJ Atkinson wrote:
    > with the PSTN, so it does not qualify as an IXC.

"Inter-exchange carrier?"  Perhaps we should examine the definition, then,
if it doesn't cover a network with nodes in four continents.

Besides, the PSTN _does_ interconnect with my network, I just continue to
make the case that since that doesn't scale, the PSTN operators won't
_generally_ interconnect with the rest of the network.  I mean, there's
just no way they could afford to.  I may be a nice guy and not charge them
above cost, but most network operators will look at PSTN dinosaurs and not
be so generous; they'll look at them as potential customers, rather than
retarded half-wits deserving sympathy, and charge them big interconnect
fees, which they won't be able to afford to pay.

So in the general case, the PSTN won't be able to afford to connect.

                                -Bill