Subject: Re: [tsvwg] comment on draft-ietf-tsvwg-ecn-tunnel

From: Bob Briscoe <[email-masked]>
Date: Thu, 01 Oct 2009 10:32:12 +0100

David,

At 07:28 30/09/2009, [email-masked] wrote:
>Bob,
>
>I started out to write a much longer message, but I'm ok with much
>of what you've written.  The only case where I think we aren't yet
>aligned on function (we can come back to alarms) is I think that:
>
> > > > >- Not-ECT [inner]:  ECT(0) [outer] and ECT(1) [outer] should
> > > > >         have the same behavior.  That behavior could be Forward
> > > > >         with Not-ECT or Drop.
>
>Whereas you want to Forward with Not-ECT in the ECT(0) [outer] case
>vs. Drop in the ECT(1) [outer] case.  Both of these are error cases.
>
>Let me suggest that if PCN will use ECT(1) to indicate a level of
>congestion comparable to CE for ECN (non-PCN) traffic, then this
>difference is justified, otherwise, I would forward with Not-ECT
>in both cases to avoid dropping traffic that isn't causing non-PCN
>congestion.

OK. PCN indeed wants to use ECT(1) as comparable to CE, but can't 
with tunnels as they are.

For the avoidance of doubt, when you say "this difference is 
justified", do you mean for all tunnels, or only for tunnels within a 
PCN domain?

This seemed to be the difference in our positions before - I'm 
playing safe in case a PCN config'd router appears outside a PCN 
domain - with the added benefit of zero config.

Put another way, are you happy with the text in S.4.2 <ecn-tunnel-03> 
for decap cases with a Not-ECT inner?

>I'm presuming that CE has comparable ECN and PCN
>meanings, justifying Drop for traffic that arrives with CE [outer]

You presume correctly.

Bob

