RE: ISCSI: Urgent Flag requirement violates TCP.

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

Venkat,

If you review RFC 2960, you will find the header alignment problem solved.
You will also find a means of providing larger elements than the MSS.
Before you go down the path of modifying TCP to the extent of making it a
datagram protocol, you may wish to review this RFC.  I found it a relatively
complete solution.

Doug

> I am sure this was considered and rejected, but I'm unable to locate a
> previous memo/email, in this long thread, where this has been rejected. I
> apologize if this is reopening something that was already settled.
>
> Is there an alternative to the Urgent Pointer mechanism for framing, where
> TCP implementations can negotiate whether or not they ensure
> iSCSI header to
> be immediately following the TCP header. While generic TCP stacks may not
> have a notion of higher level protocol framing, what are the downsides to
> two iSCSI peers (and their modified TCP stacks) negotiating this?
> Each iSCSI
> PDU is limited to the size of a TCP MSS, and that the sender indicates to
> the receiver (at login) that it guarantees that iSCSI header
> always follows
> TCP header. If a particular sender doesn't indicate this, the TOE
> can still
> work in a memory-constrained mode. This may cause some TCP segments to be
> short of the agreed-upon MSS (wire usage inefficiency), but is this a
> significant loss?
>
> Does the WG operating requirement of "MUST work with existing
> TCP/IP stacks"
> prevent this?
>
> As long as there are no other intermediate entities terminating the TCP
> connection (such as a Layer 4 load balancer), the TCP segment at the
> receiving end would appear in-tact. If a header alignment
> violation is found
> (parse error on iSCSI header), the receiver can revert to the memory
> constrained mode.
>
> Regards,
>
> Venkat Rangan
> Rhapsody Networks Inc.
> www.rhapsodynetworks.com
>
>
>
>