Re: Asynchronous Message: Session Termination

[Santosh Rao <santoshr@cup.hp.com>]

In addition to the changes discussed in this thread so far, I'd like to
suggest the following further changes to the async message PDU (Section
2.18.1 , page 72) :


1) Regarding the text :

"target indicates it will/has dropped the connection"
&
"target indicates it will/has dropped all connections"

suggest re-phrasing it to :
"target indicates it will drop the connection"
& 
"target indicates it will drop all connections"

2) State explicitly that :
a) Targets must first send the async message and then close the
connection after the specified time to ensure the message is pushed to
the initiator. ("has dropped" means the async PDU cannot be transmitted,
thereby rendering it useless.)

b) The target will abort all outstanding commands on this session as a
result of this operation.

3) Add a parameter to "target indicates it will drop the connection"
that specifies the seconds after which the target will drop the
connection (0 indicates immediately). This is consistent with the
changes being proposed for the addition of a similar parameter to the
"target indicates it will drop all connections". This allows initiators
to attempt to switch further I/Os to alternate connections within the
session accordingly. 

The description should also state explicitly that all outstanding I/Os
on that connection are aborted by the target after the connection is
terminated, unless a prior "logout for connection recovery" was received
to recover the connection being dropped, in which case the connection
allegiance of the outstanding I/Os is switched to the new connection
specified in the Logout PDU.

4) Remove the "Target requests logout" event in the Async Message PDU.
This can be achieved by using (3) in its above form, without requiring
the ping pong caused by :
T -> I : async PDU
I -> T : Logout PDU
T -> I : Logout Response PDU
T -> I : closes TCP connection.
 

Regards,
Santosh


Mark Bakke wrote:
> 
> Matthew-
> 
> How about we have Parameter3 be in addition to Parameter2?  That
> would solve the same problem.
> 
> Along with comments from Santosh, here's another try:
> 
>       4    Target indicates it will/has dropped all connections - the
>       Parameter2 field indicates, in seconds, the time until all
>       connections will be terminated (or zero if immediately), and
>       Parameter3 the minimum additional time the initiator should
>       wait before attempting to establish a new session.  If
>       Parameter3 is zero, the initiator may attempt to reconnect as
>       soon as the time specified in Parameter2 has passed.
> 
> So if an initiator receives this with P2 == 3 and P3 == 10, it
> would know it has 3 seconds to try clean up nicely, and can
> re-connect 13 seconds from when this message was received.
> 
> There is currently no way to use P3 to tell the initiator not to
> try connecting ever again, but this behavior can be provided by
> simply setting P3 to zero, and either denying the connection or
> returning a redirect when the initiator attempts to re-connect.
> 
> --
> Mark
> 
> "BURBRIDGE,MATTHEW (HP-UnitedKingdom,ex2)" wrote:
> >
> > Mark,
> >
> > The last description is good and covers all situation.  Presumably, if
> > Parameter3 is zero then the initiator is able to establish a new session
> > immediately.  Can you modify the description to specify that Parameter3 must
> > be greater than or equal to Parameter2 (it makes no sense to have a value
> > less than Parameter2) and that zero is a valid value for Parameter3.
> >
> > Matthew
> >
> > -----Original Message-----
> > From: Mark Bakke [mailto:mbakke@cisco.com]
> > Sent: Wednesday, May 23, 2001 4:17 PM
> > To: BURBRIDGE,MATTHEW (HP-UnitedKingdom,ex2)
> > Cc: ips@ece.cmu.edu
> > Subject: Re: Asynchronous Message: Session Termination
> >
> > Matthew-
> >
> > The intent of these was not to connect and re-establish the same
> > session after a set amount of time; it was to inform the initiator
> > not to try to establish a new session until the time passes, which
> > is I think what you want.  Perhaps changing the description of
> > #4 from:
> >
> >       4    Target indicates it will/has dropped all connections - the
> >       Parameter2 field indicates, in seconds, the minimum time to
> >       reconnect and Parameter3 the maximum time to reconnect.
> >
> > to:
> >
> >       4    Target indicates it will/has dropped all connections - the
> >       Parameter2 field indicates, in seconds, the minimum time to
> >       wait to establish a new session and Parameter3 the maximum
> >       time to wait to establish a new session.
> >
> > Actually, I had originally requested this, to allow a target to say
> > "I'm shutting down / failing over in X seconds; and will be back again
> > in Y seconds, so don't bother connecting until then".  With this
> > behavior, the description should read:
> >
> >       4    Target indicates it will/has dropped all connections - the
> >       Parameter2 field indicates, in seconds, the time until all
> >       connections will be terminated (or zero if immediately), and
> >       Parameter3 the maximum time the initiator should wait before
> >       attempting to establish a new session.
> >
> > If everyone agrees with this, I would rather have the above description.
> >
> > --
> > Mark
> >
> > "BURBRIDGE,MATTHEW (HP-UnitedKingdom,ex2)" wrote:
> > >
> > > Hi Julian,
> > >
> > > If a target only supports Session Recovery, then when an error is detected
> > > it will terminate the session.  The current Async Message (iSCSI Event
> > > "Target indicates that his will/has dropped all connections") does not
> > > necessary inform the initiator that the session has terminated and the
> > > initiator is quite within rights to establish a new connection and attempt
> > > With-in Session recovery.
> > >
> > > Can you change the spec to reflect that a value of zero in both the
> > > Parameter2 and Parameter3 would set the maximum time to reconnect to
> > "Never"
> > > thereby informing the initiator that the session has closed?
> > >
> > > Thanks
> > >
> > > Matthew Burbridge
> > > NIS-Bristol
> > > Hewlett Packard
> > > Telnet: 312 7010
> > > E-mail: matthewb@bri.hp.com
> >
> > --
> > Mark A. Bakke
> > Cisco Systems
> > mbakke@cisco.com
> > 763.398.1054
> 
> --
> Mark A. Bakke
> Cisco Systems
> mbakke@cisco.com
> 763.398.1054
begin:vcard 
n:Rao;Santosh 
tel;work:408-447-3751
x-mozilla-html:FALSE
org:Hewlett Packard, Cupertino.;SISL
adr:;;19420, Homestead Road, M\S 43LN,	;Cupertino.;CA.;95014.;USA.
version:2.1
email;internet:santoshr@cup.hp.com
title:Software Design Engineer
x-mozilla-cpt:;21088
fn:Santosh Rao
end:vcard