Re: [Ksummit-2005-discuss] Summary of 2005 Kernel Summit Proposed Topics

[Andi Kleen <ak@muc.de>]

On Tue, Mar 29, 2005 at 04:08:32PM -0500, jamal wrote:
> Sender is holding onto memory (retransmit queue i assume) waiting
> for ACKs. Said sender is under OOM and therefore drops ACKs coming in
> and as a result cant let go of these precious resource sitting on the
> retransmit queue. 
> And iscsi cant wait long enough for someone else to release memory so
> the ACKs can be delivered. 
> Did i capture this correctly?

Or worse your swap device is on iscsi and you need the ACK to free
memory. 

But that is unrealistic because it could only happen if 100% of
your memory is dirty  pages or filled up by other non VM users.
Which I think is pretty unlikely. Normally the dirty limits in the VM
should prevent it anyways - VM is supposed to block before all
your memory is dirty. The CPU can still dirty pages in user space,
but the cleaner should also clean it and if necessary block
the process.

> 
> If yes, the solution maybe to just drop all non-high-prio packets coming
> in during the denial of service attack (for lack of better term). In
> other words some strict prioritization scheduling (or rate control) at
> the network level either in the NIC or ingress qdisc level.

It does not help. You would need this filtering in all possible
queues of the network (including all routers, the RX queue of the NIC etc.)
Otherwise the queue in front of you can always starve you in theory.

It is even impossible to do this filtering for normal ethernet devices
because they cannot easily distingush different flows and put
them into different queus (and even if they can it is usually useless
because the max number of flows is so small that you would add
an arbitary very small max number limit of your iscsi connections, which
users surely would not like)

And you cannot control the Ethernet in front of it neither.

The only exception would be a network that is designed around
bandwidth allocation, like an ATM network. But definitely not TCP/IP.

So you cannot solve this problem perfectly. All you can do is
to do "good enough" solutions. Have big enough pipes. Keep
big enough free memory around etc. I suspect mempools are not really
needed for that, probably just some statistical early dropping
of packets is enough to give the retransmits a high enough
chance to actually make it.

 
> On a slightly related topic: is SCSI (not iscsi) considered a reliable
> protocol?
> If yes, why would you wanna run a reliable protocol inside another
> reliable protocol (TCP)?

iSCSI runs on top of TCP AFAIK

-Andi