Subject: [Diffserv] I-D ACTION:draft-ietf-diffserv-ba-def-00.txt

From: [email-masked]
Date: Wed, 16 Feb 2000 06:39:25 -0500

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

	Title		: Definition of Differentiated Services Behavior 
                          Aggregates and Rules for their Specification
	Author(s)	: K. Nichols, B. Carpenter 
	Filename	: draft-ietf-diffserv-ba-def-00.txt
	Pages		: 15
	Date		: 15-Feb-00
	
The diffserv WG has defined the general architecture for differen-
tiated services (RFC 2475) and has been focused on the definition 
and standardization of the 'per-hop forwarding behaviors' (or 
PHBs) required in routers (RFCs 2474, 2597, and 2598). The dif-
ferentiated services framework creates services within a network 
by applying rules at the edges in the creation of traffic aggregates 
(known as Behavior Aggregates) coupled with the forwarding 
path behavior. The WG has also discussed the behavior required 
at diffserv network edges or boundaries for conditioning the 
aggregates, elements such as policers and shapers [MODEL, 
MIB]. A major feature of diffserv is that only the components 
applying the rules at the edge need to be changed in response to 
short-term changes in QoS goals in the network, rather than 
The next step for the WG is to lay out how the forwarding path 
components (PHBs, classifiers, and traffic conditioners) can be 
used within the architectural framework to compose specific 
Behavior Aggregates. These BAs should have properties such that 
the transit of individual packets of a BA through a differentiated 
services network can be characterized by specific metrics. How-
ever, no microflow information should be required as packets 
transit a differentiated services network. 
This document defines and discusses Behavior Aggregates in 
detail and lays out the format and required content for contribu-
tions to the Diffserv WG on BAs and the rules that will be applied 
for individual BA specifications to advance as WG products. This 
format is specified to expedite working group review of BA sub-
missions.
A pdf version of this document is available at:
ftp://ftp-eng.cisco.com/ftp/kmn-group/docs/ba_def.pdf.

A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-ietf-diffserv-ba-def-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-ietf-diffserv-ba-def-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-diffserv-ba-def-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: George Uhl <[email-masked]>
Date: Wed, 16 Feb 2000 14:41:05 -0500

I'm responding as I'm reading the draft.  There is another sentence
cutoff at the end of the first paragraph of the Introduction section.
As I browse the draft it appears that text is getting cutoff along
page boundaries.

BTW, I'm reading this draft from:

George Uhl
 
> 
> The last sentence in the first paragraph of the Abstract is incomplete:
> 
> A major feature of diffserv is that only the components 
> George Uhl

_______________________________________________
diffserv mailing list
[email-masked]
http://www.ietf.org/mailman/listinfo/diffserv
Archive: http://www-nrg.ee.lbl.gov/diff-serv-arch/

---

From: George Uhl <[email-masked]>
Date: Wed, 16 Feb 2000 14:31:46 -0500

George Uhl

---

From: Brian E Carpenter <[email-masked]>
Date: Wed, 16 Feb 2000 15:38:02 -0600

Yes, there is a formatting error at the end of each page.
Kathie will fix it.

  Brian

---

From: demir <[email-masked]>
Date: Wed, 16 Feb 2000 13:27:59 -0800 (PST)

Oops. It should be:
A pdf version of this document is available at:
ftp://ftp-eng.cisco.com/ftp/kmn-group/docs/BA_def.pdf

Alper K. Demir

---

From: Dan Grossman <[email-masked]>
Date: Wed, 16 Feb 2000 17:15:47 -0500

A number of issues, questions and concerns.  First the minor mechanical 
hassles, then the broad implications, then a lot of things that need 
clarification.

1) ERROR 432 -- The URL you requested could not be fetched. 

This means that: 

ftp/kmn-group/docs/ba_def.pdf: No such file or directory. 

2) As George Uhl noted, text got lost at page breaks in the .txt version.

3) The semantics of a BA seems to have changed between RFC 2475 and this 
draft.  The definition ("... crossing a link in a particular direction") 
pretty clearly (at least in my mind) implies that its scope is hop-by-hop.  In 
the draft, it seems to be a kind of odd beast which isn't quite end-to-end, 
nor is it hop-by-hop.  Flows can apparently join and leave a BA anywhere in 
the DS domain.  In fact, it looks like this draft is looking do redefine a BA 
to be some kind of a spanning tree of the DS domain.  Would the authors 
explain?  

4) The draft seems to have gotten religion about measurable, quantifiabile, 
characteristics, for which I applaud it.  It does seem a bit difficult to 
reconcile this with the relative PHBs, as in the legacy class selectors and to 
a lesser extent AF.  

