Subject: Re: [Ieprep] Atlanta ieprep Agenda

From: [email-masked]
Date: Fri, 15 Nov 2002 14:37:45 EST

I wrote:

> If things being discussed/proposed have very significant implications 
> in the operational IP network world, I would certainly like to hear 
> about them.

In a message dated 11/14/2002 7:16:43 PM Eastern Standard Time, 
[email-masked] writes:

> Gee whiz.  That's most of what Bill, Sean, Barry, and I have been 
> talking about.
> 

Sorry, there's been a lot of hand waving, name calling, sarcastic comments, 
and claims that "something" will break the Internet. But because of all the 
noise, we haven't yet been able to discuss specific mechanisms that might 
work or might "break" the Internet. Besides, we aren't supposed to be 
discussing mechanisms in this WG.

Please, can we discuss the requirements without anyone jumping to a 
conclusion about what mechanisms must be used or to claims that they can't 
ever work? And if someone really wants to discuss a proposed (or suggested) 
mechanism prematuraly (which we all tend to do), could you please provide 
some concrete technical statements concerning why it will not work. Not just 
statements that your network doesn't need it and therefore no one else does.

I would really like to have some technical meat to chew on, not all the fat 
that's flying around. If you have a comment, could you please address a 
specific proposal that I have made in one of the drafts I have submitted and 
make explicit statements of what is wrong with it. And leave out the sarcasm 
and we might be able to communicate effectively.

Mike Pierce
Artel

---

From: RJ Atkinson <[email-masked]>
Date: Fri, 15 Nov 2002 20:56:00 -0500

On Friday, Nov 15, 2002, at 14:37 America/Montreal, [email-masked] 
wrote:
> But because of all the noise, we haven't yet been able to discuss 
> specific mechanisms that might work or might "break" the Internet. 
> Besides, we aren't supposed to be discussing mechanisms in this WG.

I'll try to be more concrete.

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.

The details of why these things did not work are pretty ugly and require
an annoying amount of understanding of:
	(A) what an ISP network typically looks like
	(B) how IP routers or Ethernet switches work under the hood
	(C) the economics (grim as they are) of operating a commercial ISP
	(D) the day to day life of an operations person at a commercial ISP

For DISA/NCS folks, a starting point on A through D might be to talk 
with the
government folks who engineer and operate the DISN IP networks.  A trip 
to
southern Illinois is strongly recommended.

In an effort to help some with (A) and a tiny amount with (B), I'm 
putting
together a presentation.  With luck, I'll be able to present it at 
IEprep
in Atlanta.  Modulo my calendar, I'll happily wander down to Skyline or
Courthouse Road and give it again (whiteboard is also helpful) if 
desired.
My presentation is the work of a cast of many many ISP folks; I'm 
merely the
editor stuckee.

Cheers,

Ran
[email-masked]

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

---

From: David Meyer <[email-masked]>
Date: Sat, 16 Nov 2002 04:32:50 -0800

>>           equipment generally has a hardware-based (e.g. ASIC, FPGA) implementation of the enabled features.

This was certainly my experience. Basically, there is no
"physics" that will let more complexity and mechanism result in
decreased OPEX (one has to find the tradeoffs there and work in
that space). There is also no practical way to keep such a
service from being DoS'ed.  

Dave