Re: rationale to send PDUs in increasing CmdSn on single connection
Julian Satran <[email protected]> Fri, 31 Aug 2007 18:53:46 +0300
| Newsgroups | gmane.ietf.ips |
|---|---|
| Message-ID | <OFAF0AE958.0CFEB996-ONC2257348.0056D8DE-C2257348.0057518A@il.ibm.com> |
Parav Pandit <[email protected]> wrote on 31/08/2007 12:52:04: > Hi, > > RFC 3720, section 3.2.2.1 says > > "On any connection, the iSCSI initiator MUST send the > commands in increasing order of CmdSN, except for > commands that are retransmitted due to digest error > recovery and connection recovery. " > > (Assuming Single TCP connection ISCSI session) > > 1. I interpret above 3.2.2.1 statement as > SCSI layer gives SCSI commands to the ISCSI stack in > the order of Cmd-1 and Cmd-2. > Cmd-1 will have CmdSn = 10. > Cmd-2 will have CmdSn = 11. > ISCSI stack CAN send PDUs to the TCP layer in > following order ONLY. > PDU-1 with Cmd-1. > PDU-2 with Cmd-2. > > Is this correct interpretation? > Or > Yes > 2. On a SINGLE connection can ISCSI stack send the > PDU-1 with Cmd-2 followed by > PDU-2 with Cmd-1? > NO > Assuming the answer of the question #2 is No, > > 3. If there are multiple connections in a session then > command MAY any way reach out of order. And targets > need to wait for the previous expected commands. > > So targets will receive out of order ISCSI PDUs from > the TCP layer and ISCSI stack handles them. > > So then why initiators have restriction of sending > command in the increasing order of CmdSn on SINGLE TCP > connection? > To simplify recovery and to... > Is it to simplify the implementation of targets > supporting only single TCP connection? > > and there was no visible motivation for out of order commands on a single connection > Regards, > Parav Pandit > > > > > ____________________________________________________________________________________ > Looking for a deal? Find great prices on flights and hotels with > Yahoo! FareChase. > http://farechase.yahoo.com/ > > > _______________________________________________ > Ips mailing list > [email protected] > https://www1.ietf.org/mailman/listinfo/ips _______________________________________________ Ips mailing list [email protected] https://www1.ietf.org/mailman/listinfo/ips