Re: Consensus Call on Urgent Pointer.

["John Hufferd" <hufferd@us.ibm.com>]

Glen,
We need to net it out in English.  Try it in a single paragraph.  This is
not that hard.   The Draft work we do require the use of the Should, May,
etc.  Please try again in an approprate Draft format.  Why don't you start
by modifying the paragraph I used in the consensus call.

"We are saying that the Initiator should agree to send Urgent Pointer
information, and may agree to receive Urgent Pointer data. (same thing in
reverse on the Target side).  It has also been suggested that perhaps the
specification read "The Initiator Should use the Urgent Pointer when
sending data, and May accept it on receiving data."  If any initiator does
not want to use the Urgent Data, it should say so appropriately in the
initial Login.  In this way, since some believe that the biggest impact to
SW will be in the Receive Side, SW implementations may respond Negatively
for Receiving Data, and Positively, (or not at all) for sending Data.  I
would expect certain HW implementations would want to always use Urgent
Pointer and will therefore respond Positively (or not at all) to the
exchange (assuming Positive is the default here)."


.
.
.
John L. Hufferd
Senior Technical Staff Member (STSM)
IBM/SSG San Jose Ca
(408) 256-0403, Tie: 276-0403
Internet address: hufferd@us.ibm.com


Glen Turner <glen.turner@aarnet.edu.au>@ece.cmu.edu on 11/16/2000 10:33:34
PM

Sent by:  owner-ips@ece.cmu.edu


To:   Daniel Smith/Almaden/IBM@IBMUS
cc:   ips@ece.cmu.edu
Subject:  Re: Concensus Call on Urgent Pointer.



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