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

From: "Gunn, Janet NE" <[email-masked]>
Date: Fri, 28 Jun 2002 16:52:41 -0400

While we have (luckily) not yet experienced it, it is quite possible to
imagine an emergency that causes a significant reduction in backbone
capacity.  We should be prepared to address that.  But I agree that
congestion/ lack of adequate provisioning at the "edges" is a more probable
case.  

Janet

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

...

[2] Experience to date is that the Internet has not suffered from extreme
traffic loads (i.e. more than the Internet can handle) even in the 
presence
of earthquakes (e.g. LA, Loma Prieta) or terrorism (e.g. on Sept 11th).
In fact, during such situations the "best effort" Internet has continued
to work quite well, thanks to a robust Internet Architecture.  This fact
is also not reflected in the above draft -- and seems like a bug.

_______________________________________________
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: RJ Atkinson <[email-masked]>
Date: Fri, 28 Jun 2002 17:29:53 -0400

On Friday, June 28, 2002, at 04:52 , Gunn, Janet NE wrote:

> capacity.

	In a lot of cases so far lack of problems has not been luck,
but rather thoughtful planning for robustness and for overprovisioning
by backbone operators.

	For several large ISP networks that I either worked on or am very 
familiar
with, it is pretty hard to imagine any emergency or disaster that would 
cause
a significant reduction in backbone capacity -- because they've been 
very careful
in their buildout to use diverse physical paths, redundant SONET rings 
in the WAN,
and various other techniques -- unless the situation were so dire that 
all capacity
were gone in that region.  To take some of them out, one has to take out 
the entire
communications infrastructure of a geographic region -- at which point 
QoS still
doesn't help because there is zero capacity in that region.

	The point I'm making here is that QoS is a *mechanism* that might 
be useful
in a number of situations.  It is not useful in *every* situation.  The 
requirements
need to reflect that.  The real requirement is availability when desired,
not which method the provider employs to cause that availability to 
happen.
So far, many ISPs have done the business analysis and concluded that it
is more cost-effective to over-engineer their networks (with redundancy,
capacity, and in other dimensions) than to deploy QoS.

	The proposed requirements are too mechanism specific and not 
sufficiently
high-level.

Ran
[email-masked]

---

From: senthil ayyasamy <[email-masked]>
Date: Fri, 28 Jun 2002 14:46:26 -0700 (PDT)

> capacity, and in other dimensions) than to deploy
    I dont deny your statement.Redundany is the reason
for robustness .But,the question before the house is :

- if the load on days like 9/11 exceeds the backbone
capacity 
 * how quickly one can augument the capacity*.The time
scale factor is very important as we are interested in
short-time scales.

- ISPs generally oversubscribe their links than
overprovision.Will this be a factor ? 

- senthil

__________________________________________________
Do You Yahoo!?
Yahoo! - Official partner of 2002 FIFA World Cup
http://fifaworldcup.yahoo.com

---

From: Fred Baker <[email-masked]>
Date: Fri, 28 Jun 2002 15:15:47 -0700

>- if the load on days like 9/11 exceeds the backbone

On 9/11, it's not clear that we significantly changed the utilization in 
the backbone. We re-routed some stuff due to fiber cuts and power supplies 
running out of fuel, but bluntly the Nimda and Code Red viruses had a more 
measurable effect on the net.

>overprovision.Will this be a factor ?

last I heard, which is perhaps a year out of date, Qwest was running their 
links 2.5% utilized. I don't know of any service provider that runs their 
backbone links significantly more than 10% utilized. This is what Ran is 
getting at.

---

From: "Stuart (Stu) Goldman" <[email-masked]>
Date: Fri, 28 Jun 2002 15:36:49 -0700

Folks,

It would seem that the ideal solution would apply to the network as a whole,
without having to differentiate between backbone and edge.  If we are concerned
with a case where there is congestion in both the originating and terminating
edges, it seems like the solution would apply regardless of the degree of
congestion (or more likely absence of congestion) in the backbone.

---

From: RJ Atkinson <[email-masked]>
Date: Fri, 28 Jun 2002 19:26:05 -0400

On Friday, June 28, 2002, at 06:36 , Stuart (Stu) Goldman wrote:
> without having to differentiate between backbone and edge.

Bad idea.  Often the backbone is run by a service provider which 
wholesales
transit service to a very separate access/edge network provider.

