Subject: RE: [PWE3] [Fwd: Proposed text for SAToP congestion section]

From: [email-masked]
Date: Thu, 29 Dec 2005 14:48:48 -0500

Eric,

> Think of the difference between "congestion" and "acute resource shortage"
> in perhaps more familiar terms of breathing difficulty.  Congestion is in
> fact a frequent, if not normal, condition.  Acute resource shortage is
> pathological.

It's important to be clear about the class of traffic that this discussion
applies to.  For ordinary best-effort (typical for TCP) traffic, I agree
with this distinction and analogy.  OTOH, for CBR traffic in a properly
traffic engineered network, the relationship is different:

	The network SHOULD be traffic engineered so that CBR traffic
	only experiences "congestion" when the network as a whole is
	facing an "acute resource shortage".

GS or EF service and good network traffic engineering can achieve this.

Assuming this has been done (and the text already says it SHOULD be
done), the CBR protocol can then be specified to react to "congestion"
**in CBR traffic** as indicating "acute resource shortage", and take
the appropriate (potentially dramatic) measures to reduce traffic.
Typical/routine network congestion will then only affect TCP traffic
and not trigger the CBR mechanisms.

If one mixes CBR and TCP traffic in the same traffic class using the
same resources, the result is that under "acute resource shortage", both
experience "congestion", and the CBR traffic backs off first.  If that
result is undesirable, CBR and TCP traffic SHOULD NOT be mixed in the
same traffic class (e.g., put the important TCP traffic in a different
class that loses resources before the CBR class when "acute resource
shortage" strikes).

> As for discontinuing a CBR service because it is consuming more than a
> "fair share", perhaps you did not understand the AD's comments, or perhaps
> those comments are wrong.  It is not particularly meaningful to define a
> CBR service if it does not continue to provide CBR delivery under
conditions
> of competition for (possibly scarce) resources.

If the CBR traffic is not in the same traffic class as the TCP traffic,
"fair share" is irrelevant - a traffic engineering decision has been made
to separate resources, and probably favor one class of traffic over the
other. Another way of looking at this is that if CBR and TCP traffic are
mixed in the same traffic class, then the operator is indifferent as to
which gets through under "acute resource shortage", and hence killing
the CBR traffic first is ok (cf. "SHOULD NOT be done when that outcome
is undesirable").

The bottom line is that CBR traffic SHOULD be in its own class(es) so
that it is not competing with TCP for scarce resources in "acute resource
shortage" conditions.  As long as this is done, the "fair share" issue
with TCP traffic does not arise, and the measures needed to deal with
it will not be invoked.

Thanks,
--David
----------------------------------------------------
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
----------------------------------------------------

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