Subject: RE: [Tsvwg] Answers to Review of Diffserv Basic Classes Draft

From: "Jozef Babiarz" <[email-masked]>
Date: Thu, 28 Oct 2004 10:28:06 -0400

I'm resending this email as not everyone has received it when I sent it out
on Oct. 24. Sorry if you get it twice.
Regards, Joe.
************************************************************** 
Please see below answers to David L. Black review comments.
Also, please see Section 7 "Summary of Changes from Previous Drat" for an
outline of all the changes made to
draft-baker-diffserv-basic-classes-04.txt. (04 version should be available
from the on-line Internet-Drafts directory soon).
**********************************************************
Review of draft-baker-diffserv-basic-classes-03.txt
Reviewer: David L. Black, EMC Corporation
For the IETF Transport Area Working Group (tsvwg)
August 5, 2004
-------------------------------------------------

-- Overall comment

I had skimmed an earlier version of this draft and liked it.  Having read
this one in detail, I like it a *lot*.  Diffserv has been described as a
toolkit for constructing QoS services.  This draft is like a set of project
plans (or a do-it-yourself book on plumbing, wiring,
etc.) that explains how to use the tools to build useful things in a fashion
accessible to non-experts.  This draft is a long-overdue addition to the set
of diffserv documents, and does a nice job of weaving together the important
elements of diffserv to show how they can be used together in useful ways.
I'd like to be able say that those of us working on diffserv had such a
coherent vision in mind from the beginning ... ;-).

Most of these comments are details of various sorts.  The important comments
that affect content are:

- Add top down traffic and application classification (Section 2.1).
[Joe]Added Section 2.2 "Categorization of User Service Classes" and reworked
part of section 2.1 to become Section 2.3 "Service Class Characteristics". 

- Examples 2 and 3 need work (Section 2.2).
[Joe]Expanded old Section 2.2, now became Section 2.4. Section 2.4.1 is
Example 1. Section 2.4.2 is detailed Example 2 and Section 2.4.3 is detailed
Example 3.

- AF usage discussion cleanup [(a), (b), and (c) comments on Sections
	4.3, 4.5, 4.7 and 4.8].
[Joe] Implemented changes as discussed. See item 9 in Section 7 "Summary of
Changes from Previous Draft" of version 0.4 of draft for details of changes.

- Remove implied cap on Best Effort traffic (Section 4.9 - probably
	a typo/thinko, but an important one).
[Joe] Modified sentence so that no cap is implied on bandwidth.

- Enrich mapping discussion (Section 5 to the extent not covered
	by top down classification added to Section 2.1).
[Joe]Section 5 was extended and restructured into 4 subsections, 5.1 Mapping
for Signaling, 5.2 Mapping for NTP, 5.3 Explanation of Ring Clipping, and
5.4 VPN Service Mapping.

-- Section 1.4.1

"with no further guarantees" is at odds with the recommendation in Section
4.9 that some minimum amount of bandwidth be guaranteed to best effort.
Some sort of expectation that the network will be usable for best effort
traffic (in some sense) is needed here.
[Joe] Changed wording to be compatible with section 4.9 "Best Effort needs
to provide some minimum bandwidth guarantee ..."

--  Section 2.1

Expand OAM acronym on first use.
[Joe] Done. OAM "Operations, Administration and Management".

Mention of "(traditional telephony)" in description of signaling class is
potentially confusing.  Need to say that this signaling and control traffic
*before* using the T-word.
[Joe] Implemented the change. See section 2.2, etc.

The network control traffic classes look good.  For the user/subscriber
classes, more in the way of top-down rough criteria for sorting traffic into
classes would be a good addition.  Figure 1 is a start, but aspects such as
elasticity, burstiness, and whether the traffic is signaled seem to be
collapsed into the description.  I'm not sure whether another figure with
lots of columns would be better.
[Joe] Added new section and an additional figure.

A couple of things should be added.  First of all, a top-down description of
how the traffic space is divided up that focuses on the traffic
characteristics - in essence more structure in the center column in Figure
1.  What I have in mind is almost there, but breaking out things like but
elasticity, burstiness, and whether the traffic is signaled would probably
help, although a 6+ column table is probably not what's needed.

