RE: iSCSI Data Integrity - Digests

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

Y.P.

<snip>
> > The urgent pointer has a defined behavior within RFC documentation
> > such that to define it as a record boundary is not in keeping
> > with standards.  To implement and use an urgent pointer as a record
> > boundary pointer clearly modifies the TCP standard.
>
> Very interesting argument.  Urgent pointer is meant to be a inband signal
> that can be used for any particular purpose a user has in mind.  Saying
> urgent pointer as a marker for a record or a message being a
> modification of
> TCP standard, IMHO, is definitely a stretch.  However, I yield
> the debate to
> the TCP gurus.

The urgent pointer marks urgent data and must coalesce to include additional
urgent data.  To use the urgent pointer to mark boundaries in close
proximity, as close as the next segment as you described, then you will be
required to modify TCP to not coalesce.  Starving send will not be conducive
to accelerated use and not coalescing the pointer is a violation of the TCP
standard.  Both TCP send and receive coalesce.  Yes, the urgent pointer is
an inband signal but with these clearly defined limitations.  These
limitations make it impractical for use as a record marker and likely to
thwart TCP Offload Engines as it also requires unique data handling.  The
urgent pointer is not a general purpose marker.  Its devised use is to
expedite and only requires a single variable.  You are attempting to expand
use of the urgent pointer to encompass a greatly revised definition
requiring an attribute reserved for every message unit up to one per
segment.  It is definitely a stretch to consider this not a modification of
the TCP standard, IMO.

Doug