5) On a related topic, most of parameters  will be quite sensitive to network 
topology, route selected and link characteristics, as well as the capabilities 
and configuration of the DS nodes on the path.  What I think we're saying is 
that each the value for each measureable, quantifiable parameter is in fact 
the worst case of any path along the spanning tree.  Or, actually, the worst 
spanning tree that could possibly result from a route flap.   Which might be 
quite a bit worse than it would actually be for many feasible paths.  Or, in 
another words, the parameter values experienced by  two flows belonging to the 
same BA, which enter and/or leave the DS domain at different DS edges may 
differ considerably.

6) The draft explicitly refers to pinned routes from time to time, and hints 
at them elsewhere.  Except for MPLS, do any standards track RFCs allow for 
route pinning?

7) Can anybody think of an example of a parameter which is absolute, rather 
than bounded?  We couldn't do that with ATM, despite its very fine-grained 
mechanisms and conservative approach to aggregation.

8)  I assume that it's intended that a central assumption is that each flow 
will be shaped to the agreed TCA before it enters the DS domain and policed at 
the DS edge node;  otherwise, the parameters of the BA do not obtain.

9) The authors clearly have in mind some kind of relationship between a 
service and a BA.  It is not clear to me what that might be.  Can a BA can be 
made to carry multiple services?  Is it possible for more than one BA to have 
the same PHB (i.e., with different DSCPs) such that the edge-to-edge 
characteristics experienced by packets belonging to the BAs might differ?  If 
not, do we not implicitly limit the number of distinct services that can be 
offered by a DS domain? How will defining BAs address the difficulties the 
group (and also ISSL and the ATM Forum) has been struggling with in not having 
services in its charter?

10) There is a critical point in the introduction: 
 If the properties of a BA using a particu-
 lar PHB hold regardless of how the aggregate mutates as it 
 traverses the domain, then that BA scales. If there are limits to 
 where the properties hold, that translates to a limit on the size or 
 topology of a DS domain that can use that BA. Although useful 
 single-link BAs might exist, BAs that are invariant with network 
 size or that have simple relationships with network size and 
 whose properties can recovered by reapplying rules (that is, form-
 ing another diffserv boundary or edge to re-enforce the rules for 
 the aggregate) are needed for building scalable end-to-end quality 
 of service."
How do we know that the existing PHBs allow construction of BAs that have this 
property?

I'll get back with the clarifications on specific words in the text tomorrow.

Dan

---

From: Brian E Carpenter <[email-masked]>
Date: Thu, 17 Feb 2000 11:54:13 -0600

Dan,

...
> to be some kind of a spanning tree of the DS domain.  Would the authors

I don't think the original concept of BA was intended to be a single hop;
if that's what 2475 says we may need to adjust it. Yes, the "new" BA is
edge to edge of a DS network.

> reconcile this with the relative PHBs, as in the legacy class selectors and to

That would lead to soft metrics.

> same BA, which enter and/or leave the DS domain at different DS edges may

I think that will depend on the BA.

> at them elsewhere.  Except for MPLS, do any standards track RFCs allow for

I don't think so; the QOS Routing RFC certainly discusses this issue.

> the DS edge node;  otherwise, the parameters of the BA do not obtain.

Yes

> service and a BA.  

Er, not consciously.

   Brian

It is not clear to me what that might be.  Can a BA can be

---

From: Dan Grossman <[email-masked]>
Date: Thu, 17 Feb 2000 15:17:59 -0500

> edge to edge of a DS network.
It wasn't clear, but certainly implied.  Next questions:  is there such a 
thing as a 'unicast' or a 'multicast' BA?  If so, can a unicast BA have more 
than one ingress edge node or more than one egress edge node?
> That would lead to soft metrics.
Um, what is a 'soft' metric?  
> I think that will depend on the BA.
Can you elaborate?
> I don't think so; the QOS Routing RFC certainly discusses this issue.
Is this a problem?  As in are we relying on mechanisms that don't exist?
> > 9) The authors clearly have in mind some kind of relationship between a
Then how do BAs support services?  Or, rather, TCAs?

---

From: Dan Grossman <[email-masked]>
Date: Thu, 17 Feb 2000 15:08:14 -0500

In addition to the broader questions I raised yesterday, there are a number of 
points in the draft which need clarification. This is not exhaustive, and I'm 
sure to have more later.

> customers any more than the specific PHBs employed in the pro-
> vider's network would be. QoS providers are expected to select 
> their own measures to make customer-visible in contracts and 
What's a "QoS provider"?  Is this a service provider that offers SLAs?  Or is 
it something else?

> puted. The filled in boxes in figure 1 represent the conformance 
> ensurers (e.g., shapers) and conformance enforcers (e.g., polic-
> ers). Although we expect that policers and shapers will be 
Why do we need these new terms "conformance ensurer" and "conformance 
enforcer"? 

> Associated with each BA are measurable, quantifiable, character-
> istics which can be used to describe what will happen to packets 
> of that BA as they cross the DS domain.
It's difficult to talk about these characteristics in terms of what will 
happen to individual packets, rather than flows.  Rather, these are 
characteristics which are measured over a (stastistically significant sample 
of a) flow.    

