Re: [re-ECN] re-echo of drop (was: Re: TCP's "Dynamic Range")

[Matt Mathis <[e-mail]>]

I would like to harp on one of Bob's remarks:

> We have recently realised there is an issue with re-echo on drop if the
> drops are from a policer (re-echoing unnecessarily gets the sender into
> deeper and deeper trouble). But I have a flakey solution to that, which we
> can work on writing in I-D language.

I think part of the problem here is a flaw in the way that RE-ECN
policers are envisioned.  A small tweak might make everything fit
whole lot better.    As currently envisioned a policer monitors the
total RE marks, which reflect the total congestion for the entire
path.  This then forces the policer action to be some other signal,
otherwise the police action self regenerates.

A better design would be if the policer only acted on the down stream
congestion, as indicated by RE marks minus ECN marks (remember, ECN
marks at the policer reflect upstream congestion).  With this design
the policer's action can be to apply additional ECN marks at its own
ingress interface.   This does not directly effect the downstream
congestion signals (until latter RTTs when the transport protocols
have had an opportunity to respond).

The unifying ah-ha that connects loss based RE-feedback and RE-ECN is
the observation that  "RE marks minus ECN marks" is exactly the same
signal as counted duplicate data - It is the number of packets that
will be (have been) marked or dropped further down stream.

This policer design also has a simple physical interpretation: it is a
bottleneck that is specifically designed to take the pressure off of
downstream bottlenecks.

After mulling this over, I am suspicious that there are other places
where "RE marks" should be replaced by "RE marks minus ECN marks" for
example at settlement boundaries.   Ok I will make the brash claim
that a naked "RE marks" is wrong anywhere except when talking about
the end systems.

Thanks,
--MM--