Subject: RE: [Ieprep] draft-ietf-ieprep-requirements-00.txt

From: "Folts, Harold" <[email-masked]>
Date: Thu, 4 Jul 2002 13:20:44 -0400

> -----Original Message-----
> From: RJ Atkinson [mailto:[email-masked]] 
> Sent: Friday, June 28, 2002 4:39 PM
> To: ieprep
> Subject: [Ieprep] draft-ietf-ieprep-requirements-00.txt
> 
> 
> 
> 	An underlying issue with this document is the 
> assumption that backbones might be under-provisioned.
> 
> 	Many large backbones are in fact over-provisioned.  
> That is, they have more capacity than they have maximum 
> potential offered load. In many cases, this capacity is built 
> on multiple wide-area SONET rings, so that even an earthquake 
> or smallish tactical nuclear bombs would not cause them to be 
> underprovisioned.[1]

This may be the case today, but I do not think we can assume this
indefinitely. As usage expands, service providers may not invest in
continued bandwidth expansion, but will put the increased revenues to the
bottom line like most profitable business will do.

> 
> 	In such a network, QoS is not really a meaningful 
> concept.  It seems to me that an operator with such a network 
> might well be able to provide the services desired for IEPREP 
> without making any special provisions in their network (other 
> than ensuring robust overprovisioning continues to be the case).

Again good for today, but for serious disaster situations, we have to
consider the doomsday scenario as a practical matter.

Hal

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

---

From: RJ Atkinson <[email-masked]>
Date: Thu, 4 Jul 2002 20:16:49 -0400

> bottom line like most profitable business will do.

Hal,

	The backbones that I know of that are over-provisioned are
over-provisioned because that is the profitable approach.  That is,
they've done the math and it is cheaper to over-provision than
to have a congested backbone.  The economic trends are such that
this is becoming even more profitable than it was several years ago.

	So your belief that they will under-provision their core
backbones flies in the face of all available economic data
and their general goal of profitability for IP backbones.
(To pick one example, cost of a 10 Gbps interface dropped in about half
during the past 18 months -- directly due to the presence of 10 GigE,
which can be carried in a WAN via various DWDM systems.  WAN dark
fibre costs are also a lot lower today than several years ago.)

	Note well that I distinguish a core backbone from an access
network throughout this thread.

> consider the doomsday scenario as a practical matter.

	You missed the point entirely, I'm afraid.  The over-provisioned
backbones I know of can put the *whole max load* on a single trunk (and 
have
path diverse trunks in parallel).  So there is no "partial failure" mode
possible that would create congestion in the core backbone.  They've 
either got
at least one path still up in a disaster (in which case that one path has
sufficient capacity to handle max offered load) or they have no path up.
In either scenario, QoS is simply not useful.

	Again, access networks today tend to be different and tend to be
under-provisioned -- but most usually the under-provisioned segments
do not belong to real Tier-1 ISPs, but rather to smaller regional ISPs.

Ran
[email-masked]

---

From: senthil ayyasamy <[email-masked]>
Date: Thu, 4 Jul 2002 18:05:14 -0700 (PDT)

Let me provide some facts to butteress Ran's points. I
am talking only about the core networks.

1. All the tier-1 service providers use
over-provisioing for a healthy core. Even if they use
QoS technologies, it is used as a secondary option.

2. ISP's using MPLS and related technologies tend to
use only explicit routing option which requires manual
configuration. I dont think this will be of much use
to emergency service unless otherwise you reserve that
explict path for emergency use.

3. Also one cannot easily give priority by
manipulating OSPF weights. over-provisioning is the
base condition for employing such techniques. Service
providers recompute weights only when some new routers
are introduced to re-adjust the whole topology. So
providing priority by OSPF weight optimization is also
ruled out.

4. Dynamic QoS routing schemes: One can do academic
research on possible use of QoS routing schemes for
giving priority and pre-emption. But the fact still
remains that *QoS routing is the much researched and
nill implemented technique*. The simple reason being
people often prefer manual configurations than complex
QoS mechanisms.