>Thanks,
>--David
>
>
> > -----Original Message-----
> > From: Bob Briscoe [mailto:[email-masked]]
> > Sent: Monday, September 28, 2009 10:33 AM
> > To: Black, David
> > Cc: [email-masked]; Black, David
> > Subject: RE: [tsvwg] comment on draft-ietf-tsvwg-ecn-tunnel
> >
> > David,
> >
> > At 13:48 28/09/2009, [email-masked] wrote:
> > >Bob,
> > >
> > > > Can we agree ECT(0) and ECT(1) need the same behaviour;
> > >
> > >This is ok, but for the rest of the concern:
> > >
> > > > but only for cases that can actually occur in any known ECN
> > >environment?
> > >
> > >What are the specific cases where you want to treat ECT(0) and
> > >ECT(1) differently,
> >
> > You enumerated the two cases from the draft yourself (lower down this
> > mail thread). I've repeated them below.
> >
> > >and why?
> >
> > The reasoning is in the draft, but here's a brief recap....
> >
> > 1/ Not-ECT [inner]
> > ------------------
> > > > >- Not-ECT [inner]:  ECT(0) [outer] and ECT(1) [outer] should
> > > > >         have the same behavior.  That behavior could be Forward
> > > > >         with Not-ECT or Drop.
> >
> > Both these cannot occur in an ECN environment unless
> > something's broken.
> >
> > ECT(0) [outer] was safe for the egress to forward as Not-ECT, and
> > nothing has changed to make it any less safe.
> >
> > ECT(1) [outer] was safe to forward as Not-ECT up to now,... but once
> > PCN exists, this broken combination might be caused by rogue PCN
> > routers set up in the wrong place in the Internet, so rather than
> > remove a marking that might imply congestion, it's safer to drop.
> >
> > Obviously, rogue conditions can be caused by anything, so it's a
> > balance of probabilities what you do with them. The above is as safe
> > as necessary while still allowing some room for future evolution.
> >
> > 2/ ECT(0) [inner]
> > -----------------
> > ECT(0) [inner] and
> > ECT(0) [outer] => ECT(0) [forwarded]
> > because this is normal in an ECN environment and no different for PCN.
> >
> > ECT(0) [inner] and
> > ECT(1) [outer] => ECT(1) [forwarded]
> > This cannot occur in an ECN environment unless something's broken,
> > but it's normal in a PCN environment.
> >
> > The idea is to avoid any tunnel logic having to be configured to
> > check whether the DSCP implies ECN or PCN marking. Only operators
> > wanting PCN need to actually insist that vendors comply with this
> > update. But it works for either ECN or PCN (because ECN doesn't use
> > this combination).
> >
> > [let's defer talking about alarms until we agree on functions.]
> >
> > Is this clearer now?
> >
> >
> > Bob
> >
> >
> > >Thanks,
> > >--David
> > >
> > >
> > > > -----Original Message-----
> > > > From: Bob Briscoe [mailto:[email-masked]]
> > > > Sent: Tuesday, September 22, 2009 12:58 PM
> > > > To: Black, David
> > > > Cc: [email-masked]; [email-masked]; Black, David
> > > > Subject: Re: [tsvwg] comment on draft-ietf-tsvwg-ecn-tunnel
> > > >
> > > > David,
> > > >
> > > > In the process of answering Phil's point from early Aug
> > about alarms,
> > > > your response reveals differences over primary goals. I
> > felt I should
> > > > jump in to try to get consensus on goals, then we can get
> > > > back to alarms...
> > > >
> > > > At 19:09 18/09/2009, [email-masked] wrote:
> > > > >I'm going to back up to a high-level summary on this one.
> > > > >
> > > > >The four ECN field values are Not-CET, ECT(0), ECT(1) and CE.
> > > > >Going back to RFC 3168, ECT(0) and ECT(1) are specified as
> > > > >peer values - same meaning, either can be used.
> > > > >
> > > > >PCN would like to use ECT(0) and ECT(1) as ordered values with
> > > > >ECT(1) denoting a lesser level of congestion than that denoted
> > > > >by the CE value.
> > > > >
> > > > >I have no problem with PCN doing that, *as long as* the result
> > > > >does not obstruct possible future uses that treat ECT(0) and
> > > > >ECT(1) as unordered values.
> > > >
> > > > We already have an existing use (the nonce) that treats
> > the two the
> > > > same and ecn-tunnel-03 doesn't obstruct that. You now want to also
> > > > cater for some possible future case where ECT(0) & ECT(1)
> > are still
> > > > unordered but also somehow different to the current
> > unordered case.
> > > > This is surely becoming rather esoteric and unattainable.
> > > >
> > > > >Hence I view any mechanism that
> > > > >is based on ordering ECT(0) and ECT(1) as PCN-specific and
> > > > >want such mechanisms to be in PCN documents, not ECN documents.
> > > >
> > > > Can we agree ECT(0) and ECT(1) need the same behaviour;
> > but only for
> > > > cases that can actually occur in any known ECN environment?
> > > >
> > > > This is critical to consensus, because I've found a way to support
> > > > PCN by only updating cases that can never occur in any known ECN
> > > > environment. Then a single updated tunnel behaviour still does
> > > > exactly what ECN traffic would expect, but it also supports PCN.
> > > >
> > > > If we're free to change the cases that ECN never uses, then we can
> > > > have a single tunnel behaviour for all purposes - a big win.
> > > >
> > > >
> > > > Bob
> > > >
> > > > >That leads to the following ECN tunnel specifics, which I think
> > > > >cover everything that's open in discussion.  My views are:
> > > > >- Not-ECT [inner], CE [outer] -> Drop is ok.  This is a serious
> > > > >         error case.
> > > > >- Not-ECT [inner]:  ECT(0) [outer] and ECT(1) [outer] should
> > > > >         have the same behavior.  That behavior could be Forward
> > > > >         with Not-ECT or Drop.
> > > > >- ECT(0) [inner], ECT(1) [outer] and
> > > > >   ECT(1) [inner], ECT(0) [outer]: These two should have the
> > > > >         same behavior.  Since PCN considers one of these to be
> > > > >         a normal case that should not raise an alarm, no alarm
> > > > >         should be raised for either of these combinations.
> > > > >
> > > > >Let's see if that's enough to move this towards a conclusion.
> > > > >
> > > > >Thanks,
> > > > >--David
> > > > >
> > > > >
> > > > > > -----Original Message-----
> > > > > > From: [email-masked] [mailto:[email-masked]]
> > > > > > On Behalf Of [email-masked]
> > > > > > Sent: Wednesday, August 05, 2009 8:56 AM
> > > > > > To: [email-masked]
> > > > > > Subject: [tsvwg] comment on draft-ietf-tsvwg-ecn-tunnel
> > > > > >
> > > > > > hi
> > > > > > i wanted to follow up on this from stockholm. i've tried to
> > > > > > catch up with bob & david's discussion, sorry for where my
> > > > > > reading is incomplete.
> > > > > >
> > > > > > - tunnel egress behaviour for 3168 & 4301 is inconsistent,
> > > > > > amongst other motivations for change to a single consistent
> > > > > > tunnel egress behaviour
> > > > > >
> > > > > > - one set of changes is about
> > > > > > inner: not-ect
> > > > > > outer: isn't not-ect
> > > > > > which should neve be seen.
> > > > > > i think bob & david have converged (?). i have no desire to
> > > > > > upset their convergence!
> > > > > >
> > > > > > - another cahnge is about:
> > > > > > inner: ect(0)
> > > > > > outer: ect(1)
> > > > > > decaps header: ect(1)
> > > > > > this is a change from the current specs, although it's
> > > > > > somethng that should never be seen.
> > > > > > making this change enables 2 levels of congestion severity.
> > > > > > i think bob & david both agree with this change.
> > > > > >
> > > > > > the point where there is disagreement:
> > > > > > David: in environements without 2 levels of congestion
> > > > > > severity, then this is an error, so the tunnel egress MAY
> > > > > > raise an alarm.
> > > > > > Bob: don't raise an alarm.
> > > > > >
> > > > > > David, my argument against your view is: this 'MAY raise an
> > > > > > alarm' is actually different from all the other combinations
> > > > > > of codepoints where the egress 'MAY raise an alarm'. in those
> > > > > > other cases it's always the right thing for the egress to do.
> > > > > > in this case however, if it's a domain that uses 2 levels of
> > > > > > congestion severity, then it MUST NOT raise an alarm (becuase
> > > > > > it's the expected behaviour), whereas if it's a domain that
> > > > > > uses 1 level of congestion severity, then it MAY raise an
> > > > > > alarm (becuase something's wrong).
> > > > > > to me the simplest thing would be not to raise an alarm, so
> > > > > > there doesnt have to be different configuration depending on
> > > > > > the domain. if the std does mention the alarm then somehow it
> > > > > > has to be very clear that this is different from the
> > other alarms.
> > > > > >
> > > > > > best wishes
> > > > > > phil
> > > > > >
> > > > > >
> > > >
> > > > ________________________________________________________________
> > > > Bob Briscoe,                                BT Innovate & Design
> > > >
> > > >
> > > >
> >
> > ________________________________________________________________
> > Bob Briscoe,                                BT Innovate & Design
> >
> >
> >

________________________________________________________________
Bob Briscoe,                                BT Innovate & Design

---

From: <[email-masked]>
Date: Sun, 4 Oct 2009 14:14:31 -0400

Bob,

> with tunnels as they are.

For ECN, CE means "I would have dropped this packet, endpoints should
react as if it had been dropped."  By comparable, I don't just mean
that it indicates congestion, but that the indication is at least as
severe as "I would have dropped this packet (e.g., if it had been
marked Not-ECT)."

I need to find the time to review the PCN material to check this;
I think that's the next step.

> domain 

Mumble ... another view of "playing safe" by dropping questionable
traffic is creation of an unexpected traffic black hole ... it's
not always "safe" to drop.

> - with the added benefit of zero config.

IMHO, if we're going to bless PCN usage of ECT(1) as another form of
CE, then zero config is desirable, and what you want to do is probably
what needs to be done.  If we are going to bless that PCN usage,
we will need to say so clearly and bluntly in the ecn-tunnel draft.

FWIW, this decision about whether ECT(1) can be another form of CE
will probably also mostly resolve the dangling topic of what
transitions may generate alarms.

Thanks,
--David

> On Behalf Of Bob Briscoe
> Sent: Thursday, October 01, 2009 5:32 AM
> To: Black, David
> Cc: [email-masked]

[... remainder snipped ...]

---

From: <[email-masked]>
Date: Tue, 6 Oct 2009 12:53:05 +0100

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf
Of [email-masked]
Sent: 04 October 2009 19:15
To: Briscoe,RJ,Bob,XVR9 BRISCORJ R
Cc: [email-masked]
Subject: Re: [tsvwg] comment on draft-ietf-tsvwg-ecn-tunnel

Bob,

[phil] just to follow up on this point.
if the tunnel behaviour is sorted out, this allows PCN to use the
encoding suggested in
http://tools.ietf.org/html/draft-ietf-pcn-3-state-encoding-00 [which is
most economical in only using one DSCP]:-

      +--------+--------------+-------------+-------------+---------+
      |  DSCP  | 00 <Not-ECT> | 10 <ECT(0)> | 01 <ECT(1)> | 11 <CE> |
      +--------+--------------+-------------+-------------+---------+
      | DSCP n |    Not-PCN   |      NM     |     ThM     |   ETM   |
      +--------+--------------+-------------+-------------+---------+

   ThM:  Threshold-marked.  

   ETM:  Excess-traffic-marked.  

The 'classic' example is that ThM pkts trigger admission control, and
ETM pkts trigger flow termination - eg when the fraction of ThM pkts
between a pair of gateways of the PCN-domain rise above a threshold,
then admission requests are blocked for further PCN-flow between that
pair. 

On each router, the parameters of the PCN meter/marker should be set to
ensure PCN marking is indeed before actual congestion. Therefore PCN's
admission control & flow termination mechanisms should kick in before
pkts are dropped. Therefore I believe it's fair to say that PCN-marking
is "at least as severe as" the meaning of CE for end-to-end ECN.

Best wishes,
phil

---

From: Bob Briscoe <[email-masked]>
Date: Fri, 09 Oct 2009 12:01:30 +0100

David,

>I think that's the next step.

I hope Phil's response helped you here. We want PCN:ECT(1) to mean 
"no more inelastic traffic than this" while PCN:CE will mean "reduce 
inelastic traffic due to loss of capacity". ECN:CE encompasses both 
meanings because it is for elastic traffic that will reduce then 
immediately try to increase again.

>not always "safe" to drop.

That is certainly true. But it's bad spec writing to leave this 
choice hanging for a combination that currently isn't valid. It is 
incumbent on us to clearly say what kit should do if unexpected 
combinations appear. Otherwise future protocol design has to assume 
drop might happen anyway.

For Not-ECT inner the draft makes it clear:
         forward ECT(0) outer; drop ECT(1) outer

The question is, do you agree?

It seems like you are conditionally agreeing below. The condition 
being whether we bless PCN usage of ECT(1). PCN marking & baseline 
encoding have just passed IESG review this week.  The question is do 
you want to bless PCN usage of ECT(1)? Not just PCN, but any future 
protocol that wants two-level congestion severity.

>we will need to say so clearly and bluntly in the ecn-tunnel draft.

OK. Once this thread completes, I'll do a minor text rev. I'm good at blunt :)

