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

From: "Beard, Cory" <[email-masked]>
Date: Fri, 28 Jun 2002 16:59:32 -0500

Ran,

I am surprised you read our draft differently, but the draft does indeed
allow overprovisioning as a viable approach.  Note specifically Sections
2.1 and 2.2, which say the fundamental requirements are availability and
dependability, not necessarily preferential treatment.  Section 2.1 on
availability includes the following.

   "Service providers may choose to provide high availability levels
through 
   overprovisioning even when the network is stressed.  They could
choose to 
   avoid using any mechanisms to identify or preferentially treat
emergency 
   traffic, because emergency traffic requirements would be met by the 
   default operation of their network."

Section 4.2 also says,

   "As an example, service providers may wish to provide service 
   assurances for inelastic traffic using Diffserv [10] but use 
   overprovisioning for both types of elastic traffic."

That said, overprovisioning is treated with caution as a viable
approach, especially because it would be hard to predict how the network
would behave in all possible stress conditions.

If you have suggestions on how to make the text more clear that
overprovisioning is allowed, please advise.

Cory Beard

> -----Original Message-----
> From: RJ Atkinson [mailto:[email-masked]]
> Sent: Friday, June 28, 2002 3: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]
> 
> 	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).
> 
> 	That possibility is not reflected in this draft and seems like
> a major omission to me.
> 
> Ran
> [email-masked]
> 
> [1] To be clear, most congestion and packet loss today occurs in the
> access portion of the Internet, which is often operated by a smaller
> Tier-2/3/4 provider different from the Tier-1 transit/backbone
operator.
> In this situation, QoS might be useful inside the Tier-N operator
> (e.g. on particular access links that aren't overprovisioned by the
> Tier-N
> operator), but QoS would likely not be meaningful inside the Tier-1
> backbone.
> 
> [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 19:17:49 -0400

> would behave in all possible stress conditions.

I don't follow the hard-to-predict claim.

It is pretty easy to sum the max bandwidth of all the access links,
then provision that much capacity throughout.  I've worked on
networks that engineered precisely on that basis to always have
more capacity than max offered load.

> overprovisioning is allowed, please advise.

Please remove the reference and implication to specific mechanisms
(example: QoS) from the requirements draft.  Let the requirements
draft focus on the high-level abstract requirements *only*
(example: availability of capacity to handle IEPS traffic).
Move all discussion of *mechanisms* to the other drafts.

Right now, this draft inter-mingles discussion of mechanisms (e.g. QoS)
with requirements (e.g. Availability) in an unfortunate manner.

Ran
[email-masked]