Subject: [Diffserv] help

From: Geoff Hussein <[email-masked]>
Date: Fri, 23 Feb 2001 17:51:16 -0000

-----Original Message-----
From: [email-masked] [mailto:[email-masked]]
Sent: 23 February 2001 17:00
To: [email-masked]
Subject: diffserv digest, Vol 1 #518 - 16 msgs

Send diffserv mailing list submissions to
	[email-masked]

To subscribe or unsubscribe via the web, visit
	http://www1.ietf.org/mailman/listinfo/diffserv
or, via email, send a message with subject or body 'help' to
	[email-masked]
You can reach the person managing the list at
	[email-masked]

When replying, please edit your Subject line so it is more specific than
"Re: Contents of diffserv digest..."

Today's Topics:

  1. QoS question (GN)
  2. Re: Editorial suggestions, comments and questions on new
 EFPHB definition (Kathleen Nichols)
  3. rfc2598bis comments (Dan Grossman)
  4. Re: Editorial suggestions, comments and questions on new
 EFPHB definition (demir)
  5. Re: A question on a PDB definition (Kathleen Nichols)
  6. Re: A question on a PDB definition (Hermann DE MEER)
  7. Re: A question on a PDB definition (Brian E Carpenter)
  8. Re: QoS question (demir)
  9. I-D ACTION:draft-brunner-diffserv-pdb-one2any-ar-00.txt
([email-masked])
  10. I-D ACTION:draft-brunner-diffserv-pdb-one2any-ar-00.txt (demir)
  11. MAX Threshold in RED (Ratnakar Pai)
  12. I-D ACTION:draft-brunner-diffserv-pdb-one2any-ar-00.txt
 - additional comment (demir)
  13. Re: QoS question (Brian E Carpenter)

--__--__--

Message: 1
From: "GN" <[email-masked]>
To: <[email-masked]>
Date: Thu, 22 Feb 2001 19:23:43 +0200
boundary="----=_NextPart_000_0061_01C09D04.F8117EA0"
Subject: [Diffserv] QoS question

This is a multi-part message in MIME format.

------=_NextPart_000_0061_01C09D04.F8117EA0
Content-Type: text/plain;
	charset="iso-8859-7"
Content-Transfer-Encoding: quoted-printable

Dear all=20
I would like to ask:

1. Assume a ISP that provides service based in QoS. Using the diffserv =
it is able to achieve this?

2. Assume that a user that has QoS option  in a network starts surfing =
outside the network. the QoS options are holding or the time that passes =
the edge of his ISP then he becomes a normal user.

Thanks very much
George

------=_NextPart_000_0061_01C09D04.F8117EA0
Content-Type: text/html;
	charset="iso-8859-7"
Content-Transfer-Encoding: quoted-printable

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN">
<HTML><HEAD>
<META content=3D"text/html; charset=3Diso-8859-7" =
http-equiv=3DContent-Type>
<META content=3D"MSHTML 5.00.2014.210" name=3DGENERATOR>
<STYLE></STYLE>
</HEAD>
<BODY bgColor=3D#ffffff>
<DIV><FONT size=3D2>Dear all </FONT></DIV>
<DIV><FONT size=3D2>I would like to ask:</FONT></DIV>
<DIV>&nbsp;</DIV>
<DIV><FONT size=3D2>1. Assume a ISP that provides service based in QoS. =
Using the=20
diffserv it is able to achieve this?</FONT></DIV>
<DIV>&nbsp;</DIV>
<DIV><FONT size=3D2>2. Assume that a user that has QoS option&nbsp; in a =
network=20
starts surfing outside the network. the QoS options are holding or the =
time that=20
passes the edge of his ISP then he becomes a normal user.</FONT></DIV>
<DIV>&nbsp;</DIV>
<DIV><FONT size=3D2>Thanks very much</FONT></DIV>
<DIV><FONT size=3D2>George</FONT></DIV></BODY></HTML>

------=_NextPart_000_0061_01C09D04.F8117EA0--

--__--__--

Message: 2
Date: Thu, 22 Feb 2001 10:17:50 -0800
From: Kathleen Nichols <[email-masked]>
To: demir <[email-masked]>
CC: [email-masked]
Subject: Re: [Diffserv] Editorial suggestions, comments and questions on new
EFPHB definition

demir wrote:
> 
> 1) Abstract
> "EF is intended to provide a building block for low delay and low loss
> services..."
> 
> "low jitter" phrase is missing in the abstract. 

