Re: summary of iSCSI meeting 22 June 2000

[Matt Wakeley <matt_wakeley@agilent.com>]

julian_satran@il.ibm.com wrote:

> Matt,
>
> You are correct on the connection recovery. The initiator will do it.
> However data recovery, for data that has been discarded voluntarily or not
> and command
> recovery are up to the target iSCSI (and to do it the target can't be
> completely dump).
> If the target is completely dumb the only thing it can do is notify).

Julian,

I don't see why the target is to perform command and data recovery.
The initiator knows what commands it sent.  It should ask the target what
commands it received.  This is how FCP-2 performs error recovery. Maybe I'm
just missing something, so please explain what you have in mind.

-Matt

>
>
> Julo
>
> Matt Wakeley <matt_wakeley@agilent.com> on 26/06/2000 18:39:07
>
> Please respond to Matt Wakeley <matt_wakeley@agilent.com>
>
> To:   ips@ece.cmu.edu
> cc:    (bcc: Julian Satran/Haifa/IBM)
> Subject:  Re: summary of iSCSI meeting 22 June 2000
>
> julian_satran@il.ibm.com wrote:
>
> > For all those concerned about the recovery discussion here are some
> > clarifications:
> >
> > 1. The whole discussion thread was related to an attempt to recover from
> > one TCP connection failure
> > in a session that has multiple TCP connections in order to fully exploit
> > the fault tolerance level users are expecting when using several
> > connections
>
> Agreed.
>
> > 2. As we are aware that stateful devices and operation idempotency are
> hard
> > to handle in general terms
> > we are currently contemplating mostly recovery mechanisms that are
> > "target-centric" (mostly target initiated).
>
> That's not the way I understand it.  Targets are (generically) dumb devices
> and
> only do what they're told.  It is the initiator's responsibility to recover
> the
> device/connection.  Not the target's responsibility to recover the
> initiator.
>
> This is the way FCP-2 performs error recovery.  The only thing the target
> does
> is "logout" an initiator if a master timeout expires (see RR_TOV).
>
> -Matt
>
> > Obviously we would love to be able to recreate a TCP connection
> > in exactly the state it got lost
> > but we are not aware of any such magic being available...
> >
> > Julo
> >
> > Julian Satran - IBM Research Laboratory at Haifa
> >
> > David Robinson <robinson@ebay.sun.com> on 22/06/2000 20:30:05
> >
> > Please respond to David Robinson <robinson@ebay.sun.com>
> >
> > To:   Kalman Meth/Haifa/IBM@IBMIL
> > cc:   ips@ece.cmu.edu, scsi-tcp@external.cisco.com (bcc: Julian
> >       Satran/Haifa/IBM)
> > Subject:  Re: summary of iSCSI meeting 22 June 2000
> >
> > meth@il.ibm.com wrote:
> >
> > > Further discussion of what happens when TCP packets get lost,
> especially
> > if
> > >  they contain an iSCSI header.
> > > How well can iSCSI compete with FC if we are so dependent on TCP, with
> > its
> > > dropped packets.
> > >
> > > In the LAN, TCP packets are not generally lost and we should be
> > comparable
> > > to FC.
> > > Over WAN, can have packet loss and resulting complications, but that is
> > no
> > > longer competing with FC
> > > (which doesn't exist at all in the WAN).
> >
> > Huh? TCP packets can never get lost, you either get the packet
> > or the connection is dropped.  There may be some delay as TCP
> > performs a retransmission which will be rare on LANs and not
> > so rare on WANs. I don't see how this is a FC vs TCP issue.
> >
> >      -David