RE: iSCSI: Towards Urgent Pointer Consensus

["Douglas Otis" <dotis@sanlight.net>]

David,

In the latest draft (pg 13) of iSCSI the following statement redefines TCP:

  "The result is that there WILL be a TCP segment with a valid
  TCP pointer (urgent flag set) pointing to the FIRST byte of an iSCSI
  message IN the TCP segment."

Capitalization was added for emphasis.  The TCP specification clearly
indicates use of a single Urgent Pointer variable.  By mandating pointer
placement within the TCP segment, the iSCSI proposal seeks to redefine TCP.
Second, the 'first' byte is not an accurate statement and is intentionally
vague to be misleading as to which PDU will be marked.

At the least, strike this sentence.  If this proposal seeks to not redefine
TCP then there is no need to specify TCP behavior.  This proposal has yet to
document an API that can take advantage of this required and likely
problematic Urgent Pointer Record Marking.  As this mechanism is likely to
be problematic and the API has yet to be provided, the entire option should
be removed.  Requiring dramatically different data handling without any
means to identify whether this option is in use will be to the detriment of
those making adapters.  The WG may wish to continue discussion as to whether
the use of flagging the first byte of each PDU as urgent should be a SHOULD,
but until there is a complete proposal that includes the API, this seem
premature.

Doug

> With my WG co-chair hat on, and in an attempt to
> make progress towards consensus on this.
>
> The only text that seems to have a chance of gaining
> rough consensus on the list is Daniel Smith's:
>
>   "During login, if the target requests 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."
>
> and likewise for target sending to the initiator,
> although I would substitute "SHOULD" for "should
> make an effort to", and change "must indicate its
> non-compliance" to "MUST indicate its inability".
>
> In other words for each sender-receiver pair
> (initiator sending to target and v.v.), the sender
> SHOULD implement Urgent support, and the receiver MAY
> choose to request use of it via a negotiation
> mechanism that gets both sides to agree on use
> or non-use of the mechanism.
>
> [NB: For those not familiar with this area
> of IETF lingo, in general any use of MUST,
> SHALL, SHOULD, MAY, OPTIONAL, RECOMMENDED,
> REQUIRED, MUST NOT, SHALL NOT, or SHOULD NOT
> as capitalized words intends the meanings
> defined in RFC 2119.  This is always the
> case in standards track RFCs, and is a
> common email convention.  Please see
> RFC 2119 for a complete explanation.]
>
> I understand that there are people on the list who
> want to see MUST used to require implementation and/or
> use of Urgent support.  That is unlikely to happen
> for two reasons:
>
> (1) The WG rough consensus on the list still rejects
> 	this position.  From a consensus standpoint, if
> 	a sufficient set of people want to insist on
> 	MUST, we'll have to take this issue to San Diego.
>
> (2) Based on the discussion to date, the advocates
> 	of the Urgent mechanism have not met the
> 	burden required by RFC 2119 to use MUST.
> 	Section 6 of RFC 2119 says:
>
>    Imperatives of the type defined in this memo must be used with care
>    and sparingly.  In particular, they MUST only be used where it is
>    actually required for interoperation or to limit behavior which has
>    potential for causing harm (e.g., limiting retransmissions)  For
>    example, they must not be used to try to impose a particular method
>    on implementors where the method is not required for
>    interoperability.
>
> 	I think a fair characterization of the discussion to
> 	date is that the Urgent mechanism is a potentially
> 	important optimization for a certain class of
> 	implementations.  This falls significantly short of
> 	the RFC-2119 criteria for MUST.
>
> 	Unless something changes, I don't see how your WG chairs
> 	are going to be able to defend MUST to the ADs and IESG,
> 	and in practice, we'll probably have our work cut out for
> 	us defending the SHOULD in Daniel's text.
>
> Beyond this, I have a couple of remarks about the
> conduct of the discussion:
>
> - I want to specifically thank and encourage Randall
> 	Stewart and Dick Gahan for working through some
> 	of the details of how well the mechanism is
> 	likely to work and what's at stake in specific
> 	situations.  This sort of detailed analysis is
> 	useful in illuminating the value/utility of
> 	proposed mechanisms such as this one.
> - On the other hand, I want to discourage general
> 	"end of the world"-ish pronouncements that
> 	iSCSI will "fail" in some sense if this or that
> 	isn't done precisely as the poster wants.
> 	Such messages are not helpful, and should be
> 	cut down to the technical points that the
> 	sender wishes to contribute to the discussion.
>
> This is not a consensus call, yet, but rather a
> summary of status and hopefully a hint or two about
> what it'll take to get to consensus.
>
> Thanks,
> --David
>
> ---------------------------------------------------
> David L. Black, Senior Technologist
> EMC Corporation, 42 South St., Hopkinton, MA  01748
> +1 (508) 435-1000 x75140     FAX: +1 (508) 497-8500
> black_david@emc.com       Mobile: +1 (978) 394-7754
> ---------------------------------------------------
>
>