RE: rationale to send PDUs in increasing CmdSn on single co nnection

["Pat Thaler" <pthaler@xxxxxxxxxxxx>]

The focus of comments seems to have been around single connection with
the implication that multi-connection already has to handle out of order
and the restriction is doing nothing for multi-connections sessions.
This is incorrect. Even when there are multiple connections, the
requirement to have increasing order on a connection restricts the
behavior the receiver will see. For example, when there are two
connections and packets 1 through 4 have been sent, the receiver might
see:

Connection: A      B
                   1       
                           3

                           4
                   2

But would not see:
                  A     B
                  1  
                         3
    
                         2

                  4


For a session with N connections, the receiver only has to look N places
(the front of what was received from each connection) for the next
CmdSN. If one removes the in-order per connection rule, the receiver
would have to look for the next CmdSN in the whole set of received
commands. It would be incorrect to assume that any multi-connection
iSCSI implementation would work with the restriction removed. Some may
have been implemented for the subset of out of order behavior that
occurs within the current rules. They may handle deviations from that
behavior for recovery but with less efficiency so that it is
undesireable to purposely cause that condition.

Pat


-----Original Message-----
From: Parav Pandit [mailto:paravpandit@xxxxxxxxx] 
Sent: Wednesday, September 05, 2007 6:01 AM
To: Paul Koning
Cc: David_Sheehy@xxxxxxxxxxxxxx; ips@xxxxxxxx; Julian_Satran@xxxxxxxxxx
Subject: RE:  rationale to send PDUs in increasing CmdSn on single
co nnection


--- Paul Koning <pkoning@xxxxxxxxxxxxxx> wrote:

> >>>>> "Parav" == Parav Pandit
> <paravpandit@xxxxxxxxx> writes:
> 
>  Parav> If I take pragmatic approach, Any idea,
> currently how current
>  Parav> single connection target implementation is?
> 
> I suspect most of them are single connection.
> 

>  Parav> I mean, if current targets are smart enough
> (accept out of
>  Parav> order PDUs on single connection- liberal on
> point 3.2.2.1),
>  Parav> then initiators can use their DMA
> optimization.  What do you
>  Parav> say?
> 
> Don't.
> 
> You'd be creating an initiator that violates the
> protocol spec.  You'd
> have no reason to expect that to work at all.  Many
> targets will check
> this and call it a protocol violation (you may end
> up with the
> connection terminated).  Some may not notice but may
> end up doing the
> wrong thing.
> 
>       paul

[Parav] Thanks Paul. I certainly don't want to violate
the protocol. I was wondering how current qualified,
proven iscsi targets are behaving for this scenario.
And you confirmed the same, so will surely adhere to
the protocol.

Thanks,
Parav



       
________________________________________________________________________
____________
Take the Internet to Go: Yahoo!Go puts the Internet in your pocket:
mail, news, photos & more. 
http://mobile.yahoo.com/go?refer=1GNXIC


_______________________________________________
Ips mailing list
Ips@xxxxxxxx
https://www1.ietf.org/mailman/listinfo/ips




_______________________________________________
Ips mailing list
Ips@xxxxxxxx
https://www1.ietf.org/mailman/listinfo/ips