Subject: RE: [Ieprep] FW: How does automated QoS work?

From: "Ayyasamy, Senthilkumar (UMKC-Student)" <[email-masked]>
Date: Fri, 2 May 2003 18:12:38 -0500

>> It looks like hardware vendors pay more attention to QoS.
>>
>> An
>
>Probably not.  The products described are mostly application
>software "element manager" enhancements to make it easier
>for users to configure sets of switches, combined with some
>analysis of existing network traffic (in some cases).
>
>Many other vendors (e.g. Extreme, others) have had similar
>capabilities available commercially in products for years.
>
>Such tools can be useful if one has a single administrative
>domain and wants to deploy a domain-wide QoS policy to all
>the affected devices. 

 Lets not go into one more over-provisioning discussion. I 
am very much in agreement with you, seeing the good traffic
stats from 

(i) sprintlabs - recently, they were concerned with
the excess network BW which go waste. So, they simulated
a scavenger traffic and proved that the legacy traffic 
is not affected even after adding the degraded service.

(ii) AT&T labs - over-provisioning + TE at IP level by 
tweaking weights. 

If you notice the above two results, they dimension the 
network -using historic data and forecasting methods -
such that their provisioning is sufficient. But, their 
are situation where the provisioning turn out to be 
counter-productive in an not-so-well-planned network[1]. 

Also, the availability (i.e. always above 80%) is an 
averaged out figure. Do providers maintain such 
availability all the time (even milli-second level)?

I remember a heated discussion in nanog about selfish 
routing[2]. The bottom line is that their are few
smart router vendors (like route science, sockye etc) 
which help us to find alternate best paths to the
current SPF. 

+++ C&W  do transport level traffic engineering in their 
backbone. 

My point is that:

1. Their are some alternatives to over-provisioning at the 
   core (other than QoS):
      - Smart Routing techniques (like reactive routing)
      - Transport level TE by some providers like C&W

  So, we should still focus on core (not just access.)

2. Their is also interest in QoS products for enterprise 
   and access networks (like std configuration methods
   auto-QoS etc.)

  So, we can standardize use of QoS techniques for ieprep
  in access/ enterprise networks.

[1] Braess Paradox -- well known in transport networks.

[2] but, the whole nanog discussion was based on a 
 theoretical game theory paper on selfish Routing,
 which has no practical applicability.

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

---

From: RJ Atkinson <[email-masked]>
Date: Sat, 3 May 2003 16:47:16 -0400

On Friday, May 2, 2003, at 19:12 America/Montreal, Ayyasamy, 
>    and access networks (like std configuration methods

Interest from NCS seems evident.  I haven't seen any operators
here express interest in the above.  In any event, numerous
commercial products are available today to any operator that
chooses to use them.

Standardised configuration mechanisms are being addressed in the
(proposed) IETF NetConf WG and on the related xmlconf mailing list.

>   in access/ enterprise networks.

The standardisation of mechanisms has already been done for single
administrative domain networks.  IETF does not usually tell operators
how to design their networks.

Examples of existing mechanisms include (at least):
	- IETF DiffServ
	- IEEE 802.1p (later incorporated into 802.1d) Ethernet precedence
	- Classical IP Tos

Given that, I'm not at all sure what you are proposing be undertaken 
here.

Ran