Would something like the change below be sufficient? Remember this is 
in addition to all the motivation using PCN that's already in 
ecn-tunnel-03. Pls search thru for the string "PCN".

s/ The above logic allows for ECT(0) and ECT(1) to both represent the
    same severity of congestion marking (e.g. "not congestion marked").
    But it also allows future schemes to be defined where ECT(1) is a
    more severe marking than ECT(0).  This approach is discussed in
    Appendix D and in the discussion of the ECN nonce [RFC3540] in
    Section 9, which in turn refers to Appendix F.

/  The above logic allows for ECT(0) and ECT(1) to both represent the
    same severity of congestion marking (e.g. "not congestion marked").
    But it also allows future schemes to be defined where ECT(1) is a
    more severe marking than ECT(0), in particular enabling the simplest
    possible encoding for PCN [I-D.ietf-pcn-3-in-1-encoding].  This
    approach is discussed in Appendix D and in the discussion of the
    ECN nonce [RFC3540] in Section 9, which in turn refers to Appendix F.
/

>transitions may generate alarms.

Once you've replied to this one, I'll dig out the old thread on that 
and re-post it.

Bob

---

From: <[email-masked]>
Date: Wed, 14 Oct 2009 13:36:50 -0400

Bob (and Phil),

> immediately try to increase again.

