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

[Mark Bakke <mbakke@cisco.com>]

Julian-

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

--
Mark

Matt Wakeley wrote:
> 
> 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
> 
> julian_satran@il.ibm.com 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 <mbakke@cisco.com> on 26-05-2001 00:43:30
> >
> > Please respond to Mark Bakke <mbakke@cisco.com>
> >
> > To:   IPS <ips@ece.cmu.edu>
> > 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
> > mbakke@cisco.com
> > 763.398.1054

-- 
Mark A. Bakke
Cisco Systems
mbakke@cisco.com
763.398.1054