RE: ISCSI: More on Urgent pointer

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

David,

There are two cases here.  One where the iSCSI proposal is repaired to
reflect normal operation of TCP and another case where the present proposal
stands as written.  As written, there is an expectation of there being a
record mark for every TCP segment that contains the beginning of the first
PDU as denoted by:

  "The result is the TCP urgent pointer will point to the first byte
  of the iSCSI message in the TCP segment."

The wording should be changed to:

  If the urgent pointer option is used, the result is the TCP urgent
  pointer MAY point to the first or second byte of the last PDU
  contained within the segment.  For this to occur, single byte sends
  flagged urgent of the first byte of every PDU must be made.

As you have indicated, the first PDU is not possible without violating TCP
even if within the segment, it would be the last and not the first PDU
receiving the pointer.  At the very least, as you have indicated, the word
"will" must be changed to "may" together with this clarification of which
PDU and byte receives the pointer and how the urgent pointer was flagged.

This 16 bit urgent pointer offset is determined from a single variable.  In
my view, the accuracy of this variable to an offset conversion is in
question together with TCP option handling or other factors not fully tested
to assure a level of reliability required for use of this TCP feature as a
record mark never required if used as intended as an urgent data pointer.
The accuracy of this pointer is paramount if used as a means to facilitate
data placement following a lost segment.  Already there must be extra
operations to facilitate a pointer to the first or last octet of urgent
data.

Although the PSH flag has often been explicitly rejected for use as a record
mark within several RFCs, the urgent pointer has not been given this
explicit treatment.  I suspect a reason for this obvious omission.  Does the
urgent pointer offset from the end of the TCP header accurately if the
option field is used?  In other words is the option length or data offset or
just the typical header length used to calculate the urgent offset in every
case.  As as silly side note, with a required use of the urgent pointer,
jumbo frames can never exceed 65536 in length if containing a PDU beyond
this range.

With a long history of RPC using a header to determine a record mark, the
urgent pointer has not acted as an alternative.  As urgent pointer accuracy
is an unknown, there should be a means to disable this feature should it be
found not to work for a particular implementation at least.  Should the
urgent pointer be used as an "occasional" record mark, its use should be
fully documented with a modified iSCSI-TCP API.  The same level of
documentation should also be afforded connection allegiance for iSCSI
recovery.  A protocol does not end with the wire.  Also, as there is limited
flow control to each target, additional connections to add flow control
resolution will assure there is no long fat pipes demanding this record
marking feature anyway.

Doug



> The discussion on where the Urgent pointer points has
> been oversimplified.  Returning to Silvano's question:
>
> >  if Command A and Command B are transmitted in the same
> > segment, do you care to specify if the urgent pointer points to the
> > first or second command?
>
> The Urgent pointer will definitely not point to the first
> command because both commands are in the same segment and
> the Urgent pointer is coalesced by the sending TCP.  It
> might point to the second command, or it might point to
> a command in a future segment that has not arrived (if the
> future command was queued before the segment containing
> A and B was sent).  iSCSI cannot be any more specific
> than this, because to do so (e.g., always require the
> Urgent pointer to point within the segment or to the
> first command within the segment) would violate RFC 793.
>
> I think Matt and Doug are talking past each other in part
> by assigning different meanings to the term "record mark".
> Doug appears to be using the term "record mark" to refer
> to something that marks every record boundary between
> SCSI commands, allowing any command to be recovered from
> any point in the stream based solely on knowing where its
> "record mark" is.  The Urgent pointer cannot do this (e.g.,
> the above paragraphs describe a counter-example with two
> record boundaries and only one Urgent pointer).  Matt seems
> to have used the term "record mark" to refer to something
> that marks a record boundary somewhere (in the hope that
> his implementation will find the boundary to be useful).
>
> I will again note that concrete indications from implementers
> of how much of a difference this makes in specific scenarios
> and how often those scenarios occur/can be expected to occur
> would be useful.
>
> 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
> ---------------------------------------------------
>
>