...

The point was made by the authors of RFC 2598 that the approach taken
by the authors of the drafts leading to this did not have the same
jitter concerns as the orginal definition of the EF PHB. The WG decided
it preferred this new approach, thus, apparently, an EF PHB is desired
where low jitter is not one of the primary goals.

	Kathie

--__--__--

Message: 3
To: [email-masked]
Date: Thu, 22 Feb 2001 14:05:46 -0500
From: Dan Grossman <[email-masked]>
Subject: [Diffserv] rfc2598bis comments

Looks good.  Here are some comments, many of them nits:

1) Section 1, 3rd para: remove "speed-of-light" before propagation delays.  
Prop delay has sources other than propagation through the medium (like 
regenerators) and not all transmission is optical.  In fact, it is better to

talk about fixed delay rather than propagation delay.  Also, the minimum
delay 
is the fixed delay.  So better to use the term fixed delay throughout.

2) 2.1, second para: change "We define the departure time of a packet..." to

"We adopt the convention that the departure time of a packet is defined..."

Meaning that the equations could be made to work the other way.  Also, add:

"The last bit of the packet is the last bit of the Layer 2 trailer, if 
present." This approach has problems, but since we're defining this in terms

of an interface rather than an OSI-like Service Access Point, it will have
to 
do.  It has to be this way because a_j is taken as the time that the packet
is 
availabe for forwarding, and a packet is not available for forwarding in
most 
layer 2 protocols until after the CRC has been computed.

3) 2.1, fourth para:  How can a scheduler run early?

4) 2.1 fifth para change "color-blind" to "aggregate behavior" and 
"packet-identity aware" to "individual flow behavior".

5) 2.2, definition of l_j, L_j (and R):  Isn't excluding layer 2 overhead a 
problem, since IP packets cannot be serviced without also servicing the
layer 
2 overhead?  Especially for relatively small IP packets and layer 2
protocols 
that have variable overhead? 

6) eq. 1 and eq.3, don't these require:  "For all j"

7) In the paragraph at the bottom of page 6, and in the definitons of F_j
and 
D_j, where the text says "packet that arrived".... arrived _where_?  I think

the answer is "at any input interface to that DS-node", but not quite sure.

8) 2.4, "a device may advertise..."  You probably want some other words,
like 
"E_p for a device may be characterised as having two separate components".  
"Advertise" implies either routing metrics or *Business Things We Don't 
Discuss In Diffserv*

9) In security considerations, add the following (as agreed on the list 
earlier and documented in newterms draft):
"In addition, traffic conditioning at the ingress to a DS-domain MUST ensure

that only packets having DSCPs that correspond to an EF PHB when they enter 
the DS-domain are marked with a DSCP that corresponds to EF inside the 
DS-domain.  Such behavior is as required by RFC 2475.  It protects against 
denial-of-service and theft-of-service attacks which exploit DSCPs that are 
not identified in any TCS provisioned at an ingress interface, but which map

to EF inside the DS-domain."  

10) Appendix: One thing that's not addressed is the case where there is more

than one instance of the EF PHB at an interface.  Need to do such a thing
was 
a result of the VW discussions leading up to Adelaide.  Particularly with
PQ, 
the analysis of E_a (and possibly E_p) really only applies to most
constrained 
EF instance.

11) Appendix:  Wouldn't an earliest deadline first scheduling discipline (or

an approximation like RPQ) also meet the requirements of eq.1 - eq.4, with
low 
E_a and low E_p?

--__--__--

Message: 4
Date: Thu, 22 Feb 2001 11:56:50 -0800 (PST)
From: demir <[email-masked]>
To: Kathleen Nichols <[email-masked]>
cc: [email-masked]
Subject: Re: [Diffserv] Editorial suggestions, comments and questions on new
EFPHB definition

Katie,
If you read the Introduction, you will see:
   "The intent of the EF PHB is to provide a building block for low loss,
   low delay, and low jitter services."

I was just pointing out either "low jitter" is missing in the abstract or
it is not part of the definition. I guess primary goals should be
consistent through out the document. Also, I wanted to point out, if "low
jitter" is being claimed then "low delay" --> "low jitter" needs a
little more further explanation in the draft.

Alper K. Demir

On Thu, 22 Feb 2001, Kathleen Nichols wrote:

