Subject: RE: Congestion avoidance Re: [Ieprep] draft-ietf-ieprep-framework-02.txt

From: "King, Kimberly S." <[email-masked]>
Date: Fri, 1 Nov 2002 15:39:47 -0500

An,

>By the 
> way, how are
> you doing it in your network to accommodate emergency traffic when
> congestions occur at the access nodes (not the distribution 
> or the core)?
> How about priority queuing or weighted fair  queuing ?

Bill told me about his VoIP system last year.  I'm sure he will correct me
if I have got  something wrong or things have changed.  But, he said that
QoS was not an issue.  Since the core was OC48s and OC192s running at 20%
utilization or less, there was lots of capacity.  The system was running
mostly in developed country ISPs.  

Access nodes, if I understand what you mean, don't pose a problem because
this VoIP system serves ISP NOC operators.  So they could increase their
bandwidth to the exchange if that turned out to be a problem.  It didn't
sound like it was one.

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

---

From: Sean Donelan <[email-masked]>
Date: Fri, 1 Nov 2002 16:17:49 -0500 (EST)

> mostly in developed country ISPs.

It started out that way. But now people are using their INOC-DBA phones at
home, on the road, from conferences in China, at the end of satellite
links.

So far QoS has been a non-problem.

The number 1 problem, and biggest headache, is getting emergency traffic
to pass through firewalls.  What magic bit I can set in my packets to
tell firewalls to let my emergency traffic through?

As a practical solution, we are specifying in great detail our protocol
characteristics (ports/protocol/ips), so the firewall people will let our
calls pass.

If you want to compare it to GETS, its like getting hotel PBX's to
recognize area code 710.  It doesn't matter what magic is done in the PSTN
to give calls special handling if you can't get past the hotel PBX.  On
the other hand, if GETS had used a 1-800 prefix, and then did special
magic inside the network, most PBX's would have let the calls through by
default.

The same will probably be true with the Internet.  You want to use stuff
that works by default as much as possible, to get the emergency calls
through parts of the network which don't know about your magic.  Only
apply the magic to the parts of the network which understand the magic.

This type of practical stuff is discovered when you have operational
experience.

---

From: RJ Atkinson <[email-masked]>
Date: Mon, 4 Nov 2002 17:13:34 -0500

On Friday, Nov 1, 2002, at 15:39 America/Montreal, King, Kimberly S. 
wrote:
> So they could increase their

	Most larger ISPs shun exchange points and strongly prefer private 
peering
-- in order to engineer congestion out of their networks (and out of 
their
access links with peers)  So the above is a bit of a misapprehension of 
the
deployed situation.  Exchange points aren't going to disappear entirely,
but most of the traffic growth is in private peering links (generally
these are bi-lateral pipes from A's core router to B's core router --
and generally there are N of them with geographic diversity).

Ran

---

From: Bill Woodcock <[email-masked]>
Date: Mon, 4 Nov 2002 22:53:43 -0800 (PST)

On Mon, 4 Nov 2002, RJ Atkinson wrote:
    > peering -- in order to engineer congestion out of their networks
    > (and out of their access links with peers)  So the above is a bit
    > of a misapprehension of the deployed situation.

Mmm, I wouldn't put it that way...  All traffic that exceeds what's
reasonable to put through a switch port does take private interconnects,
but those are nearly all in exchange facilities, now.  I don't see much
private peering occurring outside exchange facilities at this point.

Back to the point that Ms. King was making, I think, if you look at what
Time Warner Telecom is doing with their INOC-DBA phones, they're building
out separate dedicated infrastructure to handle the emergency calls, and
handing off across separate crossconnects at exchanges, so that if they
were to actually suffer some sort of catastrophic collapse of their entire
backbone, they'd still be able to chat with people about it on the phone.

That's going much further than anyone else, so far, but it does show that
it's perfectly possible to do, without any of the "requirements" and at a
far lower cost and higher reliability than would be offered by following
these "requirements."

                                -Bill

---

From: RJ Atkinson <[email-masked]>
Date: Tue, 5 Nov 2002 08:25:39 -0500

> private peering occurring outside exchange facilities at this point.

I was told at the time that UUnet and several other big ISPs pretty much
required that we *not* exchange traffic at an exchange point once we 
were
facilities-based.   The typical thing was to run a metro link (usually 
SONET)
between one core router from each ISP within some metropolitan area.  
In a small
number of cases, there was a SONET point-to-point link inside a shared 
facility.
The exchange  points (e.g. MAE-East) were used for exchanging traffic 
with smaller
ISPs, though point to point links (i.e. not through a switch fabric)
was not uncommon even in that case.

It sounds like either your sample space is different or things have
changed.  Interesting either way.

I'd still like to see you all give a short presentation about the 
actual nature
of deployed ISP networks today in Atlanta, though I haven't seen Scott 
comment
on that idea yet (its only been a few hours since I made the 
suggestion, so
this is not a gripe about Scott :-).

Cheers,

Ran

---

From: Bill Woodcock <[email-masked]>
Date: Tue, 5 Nov 2002 11:01:33 -0800 (PST)

On Tue, 5 Nov 2002, RJ Atkinson wrote:
    > were facilities-based.

Yeah, that was definitely the case during the period you were at @Home...
A lot of the old-school telco carriers had been getting bad PR surrounding
latency and loss where they connected to exchanges, and that was their
reaction.  They've actually examined the dollar cost of that reaction
since then, and corrected it.

                                -Bill