Re: Concensus Call on Urgent Pointer.

[Glen Turner <glen.turner@aarnet.edu.au>]

Daniel Smith wrote:
> 
> I'd word it closer to:
> 
> "During login, if the target reqests use of the Urgent Pointer (UP) then
> this should be taken as meaning that the target will operate more
> efficiently when the UP is used.  The initiator should make an effort to use
> the UP.  If it is unable (or unwilling, because of user intervention*) to
> use the UP then it must indicate its non-compliance to the target."

Another approach is to go the pseudo code route, rather than get
bogged down in English.  The MUSTs and SHOULDs complicate matters,
so the result isn't really p-code, but does seem to be reasonably
clear.

I've allowed for a single user "switch" that turns of UP totally
from either the initiator or the target for all sessions.
We need some weasel words that allow a more fine-grained implementation
without removing the user's ability to do away with UP if needed.

TARGET

  T-EFFICIENT-SEND, boolean constant

     the target can efficently send iSCSI protocol data units with the
     TCP Urgent data feature being used to mark protocol data unit
     boundaries.

  T-EFFICIENT-RECEIVE, boolean constant

     the target can efficently receive iSCSI protocol data units with
     the TCP Urgent data feature being used to mark protocol data unit
     boundaries.

  T-URGENT-ALLOWED, boolean global variable, user settable, default true

     the user wishes for the TCP urgent data feature to be used if it
     enhances efficiency

  T-URGENT-SEND, boolean per-session variable

     if true, the TCP urgent data feature SHOULD be used
     for identifying iSCSI protocol data units when sending data

     if false, the TCP urgent data feature MUST NOT be used.

  T-URGENT-RECIEVE-HINT, boolean per-session variable

     if true, the TCP urgent data feature can be expected with
     received data.

     Of course, support for Urgent data is not optional
     with TCP, but this variable MAY be used to implement
     a more efficient handling of this usually rare data.


INITIATOR

And similarly for the initiator we define I-EFFICIENT-SEND,
I-EFFICIENT-RECEIVE, I-WISHES-URGENT, I-URGENT-SEND,
I-URGENT-RECEIVE-HINT.


STATES

  Upon login the initiator MUST

    I-URGENT-SEND <- false
 
  and then SHOULD send

   I-URGENT-RECIEVE-HINT <- false
    if I-URGENT-ALLOWED
      if I-EFFICIENT-SEND
        send message UrgentPointerFromTarget: 1
      endif
      if I-EFFICIENT-RECEIVE
        send message UrgentPointerFromInitiator: 1
      endif
    endif

  The target MUST

     T-URGENT-SEND <- false

  and then SHOULD respond with

    T-URGENT-SEND <- false
    if received message UrgentPointerFromTarget: 1
      if T-URGENT-ALLOWED
        if T-EFFICIENT-SEND
          SHOULD send response UrgentPointerFromTarget: 1
          T-URGENT-SEND <- true
        else
          SHOULD send response UrgentPointerFromTarget: 0
        endif
      else
        MUST send response UrgentPointerFromTarget: 0
      endif
    endif

    T-URGENT-RECEIVE-HINT <- false
    if received message UrgentPointerFromInitiator: 1
      if T-URGENT-ALLOWED
        if T-EFFICIENT-RECEIVE
          SHOULD send response UrgentPointerFromInitiator: 1
          T-URGENT-RECIEVE-HINT <- true
        else
          SHOULD send response UrgentPointerFromInitiator: 0
        endif
      else
          MUST send response UrgentPointerFromInitiator: 0
      endif
    endif

  The initiator then SHOULD set

    if received response UrgentPointerFromInitiator: 1
      I-URGENT-SEND <- true
    endif
    if received response UrgentPointerFromInitiator: 0
      I-URGENT-SEND <- false
    endif
    if recieved response UrgentPointerFromTarget: 1
      I-URGENT-RECEIVE-HINT <- true
    endif
    if recieved response UrgentPointerFromTarget: 0
      I-URGENT-RECIEVE-HINT <- false
    endif

    if not I-URGENT-ALLOWED and I-URGENT-SEND
      SHOULD Log protocol error
    endif
    if not I-URGENT-ALLOWED and I-URGENT-RECEIVE-HINT
      SHOULD Log protocol error
    endif

The initiator SHOULD use the TCP urgent data pointer feature to
mark iSCSI PDU boundaries if I-URGENT-SEND is true.  It MUST
wait until the login process has completed before doing so.

Similarly, the target SHOULD use the TCP urgent data pointer
feature to mark iSCSI PDU boundaries if T-URGENT-SEND is
true. It MUST wait until the login process has completed
before doing so.

The robustness principle applies to received data.  Initiators
and targets MUST allow TCP segments containing iSCSI PDUs
delimited with the TCP Urgent Data feature to be correctly
processed regardless of the value of I-URGENT-RECEIVE-HINT and
T-URGENT-RECEIVE-HINT respectively.  However, initiators
and targets SHOULD record the session details and number
of occurances of this protocol violation.


-- 
 Glen Turner                                 Network Engineer
 (08) 8303 3936      Australian Academic and Research Network
 glen.turner@aarnet.edu.au          http://www.aarnet.edu.au/
--
 The revolution will not be televised, it will be digitised