Subject: [Tsvwg] Diffserv Basic Classes Draft Review

From: [email-masked]
Date: Thu, 5 Aug 2004 21:07:38 -0400

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).
- Examples 2 and 3 need work (Section 2.2).
- AF usage discussion cleanup [(a), (b), and (c) comments on Sections
	4.3, 4.5, 4.7 and 4.8].
- Remove implied cap on Best Effort traffic (Section 4.9 - probably
	a typo/thinko, but an important one).
- Enrich mapping discussion (Section 5 to the extent not covered
	by top down classification added to Section 2.1).

-- 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.

--  Section 2.1

Expand OAM acronym on first use.

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.

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.

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.

In Figure 3, add RFC references for the two 3-color markers.

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.

-- 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.

"Figure 4, provides a popular industry view" - What's a "popular
	industry view"?  A different phrase should be used.

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.

-- 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.

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).

-- 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".

   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.

-- 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.

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.

-- Section 4.3

In first paragraph, expand "Video conferencing" example to "Audio and
video conferencing".

(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?

(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).

(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.

-- Section 4.5

Section 4.3 comments (a), (b), and (c) apply here (but substitute AF3*
for any AF4* occurrences in those comments).

-- 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).

-- Section 4.8

Section 4.3 comments (a), (b), and (c) apply here (but substitute AF1*
for any AF4* occurrences in those comments).

-- 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.

-- Section 5

In general, this section should be enriched/extended, and in particular:
- Please add a VPN service mapping discussion.
- 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
- Please add a summary of the UMTS traffic class mappings.

----------------------------------------------------
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