Re: [re-ECN] Preferential Dropping

[Bob Briscoe <[e-mail]>]

John,

At 17:21 17/05/2010, John Leslie wrote:
>McCann Peter-A001034 <[e-mail]> wrote:
> > John Leslie wrote:
> >>
> >> Backbone routers either do or don't support ECN marking in place of
> >> dropping packets.
> >
> > It would still be desirable to implement the preferential dropping
> > scheme on congested links in the backbone, no?
>
>    This probably deserves some discussion; and I see no reason we
>can't discuss it before ConEx is chartered.

Yes, let's have some technical discussion for a change, on the 
understanding pref drop is not a candidate for the initial charter. 
Those who want charter discussions can tune out.


>    I'm not sure whether preferential dropping belongs in ConEx at all.
>It seems like an ECN thing to me.

A queue can do some cool OPTIONAL protection against DDoS using 
preferential drop based on ConEx (specifically re-ECN) markings. This 
might be in a server's IP stack, or in a router. I would expect more 
relevant for access routers, assuming core routers might better 
absorb flooding with raw power.

Here's the intuition. A queue under a flooding attack will drop lots 
of packets and nearly all ECN-capable packets that manage to get 
through will be marked CE (red). So a behaving re-ECN sender should 
have marked nearly all arriving traffic for ~100% expected congestion 
(~100% black). Therefore, a flooded queue can focus drop on any 
packets that claim to support re-ECN but are not black. And it can 
further focus drop on any packets that don't support re-ECN.

A network using re-ECN for traffic management will police heavy 
sources of black packets at every entrance to the network. So, a DDoS 
source is caught between a rock and a hard place. To avoid focused 
drop at the congested queue it has to colour most packets black. But 
to avoid drop at the ingress policer it has to not colour packets 
black. Either way, its packets generally get dropped before harming 
packets that are behaving.

See the second bullet "Preferential Drop" in S.5.3 of the re-ECN draft:
<http://www.bobbriscoe.net/projects/refb/draft-briscoe-tsvwg-re-ecn-tcp-08.html#retcp_Router_Forwarding_Behaviour>
[Yes, I know, it's expired - now I'm back in circulation I'll rev it.]

The analysis I did on this showed that re-ECN can raise the bar 
against DDoS so that the army has to be N times bigger to achieve the 
same *sustained* attack force, where N=1/p and p is the 'normal' 
level of congestion in the network. E.g. if normal congestion is 
0.001%, a sustained attack against a re-ECN internetwork has to be 
100,000 times bigger to cause the same damage as it could against a 
network without re-ECN.

Obviously, there are assumptions and details, but that was the 
take-home message. If anyone wants more details, just ask.


>    The benefit of ECN marking instead of dropping is that a congestion
>signal can trigger a slowing of sending rate more quickly if we don't
>have to wait for a packet drop to be recognized.
>
>    The downside is that we can't be sure that an ECN mark will actually
>make it through and result in a backoff of sending rate. A misguided
>operator might scrub ECN markings; an ECN-marked packet might encounter
>_other_ congestion and be dropped;

SUch a drop will still be an (eventual) congestion signal

>or the signal could fail to make it
>back to the sender for a number of reasons.
>
>    The issue is whether anything about ConEx markings could signal a
>trustworthy assurance that ECN marking is more likely to result in
>earlier backoff.

So far I'm not convinced by preferential drop based on ECN markings.


>    This doesn't feel particularly in-charter to me (at least not in
>the initial charter); but we have until Thursday at least to discuss
>things that are _not_ in-charter.

I also believe strongly that pref drop is off-charter, at least initially.

Incidentally, I've also worked out that it is perfectly possible to 
add the above preferential drop behaviour to the specs later, without 
creating an incremental deployment problem.


Bob


>    ;^)
>
>--
>John Leslie <[e-mail]>
>_______________________________________________
>re-ECN mailing list
>[e-mail]
>https://www.ietf.org/mailman/listinfo/re-ecn

________________________________________________________________
Bob Briscoe,                                BT Innovate & Design