5. Diffserv mechanisms: I am not aware of its
deployment details. But this might be a possible place
for use. But still it will be useful only at the
access as the core tend to be over-provisioned.

I think both requirement draft and fred's draft
suggests over-provisioning  as a possible technique. 
 
So the problem is only at the access. Most of the
IEPREP outputs will be most applicable for access
providers only.

As for as transit is concerned, I am little hesistant.
Some persons in this list have commented that service
providers has a tendeny to keep the congestion at the
transit. But as ran said, transit is also
over-provisioned and IETF cannot suggest any
recommendation for transit as such.

> do not belong to real Tier-1 ISPs, but rather to

__________________________________________________
Do You Yahoo!?
Sign up for SBC Yahoo! Dial - First Month Free
http://sbc.yahoo.com

---

From: RJ Atkinson <[email-masked]>
Date: Thu, 4 Jul 2002 21:11:44 -0400

On Thursday, July 4, 2002, at 09:05 PM, senthil ayyasamy wrote:
> But as ran said, transit is also

To be clear, I said that in many cases transit is also over-provisioned,
particularly so with private peering (which is now dominant over
exchange points as a way Tier-1s exchange traffic among themselves).
I am not omniscient, so I've tried to be careful not to claim that
all core links or all core transit is over-provisioned even among the
Tier-1 operators.  For some Tier-1s I believe that they really do
over-engineer, based on knowledge of their networks and practices,
for other Tier-1 operators I'm not as well informed as for the first set.

However, this misses my main original point, which is that QoS
is a mechanism and is not a requirement.  The requirement is
"availability" and there are several mechanism an operator might
choose to meet that requirement, including but not limited to QoS,
over-engineering, or other methods.

Ran
[email-masked]

---

From: senthil ayyasamy <[email-masked]>
Date: Thu, 4 Jul 2002 18:25:38 -0700 (PDT)

> over-engineering, or other methods.
 I accept that requirement draft should take no
position about a deployment issue and have to be
generic. But, cant a requirement draft give some
possible examples about mode of deployment?

=====
Ayyasamy Senthilkumar
M.S.(Computer Networking)
UMKC,MO.
-----------------------------
An expert is a man who has made all the mistakes that can be made in a very narrow field.
--Niels Bohr.

---

From: "Stuart (Stu) Goldman" <[email-masked]>
Date: Fri, 05 Jul 2002 08:43:34 -0700

Folks,

As an old engineer, I understand the frustration.  The requirements given for
the Ark were quite specific. So many cubits by so many. Don't worry, if you
just follow the specifications all the animals will fit. I believe even the
type of wood to be used was specified. Building the Ark would have been much
more difficult if the requirements did not include any implementation aspects
at all, and just said it needed to be "big enough and strong enough" to hold
an unspecified number of animals for an unspecified time during unspecified
weather conditions.

Until we can get the terrorists to provide details on their pending attacks,
we have to work from vague, "unspecified" requirements which lead some of us
to try to do the very best we can by installing as much protection as we can
envision in the absence of a requirement that specifies at what point in the
escalating doomsday scenarios it is ok for the system to fail emergency
communications.

A great deal of money was "wasted" yesterday in the US providing protection
against 4th of July attacks that failed to materialize.  The people who said
that the protection was beyond what was needed were indeed right. I can only
say that we are in difficult times and perhaps we too should error a bit more
on the side of preparing for more dire scenarios. I would rather "waste" some
time and money over hardening, than to find that my emergency communications
breakdown during a really, really  bad emergency.

---

From: RJ Atkinson <[email-masked]>
Date: Fri, 5 Jul 2002 13:24:13 -0400

On Friday, July 5, 2002, at 11:43 AM, Stuart (Stu) Goldman wrote:
> Building the Ark would have been much

Stu,

	The flaw in your analogy is that in this case there are a whole slew
