Re: ISCSI: Urgent Flag requirement violates TCP.

[Matt Wakeley <matt_wakeley@agilent.com>]

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