RE: a vote for asymmetric connections in a session

[Joshua Tseng <jtseng@NishanSystems.com>]

Hi Matt,

>> In the event of a failed connection, the sliding window isn't going to
help
>> much since you have to first detect the failed connection.  Once this is
>> accomplished, the initiator will know which command was lost for sure,
>
>How is the initiator going to know what commands got to the target or not
>without the command reference numbers in the iSCSI document?

I believe the Task ID is sufficient.

>> but will not know how many, if any, of the subsequent commands sent after
the
>> lost command, were also lost.
>
>Well, all of them on the failed connection - if the connection failed, the
>following commands could not have been delivered.

I believe we were talking about the symmetric model, where commands could be

sent on more than one connection.  The subsequent commands could have been
sent on a different connection than the one that failed.

>>  I presume, the initiator will then
>> retransmit all commands without knowing whether or not they were lost,
>> rather than wait for the target to advance the acknowledgement counter.
>>
>> This is all awesome and impressive behavior, exactly what we want.  The
only
>> problem is this exact same behavior can be had without the windowing
>> mechanism.
>
>Could you describe how it can be had?

Well, the initiator has the task ID of all outstanding commands when the
connection
failed.  The initiator should also know what order they were transmitted.
He
could retransmit them again in the same order, with the retry bit set.  I
believe
this was mentioned earlier.

Regards,

Josh