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

[Bob Briscoe <[e-mail]>]

Matt,

At 19:47 29/10/2009, Matt Mathis wrote:
>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.

You're right that the policer in Appx B of
         draft-briscoe-tsvwg-re-ecn-tcp-motivation-01
monitors whole path congestion. But since implementing it, we've 
moved to the same idea as you - using downstream congestion - we 
haven't written it up yet tho.

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

It does (now).

>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

I'll let this one pass for now, but it isn't quite true. (The policer 
might well be introducing a fair bit of drop - if the policer matched 
25% policer drop with 25% CE marking introduced at its ingress, that 
would hide 25% of any ECN marking further downstream.)

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

Yes.
Except duplicates have to be measured per flow and at the transport 
layer, and they're specific to certain transports - as already argued 
out on this list.


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

Sort of true - I'd rather say taking the pressure off downstream 
bottlenecks is a side-effect. The design objective it has to be 
written against is to create sufficient disincentive to cause 
congestion, which gives a precise way to calculate exactly how much 
it should drop.

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

Absolutely - right from the very first twinkle of re-feedback in the 
eye - that was the original design goal - to be able to measure 
downstream congestion simply in bulk at borders. The aim was 
something passive and simple that would work with all-photonic 
borders in the future.

>Ok I will make the brash claim
>that a naked "RE marks" is wrong anywhere except when talking about
>the end systems.

Correct. Definitely... Brashly even. :)

Cheers


Bob


>Thanks,
>--MM--

________________________________________________________________
Bob Briscoe,                                BT Innovate & Design