ECN:CE means "reduce traffic".  If one looks at RED as an example
of the sort of AQM that works well with ECN, ECN:CE signals that
queue occupancy is above the desired operating point and traffic
needs to be reduced in order to move towards the operating point;
it's not sufficient to only not add additional traffic.  The
attempted increase in elastic traffic will subsequently happen on
a significantly longer time scale (e.g., it will not immediately
try to restore the old throughput), as the process is AIMD, not MIMD.

So, I'm comfortable with PCN:CE being treated like ECN:CE.  I'm not
comfortable with PCN:ECT(1) being treated like ECN:CE, as I expect
PCN to be setting it earlier (wrt increasing traffic level) than
ECN:CE (i.e., the P in PCN stands for "pre").  If the queue occupancy
is above the desired operating point (criteria for setting ECN:CE),
PCN:ECT(1) isn't going to help, because it only stops the situation
from getting worse (unless we assume that the inelastic traffic
is composed of short-lived "mice" resulting in continuous occurrence
of flow termination), so PCN:CE will need to be used in order to
obtain improvement.

This is also consistent with Phil's response in which he describes
PCN:ECT(1) as kicking in before congestion occurs - wrt this fuzzy
notion of congestion occurring, ECN:CE kicks in as congestion occurs,
not before, and this distinction is aligned with the P in PCN standing
for "Pre".