Second, a top down grouping the user/data classes into a smaller number of
groups by application protocol type would help - to a first approximation,
there are:
- 5 media-oriented classes, split into Interactive (Telephony, Multimedia
	conferencing, RT Interactive) and Streaming (Multimedia, Broadcast
	Video) subgroups.	
- Signaling
- 3 data classes (Low Latency, High Throughput, Low Priority), with
	Low Latency being Interactive, High Throughput being close to
	streaming (but more jitter-tolerant than media, plus TCP-like
	drop response), and Low Priority being Don't Care to some degree.
- Standard (Best Effort)

Signaling needs to be distinguished from Low Latency Data, as Signaling
traffic *is* low latency data.  The essential distinction is something like
"administrative control and management" of the traffic affected as the
protocols in this class tend to be tied to the (usually media)
streams/sessions they signal and control.
[Joe] The above issues/suggestion are addressed in new section 2.2
"Categorization of User Service Classes" and section 2.3 "Service Class
Characteristics".

In Figure 3, add RFC references for the two 3-color markers.
[Joe] Done.

Last bullet in Section 2.1 needs to say "one of" the two services can be
supported.  If Low Priority data is mapped to 000xxx, recommend that xxx not
be 000 to allow this to be distinguished from Standard.
[Joe] Made the above change and recommend that 000xx1.

-- Section 2.2

Editing needed: A network administrator determined that they need
	There are a number of editing problems elsewhere - I didn't
	flag all of them.
[Joe] Reworked section 2.2

"Figure 4, provides a popular industry view" - What's a "popular
	industry view"?  A different phrase should be used.
[Joe] Removed that phrase and replaced it with " Service Provider Network
Configuration Example 1".

Examples 2 & 3 - where did the numbers "five" and "eight" come from?
	Describing these networks in terms of traffic carried/services
	provided and the resulting differentiation goals would be
	better than picking numbers out of thin air.  In general,
	these examples are short on detail/explanation.
[Joe] These two examples have been expanded with service descriptions, etc.
in section 2.4.2 Example 2 and 2.4.3 Example 3.

-- Section 3.2

In the past, I think routing has divided interior vs. exterior routing
protocol traffic into CS7 vs. CS6.  One of the implications of this draft
appears to be that this approach is no longer recommended,
	[ ... snipped due to UPDATE ...]
UPDATE: I'm informed by people who know better than I that routing does not
use CS7, so it suffices to add routing to the list of traffic that is not
appropriate for the Administrative Service class.
[Joe] Left it as was.

Say how to distinguish Network Control signaling flows from user/subscriber
signaling (this is not as easy as it looks, as it may depend on who owns the
softswitch).
[Joe] Addressed in Section 2.2, and 5.1.

-- Section 4.1

IP Telephony "MUST" use Telephony service class is at odds with the "SHOULD"
for the list of protocols - either explain that the listed protocols can be
used for services other than IP Telephony, or downgrade the "MUST" to a
"SHOULD".
[Joe] Change it to SHOULD. 

   o  Packet flows from trusted sources (media gateways inside
      administered network) MAY not require policing.

Can't say "MAY not", and that's also not quite right.  Try "Policing is
OPTIONAL for traffic from trusted sources whose behavior is assured via
other means (e.g., administrative controls on those systems)." The text in
the immediately following bullet has a better structure.
[Joe] Changed it to state that policing is OPTIONAL.

-- Section 4.2

Explain "clipping".  In essence, if the signaling protocol that sets up the
connection fails to complete in the expected time, the result is audio
loss/degradation at the start of the session, which is particularly
noticeable when dealing with unforgiving POTS systems.
[Joe] Added Section 5.3 "Explanation of Ring Clipping".

How is "peer to peer real time control function" distinguished from low
latency data?  Data vs. control is fuzzy at best, so some discussion of what
is controlled and/or the importance of the control function would help.
[Joe] Addressed in several sections 2.2, 2.3 and 5.1.