> demir wrote:
> > 
> > 1) Abstract
> > "EF is intended to provide a building block for low delay and low loss
> > services..."
> > 
> > "low jitter" phrase is missing in the abstract. 
> 
> ...
> 
> The point was made by the authors of RFC 2598 that the approach taken
> by the authors of the drafts leading to this did not have the same
> jitter concerns as the orginal definition of the EF PHB. The WG decided
> it preferred this new approach, thus, apparently, an EF PHB is desired
> where low jitter is not one of the primary goals.
> 
> 	Kathie
> 

--__--__--

Message: 5
Date: Thu, 22 Feb 2001 14:38:30 -0800
From: Kathleen Nichols <[email-masked]>
To: Brian E Carpenter <[email-masked]>
CC: Hermann DE MEER <[email-masked]>, demir <[email-masked]>,
[email-masked]
Subject: Re: [Diffserv] A question on a PDB definition

Brian E Carpenter wrote:
> 
> Too late. It's already approved for RFC publication. But it
> doesn't prevent PDB authors including such text if they know
> what to write for their particular PDB.
> 
>   Brian
....

I want to agree with Brian here. The PDB spec is not intended to
keep authors from putting *more* information in that they feel
is appropriate or useful for the technical understanding of that
PDB. It was more intended to give a general format and a sort of
"minimum standard" of what authors should be thinking of. The real
test of these is how they are received. 

	Kathie

--__--__--

Message: 6
To: Kathleen Nichols <[email-masked]>
cc: Brian E Carpenter <[email-masked]>,
Hermann DE MEER <[email-masked]>, demir <[email-masked]>,
[email-masked]
Subject: Re: [Diffserv] A question on a PDB definition
Date: Thu, 22 Feb 2001 23:07:48 +0000
From: Hermann DE MEER <[email-masked]>

Brian and Kathy,

> Brian E Carpenter wrote:
> > 
> > Too late. It's already approved for RFC publication. But it
> > doesn't prevent PDB authors including such text if they know
> > what to write for their particular PDB.
> > 
> >   Brian
> ....
> 
> I want to agree with Brian here. The PDB spec is not intended to
> keep authors from putting *more* information in that they feel
> is appropriate or useful for the technical understanding of that
> PDB. It was more intended to give a general format and a sort of
> "minimum standard" of what authors should be thinking of. The real
> test of these is how they are received. 
> 
> 	Kathie

I thought it may be worthwhile to raise the issue as I am thinking
it important enough to be included in the PDB spec in terms of
a general format, as you put it. In particular
so as it may not be an obvious thing to look at by potential authors,
but perhaps worthwhile enough for them to be aware of, nevertheless. 
Importance may not always be related to visibility. 

"too late" is too late, of course.

thanks for considering anyway.

--Hermann

--__--__--

Message: 7
Date: Thu, 22 Feb 2001 17:40:55 -0600
From: Brian E Carpenter <[email-masked]>
Organization: IBM
To: Hermann DE MEER <[email-masked]>
CC: Kathleen Nichols <[email-masked]>, demir <[email-masked]>,
[email-masked]
Subject: Re: [Diffserv] A question on a PDB definition

I would like to add that the point Alper and Hermann brought up
is important; it's just unfortunate that we didn't catch it
before we closed the PDB document.

   Brian

Hermann DE MEER wrote:
> 
> Brian and Kathy,
> 
> > Brian E Carpenter wrote:
> > >
> > > Too late. It's already approved for RFC publication. But it
> > > doesn't prevent PDB authors including such text if they know
> > > what to write for their particular PDB.
> > >
> > >   Brian
> > ....
> >
> > I want to agree with Brian here. The PDB spec is not intended to
> > keep authors from putting *more* information in that they feel
> > is appropriate or useful for the technical understanding of that
> > PDB. It was more intended to give a general format and a sort of
> > "minimum standard" of what authors should be thinking of. The real
> > test of these is how they are received.
> >
> >       Kathie
> 
> I thought it may be worthwhile to raise the issue as I am thinking
> it important enough to be included in the PDB spec in terms of
> a general format, as you put it. In particular
> so as it may not be an obvious thing to look at by potential authors,
> but perhaps worthwhile enough for them to be aware of, nevertheless.
> Importance may not always be related to visibility.
> 
> "too late" is too late, of course.
> 
> thanks for considering anyway.
> 
> --Hermann

--__--__--

