Subject: Re: [Ieprep] Atlanta ieprep Agenda

From: [email-masked]
Date: Sat, 16 Nov 2002 12:30:28 EST

In a message dated 11/15/2002 8:57:41 PM Eastern Standard Time, 
[email-masked] writes:

> Several ISPs that deployed "prioritisation" and/or "QoS" found that:
>     (1) priority packets got worse treatment than best-effort packets,
>         particularly in times of network stress
>     (2) deployment costs were intolerably high (i.e. money needed to deploy
>         was non-trivially high).
>     (3) deployment was not feasible in a large-scale commercial backbone
>     (4) operations costs (e.g. debugging) were insanely high
>     (5) much of the currently deployed equipment did not behave very well
>         when lots of features (especially QoS) were enabled.  To be fair,
>         some equipment is robust when features are turned on.  The latter
>           equipment generally has a hardware-based (e.g. ASIC, FPGA) 
> implementation
>           of the enabled features.
> 

What particular "prioritisation and/or QoS" schemes are you referring to? Are 
you talking about DiffServ AF with multiple drop precednences, or something 
else? Yes, I'm sure that some are really bad, a conclusion I came to the 
first time I studied them.

Mike Pierce
Artel

---

From: RJ Atkinson <[email-masked]>
Date: Sat, 16 Nov 2002 13:33:29 -0500

On Saturday, Nov 16, 2002, at 12:30 America/Montreal, [email-masked] 
wrote:
> What particular "prioritisation and/or QoS" schemes are you referring 
> to? Are you talking about DiffServ AF with multiple drop precednences, 
> or something else?

A wide range of them.  An incomplete list (off the top of my head) 
includes:
	Diffserv (with AF, EF, or some more experimental approaches)
	ATM
	RSVP/IntServ

Dave Meyer and other ISP folks should feel free to add to the above 
list.

Older DoD IP networks once upon a time had MLPP implemented per RFC-791 
IP ToS bits.
It worked well enough on that equipment (mostly Proteons or so I'm 
told),
iff one considered strict precedence with starvation to be the right 
policy.
It *did* regularly starve non-priority users, due to reliance on QoS 
rather than
provisioning enough bandwidth, which led to the priority creep that Rex 
Buddenburg
previously discussed.

Ran
[email-masked]

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