-- Section 4.3

In first paragraph, expand "Video conferencing" example to "Audio and video
conferencing".
[Joe] Done.

(a) If the end point is not capable of setting
   the DSCP value, then the router topologically closest to the end
   point MUST perform Multifield (MF) Classification as defined in
   [RFC2475] and mark all packets as AF41.

That's peculiar - it looks like it assumes the end-point stays inside the
rate "A" profile/envelope, unless I missed something.  Was AF4x intended
instead of AF41?
[Joe] Changed it to AF4x.

(b) Just to complicate things - running trTCM in Color-Aware mode assumes
that "A" and "B" don't change across domain boundaries.  If they do,
Color-Blind may be necessary if the trTCM rates or burst sizes increase
significantly in the direction of flow (else get too much red & yellow
traffic, by comparison to traffic coming in on interfaces with trTCM running
Color-Blind).
[Joe] Made changes to Conditioning Performed at DiffServ Network Edge
sections to:
o  If packets are marked by a trusted sources or previous trusted DiffServ
domain, and the color marking is to be preserved, then the two rate three
color marker SHOULD be configured to operate in Color-Aware mode.
o  If the packet marking is not trusted or the color marking is not to be
preserved, then the two rate three color marker SHOULD be configured to
operate in Color-Blind mode.

(c) Should say something about use or non-use of marking to distinguish
application-defined content layers in a single [media] stream (e.g.,
complete frames vs. delta frames, additional data for higher resolution).
IMHO, history reveals this example to be an attractive nuisance 
(intellectually appealing, but unworkable in practice due to dynamic
variation in codec output rates) and hence ought to carry a "SHOULD NOT"
recommendation to disfavor it by comparison to the straight
application-level-unaware rate-metering described here.
[Joe] Deleted statement (last sentence in the first paragraph of section
4.3) that: "In the future, it is expected that these services will generate
continuously variable rate traffic with packet marking indicating flow
importance." No discussion was added to draft on "complete frames vs. delta
frames", etc. metering/conditioning scenarios as this draft only addresses
application-level-unaware rate metering.

-- Section 4.5

Section 4.3 comments (a), (b), and (c) apply here (but substitute AF3* for
any AF4* occurrences in those comments).
[Joe] (a) and (b) changed to as above for AF3*. (c) only stated
rate-metering.

-- Section 4.7

Section 4.3 comments (a), (b), and (c) apply here (but substitute AF2* for
any AF4* occurrences in those comments and likewise substitute srTCM for
trTCM).
[Joe] (a) and (b) changed to as above for AF2*. (c) only stated
rate-metering.

-- Section 4.8

Section 4.3 comments (a), (b), and (c) apply here (but substitute AF1* for
any AF4* occurrences in those comments).
[Joe] (a) and (b) changed to as above for AF1*. (c) only stated
rate-metering.

-- Section 4.9

   SHOULD be configured to receive a small
   percentage of forwarding resources (at least 5%).

That can't what was intended, as it places a cap on best effort bandwidth.
Remove the cap by doing something like inserting "at least" before "a small
percentage" and adding "as a guaranteed minimum" at the end.  I suspect this
is a typo/thinko/oversight.
[Joe] Modified sentence so that no cap is implied on bandwidth.

-- Section 5

In general, this section should be enriched/extended, and in particular:
- Please add a VPN service mapping discussion.
[Joe] Added Section 5.4 on support of service classes in VPNs. 

- A discussion of mapping media flows (audio and/or video) should go
    here, unless it's covered by the discussion requested in Section 2.1
[Joe] Addressed in Section 2.2
- Please add a summary of the UMTS traffic class mappings.
[Joe] After a closer analysis, we determined that further work is needed in
this area. We believe that the interworking between DiffServ service classes
and UMTS Traffic Classes should be addressed in a separate document.
Therefore, we removed from this draft any suggested mapping of DSCP values
and DiffServ service classes into UMTS Traffic Classes.