These are distinct networks (e.g. separate AS, separate owners, 
contractual
business relationships between them).  Different mechanisms have 
different
costs.  It would be unfair to force all providers to use the same 
mechanism.

> If we are concerned

If one edge were an over-provisioned MAN, then it ought not be required
to implement the same mechanism as an edge that were an under-provisioned
access network.

We need to keep the Requirements draft very high-level with only abstract
requirements (e.g. Availability) without discussing particular mechanisms
or deployment strategies.  There can then be some number of different
drafts discussing various different kinds of mechanisms that an operator
might consider.

Ran
[email-masked]

---

From: RJ Atkinson <[email-masked]>
Date: Fri, 28 Jun 2002 19:13:26 -0400

On Friday, June 28, 2002, at 05:46 , senthil ayyasamy wrote:
> But,the question before the house is :
>

It is, in fact, NOT the question in front of the WG.

The question is whether to mandate a particular *mechanism* (namely QoS)
in a document that purports to describe *high-level requirements*.

Secondarily, my assertion is that many backbones are engineered
to handle at least max(aggregate(access link bandwidth)) all the
time.  When an operator has their own facilities (e.g. fibre
and DWDM equipment), it is often cheaper to over engineer a
backbone than to deploy QoS or other mechanisms for dealing
with contention.

> overprovision.

That statement is false for most backbones in North America
and for many backbones in other places around the world.

It is true for many smaller Tier-2 or Tier-3 or Tier-4 access
IP service providers.  In particular, many of these smaller
IP service providers lack their own facilities, which means
they have a fundamentally different business model than
large backbone operators having their own facilities.

My comments were specifically using major backbones as the example.
I perhaps should have qualified by saying "in North America",
but that seems like a quibble rather than a material objection.

Ran
[email-masked]

---

From: senthil ayyasamy <[email-masked]>
Date: Fri, 28 Jun 2002 17:55:44 -0700 (PDT)

> backbone than to deploy QoS or other mechanisms for
Ok..the options  can be tabled like this:
- Core 
   * over-provision 
   * QoS  
   * traffic engineering 
- transit
   * co-operation between ISPs
- access
   * QoS 

Some of the relevant issues:
- At emergency times,if in some case,expected load
exceeds the backbone capacity,how quickly you can
increase the backbone capacity.
   If you cannot bring the network to normality within
a short time scale,one have to go for QoS /traffic
engineering options.

Also,remember we are trying to give priority to
emergency traffic and not create a robust network
which will be a answer to all sort of congestion
problems.

- Access has the only option of using QoS to
prioritize emergency traffic.

- one should have a effective co-operation between
service providers to accomodate emergency traffic.This
can be addressed by means of peering or service level
agreements only.

- senthil

=====
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: RJ Atkinson <[email-masked]>
Date: Fri, 28 Jun 2002 21:08:55 -0400

>    * co-operation between ISPs
	* overprovision
	* QoS
	* traffic engineering
>    * QoS
	* overprovision
	* traffic engineering
	
And even with those edits it is an incomplete table of options.

Bottom line:
	- overprovisioning is a technique that can be used anyplace
	  in the network
	- the requirements document needs to focus on high-level
	  requirements and not confuse them with implementation options

> a short time scale,one have to go for QoS /traffic

None of that is true if the backbone is over-engineered.

> which will be a answer to all sort of congestion

Free clue:
	Many backbone operators *pride* themselves on not having
*any* congestion inside their networks.  So creating a robust
network free from congestion *is* often their design and
deployment goal.

> prioritize emergency traffic.

Not true.  I've built MAN access networks that were
over-provisioned.  QoS is not required for those
networks.   And even if under-provisioned, QoS
is NOT the only engineering option for the operator.

> can be addressed by means of peering or service level

That is essentially a business or contractual matter,
hence explicitly outside the scope of the IETF.  For
anti-trust reasons, the IETF needs to stay away from
making any recommendations about such business matters.

Ran
[email-masked]

---

From: senthil ayyasamy <[email-masked]>
Date: Fri, 28 Jun 2002 18:26:29 -0700 (PDT)

I very much agree with your points.I have changed the
subject to not  disturbe the requiremenst drafts
discussion. 
> >    * co-operation between ISPs

  Dont you think overprovisioing at the transit is
little tricky .  

> is NOT the only engineering option for the operator.
  But,still at access they do less statistical
multiplexing when compared to core.Multi-homing is
also an option.

---

