Re: iSCSI: Markers

[Jonathan Stone <jonathan@dsg.stanford.edu>]

In message <NMEALCLOIBCHBDHLCMIJEEBKCKAA.somesh_gupta@silverbacksystems.com>,
"Somesh Gupta" writes:


>> Mostly that what you're asking for is no longer TCP.
>> TCP does not preserve record, or packet, or push boundaries.
>
>  Let us not be so religious about it. Everything must evolve.

Somesh,

Nobody is being religious.  You are asking for changes to RFC 1122,
section 4.2.  Perhaps TCP will need that in the fullness of...well,
need it *now*, I guess, but I thought IPS was forbidden to go there.
Or am I mistaken on that?


>  Ok. We do require change to the TCP implementation. I already gave
>  you that.

If you want iSCSI receivers to rely on non-conforming assumptions
about segmentation and upper-level boundaries, then that's a change to
TCP (send policies, retransmit policies, and receiver-to-application
policies about coalescing segments), which are not part of extant TCP
implementations. The necessary changes fly in the face of the `MUST'
requirements on RFC 1122, sec. 4.2, pp 82-83; and also require that
the SHOULD in the `DISCUSSION' of filling become a `MUST NOT'.

I dont see how anyone can claim that's not a change to TCP.

[...]


>  Again, no protocol changes and interoperability with existing
>  implementations is the goal. Even with markers, the receive
>  TCP has to change significantly.

It *is* a protocol change.  Not a change to the on-the-wire format,
true; its a change to the state machines which form user SEND requests
into valid TCP segments, and in how received segments are passed up
to the application.  That's still a change to the protocol.

I dont see any way for a software iSCSI implementation to conform with
what you suggest, in general, without changing the innards of TCP in a
way which (again in general) violates the Host Requirements RFC.

Again, I'm not being doctrinaire about this. I'd use it myself, if I could.