Hello!
> Hmm, that's bad news. I thought the BSD guys had good experience with RED
> syndrop.
I think they have no experience, either bad or good.
> I was planning to use RED to make the memory management for the defragment
> code better. Especially with always defrag the current algorithm is not
> very good and can be easily DOSed - unfortunately a lot of people use that
> on their firewalls. I'll do some experiments next week.
This will not help against deliberate DoS, certainly.
But it _can_ be better working with legal overload, because all sane
applications do backoff, when losing data.
Theorem
-------
When policing something, _all_ the schemes, which do not distinguish
resource consumers are equivalent. Be it red, tail drop, head drop,
random drop of any kind etc. All they penalize all the consumers
equally, so that aggressive consumer always win the race.
When doing RED on TCP, we rely on the fact that sender is "self-identifying"
i.e. backoffs when RED hit it.
Resource consumption per backing off user is crucial factor here.
It can be determined only from experiment: will this backoff visible
on background or not. For SYNs it is invisible at all. For established
TCP it is big good number. If it will be visible for fragmented datagrams,
you win. Not for DoS case, certainly.
BTW in this case "fair" resource allocation is possible.
F.e. for defragmenter you could use SFQ-like scheme. It is cheap
and mighty. Even true fair queue based on destiantion IP address
is possible in the case of "always defrag". And it really defends against DoS.
Alexey
-
To unsubscribe from this list: send the line "unsubscribe linux-net" in
the body of a message to [EMAIL PROTECTED]