Let's get through this issue, then we can figure out how to apply
the result to tunnel egress handling.

Thanks,
--David

> Sent: Friday, October 09, 2009 7:02 AM
> To: Black, David
> Cc: [email-masked]

---

From: Bob Briscoe <[email-masked]>
Date: Wed, 14 Oct 2009 19:26:49 +0100

David,

I don't believe this is core to ecn-tunnel at all.

The semantics of a tunnel handling two severity levels of congestion 
only requires knowing that there might be two levels of severity. The 
semantics of those levels in different schemes  (whether PCN or 
something like the research paper on VCP) are irrelevant to the 
tunnelling issue at hand here. That is the strength of how the 
Internet architecture is layered.

There was a straight y/n question to answer in the mail (still below).

And a suggestion of text for the draft, asking whether it satisfied you.

Bob

---

From: <[email-masked]>
Date: Thu, 15 Oct 2009 16:55:43 +0100

David

<< This is also consistent with Phil's response in which he describes
PCN:ECT(1) as kicking in before congestion occurs - wrt this fuzzy
notion of congestion occurring, ECN:CE kicks in as congestion occurs,
not before, and this distinction is aligned with the P in PCN standing
for "Pre".

yes. 
My default assumption is that both PCN:ECN(1) and PCN:CE kick in before
any actual congestion occurs - where congestion means the queue
overflowing or it means the queue growing such that AQM would mark or
drop the pkt. 

At the end you say you want to work through "this issue" - please could
you clarify what issue you mean, as I don't think I get it right. For
instance, where you say "I'm not comfortable with PCN:ECT(1) being
treated like ECN:CE" - I thought treatment here meant "treatment by
tunnels" but your other comments seem to be more about the whole
behaviour of PCN vs ECN

Thanks
[phil

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf
Of [email-masked]
Sent: 14 October 2009 18:37
To: Briscoe,RJ,Bob,XVR9 BRISCORJ R
Cc: [email-masked]; [email-masked]
Subject: Re: [tsvwg] comment on draft-ietf-tsvwg-ecn-tunnel

Bob (and Phil),

Thanks,
--David

---

From: Bob Briscoe <[email-masked]>
Date: Sat, 24 Oct 2009 18:25:27 +0100

David,

Over the last few months, our conversation has been progressing like 
two guys at each end of a blunt saw. Can we try to reach a conclusion 
on each of the three 'cuts' below? I shall be posting a rev before Monday.

1/
>[DB] I'm not comfortable with PCN:ECT(1) being treated like ECN:CE, 
>as I expect PCN to be setting it earlier than ECN:CE.  If the queue 
>occupancy is above the desired operating point, PCN:ECT(1) isn't 
>going to help, because it only stops the situation from getting worse

[BB] You may not be aware that PCN has two threshold bit-rates: a 
lower one when PCN:ECT(1) is triggered meaning 'stop admission' and a 
higher one when PCN:CE is triggered, which means 'terminate flows'.

Anyway, (paraphrasing Phil Eardley) are you uncomfortable about 
'treatment' in the sense of tunnelling treatment (wire protocol), or 
is this about PCN marking algo treatment, which ought to move to the PCN list?

2/
>[DB]> >If we are going to bless that PCN usage,...
>
>[BB]> For Not-ECT inner the draft makes it clear:
> > The question is, do you agree [to bless that PCN usage]?

3/
>[DB] > >...we will need to say so clearly and bluntly in the ecn-tunnel draft.
>
>[BB]> Would something like the change below be sufficient? Remember this is

Bob

---

From: <[email-masked]>
Date: Thu, 29 Oct 2009 17:24:05 -0400

Bob and Phil,

> on each of the three 'cuts' below? I shall be posting a rev 

Let's see if this sharpens the saw.  I apologize for the delays on
my part - the people who pay my salary expect me to do my day job
for some strange reason :-).  I will not be in Hiroshima (can't
justify the travel, sorry).