From: RJ Atkinson <[email-masked]>
Date: Fri, 28 Jun 2002 21:46:33 -0400

On Friday, June 28, 2002, at 09:26 , senthil ayyasamy wrote:
>   Dont you think overprovisioing at the transit is little tricky .

It is not intrinsically any harder than over-provisioning one's core.
Any transit link of any sort involves close cooperation among the
operators involved.  Large backbones are likely to have their transit
handled via dedicated links.  NAPs are fading as a place that big
operators exchange traffic.  Most NAPs build on a non-blocking switch
fabric (historically FDDI and ATM, more recently huge Ethernet switches).

> But,still at access they do less statistical multiplexing when compared 
> to core.

I don't follow your meaning at all.  In particular, the phrase 
"statistical
multiplexing" is quite confusing to me in the context of an IP network.
The statistical multiplexing I think of is a method used in POTS 
telephony
networks for reducing bandwidth consumed by voice telephone calls, by
leveraging the tendency of humans to have silence in between words.

The most popular deployment strategy today (at least in North America) is
clearly SONET rings.  Other popular technologies in backbone cores today
include ATM.  Such SONET or ATM is often built out on top of a DWDM 
system
on dark fibre owned by (or under IRU to) the operator.  I expect 10 Gig 
Ethernet
to be part of the equation, more often in MAN than in WAN, by end of 
this calendar year.

MAN networks tend to be built out of CWDM, SONET, ATM, and/or 1/10 Gig 
Ethernet.

Access networks tend to be T1, T3, DSL, cable modems, and/or dialup 
modem banks
(with very limited amounts of ISDN).

[As noted in an earlier note, there is a bit of North American bias to 
the above
summary.]

> Multi-homing is also an option.

Not sure what you mean by "multihoming is also an option".

Ran
[email-masked]

---

From: senthil ayyasamy <[email-masked]>
Date: Fri, 28 Jun 2002 21:38:58 -0700 (PDT)

> multiplexing when compared 
> > to core.
> 
  I used the term for meaning *over booking*.Service
providers overbook their access networks.This is the
reason why a flash crowd can easily flood the access
with core being unaffected.So,one can go for content
distribution.It increases redundancy by load balacing
but it doesnt allow one to give priority to emergency
service.So,their should be a method for segregating
the emergency packets from the SYN floods(which
normally congests the newsites).

>So creating a robust
>network free from congestion *is* often their design
>and deployment goal.

Like how you increase the robustness in the core for
supporting emergency traffic (as mentioned by you),you
can get service from more than one service providers
at the cost of increasing the AS connectivity
complexity for robustness at the access.Will this be a
factor too ???.

- senthil

=====
Ayyasamy Senthilkumar

---

From: Henning Schulzrinne <[email-masked]>
Date: Sat, 29 Jun 2002 05:27:35 -0400

I don't know if Abilene counts as a backbone provider in your book. 
According to http://loadrunner.uits.iu.edu/weathermaps/abilene/, a 
significant number of links are running well above 10 and some above 
30%. And this is on a Saturday morning at 4 am, after the file-swapping 
undergraduates have left campuses for the semester...

I would value contrary evidence.

Fred Baker wrote:
> the backbone. We re-routed some stuff due to fiber cuts and power 
> supplies running out of fuel, but bluntly the Nimda and Code Red viruses 
> had a more measurable effect on the net.
> 
> last I heard, which is perhaps a year out of date, Qwest was running 
> their links 2.5% utilized. I don't know of any service provider that 
> runs their backbone links significantly more than 10% utilized. This is 
> what Ran is getting at.
> 
>

---

From: RJ Atkinson <[email-masked]>
Date: Sat, 29 Jun 2002 09:08:50 -0400

On Saturday, June 29, 2002, at 12:38 , senthil ayyasamy wrote:
> Service providers overbook their access networks.

Some providers underprovision ("overbook") their access networks.
Some providers overprovision their access networks.

Both situations exist in the deployed Internet.  As noted before,
I've personally deployed numerous MANs that were overprovisioned
(because it was cheaper to do that than to deploy/operate QoS).

> supporting emergency traffic (as mentioned by you),
> you can get service from more than one service providers

	I can't speak for folks who might want to purchase IEPREP
services, not least because that is a large and very diverse
set of folks, particularly since IETF needs to consider the
issue globally, not just with a US focus.  I doubt that
every country will have the same deployment practices
with regards to IEPREP.

Ran
[email-masked]