Subject: Re: iSCSI: Logout command, or The Initiator's new close()

From: "Matt Wakeley" <[email-masked]>
Date: Tue, 05 Jun 2001 17:46:03 -0700

I think we must dictate implementation.  Anything other than specifying how
the close is to work mean interoperability problems.  I vote for Mark's first
choice:

> The most straight-forward choice might be:
> 
>    Initiator sends the logout request, and simply waits for
>    the response without closing the connection.  The target
>    sends the logout response, and closes its end of the
>    connection.  The initiator receives the logout response,
>    and the FIN from the target, and closes its end of the
>    connection.

That way, if there are outstanding I/Os that need to be completed or errors
that must be communicated, the appropriate communication can be completed
before the TCP connections are destroyed.

-Matt Wakeley
Agilent Technologies

[email-masked] wrote:
> 
> Mark,
> 
> I don't think that we should dictate implementation.
> As we assume that nothing is sent after Logout (should we spell this out)
> and we have to wait
> for the logout response we can do  a half close and wait or wait and do a
> full close after seeing the Logout response.
> The first is faster the second is simpler.
> 
> Regards,
> Julo
> 
> Mark Bakke <[email-masked]> on 26-05-2001 00:43:30
> 
> Please respond to Mark Bakke <[email-masked]>
> 
> To:   IPS <[email-masked]>
> cc:
> Subject:  iSCSI: Logout command, or The Initiator's new close()
> 
> Section 2.14 (the logout command) is not clear on how the logout
> command and response work when the logout request is send on a
> connection for which it requests termination.  We should probably
> specify the TCP close behavior of the initiator and target.
> 
> The initiator can send the logout request, and either close
> the current connection, half-close the connection and wait
> for the logout response (like HTTP/1.0), or leave it open,
> and close the connection upon receiving the response or the
> FIN from the target.
> 
> Upon receiving the logout request, the target can either
> close the connection immediately, send the logout response
> and then close the connection, or send the logout response
> and wait for the initiator to close the connection upon its
> receipt of the logout response.
> 
> Logout would work best if the initiators and targets all did
> this in the same manner, choosing one of the above behaviors
> for the initiator, and a compatible one for the target.
> 
> The most straight-forward choice might be:
> 
>    Initiator sends the logout request, and simply waits for
>    the response without closing the connection.  The target
>    sends the logout response, and closes its end of the
>    connection.  The initiator receives the logout response,
>    and the FIN from the target, and closes its end of the
>    connection.
> 
> Any opinions on whether this is best?  This choice does not
> require the initiator to know that the connection that is being
> closed is the one it sent the logout response on, but does
> require the target to send the logout response before it actually
> closes the connection.
> 
> Another behavior that might work would be to say that the target
> closes all of its connections and does cleanup before sending the
> logout response, and if the connection on which the request came
> in is gone, it does not send a response.  An initiator whose
> connection is closed after sending the logoout request can assume
> that the request worked.
> 
> Anyway, I think that it would be good to clarify this.
> 
> --
> Mark A. Bakke
> Cisco Systems
> [email-masked]
> 763.398.1054

---

From: Mark Bakke <[email-masked]>
Date: Fri, 08 Jun 2001 11:05:49 -0500

Julian-

I agree with Matt; since I haven't seen any disagreement
with this option, can we dicate it in 07?

--
Mark

-- 
Mark A. Bakke
Cisco Systems
[email-masked]
763.398.1054