of parallel documents that outline various implementation approaches to
meeting the requirements.  So the proposal is not that implementation 
approaches
be undocumented, but rather that we crisply separate the requirements 
into
one document and the various ideas on implementation approaches into 
other
documents.

> escalating doomsday scenarios it is ok for the system to fail emergency

	That's just bogus in this context.  A classic big red herring.  In 
the example
on the floor, it doesn't matter which attacks someone uses on a large 
ISP where each
trunk can handle max load for their core.  Either there is at least one 
trunk,
in which case there won't be any congestion XOR there are no trunks in 
which case
neither QoS nor anything else will help.

	If NCS will focus on requirements and give implementers flexibility 
about
how to meet them, then it will surely be lower cost to me as a US 
taxpayer.  In any event,
IETF is working on an *international* standard and different countries 
have very different
requirements (e.g. I'm told Swedish requirements do not resemble NCS's 
requirements
particularly closely).   If NCS can't bring itself emotionally to work 
within a
framework where we separate requirements from implementation details, 
then what remains
is purely a contractual matter for NCS & contractors AND there is no 
IETF standards content
left so this list can be shutdown.

Ran
[email-masked]

PS:	I remain impressed by the amount of taxpayer dollars NCS is 
spending to try
	to pack this working group.  Sad, but impressed.  :-(

---

From: Henning Schulzrinne <[email-masked]>
Date: Fri, 05 Jul 2002 13:43:47 -0400

> neither QoS nor anything else will help.

Curiosity item: At least from looking at various big-ISP maps (like the 
one formerly starting with U), it is quite common that a single 
POP-to-POP connection is Nxsomething, e.g., NxOC-3 or NxOC192. Thus, it 
seems at least plausible that there could suddenly M, where M << N and M 
 > 0, parallel links. If these are all in the same fiber bundle or even 
just wavelengths on the same fiber, this may be unlikely, but I thought 
that load balancing across (logically) parallel links that are 
physically diverse was fairly common for quick recovery.

Also, for any interesting network, even if overdimensioned, you can take 
out enough links so that (parts of) the network remain connected, 
through more than one hop, but at significantly reduced capacity. Are 
you claiming that all (good) ISPs are designed so that any 
still-connected network, regardless of which combination of links your 
adversary can take out, can carry the busy hour load?

Henning

---

From: RJ Atkinson <[email-masked]>
Date: Fri, 5 Jul 2002 15:57:34 -0400

On Friday, July 5, 2002, at 01:43 PM, Henning Schulzrinne wrote:

> Are you claiming that all (good) ISPs are designed so that any 
> still-connected network,
> regardless of which combination of links your adversary can take out, 
> can carry the busy hour load?

	No, I'm claiming that several existing ISPs are designed today such 
that
any single backbone link can carry the full max offered load across that 
link
(e.g. Atlanta -- Dallas), even if all other parallel links (e.g. 
Atlanta -- St Louis
-- Dallas) are taken out (e.g. by a backhoe cutting a fibre bundle). [1]

	And typically the NxOC-(speed) links are actually provisioned as N
wavelengths on a shared DWDM system using a single shared fibre pair.
So if a backhoe hits or a DWDM box fails or a router fails, all of those
parallel links drop together.

	In some cases, the operators are waiting for vendors to ship OC-768 POS
interfaces so they can get rid of the 4xOC-192 links used today.  I 
don't see
a lot of NxOC-3, NxOC-12, or NxOC-48 links today -- simply because it is 
usually
cheaper (both capital and operating costs) to simply deploy one of the 
next
larger standard OC-(speed) interfaces than to deploy NxOC-(smaller speed)
interfaces.

	But this is all sidebar, the issue is whether QoS is a requirement
or a mechanism.  I submit that QoS is a mechanism for ensuring 
availability,
not a requirement in and of itself.

Ran
[email-masked]

[1] By the way, backhoes appear to be the biggest risk going to Internet
connectivity.  Most regular attendees of NANOG or such like will agree.