Message: 8
Date: Thu, 22 Feb 2001 22:30:44 -0800 (PST)
From: demir <[email-masked]>
To: GN <[email-masked]>
cc: [email-masked]
Subject: Re: [Diffserv] QoS question

George,
I am not very sure if I understood your questions. However, I would like
to answer your first question as much as I understood. I am unable to
understand your second question. I assume it is a question regarding to if
a QoS architecture is sender-based or receiver-based or both.
1) The higher level answer of your first question is "yes it can achieve
to provide QoS guarantees". Please note that QoS is a very general concept
used in the networking literature. My answers are IETF Diffserv
oriented. IETF diffserv architecture is based on relatively simple and
coarse-grained methods of providing *differentiated service* for the
Internet traffic. If you like to get more information and understand how
IETF diffserv arcitecture can achieve QoS guarantees (from Diffserv
perspective) and what it is, I would suggest that you read the info. on
the web page of IETF Diffserv, RFC2574 and RFC2575.
2) I assume your second question depends on the architecture defined. In
IETF Diffserv, sender of the traffic receives the QoS guarantees. The
service will depend on the SLA beween the customer and the service
provider. In that sense, diffserv is very open to various "business
models". There are other architectures that might be receiver-oriented or
both.

Alper K. Demir

On Thu, 22 Feb 2001, GN wrote:

> Dear all 
> I would like to ask:
> 
> 1. Assume a ISP that provides service based in QoS. Using the diffserv it
is 
> able to achieve this?
> 
> 2. Assume that a user that has QoS option  in a network starts surfing 
> outside the network. the QoS options are holding or the time that passes
> the edge of his ISP then he becomes a normal user.
> 
> Thanks very much
> George
> 

--__--__--

Message: 9
To: IETF-Announce: ;
CC: [email-masked]
From: [email-masked]
Reply-to: [email-masked]
Date: Fri, 23 Feb 2001 06:43:00 -0500
Subject: [Diffserv] I-D ACTION:draft-brunner-diffserv-pdb-one2any-ar-00.txt

--NextPart

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

	Title		: An one-to-any Assured Rate Per-Domain Behavior for

                          Differentiated Services
	Author(s)	: M. Brunner et al.
	Filename	: draft-brunner-diffserv-pdb-one2any-ar-00.txt
	Pages		: 8
	Date		: 22-Feb-01
	
This document defines a Per-Domain Behavior (PDB) called one-to-any
Assured Rate. The PDB is useful to implement services in a
Differentiate Services domain, which need an assured rate. The
assurance is given with a certain well-defined probability for
traffic using this PDB. However, no delay and no jitter guarantees
are provided.

A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-brunner-diffserv-pdb-one2any-ar-00
.txt

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-brunner-diffserv-pdb-one2any-ar-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-brunner-diffserv-pdb-one2any-ar-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.

--NextPart
Content-Type: Multipart/Alternative; Boundary="OtherAccess"

--OtherAccess
Content-Type: Message/External-body;
	access-type="mail-server";
	server="[email-masked]"

Content-Type: text/plain
Content-ID:	<[email-masked]>

ENCODING mime
FILE /internet-drafts/draft-brunner-diffserv-pdb-one2any-ar-00.txt

--OtherAccess
Content-Type: Message/External-body;
	name="draft-brunner-diffserv-pdb-one2any-ar-00.txt";
	site="ftp.ietf.org";
	access-type="anon-ftp";
	directory="internet-drafts"

Content-Type: text/plain
Content-ID:	<[email-masked]>

--OtherAccess--

--NextPart--

--__--__--

Message: 10
Date: Fri, 23 Feb 2001 04:56:39 -0800 (PST)
From: demir <[email-masked]>
To: [email-masked]
Subject: [Diffserv] I-D ACTION:draft-brunner-diffserv-pdb-one2any-ar-00.txt

Dear Authors,
I have couple of comments and questions:
- To me, one2any AR is not much different than AR PDB that is also somehow
stated in the draft, I guess.
- I think, once you support one2any; one2one and one2few is supported by
default cause they are subset of one2any where AR PDB already supports. 
- Is this PDB based on a "stochastic model" where "stochastic admission
rule" is used as a supporting mechanisms for assured rate for one2ay? If
so, I guess "probabilistic/stochastic AR name would be a better name that
supports one2one, one2few and one2any. If not, what do you think about
using a "stochastic model" as a "admission rule" and claiming for "assured
rate" in a real life? Does it really change the risk of having a (strong)
"probabilistic assured rate"?
- I think the main challenge for one2any is that without under-utilizing
the network how "provisioning problem" can be solved where assured rate is
claimed for one2one, one2few and one2any. In that sense, AR PDB has the
"well-provisioned" network assumtion. I guess the challenge is what are
the mechanisms to achieve this assumtion.

