Subject: Re: iSCSI: Marker Intervals

From: "Julian Satran" <[email-masked]>
Date: Thu, 13 Sep 2001 00:29:14 +0300

Barry,

Sorry - even here an interval is not negotiated but it may create
confusion.
I've added a dependency (must appear together). The part in appending
reads:

01   RFMarkInt

   Use: IO
   Who can send: Initiator and Target

   RFMarkInt=<number-from-1-to-65535>[,<number-from-1-to-65535>]

   This is a connection specific parameter.

   The receiver indicates the minimum to maximum interval (in 4-byte words)
   the receiver wants the markers. In case the receiver wants only a
   specific value, only a single value has to be specified. The sender
   selects a value within the minimum and maximum the receiver requires (or
   the only value the receiver requires) or indicates through the FMarker
   key=value its inability to set markers. The interval is measured from
   the end of a marker to the beginning of the next marker. For example, a
   value of 1024 means 1024 words (4096 bytes of "pure" payload between
   markers). Whenever FMarker and RFMarkInt are both sent they MUST appear
   on the same Login Request/Response.

   Default is 2048.

"Barry Reinhold" <[email-masked]> on 11-09-2001 18:27:45

Please respond to "Barry Reinhold" <[email-masked]>

To:   Julian Satran/Haifa/IBM@IBMIL
cc:   "ISCSI" <[email-masked]>
Subject:  iSCSI: Marker Intervals

Ok,
     If there is not a concept of a range how do I handle the syntax of
RFMarkInt as defined in item 20 in appendix D. This syntax is given as:

RFMarkInt=<number-from-1-to-65535>[,<number-from-1-to-65535]

I have assumed an initiator could send something like:

RFMarkInt=1,12

With the semantics being that the marker interval must be between 4 and 48
bytes.

The documentation associated with item 20 indicates that I am supposed to
take a value within this range or signal my inability, through FMarker=no,
to support markers. This negotiation process is pretty open for
disagreements on marker intervals.

It would appear to me that one would be likely to start a negotiation
process by sending
FMarker then following it with RFMarkInt and SFMarkInt. The question still
remains in my mind as to what behavior the spec. wants when RFMarkInt is
not
within the range supported by the sender.

Options:

1. Terminate the login/connection with a code indicating the situation
2. Send another FMarker with FMarker=no or perhaps FMarker=receive

BTW - If marker intervals are "large" the marker can easily point to a PDU
that has been processed. In this case the receiver has to read to the next
marker which may dump a lot of PDUs and probably leave the connection
"stalled". There could be a lot of command PDUs in 8K bytes represented by
the default of 2048. I would be interested in hearing from anyone (either
on
the reflector or in private) who wants to receive markers as to what
intevals they think will be optimal/desired.

>-----Original Message-----
>From: [email-masked] [mailto:[email-masked]]On Behalf Of
>Julian Satran
>Sent: Saturday, September 08, 2001 4:58 AM
>To: Barry Reinhold
>Cc: ISCSI
>Subject: Re: Marker negotiation
>
>
>
>Barry,
>
>I was not aware that we allow ranges - only individual values. The  range
>in the examples are there to indicate a possible range for the value and
>for each key there is a selection rule (usually the lower or higher).
>
>Julo
>
>"Barry Reinhold" <[email-masked]> on 06-09-2001 19:43:54
>
>Please respond to "Barry Reinhold" <[email-masked]>
>
>To:   Julian Satran/Haifa/IBM@IBMIL
>cc:   "ISCSI" <[email-masked]>
>Subject:  Marker negotiation
>
>
>
>Julain,
>     If doing a numerical negotiation - such as for marker intervals - if
a
>range is offered that is not liked what is the responder expected to do?
>Numerical negotiations don't allow for selection of values out of range.
>
>Example:
>
>I -> FMarker=send-receive
>T -> FMarker=send-receive
>I -> RFMarkint=1,12
>T -> doesn't want anything below 1024. What does he do?
>
>Barry Reinhold
>Principal Architect
>Trebia Networks
>[email-masked]
>603-868-5144/603-659-0885/978-929-0830 x138
>
>
>
>