RE: iSCSI: response to second login (with same ISID)

[julian_satran@il.ibm.com]

Martin,

I agree that it would be bad if at login an initiator would have to wait
for a long time for the target
to detect if the old session has gone away.   But there is nothing in  the
current spec that will
prevent a good target implementation doing what you describe whithout any
negotiation.

Regards,
Julo

"Martin, Nick" <Nick.Martin@compaq.com> on 25-05-2001 23:22:11

Please respond to "Martin, Nick" <Nick.Martin@compaq.com>

To:   Julian Satran/Haifa/IBM@IBMIL, ips@ece.cmu.edu
cc:
Subject:  RE: iSCSI: response to second login (with same ISID)




Julian,

I do not know how long it would take a target using a ping to determine
that
an old session is really dead.  Some folks think it would be too long, thus
they want to be able to "login unconditionally".  Primarily I thought this
would be used for initiators rebooting after ungraceful shutdown.  (For
those who can otherwise reboot quickly, but would stall on each iSCSI
session not already recovered by the target.)

I do not expect to want to use a "login unconditionally" option.  (I can
handle rejection ;)
The scary thing to me was if an initiator could not try an ISID which was
in
use (intentionally, accidentally, or erroneously) without disrupting
(logging out) its current user (a.k.a. option 2).
It appears that if given a "login unconditionally" option, some folks would
use it exclusively.

If the initiator can specify the maximum time it would take a target to
notice dead connections and sessions, then the argument that waiting for
target recovery of the session would take too long presumably goes away.

I am thinking about login negotiated parameters like MinIdleTime and
MaxIdleTime values in seconds.  These could specify respectively the
connection idle interval after which a NO-OP (keep-alive) should be sent
and
expected, and the time with no traffic received on this connection which
should be regarded as an implicit logout request due to connection failure.
(This could cause an async event if detected by the target and a working
connection remains in this session.)

Better names can be chosen.  Reasonable defaults might be 10 seconds and 60
seconds.  There should be a recommendation like MaxIdleTime should always
be
at least 3 times MinIdleTime.  Such parameters would probably exist within
the Target and the Initiator, even if they are not negotiated or exchanged.
The intent is that an Initiator that cares, can limit Target connection
recovery delays.

These parameters set by the Initiator for the Target, would be known to
both.  A broken connection could be detected by each at approximately the
same time.  The keep-alive NO-OP's could be pings so that both directions
would be kept alive by a single exchange.  If the Initiator wants to be
responsible for keep-alives, it should do them before the specified
MinIdleTime, if it wants the Target to do them, it may need to do them
also,
slightly after the specified MinIdleTime, but well before MaxIdleTime.

My networking is weak, so I am not sure whether there should be a separate
(shorter) time specified for the maximum time to wait for the reply to a
ping, or how long to wait to retry it.  I am not clear on the interactions
with TCP and its timeouts and retries.  Is there a maximum time a ping
could
take and still get through?  Is there a maximum time a busy iSCSI target or
initiator would be expected to delay before sending a reply to a ping?

Does this sound like a good idea at all or not?

Thanks,
Nick