RE: iSCSI : Abort Task "connection allegiance"

["Douglas Otis" <dotis@sanlight.net>]

Santosh,

It is common to have multiple routers providing access over different IPs to
the same machine.  At an indication of trouble, an alternative path would be
employed to prevent any significant service disruption with a path switch
the extent of effort.  The present scheme only considers multiple
connections as a means to modify TCP congestion algorithms in obtaining
larger shares of the network bandwidth and ignores issues of reliability and
disruption avoidance.  To require ULP (higher level protocol) exchange as
part of making the path switch on existing connections together with an ULP
restart of service is highly disruptive and indicates an unreliable delivery
scheme.

Already all PDUs are marked with a serial number across all connections.
The problems of out-of-order issues occur due to a lack of integrity of this
serialization.  When this serialization fails, it is hoped TCP provides
necessary sequential assurance and is thus imposing a connection restriction
as this would then introduce a different underlying TCP sequence.  The
present handshake already mandates some state sharing across all connections
with Exp* and Max*.  Allowing fail-over at the transport level is the only
means that would have a broader application and would not impose
restrictions on the ULP such as SCSI.  Such an approach is a means of
isolating various layers involved and a means of ensuring there is not a
required cooperation of the ULP.

Although you express concern about main-line execution of SCSI where to
reduce the amount of state information shared between connections,
connection allegiance is employed; the means of allowing a transition to a
different connection without assistance of SCSI should be allowed for a good
design.  Any required state information should be transferable
automatically.  The alternative is highly disruptive.  As a performance
optimization, indicate preference for allegiance but do not mandate it and
repair serialization integrity of the transport to remain viable across
multiple connections.  To do less will reduce the integrity of the system
and impose highly complex scenarios for recovery.

Doug



> >Santosh,
> >The advantage of multiple connections or multiple homing is removed if
> >connection allegiance is mandated.
>
> Doug,
>
> Section 1.2.5 already mandates connection allegiance for all PDUs of a
> command.
> ("For SCSI commands that require data and/or parameter
> transfer, the (optional) data and the status for a command must be
> sent over the same TCP connection that was used to deliver the SCSI
> command (we call this "connection allegiance").")
>
> I believe the dis-advantages of sending different PDUs of a command over
> different connections has already been discussed and discarded due to the
> various state sharing issues as well as out-of-order issues it causes.
>
> So, is the concern expressed about the existing MUST in the above
> statement
> in the draft ? Or are the comments directed towards the proposal
> to extend
> connection allegiance to the Abort Task as well ?
>
> >The ability to recover from a seemingly failed connection may include a
> >request to restart using a different connection.  Such request
> will likely
> >be sent over a different connection if there is a desire to migrate.
> >Connection allegiance was to allow distributed state information
> to remain
> >isolated.  This isolation is problematic and not mandating allegiance
> >ensures there will always be a means to communicate intermediate states
> >between connections.
>
> While the "retry" command processing at the target may involve
> co-operation
> across multiple NIC instances to fetch the data/status, this should be ok
> since it is the exception path. We should not attempt to optimize
> this path
> and affect the mainline paths. The mainline I/O paths require connection
> allegiance for a number of reasons that have been previously discussed on
> the reflector.
>
> >Connection allegiance should only be preferred.
>
> The lack of connection allegiance for all PDus of a command can cause
> out-of-order problems, with status PDUs arriving at the initiator
> ahead of
> the data PDUs.It also requires sharing I/O state information
> across NICs for
> the mainline paths, as compared to the current model where this is only
> required in exception paths.
>
> Regards,
> Santosh
>
>
> _________________________________________________________________________
> Get Your Private, Free E-mail from MSN Hotmail at http://www.hotmail.com.
>
>