Subject: Re: Marker negotiation

From: "Julian Satran" <[email-masked]>
Date: Sat, 8 Sep 2001 11:58:18 +0300

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

---

From: "Barry Reinhold" <[email-masked]>
Date: Tue, 11 Sep 2001 11:27:45 -0400

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,
>