Subject: RE: FW: [Re: [Ieprep] ieprep-requirements-01 - reqs 6-10 - discus sion request]

From: "Nguyen, An" <[email-masked]>
Date: Sat, 9 Nov 2002 20:00:27 -0500

Ran,

When the 9/11 happened last year, the internet traffic was fine in general
according to you and others. Do you have any rough number on how much of it
was time-sensitive ( e.g., voiceIP, video, etc.) traffic? I guess the
percentage of time-sensitive must have been very little compared to
time-insensitive data traffic such as web, email, and others. My thinking is
when people surf the web or send an email, they don't care much if there are
congestions in the networks because they commonly accept it as the way the
internet works. But when it comes to voice traffic, it is a totally
different matter ( very noticeable as you and I experience it with the
cellular phone). This leads me to ask you, Bill, and others another
question: do you foresee that the Internet will be use to  transport most of
voice traffic and other time-sensitive applications and eventually will
replace POTS network because of its ubiquity? If the answer is "yes" then
the "future" Internet will have to carry much more time sensitive traffic
and congestions will be an issue. 

NCSs's mission is to ensure that communications are available during
emergency and crisis. We need to communicate with others when emergency
occurs. And when emergency happens in an area, traffic congestions are
likely to occur. So, without some sort of priority treatment for NS/EP
traffic, it's extremely hard for us to fulfill our mission.

Regards,

An

-----Original Message-----
From: RJ Atkinson [mailto:[email-masked]]
Sent: Friday, November 08, 2002 8:14 PM
To: [email-masked]
Cc: Bill Woodcock; [email-masked]
Subject: Re: FW: [Re: [Ieprep] ieprep-requirements-01 - reqs 6-10 -
discussion request]

On Friday, Nov 8, 2002, at 16:28 America/Montreal, Gary Thom wrote:
> One thing to remember, is that we are really looking at operating under
> non-normal conditions. This may be due to an unusually high load or 
> with
> degraded capability. During an emergency, such as a huricane or 
> earthquake,
> not only will you have everyone trying to find out if their loved ones 
> are
> ok, but you may have loss of bandwidth or or other error conditions 
> due to
> damaged equipment, fiber, etc. In this situation, we want to give 
> emergency
> communications an advantage.

Gary,

	Would you consider 9/11/2001 to be "non-normal conditions" ?
As someone with a number of friends who work daily in the Pentagon,
and several parish members who died that day, I'd say that day was
pretty unusual.

	During that day, a few content providers had problems delivering
all the requested content.  In at least some cases, this was server
overload.  However, careful analysis of traffic logs by large ISPs
afterwards confirms that the Internet performed brilliantly.  Despite
fibre cuts in lower Manhatten and numerous environmental problems at
Hudson Street, the Internet automatically re-routed around the damage
and kept going.  And the large ISPs did NOT (repeat did NOT) start
dropping packets because of the cut fibres -- their backbones were
carefully over-engineered so the traffic was re-routed around the
lost links.

	Access to the US NASA feeds of the mars lander landing was a bigger
problem in Internet terms, yet even then the problems were on NASA's
access links and its servers, rather than in any large ISPs network.

	To me, the key thing is that the critical traffic gets through.
