Subject: TCP Framing

From: [email-masked]
Date: Wed, 16 May 2001 22:33:53 -0400

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
[email-masked]       Mobile: +1 (978) 394-7754
---------------------------------------------------

---

From: "Matt Wakeley" <[email-masked]>
Date: Wed, 16 May 2001 22:41:29 -0700

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