Re: TCP Framing

["Matt Wakeley" <matt_wakeley@agilent.com>]

David,

Please answer this question:  Can the iSCSI spec *mandate* the use of this new
TSVWG framing RFC in all iSCSI implementations (especially the ones that will
be complete before this new RFC is even published)?

If the answer is "no" then....

As I expressed in my earlier posting, the goal and purpose of framing is to:

1- eliminate the huge amounts of buffering (high speed, expensive, eats up
board space, more expensive than fibre channel) that will be required by 10Gig
implementations, and
2- provide a common feature set so that any (10Gig) implementation will be
able to interoperate with any other iSCSI implementation, be it 1Gig, 10Gig,
HW or SW implementations.

The only way to do this is to *mandate* implementation of some kind of framing
mechanism *IN THE iSCSI SPEC*.

Implementing framing by a TSVWG RFC is great, *if* the iSCSI spec could
*mandate* the implementation of this new RFC.  However, I don't think that
iSCSI will be able to mandate anything about the TCP stack (or its "shim"
layers) [for example, you can't "mandate" that a SW implementation of iSCSI on
Windows NT4 use the new RFC, because it is simply not available].  The *only*
thing that iSCSI can mandate is what is sent over the [generic, unmodified,
unshimmed] TCP connection that iSCSI uses.

In other words, if iSCSI can not mandate modified versions of TCP or
shim/framing/whatever layers,  then in order for a 10Gig implementation to
interoperate with all other iSCSI implementations, it will be required to
implement buffering, which is what we want to avoid in the first place.

The proposal is to *mandate* the *availability* of markers in the iSCSI spec. 
If two communicating nodes do not require framing, then they don't have to use
markers.  If and when TSVWG comes up with a better framing mechanism, then
markers don't have to be invoked.  However, if a node requires markers to
operate optimally, the other node "MUST" be required to supply them.

-Matt Wakeley
Agilent Technologies 

Black_David@emc.com wrote:
> 
> I checked with the TSVWG chairs (our overworked Transport
> Area Directors), and the current state of the TCP framing
> world is that TSVWG expects to advance a slightly
> modified version of the tcpulpframe draft discussed
> in Minneapolis to become an RFC of some form in the
> near future (subject to timely revision by the authors).
> 
> This suggests that making iSCSI markers mandatory may
> not be a wise decision.  We'll need to see the revised
> version of tcpulpframe and understand what the IESG
> does with it before figuring out the right wording
> to deal with it in iSCSI, but this should probably
> be viewed as the default TCP framing mechanism.
> 
> Let me remind everyone that TCP framing drafts get
> discussed on the tsvwg list, *not* here.  I put this
> message up in response to earlier messages expressing
> concern about lack of knowledge about what TSVWG
> intends to do in this area.
> 
> Thanks,
> --David
> 
> ---------------------------------------------------
> David L. Black, Senior Technologist
> EMC Corporation, 42 South St., Hopkinton, MA  01748
> +1 (508) 435-1000 x75140     FAX: +1 (508) 497-8500
> black_david@emc.com       Mobile: +1 (978) 394-7754
> ---------------------------------------------------