MaxCmdRN and 16 bit

[julian_satran@il.ibm.com]

Making a separate PDU was on our mind too.
It allows a cleaner implementation and handled two-way (an initiator to
target PDU) it may solve also the StatRN thing (that left for piggyback
will strain the header).


As for the 16 bit - it means 150k I/Os per second in the first stage of the
pipeline!

Anyhow if we extend it to 4 byte then we may want to go for a 48 byte
header.

We should do a tally on that on today's call.

Julo


---------------------- Forwarded by Julian Satran/Haifa/IBM on 29/06/2000
08:28 ---------------------------





Costa Sapuntzakis <csapuntz@cisco.com> on 28/06/2000 22:38:19

Please respond to Costa Sapuntzakis <csapuntz@cisco.com>

To:   Julian Satran/Haifa/IBM@IBMIL
cc:   ips@ece.cmu.edu

Subject:  06/28 draft: MaxCmdRN scheme






I propose to remove MaxCmdRN from the iSCSI PDUs in which it currently
appears and placing it in a separate iSCSI PDU.

We need some way of ordering updates to MaxCmdRN. I propose the following
mechanism:

Update MaxCmdRN

   Byte /     0       |       1       |       2       |       3       |
       /              |               |               |               |
      |7 6 5 4 3 2 1 0|7 6 5 4 3 2 1 0|7 6 5 4 3 2 1 0|7 6 5 4 3 2 1 0|
      +---------------+---------------+---------------+---------------+
     0| Opcode (0x8A) |      0        |             MaxCmdRN          |
      +---------------+---------------+---------------+---------------+
     4| Length                                                        |
      +---------------+---------------+---------------+---------------+
     8| UpdateRN                      |               0               |
      +---------------------------------------------------------------+

MaxCmdRN: the maximum CmdRN that can be accepted by the client
UpdateRN: the next CmdRN that is expect at the target

Algorithm at initiator to update MaxCmdRN:

The initiator keeps the following state for each session:
   session.maxCmdRN
   session.updateRN

if packet.updateRN > session.updateRN ||
   (packet.updateRN == session.updateRN &&
    packet.maxCmdRN > session.maxCmdRN)
   session.maxCmdRN = packet.maxCmdRN

(all arithmetic is done in sequence space)




Solicit MaxCmdRN

   Byte /     0       |       1       |       2       |       3       |
       /              |               |               |               |
      |7 6 5 4 3 2 1 0|7 6 5 4 3 2 1 0|7 6 5 4 3 2 1 0|7 6 5 4 3 2 1 0|
      +---------------+---------------+---------------+---------------+
     0| Opcode (0x0f) |      0                                        |
      +---------------+---------------+---------------+---------------+
     4| Length                                                        |
      +---------------+---------------+---------------+---------------+

   Used to probe closed windows/get initial MaxCmdRN.


Also, something needs to be said about shrinking windows. Is it allowed?

-Costa








Costa Sapuntzakis <csapuntz@cisco.com> on 29/06/2000 02:23:56

Please respond to Costa Sapuntzakis <csapuntz@cisco.com>

To:   ips@ece.cmu.edu
cc:    (bcc: Julian Satran/Haifa/IBM)

Subject:  16-bit CmdRN too small?






Is 16-bit CmdRN too small?

A 16-bit CmdRN with a sliding window gives you the ability to issue
max 32768 commands simulatenously.

If each of these is an 8K write:

32768 * 8K = 256MB

Which, on a 10GE connection, is about 200ms. If the round-trip time
is greater than 200ms, then the initiator can't fill the pipe.

-Costa