[Top] [All Lists]

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

To: netdev <netdev@xxxxxxxxxxx>
Subject: Re: [Ksummit-2005-discuss] Summary of 2005 Kernel Summit Proposed Topics
From: Rick Jones <rick.jones2@xxxxxx>
Date: Tue, 29 Mar 2005 14:03:55 -0800
Cc: open-iscsi@xxxxxxxxxxxxxxxx, ksummit-2005-discuss@xxxxxxxxx
In-reply-to: <1112130512.1077.107.camel@xxxxxxxxxxxxxxxx>
References: <424346FE.20704@xxxxxxxxxxx> <20050324233921.GZ14202@xxxxxxxxxxxxxx> <20050325034341.GV32638@xxxxxxxxx> <20050327035149.GD4053@xxxxxxxxx> <20050327054831.GA15453@xxxxxxxxx> <1111905181.4753.15.camel@mylaptop> <20050326224621.61f6d917.davem@xxxxxxxxxxxxx> <Pine.LNX.4.61.0503272245350.30885@xxxxxxxxxxxxxxxxxxxxxxxxxxx> <m1zmwn21hk.fsf@xxxxxx> <1112027284.5531.27.camel@mulgrave> <20050329152008.GD63268@xxxxxx> <1112116762.5088.65.camel@beastie> <1112130512.1077.107.camel@xxxxxxxxxxxxxxxx>
Sender: netdev-bounce@xxxxxxxxxxx
User-agent: Mozilla/5.0 (X11; U; HP-UX 9000/785; en-US; rv:1.6) Gecko/20040304
jamal wrote:
I didnt quiet follow the discussion - Let me see if i can phrase the
problem correctly (Trying to speak in general terms):

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?

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.

Eventually the TCP will hit its RTX limit and punt the connection, freeing the buffers kept for retransmission right?

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

Isn't it better to consider TCP a protocol that provides reliable notice of (presumed) failure rather than a "reliable protocol?"

rick jones

<Prev in Thread] Current Thread [Next in Thread>