> Explicit expressions of 
> what happens to this behavior under aggregation, possibly param-
> eterized by node in-degrees or network diameters are required. 
After a couple of attempts, I was finally able to parse this sentence.  But 
what are "node in-degrees"?

> Rules must be recursively applied to result in a 
> known behavior.
I assume that this means 'interior rules', which aren't discussed before this 
point.

> Behavior Aggregates arise from a particular relationship between 
> edge and interior (which may be parameterized). 
I don't understand this statement.  What kind of relationship are we talking 
about?  What is the significance of 'arising'?  What kinds of parameters 
affect such a relationship?

Also, I'm beginning to think that there is a blurring between a _Type_ of BA 
(as in the thing specified in one of these specifications) and an _Instance_ 
of a BA (occurring in a DS domain).  It would be helpful if the authors made 
it clear which of these they are discussing at various points in the draft.

> The characteristics of a BA tell how it behaves under ideal condi-
> tions if configured in a specified manner (where the specification 
> may be parameterized). Characteristics of a BA might be drop 
> rate, throughput, delay bounds measured over some time period. 
That should be drop rate bounds -- I can't imagine a use for a service that 
drops exactly 10^x packets, no more and no less, will be dropped, much less 
mechanisms to support it.

> The definition and characteristics of a BA MAY be parameterized 
> by network-specific features; for example, maximum number of 
> hops, minimum bandwidth, total number of entry/exit points of 
> the BA to/from the diffserv network, maximum transit delay of 
> network elements, minimum buffer size available for the BA at a 
> network node, etc.
I'm not clear on the intent of this.  These kinds of things obviously affect 
the characteristics of the BA, but seem to be more in the nature of 
provisioning considerations.  Is this part of the distinction between BAs and 
services?

> For short-time behavior, 
> we are interested primarily in two things: 1) how many back-to-
> back packets of this BA will we see at any point (this would be 
> metered as a burst) and 2) how large a burst of packets of this BA 
> can appear in a queue at once (gives queue overflow and loss).
This sentence leaves me with more questions than it answers.  Starting with 
point-of-reference:  where will "we" be observing to "see" back-to-back 
packets?  Particularly considering the apparently spanning tree nature of a BA 
instance.  What are the causal relationships?  Is it something along the lines 
of "the application of the traffic conditioners plus the edge rules plus the 
interior rules cause the number of back-to-back packets in the burst to be 
bounded by x, where x is an objective, and the edge rules, interior rules and 
traffic conditioners will be engineered such that the objective x will be met?"

> 6.2 Considerations in specifying short-term or bursty BA
>        characteristics
I find this example to be  confusing.  It now appears that all flows in BAx 
transit link L.  I thought I'd understood that this was not necessarily the 
case, and that a BA could contain flows with multiple ingress edges and 
multiple egress edges, even if it was unicast?  

> Flows of 
> BAx packets from the N uplinks each have average rate R and are 
> destined to cross L.
Is that "each are conditioned to have an average rate R" or "are assumed 
(based on historical measurements or traffic models) to have an average rate 
R"?  ALso note that the example assumes that all packets are MTU sized, which 
is a worst case (but probably not a realistic worst case).

Incidentally, once the mechanical problems with the .pdf file got sorted out, 
I found it infinitely more readable than the .txt version.  I hope that this 
is some kind of experiement in updating the IETF's obsolescent documentation 
formatting guidelines.

Changing hats, if any of these new terms are truly needed, or if we have to 
redefine/clarify terms like "behavior aggregate",  would the authors provide 
me with definitions for the terminology draft?

---

From: Kathleen Nichols <[email-masked]>
Date: Thu, 17 Feb 2000 22:21:13 -0800

Yes, Kathie will fix it. But not till I get back from vacation
next week I think. I'll post if there is some way I can get it
fixed before then.

	Kathie

---

From: Kathleen Nichols <[email-masked]>
Date: Thu, 17 Feb 2000 22:32:11 -0800

First, apologies for the problems in the draft. We felt it was
overdue and I wanted to get it out and shipped it just before
spending all day in a meeting then going on vacation (which
is where I am now, so I won't go into depth on all of this.

But, Dan's notes compel me to respond to two things.

First, using a descriptive phrase does not mean we are inventing
"new terminology"; in fact, it sometimes means that we are
conciously avoiding the use of "terminology".

Dan Grossman wrote:
....
> Is this a problem?  As in are we relying on mechanisms that don't exist?

The use of any reference to this was merely to state that IF
a BA were relying on some sort of "pinned" routes (and we wanted
to be general here), the description should explicitly say so.
That is ALL. I'd be interested to hear if this is a widely
shared view, that the document is somehow advocating or assuming
them, so that we can fix this in the next revsision.

	Kathie