----------------------------------------------------
David L. Black, Senior Technologist
EMC Corporation, 176 South St., Hopkinton, MA  01748
+1 (508) 293-7953             FAX: +1 (508) 293-7786
[email-masked]        Mobile: +1 (978) 394-7754
----------------------------------------------------

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

Regards, Joe.
Jozef Babiarz
email: [email-masked]
_______________________________________________
tsvwg mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/tsvwg

---

From: "Jozef Babiarz" <[email-masked]>
Date: Sun, 24 Oct 2004 19:51:22 -0400

Also, please see Section 7 "Summary of Changes from Previous
Drat" for an outline of all the changes made to

		-- Overall comment

		I had skimmed an earlier version of this draft and liked it.
Having read this one in detail, I like it a *lot*.  Diffserv has been
described as a toolkit for constructing QoS services.  This draft is like a
set of project plans (or a do-it-yourself book on plumbing, wiring,
		etc.) that explains how to use the tools to build useful
things in a fashion accessible to non-experts.  This draft is a long-overdue
addition to the set of diffserv documents, and does a nice job of weaving
together the important elements of diffserv to show how they can be used
together in useful ways.  I'd like to be able say that those of us working
on diffserv had such a coherent vision in mind from the beginning ... ;-).

		Most of these comments are details of various sorts.  The
important comments that affect content are:

		- Add top down traffic and application classification
(Section 2.1).
		[Joe]Added Section 2.2 "Categorization of User Service
Classes" and reworked part of section 2.1 to become Section 2.3 "Service
Class Characteristics". 

		- Examples 2 and 3 need work (Section 2.2).
		[Joe]Expanded old Section 2.2, now became Section 2.4.
Section 2.4.1 is Example 1. Section 2.4.2 is detailed Example 2 and Section
2.4.3 is detailed Example 3.

		- AF usage discussion cleanup [(a), (b), and (c) comments on
Sections
			4.3, 4.5, 4.7 and 4.8].
		[Joe] Implemented changes as discussed. See item 9 in
Section 7 "Summary of Changes from Previous Draft" of version 0.4 of draft
for details of changes.

		- Remove implied cap on Best Effort traffic (Section 4.9 -
probably
			a typo/thinko, but an important one).
		[Joe] Modified sentence so that no cap is implied on
bandwidth.

		- Enrich mapping discussion (Section 5 to the extent not
covered
			by top down classification added to Section 2.1).
		[Joe]Section 5 was extended and restructured into 4
subsections, 5.1 Mapping for Signaling, 5.2 Mapping for NTP, 5.3 Explanation
of Ring Clipping, and 5.4 VPN Service Mapping.

		-- Section 1.4.1

		"with no further guarantees" is at odds with the
recommendation in Section 4.9 that some minimum amount of bandwidth be
guaranteed to best effort.  Some sort of expectation that the network will
be usable for best effort traffic (in some sense) is needed here.
		[Joe] Changed wording to be compatible with section 4.9
"Best Effort needs to provide some minimum bandwidth guarantee ..."

		--  Section 2.1

		Mention of "(traditional telephony)" in description of
signaling class is potentially confusing.  Need to say that this signaling
and control traffic *before* using the T-word.
		[Joe] Implemented the change. See section 2.2, etc.

		The network control traffic classes look good.  For the
user/subscriber classes, more in the way of top-down rough criteria for
sorting traffic into classes would be a good addition.  Figure 1 is a start,
but aspects such as elasticity, burstiness, and whether the traffic is
signaled seem to be collapsed into the description.  I'm not sure whether
another figure with lots of columns would be better.
		[Joe] Added new section and an additional figure.

		A couple of things should be added.  First of all, a
top-down description of how the traffic space is divided up that focuses on
the traffic characteristics - in essence more structure in the center column
in Figure 1.  What I have in mind is almost there, but breaking out things
like but elasticity, burstiness, and whether the traffic is signaled would
probably help, although a 6+ column table is probably not what's needed.

		Second, a top down grouping the user/data classes into a
smaller number of groups by application protocol type would help - to a
first approximation, there are:
		- 5 media-oriented classes, split into Interactive