Saying that it must be "prioritised" implies a specific mechanism for
prioritisation.  It is better for us to focus on the real requirement
of the traffic getting through, than on specific mechanisms (in your 
words,
prioritisation) which might not be (probably aren't) needed, create new 
attack
vectors on the ISP network, and increase operational complexity.   There
is a significant body of evidence that a better (and lower-cost) 
approach
is to over-engineer the network so that the network simply can handle 
all
the offered load.

	I spent a fair bit of time yesterday talking with folks from major
ISPs.  One is a large inter-continental ISP with POPs located in 
Asia/Pacific,
North America, and Europe.  Another is based in Japan.  (etc.).  In
each case, they indicated that their backbone links are significantly
overprovisioned (max load << (50% link capacity)).  A typical number 
that
was mentioned was that links have a "max load" equal to 30-35% of link 
capacity.
They also noted that they have significant path diversity in their 
networks,
specifically including physical fibre path diversity.  This was 
originally
done as defence against back-hoe equipment, but it happens to work 
really
well during other kinds of natural/unnatural problems as well.  To give
another example, there was a fibre cut near Baltimore a while back.  It
cut several fibre bundles from different carriers.  The IP routing 
system
just automatically detected the link-down state and routed around the 
cut links
-- and there was enough spare capacity in the other links that there 
was no 
significant loss of service.

	Claims of the form "the Internet gets congested and drops packets
when an emergency happens" currently lack credibility, because they are
contrary to the measured, scientific data that we happen to have.  I'd
be much more inclined to take those claims seriously if someone would 
show
up with specific measured data about an actual incident.  And in that 
case,
it would be important to have enough specifics to actually sit down and
analyse precisely what happened -- without a great deal of detail this 
WG
is unlikely to correctly and clearly characterise the issue so that 
another
IETF WG to figure out what the correct protocol change(s) might be or 
for ISPs
to figure out which existing mechanisms might be candidates for broader
deployment.

	It would also be helpful if going forward we could clearly separate
our
sundry concerns into the different layers of the Internet Architecture 
(Physical,
Link, IP, Transport, Application).[1]

Ran
[email-masked]

[1] The Internet Architecture is not identical to ISO OSI Model.  For 
example,
we have no Session Layer in the Internet.

_______________________________________________
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: Sean Donelan <[email-masked]>
Date: Sat, 9 Nov 2002 21:21:44 -0500 (EST)

On Sat, 9 Nov 2002, Nguyen, An wrote:
> My thinking is when people surf the web or send an email, they don't
> care much if there are congestions in the networks because they commonly
> accept it as the way the internet works.
[...]
> traffic, it's extremely hard for us to fulfill our mission.

My cell phone tends to drop calls, has annoying dropouts, and doesn't
work at all in my kitchen.  Is NCS's mission to make cell phones have
perfect stereo quality sound, work everywhere, under every possible
condition? From what I've read, the proposed cell phone priority system
does not include "improving" the quality of the cell phone system,
requiring carriers to make cell phones work under every conceivable
condition, as well as wireline phones, or any of the other wish list
items. Cell phones work about as well as cell phones work.

Then why expect anything different of IP telephony?

IP telephony will work about as well as IP telephony works.  Adding an
method for transporting the emergency flag data will not change the
quality of service during an emergency.

There may be conditions where a priority flag may be needed.  But without
real-life experience its difficult to know where the bottlenecks will be.
Bill Woodcock's INOC-DBA phones haven't really tested this condition yet.

Traditional wireline phone switches do not handle a large number of call
attempts from non-wireline sources such as cell phone or IP telephony
gateways well. Gateways tend to concentrate a lot of traffic in a few
limited connections. To keep the POTS switch from crashing, the gateways
may need to rate limit the number of call attempts on the near side.
When gateways are rate-limiting to protect the POTS network it creates a
blocking queue on the IP or Cellular side.  IP folks will recognize this
as the traditional Head Of Line Blocking problem.  IP folks have worked
hard to get rid of HOLB on the Internet, but we probably can't fix the
POTS system.

Is this a real problem? I don't know.

---

From: Scott Madley <[email-masked]>
Date: Sun, 10 Nov 2002 09:05:41 +0000 (GMT)

> hard to get rid of HOLB on the Internet, but we probably can't fix the

How so, and what is defined as a large number of call attempts?  While not
up to RBOC traffic levels, there are a few dedicated VoIP companies that
are pushing millions of calls a month onto the PSTN.  Port densities on
VoIP aren't exactly the greatest, so you actually tend to have a lot of
traffic on a lot of connections, spread out across alot of boxes.
Sound engineering also dictates that you'll have connections into several
different switches depending on the amount of traffic PSTN bound traffic
your pushing.

Gateways don't control access to the media, rather they just faciliatate
it.  Softswitches control access to the media, so there needs to be an
intelligent element within that determines who gets access and who gets
preempted during congestion conditions.  The underlying fact is there are
two elements which are critical to completing telephone calls,
availability of signalling (SS7) and availability of media (trunking)
irregardless of the network type.  If either isn't available your call
isn't going thru.

I'm slightly confused as to whether your talking about packet
rate-limiting or resource contention with the far-end (signalling)?  I've
yet to see a 5E crash from high-call volume (setup/teardown), I have however seen
them become useless due to signalling failures (hitting priority level 3
isn't fun).  Which brings up the question, is it better to setup the call
and lose a few packets, or ensure packet delivery but be unable to setup
the call?

Cheers
-Madley

---

From: Sean Donelan <[email-masked]>
Date: Sun, 10 Nov 2002 05:37:21 -0500 (EST)

> and lose a few packets, or ensure packet delivery but be unable to setup

You'll need to talk to the ATIS folks why network reliability of the PSTN
is impacted by large numbers of call-attempts from Next Generation
Networks.

http://www.atis.org/pub/clc/niif/issues/0189.doc

---

From: Bill Woodcock <[email-masked]>
Date: Sun, 10 Nov 2002 03:37:43 -0800 (PST)

On Sat, 9 Nov 2002, Nguyen, An wrote:
    > time-insensitive data traffic such as web, email, and others.

Correct.  Most traffic across many measurement points is peer-to-peer file
sharing.  Voice, video, and other time-sensitive traffic is a miniscule
and diminishing portion of the total, and that trend will likely continue.

    > My thinking is when people surf the web or send an email, they
    > don't care much if there are congestions in the networks because
    > they commonly accept it as the way the internet works.

Actually, I'd say that they don't care because it's not appreciable to
them.  People don't generally pay too much attention to a tenth of a
second here or there.

    > But when it comes to voice traffic, it is a totally different matter.

How so?  Please elaborate.  I'd say that people don't care about
congestion on the Internet when using VoIP because, like when using TCP,
it's unnoticable to humans without measurement tools.

    > (very noticeable as you and I experience it with the
    > cellular phone).

Agreed, congestion on the PSTN is very noticable, in that it results in a
failure to complete a call, or a dropped call.  That's the critical
failure of circuit switching, and one of the principal reasons it's being
deprecated.

    > This leads me to ask you, Bill, and others another
    > replace POTS network because of its ubiquity?

Yes, I do believe that.  Although that's a _long_ ways off.  The dinosaurs
didn't die overnight.

    > If the answer is "yes" then the "future" Internet will have to
    > carry much more time sensitive traffic...

Yes, but it'll be a much more miniscure portion even than it is today.

    > ...and congestions will be an issue.

This seems to me to be a completely unsupported statement...  How are you
arriving at this conclusion?

    > emergency and crisis.

You might want to come up with a new mission, then, since that one's
unachievable, whether by circuit switching or packet switching.

    > We need to communicate with others when emergency occurs.

Yes, of course.

    > And when emergency happens in an area, traffic congestions are
    > likely to occur.

Well, I can see how you'd draw that conclusion from looking at the PSTN...
The PSTN is incredibly fragile, and the slightest failure results in
problems which are very obvious to users.  However if you look at the
Internet, the effects that the types of things NCS is likely to call an
emergency have on it are relatively miniscule, and the visibility of those
effects to the users are still more miniscule.  So this hasn't proven to
be a problem area.  NATs, particularly those with dynamic outside
addresses, are a huge problem area, by contrast.  Those create a total
failure of connectivity, not an audio-quality degredation that's temporary
and beneath the threshold of noticability for users.

    > So, without some sort of priority treatment for NS/EP

In fact, without traffic prioritization, it's _impossible_ for you to
fulfill your mission.  And _with_ traffic prioritization, it's impossible
to fulfill your mission.  This has to do with your definition of your
mission, not traffic prioritization.  I'm guessing that someone somewhere
in NCS has a more conservative statement of your mission which is actually
achievable, and is similarly orthoganal to traffic prioritization.

                                -Bill

---

From: Bill Woodcock <[email-masked]>
Date: Sun, 10 Nov 2002 03:48:43 -0800 (PST)

On Sun, 10 Nov 2002, Scott Madley wrote:
    >> IP folks have worked hard to get rid of HOLB on the Internet, but
    >> we probably can't fix the POTS system.
    > How so, and what is defined as a large number of call attempts?

My experience with intra-PSTN-telco interconnects is admittedly quite
limited, but what of it that I've observed has been fairly heavily
dependent upon Nx chan-DS1 interconnects, at 24 call appearances each.  By
comparison, Internet peering connections are typically GigE, which,
running at 70% capacity, would carry about 65,000 call appearances each.

My experience with PSTN-to-VoIP interconnects is direct and current, and
I'm observing PSTN telcos doing Nx PRI handoffs at 23 call appearances
each, where N is typically not more than four.

    > The underlying fact is there are two elements which are critical to
    > completing telephone calls, availability of signalling (SS7)

Or SIP.

    > and availability of media (trunking) irregardless of the network
    > type.

Fortunately GigE is dirt cheap, which is why so much of the network is
getting built out of it nowadays.

                                -Bill

---

From: RJ Atkinson <[email-masked]>
Date: Sun, 10 Nov 2002 08:28:05 -0500

On Saturday, Nov 9, 2002, at 20:00 America/Montreal, Nguyen, An wrote:
> was time-sensitive ( e.g., voiceIP, video, etc.) traffic?

I haven't seen any *good* measured statistics on which applications 
consume
what % of (packets, bytes) since I stopped working for an ISP.

> I guess the percentage of time-sensitive must have been very little 
> compared to
> internet works.

Ah.   The measured data from 9/11 did measure potential congestion.  It 
was
miniscule inside the Internet.  The measured data indicates that there 
WERE
problems with server performance of some popular web servers; -- those 
content
providers ripped graphics off their web pages moving to HTML only, then
reconfigured/added servers, and eventually solved those content server 
issues
on that day.

> But when it comes to voice traffic, it is a totally

I used inter-domain VoIP on the morning of 9/11 and did not experience
any problems.  Note that one end of that link was in the Reston area,
transiting MAE-East on its way to MAE-West, with the other end in 
Silicon
Valley.  That's only one sample, admittedly, but it is a sample that is
entirely consistent with the actual measured data on network behaviour
during 9/11.

If the Internet had broken on 9/11, which it emphatically did not (as
measured data clearly shows), then an argument to change the way ISPs
deploy their network might be more persuasive.  Since that did NOT 
happen,
there is very good reason to continue to use what clearly worked well
under unusual circumstances.   (Since it isn't broken, why change it.)

> replace POTS network because of its ubiquity?

I seriously doubt that the PSTN will ever be replaced by a VoIP network.
I think VoIP is more likely to be used within a campus or to build
relatively small-scale (compared with PSTN) intra-organisational 
cost-optimised
toll bypass.  And I think those campus phone switches will continue
to have traditional PSTN interfaces.  If nothing else, that will be 
needed
to contact folks who are off-the-VoIP-network (e.g. customers, mobile 
phone
users) and take incoming calls from the PSTN.

My employer uses VoIP and lease-lines to bypass long-distance toll 
charges
on some intra-company links, but we use a huge amount of PSTN also.  
The DoD's
AutoVON/DSN does the same (no VoIP, due to JCS directive, but private 
connectivity
for sure), yet DoD still uses a huge amount of PSTN.  So does GE's 
corporate
phone network.  Bypasses such as the one that GE built/uses have been 
around
for many many years, yet have not affected growth of the PSTN.

[Aside:	I'm aware of DISA's use of VoIP at Skyline and also that not all
residents of Skyline like it;  (ironic quote of the day from earlier in 
2002
from someone who works there:  "The beauty of VoIP is that when the 
data network
is down, one can't report the outage to the network support staff.")]

The PSTN has the advantage that it is overwhelmingly one application, 
voice,
which is well characterised and predictable, so it can (and does) 
optimise its
network design/deployment for that one application.

The Internet will never have the luxury of only supporting a single 
application
in that way, so the Internet will need to continue to have a different 
kind
of design approach.

> traffic, it's extremely hard for us to fulfill our mission.

Prioritisation is a mechanism.  The NCS mission, as you state, is to
ensure communications availability.  NCS ought not care which mechanism
is used, provided that communications remain available.

Over-provisioning is a different mechanism, commonly used today (max 
link
utilisation equal to 30% of link capacity is typical among the ISPs I 
was talking
with last Thursday),  to ensure that packets don't get lost in the 
network,
because it is cheaper than deploying something like DiffServ.  Other 
mechanisms
also exist.

[ASIDE:		So far, each time there has been a press release or article
claiming that ISP <x> has deployed DiffServ throughout its network, 
when I
have tracked down the facts of the matter it has turned out to be 
marketing
or press confusion unrelated to the actual operational network.  It 
would be
VERY helpful if any ISP would make a public presentation at NANOG/RIPE 
about
their deployment.  So if anyone is at such a place and is listening, 
please
consider making such a public presentation in detail.]

An alternative perspective is that NCS ought to focus on talking with 
ISPs about
contracts that have *performance-based* metrics for ensuring network 
availability,
rather than contracts that require particular mechanisms to be deployed
(whether or not those mechanisms work in a particular situation).

After all, as long as an ISP that has chosen to provide contracted 
services
to NCS can provide those services, why should NCS care which 
mechanism(s)
are used to provide those services ?

This alternative view is consistent with more recent USG contracting 
practices,
such as the USN outsourcing of its LANs to EDS, where EDS is given 
performance
metrics to achieve, but has total flexibility in how to meet those 
metrics.

Ran
[email-masked]

---

From: RJ Atkinson <[email-masked]>
Date: Sun, 10 Nov 2002 08:45:18 -0500

There are multiple defintions of "gateway" in this conversation.
It would help if folks were more specific... :-)

Two Quick Examples:
	gateway == VoIP PBX with a T1 voice uplink to PSTN
	gateway == VoIP server inside the Internet to connect VoIP users

---

From: RJ Atkinson <[email-masked]>
Date: Sun, 10 Nov 2002 08:51:44 -0500

> it's unnoticable to humans without measurement tools.

Bill,
	That depends A LOT on the vocoder.  Some vocoders are brittle and
will not provide intelligible speech if they encounter small amounts of
delay/jitter/pkt-loss.  Other vocoders are more robust in the same 
circumstance.
The latter are more sensible for use in VoIP systems.  ITU's set of
standard vocoders contain examples of both.

	And I think An is thinking about non-trivial amounts of congestion
(hypothetically) existing in the network, while you are thinking about
the (currently) trivial amounts of congestion in the network.  Different
implicit assumptions will yield different conclusions.

> unachievable, whether by circuit switching or packet switching.

	To be fair, GETS worked VERY well on 9/11/01.  To also be fair,
the demand for Iridium phones probably peaked on 9/12/01, so GETS
isn't and wasn't the only possible approach to continued connectivity.

Ran
[email-masked]

---

From: RJ Atkinson <[email-masked]>
Date: Sun, 10 Nov 2002 08:57:17 -0500

> getting built out of it nowadays.

Most GigE products (from any mainstream vendor) will have some level of
support for 802.1P precedence.  Those that are also IP routers will
have some level of support for DiffServ as well.  Important details
of implementations DO vary from one vendor to another.  But it is
definitely the case that (some level of) equipment support for
DiffServ/IP ToS/802.1p is pretty common today.

And 10 GigE is very expensive today, primarily due to optics component
costs.  Those are coming down.  After some time period, 10 GigE
will become more affordable.  And 10 GigE products *mostly* have
support for the above as well (there are a larger number of
exceptions right now with 10 GigE, including at least one widely used
vendor's implementation).

What seems to be missing is the actual experience with large-scale
deployment of QoS in the WAN of an ISP.  As noted several times before,
RIPE/NANOG would probably love to see presentations from anyone with 
such
experience.

Ran

---

From: Henning Schulzrinne <[email-masked]>
Date: Sun, 10 Nov 2002 11:05:52 -0500

> under unusual circumstances.   (Since it isn't broken, why change it.)

Except that almost none of the real-time load used the Internet that 
day, so that this doesn't tell us much should such load-shift occur.

> I seriously doubt that the PSTN will ever be replaced by a VoIP network.

This, I believe, depends on the definition of "replace". There are at 
least three possible versions of that:

- use the same commodity Internet for all voice traffic;
- use some form of VPN, possibly at L 2.5 (MPLS), so that you share 
facilities and 'switches', but have clear traffic separation;
- set up physically separate networks, at least at the wavelength layer.

We probably also need to distinguish between existing IXCs and LECs and 
greenfield deployments. For example, there is very strong interest in 
all-IP radio access networks for 3G and later wireless carriers. 
Similarly, there have been stories that when a carrier went into a new 
country (BT and Spain, I believe), they didn't bother with a CS network 
and used a (separate) IP network.

This does not mean that voice traffic will dominate Internet traffic. It 
would only do this if you moved all local calling traffic to the 
Internet. However, that makes life easier, since the impact of 
prioritization on the rest of the traffic, say, is much less if you 
rate-limit the high-priority traffic.

> to have traditional PSTN interfaces.  If nothing else, that will be needed
> to contact folks who are off-the-VoIP-network (e.g. customers, mobile phone

---

From: RJ Atkinson <[email-masked]>
Date: Sun, 10 Nov 2002 12:03:37 -0500

On Sunday, Nov 10, 2002, at 11:05 America/Montreal, Henning Schulzrinne 
wrote:

> day,
> so that this doesn't tell us much should such load-shift occur.

Very little of the PSTN load uses the Internet on any day, including 
that one.
I think the normal real-time load on the Internet (real-time is MUCH 
broader
than PSTN-like voice) was still present by and large (perhaps even a bit
more usage -- making outbound calls from Northern VA via PSTN was 
problematic
but dialing 4-digit extension to our other offices over IP worked fine;
guess which one I used more).

> three possible versions of that:

Good catch.

> - set up physically separate networks, at least at the wavelength 

I think option (1) above won't ever happen.

With Option 2, I'd be surprised if such an MPLS approach did not also 
include
explicit bandwidth provisioning for the MPLS "circuits".  I don't see 
this
as likely to soon "replace" the PSTN.  I do think this will get used 
for some
private voice services (not PSTN).

Option 3 is essentially re-engineering the PSTN, rather than using the 
public
global Internet.  Ask the phone guys what they think; it seems 
counter-intuitive
to do this, but I'm not informed either way.

Ran

---

From: Sean Donelan <[email-masked]>
Date: Sun, 10 Nov 2002 17:52:40 -0500 (EST)

> running at 70% capacity, would carry about 65,000 call appearances each.

As I understand the problem, its not the number of calls which is limited
by the trunking capacity, but the number of call attempts and not
implementing congestion controls on the NGN side.  Its like when concert
tickets go on sale in a major city, and everyone starts calling the box
office at the same time swamping the PSTN.  Even though 99% of the calls
don't go through, the call attempts still disrupt PSTN service elsewhere.

---

From: Bill Woodcock <[email-masked]>
Date: Sun, 10 Nov 2002 15:56:12 -0800 (PST)

On Sun, 10 Nov 2002, Henning Schulzrinne wrote:
    > This does not mean that voice traffic will dominate Internet traffic.
    > It would only do this if you moved all local calling traffic to the
    > Internet.

Mmm, no, wouldn't do it then, either.  The global volume of calls is
infinitesmally tiny relative to Internet traffic.  Dumping all of it on
the Internet wouldn't make any appreciable difference to the Internet.

                                -Bill

---

From: Henning Schulzrinne <[email-masked]>
Date: Sun, 10 Nov 2002 20:54:03 -0500

Indications are that this is a common misperception. Read Odlyzko's 
papers on the topic for an attempt to estimate Internet traffic; local 
US call volume is a well-known quantity (see FCC documents). If you have 
a better estimate of Internet traffic volume, please provide a reference.

---

From: Henning Schulzrinne <[email-masked]>
Date: Sun, 10 Nov 2002 21:17:16 -0500

FWIW, http://www.cs.columbia.edu/~hgs/internet/traffic.html has some 
data sources.

---

From: Bill Woodcock <[email-masked]>
Date: Sun, 10 Nov 2002 23:21:58 -0800 (PST)

> a better estimate of Internet traffic volume, please provide a reference.

Andrew's numbers are the best-supported.  Are the call-volume numbers on
your web page at 64k, 11k, or 7k?

                                -Bill

---

From: "Alistair Munro" <[email-masked]>
Date: Mon, 11 Nov 2002 09:16:04 -0000

Hi Ran,

> 
> What seems to be missing is the actual experience with 
> large-scale deployment of QoS in the WAN of an ISP.  As noted 
> several times before, RIPE/NANOG would probably love to see 
> presentations from anyone with 
> such
> experience.
> 

Would you count the experiences with Premium service on Abilene,
recently reported by the Internet2 QoS WG, as useful input? I haven't
got the reference to hand but you can find it via www.internet2.edu.

Regards,

Alistair
 
--
Dr. Alistair Munro,
Chief Systems Engineer, Degree2 Innovations Ltd.
Regus House, 1 Friary, Temple Quay, Bristol, BS1 6EA, U.K.
E-mail: [email-masked]
Tel: (work) +44-117-900-8114, (home) +44-1275-462707, (mobile)
+44-7974-922-442;
Fax: +44-117-900-8151
Web: http://www.u4eagroup.com

---

From: RJ Atkinson <[email-masked]>
Date: Mon, 11 Nov 2002 06:09:41 -0500

On Monday, Nov 11, 2002, at 04:16 America/Montreal, Alistair Munro 
> got the reference to hand but you can find it via www.internet2.edu.

Any data beats no data.

That noted, Abiliene/Internet2 have a number of properties that are 
very very
different from a commercial ISP WAN.  Their mission explicitly includes
applied research, so they necessarily run their network differently than
a Tier-1 commercial ISP.  Also, their customer base is very different 
in mixture
from a Tier-1 commercial ISP.  For what its worth, ESnet and NASA 
Science
Internet are in the same bucket as Abilene/Internet2 in this particular 
aspect.

Do they have a paper on the operational problems they found with 
turning on QoS,
what QoS they turned on, etc.  ?

Ran

---

From: "Alistair Munro" <[email-masked]>
Date: Mon, 11 Nov 2002 11:37:40 -0000

Hi Ran,

> what QoS they turned on, etc.  ?

The complete picture can be got from http://qbone.internet2.edu/bb/. 

While Internet2/Abilene is, as you point out, not a typical ISP model,
it's the only one I know about where a large-scale QoS experiment has
been done.

I've been keeping an eye on the VoIP/congestion discussions. For what
it's worth:

1. I was advised to run VoIP services on a separate physical segment
from IT services. Having ignored this advice, I have found that, unless
there are a lot of long-lived TCP transfers (not the case in general),
the grade of service is fine for a small number of VoIP phones. If we
depended on VoIP internally I would definitely run it in a separate
physical network. 802.1q and 802.1d might be an alternative (is 802.1p
not absorbed into these two other standards now?) but I haven't
evaluated any products - I believe the Siemens Skyport range uses LAN
priority and bandwidth management for VoIP;
2. I'm sure loss/delay sensitive applications will run quite happily on
low bandwidth media. However, they don't always work well if they have
to coexist with a lot of other services and users, especially long-lived
TCP flows.

Regards,

Alistair

---

From: Henning Schulzrinne <[email-masked]>
Date: Mon, 11 Nov 2002 08:12:34 -0500

See http://qbone.internet2.edu/

>
> Do they have a paper on the operational problems they found with turning
> on QoS,

---

From: Henning Schulzrinne <[email-masked]>
Date: Mon, 11 Nov 2002 11:06:20 -0500

> your web page at 64k, 11k, or 7k?

64 kb/s, since compression isn't used on US landline circuits, as far as 
I know.

---

From: "Barry Raveendran Greene" <[email-masked]>
Date: Mon, 11 Nov 2002 09:35:27 -0800

Please put this into perspective. Qbone is really a tool to test the QOS
functions, not to test if oversubscription+QOS is going to work.

---

From: Bill Woodcock <[email-masked]>
Date: Mon, 11 Nov 2002 10:33:59 -0800 (PST)

> 64 kb/s, since compression isn't used on US landline circuits, as far as

That was my assumption as well.  Which makes all voice traffic somewhat
less than 1.5% of the size of the Internet, and dropping really quickly.
I think I was justified in discribing that as minute, or miniscule, or
whatever word I used.  The basic point was that the Internet, with
typically anywhere between 60% and 99.9% unused headroom, isn't going to
keel over or behave radically differently, if another 1.5% more traffic
were dropped on it.

                                -Bill

---

From: "Alistair Munro" <[email-masked]>
Date: Tue, 12 Nov 2002 10:03:36 -0000

Hi All,

To remove doubt: nobody said any of the I2/Qbone work was an operational
model for an ISP. It exposed a lot of useful issues that remain
unresolved in the IP QoS area.

Regards,

Alistair

> From: Barry Raveendran Greene [mailto:[email-masked]] 
> Sent: 11 November 2002 17:35
> To: Henning Schulzrinne; RJ Atkinson
> Cc: Alistair Munro; [email-masked]
> Subject: RE: [Ieprep] QoS & GigE
> 
> 
> 
> Please put this into perspective. Qbone is really a tool to 
> test the QOS functions, not to test if oversubscription+QOS 
> is going to work.
> 
> > > turning on QoS, what QoS they turned on, etc.  ?
> > >
> > > Ran
> >
> >

---

From: Scott Madley <[email-masked]>
Date: Thu, 14 Nov 2002 03:14:45 +0000 (GMT)

> > running at 70% capacity, would carry about 65,000 call appearances each.

Typical interconnects are of the DS1 variety, however depending on the
trunking need and the desired call-routing architecture ILEC's do hand
off on the DS3 level towards each other.  Individual DS0's in a trunk-grp are
referred to a members, and a DS1 compromised of 24 DS0's is referred to as
a span.  High-Capacity Trunk Groups between tandem locations usually
compromise 20+ individual T1's.

The beauty of the Internet is that we have an in-band messaging system to
exchange routing information via BGP4.  The PSTN still operates on a 56K
based system.  So if I can't send an IAM to the far-end switch I can't set
up the end to end circuit in order to complete the call.  Which brings up
the premise if you can't signal, you can't connect.

> don't go through, the call attempts still disrupt PSTN service elsewhere.

The problem isn't trunking or lack of trunking, but rather saturation to a
particular DN that is being called.  A properly engineered PSTN network
will have main trunk groups to each CO homed off a tandem location, in
addition to alternate routing that will use additional trunk-groups
transversing different CO's in the event of saturation.  I don't know if I
would consider a scenario such as the above, a real-world case of
congestion or degradation of the PSTN.  During an emergency scenario,
outbound/inbound calling would increase to a variety of DN's, not just one
in particular, thus taxing all trunk-grps, not just the one's associated
(primary/secondary/tertiary/etc) with routing to a select DN.

-Scott