> higher one when PCN:CE is triggered, which means 'terminate flows'.

I have been aware of that.  PCN:CE causes reduction of traffic load in
a fashion similar to ECN:CE.  PCN:ECT(1) is a indication of less severe
congestion that is triggered earlier as congestion increase.  IMHO, it
therefore does not directly correspond to ECN:CE.

> 'treatment' in the sense of tunneling treatment (wire protocol), or 

The former.  How PCN marks packets is specified in PCN documents, and
should not be changed here.  I clearly used poor words in leaving you
and Phil with the impression that I wanted to change PCN - that was
*never* my intention (sorry).

My concern is based on the following two points:

(A) I agree with reasoning of the form "<X> needs to be done for ECN:CE,
	therefore it needs to be done for PCN:CE."  That's has to be
	valid, because if it were not, PCN would not have used the CE
	codepoint.

(B) I do not agree with reasoning of the form "<X> needs to be done
	for ECN:CE and PCN:CE, therefore it needs to be done for
PCN:ECT(1)."
	As noted above, PCN:ECT(1) is not a directly comparable
congestion
	indication to either ECN:CE or PCN:CE.

The immediate consequence of this is that we disagree on the treatment
of Inner:Not-ECT/Outer:ECT(1).  I view the arguments for Drop in this
case as instances of the (B) reasoning that I do not agree with.  Hence
I prefer the treatment of this case to be forwarding with Not-ECT (!!!)
[exclamation points indicate unusual case that gets logged/alarmed.]

OTOH, this is splitting hairs over an error case [i.e., (!!!)].  If I'm
the only person with this concern, at some point the chairs should
declare that I'm on the "rough" end of "rough consensus" and that'll
be that - this issue is not worth the time of the ADs or IESG.
 
> > > The question is, do you agree [to bless that PCN usage]?

Not in that fashion - see above.

> > >     ECN nonce [RFC3540] in Section 9, which in turn refers to
Appendix F.

Independent of our other discussions, I think that text change should
be made, as it clearly states the primary motivation for some of the
changes, and I see that it's been done in the -04 draft.

> transitions may generate alarms.

That issue surrounded what to do when the inner and outer headers
have different ECT values.  PCN uses Inner:ECT(0)/Outer:ECT(1), but
has no use for the other case, Inner:ECT(1)/Outer:ECT(0).

The log/alarm behavior in Figure 4 of the -04 draft is somewhat
alarming ;-) ;-).

Clearing ECT(1) to Not-ECT doesn't get logged or raise an alarm,
but clearing ECT(1) to ECT(0) does, while clearing CE to Not-ECT
doesn't.  Before you write a long response, I'm aware that the
explanations of what does vs. does get the log/alarm treatment
involve what happens when a new tunnel decapsulator is paired with
one of the two RFC 3168 encapsulator variants, but the result is
still strange and possibly of limited value for PCN.

Let me suggest a blunter alternative:

- Only log/alarm (!!!) by default the transitions away from Not-ECT
	in the inner header (first line in Figure 4, 3 right hand
boxes).
	These are just plain wrong, no matter what.
- Do not alarm any other combinations by default.  That puts a rapid
	end to this discussion.
- Provide an explanation (in an Appendix?) about what to alarm in a
	controlled PCN environment.  The short summary is that because
	PCN has to be deployed in a closed/controlled network, it's
	reasonable for the operator to know (in some cases) that there
	are no RFC 3168 encapsulators, and therefore be confident I
	explicitly enabling a considerably more aggressive log/alarm
	approach that catches all reduction/removal of congestion
	markings by comparison to what's in Figure 4.

If this is done, I think the current Appendix F can be bit-bucketed,
and that's probably an improvement.

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