(Telephony, Multimedia
			conferencing, RT Interactive) and Streaming
(Multimedia, Broadcast
			Video) subgroups.	
		- Signaling
		- 3 data classes (Low Latency, High Throughput, Low
Priority), with
			Low Latency being Interactive, High Throughput being
close to
			streaming (but more jitter-tolerant than media, plus
TCP-like
			drop response), and Low Priority being Don't Care to
some degree.
		- Standard (Best Effort)

		Signaling needs to be distinguished from Low Latency Data,
as Signaling traffic *is* low latency data.  The essential distinction is
something like "administrative control and management" of the traffic
affected as the protocols in this class tend to be tied to the (usually
media) streams/sessions they signal and control.
		[Joe] The above issues/suggestion are addressed in new
section 2.2 "Categorization of User Service Classes" and section 2.3
"Service Class Characteristics".

		Last bullet in Section 2.1 needs to say "one of" the two
services can be supported.  If Low Priority data is mapped to 000xxx,
recommend that xxx not be 000 to allow this to be distinguished from
Standard.
		[Joe] Made the above change and recommend that 000xx1.

		-- Section 2.2

		Editing needed: A network administrator determined that they
need
			There are a number of editing problems elsewhere - I
didn't
			flag all of them.
		[Joe] Reworked section 2.2

		"Figure 4, provides a popular industry view" - What's a
"popular
			industry view"?  A different phrase should be used.
		[Joe] Removed that phrase and replaced it with " Service
Provider Network Configuration Example 1".

		Examples 2 & 3 - where did the numbers "five" and "eight"
come from?
			Describing these networks in terms of traffic
carried/services
			provided and the resulting differentiation goals
would be
			better than picking numbers out of thin air.  In
general,
			these examples are short on detail/explanation.
		[Joe] These two examples have been expanded with service
descriptions, etc. in section 2.4.2 Example 2 and 2.4.3 Example 3.

		-- Section 3.2

		In the past, I think routing has divided interior vs.
exterior routing protocol traffic into CS7 vs. CS6.  One of the implications
of this draft appears to be that this approach is no longer recommended,
			[ ... snipped due to UPDATE ...]
		UPDATE: I'm informed by people who know better than I that
routing does not use CS7, so it suffices to add routing to the list of
traffic that is not appropriate for the Administrative Service class.
		[Joe] Left it as was.

		Say how to distinguish Network Control signaling flows from
user/subscriber signaling (this is not as easy as it looks, as it may depend
on who owns the softswitch).
		[Joe] Addressed in Section 2.2, and 5.1.

		-- Section 4.1

		IP Telephony "MUST" use Telephony service class is at odds
with the "SHOULD" for the list of protocols - either explain that the listed
protocols can be used for services other than IP Telephony, or downgrade the
"MUST" to a "SHOULD".
		[Joe] Change it to SHOULD. 

		   o  Packet flows from trusted sources (media gateways
inside
		      administered network) MAY not require policing.

		Can't say "MAY not", and that's also not quite right.  Try
"Policing is OPTIONAL for traffic from trusted sources whose behavior is
assured via other means (e.g., administrative controls on those systems)."
The text in the immediately following bullet has a better structure.
		[Joe] Changed it to state that policing is OPTIONAL.

		-- Section 4.2

		Explain "clipping".  In essence, if the signaling protocol
that sets up the connection fails to complete in the expected time, the
result is audio loss/degradation at the start of the session, which is
particularly noticeable when dealing with unforgiving POTS systems.
		[Joe] Added Section 5.3 "Explanation of Ring Clipping".

		How is "peer to peer real time control function"
distinguished from low latency data?  Data vs. control is fuzzy at best, so
some discussion of what is controlled and/or the importance of the control
function would help.
		[Joe] Addressed in several sections 2.2, 2.3 and 5.1.

		-- Section 4.3

		In first paragraph, expand "Video conferencing" example to
"Audio and video conferencing".
		[Joe] Done.

		(a) If the end point is not capable of setting
		   the DSCP value, then the router topologically closest to
