Subject: [Ieprep] I-D ACTION:draft-ietf-ieprep-packet-marking-policy-00.txt

From: [email-masked]
Date: Tue, 25 Jun 2002 07:03:30 -0400

A New Internet-Draft is available from the on-line Internet-Drafts directories.
This draft is a work item of the Internet Emergency Preparedness Working Group of the IETF.

	Title		: Recommended Packet Marking Policy
	Author(s)	: F. Baker
	Filename	: draft-ietf-ieprep-packet-marking-policy-00.txt
	Pages		: 17
	Date		: 24-Jun-02
	
This paper summarizes a recommended correlation of applications to
Differentiated Service Code Points.  There is no intrinsic
requirement that individual DSCPs correspond to given applications,
but as a policy it is useful if they can be applied consistently.

A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-ietf-ieprep-packet-marking-policy-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-ietf-ieprep-packet-marking-policy-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-ietf-ieprep-packet-marking-policy-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: senthil ayyasamy <[email-masked]>
Date: Tue, 25 Jun 2002 18:00:59 -0700 (PDT)

Fred,
 Section 3 talks about reflexive DSCP policy.If i am
correct , the draft recommends reflexive DSCP policy
for providing uniform service differentiation in both
the directions as diffserv is undirectional .

But, it can be done more easily  by configuring same
DSCP in both the directions.

Also,I have a slight inkling that reflexive DSCP will
be unnecessary for emergency services.Both the sender
and receiver will clearly know their priority in
advance .hence ,they can very well use same DSCP code
point in both the directions .Its just a thought ,I
may be wrong.

- Senthil

=====
Ayyasamy Senthilkumar
M.S.(Computer Networking)
UMKC,MO.
-----------------------------
An expert is a man who has made all the mistakes that can be made in a very narrow field.
--Niels Bohr.

__________________________________________________
Do You Yahoo!?
Yahoo! - Official partner of 2002 FIFA World Cup
http://fifaworldcup.yahoo.com

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

---

From: Fred Baker <[email-masked]>
Date: Tue, 25 Jun 2002 23:54:14 -0700

At 06:00 PM 6/25/2002 -0700, senthil ayyasamy wrote:
>it can be done more easily  by configuring same DSCP in both the directions.

BTW, I committed an error here; Rei posted the reflexive DSCP policy draft 
Sunday night, but I had not seen that on Friday night, so I posted the same 
text in my draft just so we could have it on the agenda. We can decide as a 
working group whether we want to treat them together or separately, and 
whether we want to propose that policy.

But there are two issues: how the sender views the traffic, and how the 
requester views it. I have been asked to build into my routers a facility 
to identify incoming requests, capture their DSCP, and ensure that 
answering streams use the same DSCP. My comment has invariably been that 
this is properly the province of the host, and most easily done there. But 
I am being pushed by those who don't trust the host to accomplish exactly 
this in the network. I would be much easier, from my perspective, if I 
could say "dimwit, the host already does this." And in Rei's case, the host 
may have specific policy embedded in metadata or some other policy 
mechanism that says it should use one service for this content and another 
service for that content.

So we (Rei and I) propose that both of these are quite viable, and the one 
thing that is not really viable is to respond to a request sent with a very 
specific PHB with a default value. It would be better if the requester has 
the opportunity to influence the applied policy, and the responder (who may 
have metadata guiding him) has the ability to over-ride that.

---

From: senthil ayyasamy <[email-masked]>
Date: Wed, 26 Jun 2002 00:52:32 -0700 (PDT)

> have metadata guiding him) has the ability to
  Another quick question:
The requirement to have reflexive DSCP is only for
emergency services or even for some other applications
? 

But,as i told ,consider a emergency information
transfer between two persons.The reciver will surely
know in priori the sender's priority .hence,receiver
can use the same DSCP as the sender.There  should be
some other strong case for having a reflexive DSCP
policy other than emergency application (Again,I am
not sure ..i may be wrong) .

- senthil

=====
Ayyasamy Senthilkumar

---

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

At 12:52 AM 6/26/2002 -0700, senthil ayyasamy wrote:
>The reciver will surely
>can use the same DSCP as the sender.

why would a DSCP necessarily indicate a priority? Apart from an 
authenticated user transaction, why would the sender know what the receiver 
those a policy should be?

The question becomes: if I have several users with different contracts 
asking me about file foo, why would I not deliver file foo in accordance 
with their several contracts?

>There  should be
>policy other than emergency application

the places I am being pushed for it are in general use.

---

From: senthil ayyasamy <[email-masked]>
Date: Wed, 26 Jun 2002 02:37:07 -0700 (PDT)

> those a policy should be?
  
   If i understood clearly,Your intent is  to have
have different/Same  DSCP mapping at both directions
depending on one's requirements or policy.Considering
X and Y as sender and receiver,DSCP used from X-->Y
and Y-->X can be different.
   I misunderstood that the whole work is *ONLY* to
maintain same DSCP on both directions.

=====
Ayyasamy Senthilkumar

---

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

At 02:37 AM 6/26/2002 -0700, senthil ayyasamy wrote:
>DSCP used from X-->Y

they certainly can, and right now usually are. But service providers 
deploying diffserv tell me that this is not necessarily the service they 
want to offer. They want to be able to offer varying grades of service to 
users paying varying amounts of money.

>maintain same DSCP on both directions.

yes, and also to say what that DSCP is based on some concept of user class. 
If, for example, I have a user class which is "authenticated ETS user" and 
another user class which is "random person", the traffic in the first class 
might go as AF11 and the second as AF12 (same queue, slightly more prone to 
loss).

not that this would be important in a group such as this :^)