Subject: [Ieprep] I-D ACTION:draft-talauliker-ieprep-diffserv-00.txt

From: [email-masked]
Date: Tue, 25 Jun 2002 07:02:04 -0400

A New Internet-Draft is available from the on-line Internet-Drafts directories.

	Title		: Internet Emergency Preparedness Services in a 
                          Differentiated Services Domain
	Author(s)	: S. Talauliker, C. Beard
	Filename	: draft-talauliker-ieprep-diffserv-00.txt
	Pages		: 9
	Date		: 24-Jun-02
	
The international community needs advice as to what standards to rely 
on for the operational implementation of services for Emergency 
Preparedness.  This draft outlines the best current practices to 
provide deterministic behavior of Internet applications during 
emergencies using Differentiated Services.  It should be noted that 
there can be more than one suitable approach and this draft only 
describes what can be done with the existing Differentiated Services 
architecture.

A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-talauliker-ieprep-diffserv-00.txt

To remove yourself from the IETF Announcement list, send a message to 
ietf-announce-request with the word unsubscribe in the body of the message.

Internet-Drafts are also available by anonymous FTP. Login with the username
"anonymous" and a password of your e-mail address. After logging in,
type "cd internet-drafts" and then
	"get draft-talauliker-ieprep-diffserv-00.txt".

A list of Internet-Drafts directories can be found in
http://www.ietf.org/shadow.html 
or ftp://ftp.ietf.org/ietf/1shadow-sites.txt

Internet-Drafts can also be obtained by e-mail.

Send a message to:
	[email-masked].
In the body type:
	"FILE /internet-drafts/draft-talauliker-ieprep-diffserv-00.txt".
	
NOTE:	The mail server at ietf.org can return the document in
	MIME-encoded form by using the "mpack" utility.  To use this
	feature, insert the command "ENCODING mime" before the "FILE"
	command.  To decode the response(s), you will need "munpack" or
	a MIME-compliant mail reader.  Different MIME-compliant mail readers
	exhibit different behavior, especially when dealing with
	"multipart" MIME messages (i.e. documents which have been split
	up into multiple messages), so check your local documentation on
	how to manipulate these messages.

Below is the data which will enable a MIME compliant mail reader
implementation to automatically retrieve the ASCII version of the
Internet-Draft.

---

From: "Alistair Munro" <[email-masked]>
Date: Wed, 26 Jun 2002 09:07:11 +0100

Hi All,

As an implementer, this draft raises more questions than it answers. I'm
reluctant to accept it as current practice, (which it claims to be)
although it is helpful in identifying the size of the solution space.
I'm not sure if the attempt to use (subvert?) QoS differentiation and
congestion management mechanisms to project application-level
prioritisation to network level is a desirable thing to do, and it will
end up being far too restrictive in practice. Maybe my interpretation is
wrong on its intention, but I'm sure this has been deprecated in the
past

Having said this, the draft has given me a lot of ideas for experiments
to identify potential best practice, but it's very speculative in its
present form.

Regards,

Alistair

--
Dr. Alistair Munro,
Chief Systems Engineer, Degree2 Innovations Ltd.
Regus House, 1 Friary, Temple Quay, Bristol, BS1 6EA, U.K.
E-mail: [email-masked]
Tel: (work) +44-117-900-8114, (home) +44-1275-462707, (mobile)
+44-7974-922-442;
Fax: +44-117-900-8151
Web: http://www.u4eagroup.com

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

---

From: Fred Baker <[email-masked]>
Date: Wed, 26 Jun 2002 08:21:15 -0700

>reluctant to accept it as current practice, (which it claims to be)

There you have only my claim to follow. We have been putting the list 
together at Cisco based on an accumulation of networks and products (ours 
and others) using various DSCP values with various application sets. The 
scavenger service is an Internet II service, for example, one that doesn't 
make much sense to me (I thought that was what the default service was for) 
but which a lot of folks are fairly excited about (they pay less money for 
transfer with no guarantees).

>wrong on its intention, but I'm sure this has been deprecated in the past

speaking as one of the folks who designed the differentiaed services 
architecture, I assure you that this is fundamental to diffserv. You take 
traffic that has similar requirements and is going to similar user groups 
and handle it as an aggregate. The facilities you enable for the traffic in 
a certain aggregate are intended to be consistent with the needs of the 
applications in that aggregate.

Why are you sending a working group discussion to ietf-announce?

---

From: "Alistair Munro" <[email-masked]>
Date: Wed, 26 Jun 2002 16:39:54 +0100

Hi Fred,

> transfer with no guarantees).

Are we talking about the same draft? I agree with what you say in yours,
but I was referring to the Talauliker one in this case. The stuff about
RED (and variants) appears to be simulations, hence my comment about
more questions than answers as far as practice goes, but please correct
me.

> applications in that aggregate.

I'm not questioning this either. It is the issue of priority vs. quality
that concerned me. The Talauliker draft seems to be about priority using
DSCPs and RED mechanisms. I would prefer to use them to their best
advantage in doing what they were designed for without imposing a
secondary purpose on them. Priority is a different issue and known to be
difficult to resolve. Did I mistake what was written?

> Why are you sending a working group discussion to ietf-announce? 

I'm sorry about this - I didn't delete the ietf-announce in the reply.
It was not intentional.
 
Regards,

Alistair

---

From: Fred Baker <[email-masked]>
Date: Wed, 26 Jun 2002 09:28:05 -0700

At 04:39 PM 6/26/2002 +0100, Alistair Munro wrote:
>but I was referring to the Talauliker one in this case.

I'm sorry, I should have read your subject line less quickly. oops.