the end
		   point MUST perform Multifield (MF) Classification as
defined in
		   [RFC2475] and mark all packets as AF41.

		That's peculiar - it looks like it assumes the end-point
stays inside the rate "A" profile/envelope, unless I missed something.  Was
AF4x intended instead of AF41?
		[Joe] Changed it to AF4x.

		(b) Just to complicate things - running trTCM in Color-Aware
mode assumes that "A" and "B" don't change across domain boundaries.  If
they do, Color-Blind may be necessary if the trTCM rates or burst sizes
increase significantly in the direction of flow (else get too much red &
yellow traffic, by comparison to traffic coming in on interfaces with trTCM
running Color-Blind).
		[Joe] Made changes to Conditioning Performed at DiffServ
Network Edge sections to:
		o  If packets are marked by a trusted sources or previous
trusted DiffServ domain, and the color marking is to be preserved, then the
two rate three color marker SHOULD be configured to operate in Color-Aware
mode.
		o  If the packet marking is not trusted or the color marking
is not to be preserved, then the two rate three color marker SHOULD be
configured to operate in Color-Blind mode.

		(c) Should say something about use or non-use of marking to
distinguish application-defined content layers in a single [media] stream
(e.g., complete frames vs. delta frames, additional data for higher
resolution). IMHO, history reveals this example to be an attractive nuisance

		(intellectually appealing, but unworkable in practice due to
dynamic variation in codec output rates) and hence ought to carry a "SHOULD
NOT" recommendation to disfavor it by comparison to the straight
application-level-unaware rate-metering described here.
		[Joe] Deleted statement (last sentence in the first
paragraph of section 4.3) that: "In the future, it is expected that these
services will generate continuously variable rate traffic with packet
marking indicating flow importance." No discussion was added to draft on
"complete frames vs. delta frames", etc. metering/conditioning scenarios as
this draft only addresses application-level-unaware rate metering.

		-- Section 4.5

		Section 4.3 comments (a), (b), and (c) apply here (but
substitute AF3* for any AF4* occurrences in those comments).
		[Joe] (a) and (b) changed to as above for AF3*. (c) only
stated rate-metering.

		-- Section 4.7

		Section 4.3 comments (a), (b), and (c) apply here (but
substitute AF2* for any AF4* occurrences in those comments and likewise
substitute srTCM for trTCM).
		[Joe] (a) and (b) changed to as above for AF2*. (c) only
stated rate-metering.

		-- Section 4.8

		Section 4.3 comments (a), (b), and (c) apply here (but
substitute AF1* for any AF4* occurrences in those comments).
		[Joe] (a) and (b) changed to as above for AF1*. (c) only
stated rate-metering.

		-- Section 4.9

		That can't what was intended, as it places a cap on best
effort bandwidth.  Remove the cap by doing something like inserting "at
least" before "a small percentage" and adding "as a guaranteed minimum" at
the end.  I suspect this is a typo/thinko/oversight.
		[Joe] Modified sentence so that no cap is implied on
bandwidth.

		-- Section 5

		In general, this section should be enriched/extended, and in
particular:
		- Please add a VPN service mapping discussion.
		[Joe] Added Section 5.4 on support of service classes in
VPNs. 

		- A discussion of mapping media flows (audio and/or video)
should go
		    here, unless it's covered by the discussion requested in
Section 2.1
		[Joe] Addressed in Section 2.2
-	Please add a summary of the UMTS traffic class mappings.
		[Joe] After a closer analysis, we determined that further
work is needed in this area. We believe that the interworking between
DiffServ service classes and UMTS Traffic Classes should be addressed in a
separate document. Therefore, we removed from this draft any suggested
mapping of DSCP values and DiffServ service classes into UMTS Traffic
Classes.

		_______________________________________________
		tsvwg mailing list
		[email-masked]
		https://www1.ietf.org/mailman/listinfo/tsvwg
<https://www1.ietf.org/mailman/listinfo/tsvwg> 

		Regards, Joe.
		Jozef Babiarz