Alper K. Demir

--__--__--

Message: 11
From: Ratnakar Pai <[email-masked]>
To: "[email-masked]'" <[email-masked]>
Date: Fri, 23 Feb 2001 18:36:24 +0530
Subject: [Diffserv] MAX Threshold in RED

Hi,
     In the Random Drop Table of the MIB, the random drop algorithm is to
drop a Packet with a probability equal to the MaxProb specified , when the
queue average crosses the the Maximum Thresholds. But isnt it that this
specifies the Max Probability to be used only when the Queue average is
between the minimum and maximum thresholds, and when the average crosses the
maximum threshold , every packet should be dropped? If it is as specified in
the MIB, then the Queue Average could increase even when the Queue Average
is greater than the Maximum Threshold....

Ratnakar.

--__--__--

Message: 12
Date: Fri, 23 Feb 2001 05:19:00 -0800 (PST)
From: demir <[email-masked]>
To: [email-masked]
Subject: [Diffserv] I-D ACTION:draft-brunner-diffserv-pdb-one2any-ar-00.txt
- additional comment

In addition to previous comments, I guess "deterministec" and
"estimation" based models that can be applicable to "admission rule" are a
few candidates that I can spell out. I am not sure if it is possible to
use tham as an alternative Or/ If It might be okay to integrate them into
a "single model" to define a PDB because there is a risk of resulting with
a complicated PDB where SLS are hard to be defined/specified. To me, as
long as there is need or acceptance from users/customers, there is no
problem. 

Alper K. Demir

--__--__--

Message: 13
Date: Fri, 23 Feb 2001 10:40:31 -0600
From: Brian E Carpenter <[email-masked]>
Organization: IBM
To: demir <[email-masked]>
CC: GN <[email-masked]>, [email-masked]
Subject: Re: [Diffserv] QoS question

I would suggest that this discussion continues on the diffserv interest
list.

  [email-masked]
  Send "subscribe diffserv-interest" to [email-masked]

But indeed, first read RFC 2475.

   Brian

demir wrote:
> 
> George,
> I am not very sure if I understood your questions. However, I would like
> to answer your first question as much as I understood. I am unable to
> understand your second question. I assume it is a question regarding to if
> a QoS architecture is sender-based or receiver-based or both.
> 1) The higher level answer of your first question is "yes it can achieve
> to provide QoS guarantees". Please note that QoS is a very general concept
> used in the networking literature. My answers are IETF Diffserv
> oriented. IETF diffserv architecture is based on relatively simple and
> coarse-grained methods of providing *differentiated service* for the
> Internet traffic. If you like to get more information and understand how
> IETF diffserv arcitecture can achieve QoS guarantees (from Diffserv
> perspective) and what it is, I would suggest that you read the info. on
> the web page of IETF Diffserv, RFC2574 and RFC2575.
> 2) I assume your second question depends on the architecture defined. In
> IETF Diffserv, sender of the traffic receives the QoS guarantees. The
> service will depend on the SLA beween the customer and the service
> provider. In that sense, diffserv is very open to various "business
> models". There are other architectures that might be receiver-oriented or
> both.
> 
> Alper K. Demir
> 
> On Thu, 22 Feb 2001, GN wrote:
> 
> > Dear all
> > I would like to ask:
> >
> > 1. Assume a ISP that provides service based in QoS. Using the diffserv
it is
> > able to achieve this?
> >
> > 2. Assume that a user that has QoS option  in a network starts surfing
> > outside the network. the QoS options are holding or the time that passes
> > the edge of his ISP then he becomes a normal user.
> >
> > Thanks very much
> > George

--__--__--

_______________________________________________
diffserv mailing list
[email-masked]
http://www1.ietf.org/mailman/listinfo/diffserv
Archive:
http://www2.ietf.org/mail-archive/working-groups/diffserv/current/maillist.h
tml

End of diffserv Digest

_______________________________________________
diffserv mailing list
[email-masked]
http://www1.ietf.org/mailman/listinfo/diffserv
Archive: http://www2.ietf.org/mail-archive/working-groups/diffserv/current/maillist.html