RE: ISCSI: Urgent Flag requirement violates TCP.

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

Matt,

Revise the iSCSI proposal to reflect normal TCP behavior if using the urgent
flag at the very least or it is also modifying the TCP sender.  It is
unlikely nominal operation provides results indicated in the iSCSI proposal.

As this required atypical use of TCP is only beneficial with a modified TCP
receiver and as it slows a standard TCP implementation with extra sends and
pointer operations, complete this proposal by documenting the API for this
modified TCP receiver implementation.  TCP is not a wire specification.  The
iSCSI urgent pointer proposal is modifying the TCP receiver, even as an
option, and there is a larger responsibility in creating an adapter
interface that conforms to this protocol more than one company presumably
will be using.  Such an API should include a means of notifying the adapter
which port will operate according to iSCSI UPRM-TCP as a minimal requirement
as this protocol provides no outward notification.

Your replacement for RFC 2960 will get lost in the woods should it be used
on the wrong port or with the wrong encapsulation.  Without this effort,
each implementation of this TCP modification will be unique with respect to
the adapter interface and that is not likely acceptable as these adapters
will still be used for other network traffic.  This major innovation
singularly benefits but one version of iSCSI.

Should there be a TCP implementation that does not conform to pointer
expectations as most machines do not actually point to byte locations, and
as some vendors may wish to not burden their standard TCP, provide a means
to allow this feature to remain optional.  Should this concept prove
problematic, then there would be an alternative path without the burden.

Doug

> Doug,
>
> When are you going to get it... we are not modifying TCP at all!
> The use of urgent data is already provided for in TCP, and its API.
> We are simply making use of a rarely used feature in TCP.
>
> Sorry if using an existing feature of TCP removes a reason for
> using RFC 2960.
>
> Douglas Otis wrote:
>
> > Matt,
> >
> > Will all TCP implementations need to be decertified if not
> complying to TCP
> > record marking pointer expectations for all machine architectures?
>
> I don't know what you are trying to say.  The urgent field is
> defined in the TCP
> header, and TCP defines how the data in each field is
> interpretted (network byte
> order).  This field points to an offset in the TCP stream where
> the urgent data
> byte is.
>
> >  Will
> > accelerated NIC adapter companies be required to service an
> urgent pointer
> > record marking TCP protocol in a singular fashion?  There is more being
> > networked than just SCSI but this technique is useful only with unique
> > processing of each transport and this exceptional handling will
> degrade the
> > standard case.  There is nothing that could identify this urgent pointer
> > convention within the transport to indicate the need for this special
> > treatment making the issue even more complex.  Modification of
> TCP becomes a
> > setback to standardization.  Such a modification of TCP must
> not be the goal
> > of this WG.
> >
> > As the alternative, RFC 2960 is generalized and allows for the record
> > marking feature for all transports which is being attempted with this
> > specialized record marking TCP.  The RFC 2960 protocol allows
> all transports
> > to share this and many other  benefits while using either hardware or
> > software acceleration without special case handling or
> degradation.  This WG
> > should care about standardization of network protocols.  To make these
> > modifications to TCP, first document how the API for TCP will change so
> > vendors can make interchangeable devices.  Or is that also a don't care?
> > TCP is not just a wire standard as you indicate.
> > Urgent-Pointer-Record-Marking-TCP or just UPRM-TCP needs further
> > documentation if it is pursued, however I urge its deletion from the
> > proposal.
> >
> > Doug
> >
> > > Douglas Otis wrote:
> > >
> > > > David, Matt,
> > > >
> > > > The use of the urgent flag actually slows a normal TCP
> stack in both the
> > > > added single byte send and the added execution for handling
> the urgent
> > > > pointer.
> > >
> > > So? iSCSI is meant/targetted to be deployed using accelerated
> > > solutions. The
> > > performance of older generation stacks is a don't care.
> > >
> > > >  In addition to differences in interpretation, there may also be
> > > > byte position errors due to machine pointer alignments.
> > >
> > > This makes no sense at all.
> > >
> > > > As the urgent
> > > > pointer was never intended as a record pointer nor is the
> > > position of the
> > > > pointer directly passed to the application, such errors easily
> > > go unnoticed
> > > > just as differences between stacks.
> > > >
> > > > Your practical use for this flag would be to implement
> non-standard TCP
> > >
> > > > designed specifically to locate a record mark useful to software
> > > > specifically designed to interpret SCSI transport which could
> > > not be used
> > > > for standard TCP streams.  By making this urgent flag use a
> > > Must, you are
> > > > benefiting designs using the modified TCP while standard TCP
> > > implementations
> > > > suffer degraded performance as a result.
> > >
> > > Refer to my first comment.
> > >
> > > >
> > > >
> > > > The practical use of this feature would be to add a running
> > > list of record
> > > > positions that may point to the being of some records.  Should
> > > there be a
> > > > lost TCP segment, data transfers contained in the following
> > > segments could
> > > > be placed within application space pending recovery of the
> > > missing segment.
> > > > Status messages would be held but data, which should occupy
> the greatest
> > > > volume, could be stored without double buffering during the
> > > segment recovery
> > > > period.  A noble goal but only possible with very non-standard TCP
> > > > implementations.
> > >
> > > Yeah, so?
> > >
> > > >
> > > >
> > > > As there would be no way to identify the use of this feature in
> > > the general
> > > > sense, you will be making a royal mess for those wishing to
> > > make dedicated
> > > > hardware to accelerate "standard" protocols.
> > >
> > > Hold it! No one said anything about "modifying" the
> "behavior" of TCP.  As
> > > viewed from outside the box, the TCP works just as it is defined
> > > to work today.
> > > How it is implemented inside the box is *NOT* "standardized".  If
> > > you want to
> > > build your TCP with software and I want to  build it with
> > > hardware, it doesn't
> > > matter.  The standard defines the behavior as seen from
> outside the box.
> > >
> > > If you want to build your iSCSI using your existing (somewhat
> standardized
> > > sockets) software interface, fine you can do it.  If I want to
> > > make a hardware
> > > accelerated version that has a "different" interface between
> > > iSCSI and TCP, I
> > > can do it.  Like I said, the "standards" only dictate the
> > > behavior as seen from
> > > outside the implementation, not how it is implemented inside.
> > >
> > > >  As the charter for this WG is
> > > > to avoid modifying TCP, why make the use of a standard TCP
> transport a
> > > > handicap or to muddy the waters for those wishing to make standard
> > > > accelerated hardware?
> > > >
> > > > Doug
> > >
> > > -Matt Wakeley
> > > Agilent Technologies
> > >
>
>