Subject: RE: iSCSI Markers

From: "Glenn Dasmalchi" <[email-masked]>
Date: Thu, 10 Jan 2002 09:30:49 -0800

> -----Original Message-----
> From: John Hufferd [mailto:[email-masked]]
> Sent: Thursday, January 10, 2002 1:27 AM
> To: [email-masked]
> Subject: iSCSI Markers
>  
> I see no relationship to COWS, except both have an 8 byte 
> header.   If you
> have TUFs, you do not need to have Word Stuffing.  The 
> problem with COWS is
> not is header it is the Word Stuffing and the Replacement Pointers.
> 
The random key marker approach in the TUF draft has a non-zero
probability of generating a "false positive" in theory (requires
resegmenting middle boxes + aliased data + exact length resegmentation,
etc.). Personally I think the probability is so low as to not be a
consideration, but a COWS approach using TUF-style segmentation does
address the issue.

The point about the iSCSI charter is interesting, do others feel that
the segmentation requirements for TUF/PDU Alignment disqualify it from
consideration for iSCSI?

-Glenn

---

From: Mark Bakke <[email-masked]>
Date: Thu, 10 Jan 2002 11:47:40 -0600

Glenn-

I agree that TUF is a better solution for iSCSI, and do
not believe that either TUF or Markers are needed for this
first version of the iSCSI protocol.

I believe that the best solution so far for iSCSI framing is
in TUF/PDU Alignment or to use another message protocol instead
of TCP.  Adding markers using either method is not usable by
any other application than iSCSI, and adds some demands on
implementations that can not make use of it anyway.

Regardless of whether it is standard, TUF is not that hard
to do, and it's what we should be doing.  Without a more
general solution like TUF, TCP will start running out of gas
for other applications as well as iSCSI, and we will have to
go look at other protocols instead when we get to 10G and
beyond.  I don't think that modifications to the usage of
TCP are outside the scope of what iSCSI should influence.  We
clearly can't just do the work ourselves in a bubble, since
that's not our charter.  But we can certainly influence other
high-bandwidth TCP users to help come up with good, general
solutions.  I don't think that the cost/performance problems
that markers are trying to solve really exist today.  We can
deal with the performance issues at the expense of more
memory on NIC cards, or by doing scatter-gather on storage
devices and gateways.  It just costs a little more.  As the
market for iSCSI stuff develops, and costs have to go down,
we can address this by doing the right solution, which I
do not believe involved markers.  iSCSI is not the only
protocol that is used to carry data on a network.  NFS, CIFS,
DAFS, FTP, HTTP, and others carry far more data than iSCSI.
If we don't solve the problems for these as well, our NIC
offload cards will eventually have to have "special" code
for each one of these, which may end up being just as
expensive than adding some memory.

I personally think that there is no reason to mandate markers
or framing of any kind in this iSCSI RFC.  We are just not
ready, and we already have enough things (security) that are
mandated that will not be part of most implementations anyway.
We are just not ready for the real solution yet.

Those who wish to use markers for the time being should
certainly do so, but we must not (oops, should have said
that in caps :-) mandate their implementation and use.
If markers stay in the draft in either form, they should
remain optional.

Just my opinions,

Mark

-- 
Mark A. Bakke
Cisco Systems
[email-masked]
763.398.1054

---

From: Stephen Bailey <[email-masked]>
Date: Thu, 10 Jan 2002 14:22:24 -0500

Glenn,

> the segmentation requirements for TUF/PDU Alignment disqualify it from

Just to be pedantically clear, nothing stops the IPS WG from
`considering' (the use of) solutions developed elsewhere (e.g. tsvwg).
What IPS is prohibited from is specifying ITS OWN transport
modifications.

I have understood this to mean (David can probably correct me, and
probably will :^) iSCSI could specify a way to negotiate the use of
TUF, but can't say anything about MAY, or MUSTs of its use.  An RFC
can not normatively reference one lower on the track (experimental <
proposed standard < draft standard < standard).

Extending into the realm of complete guesswork, I imagine that even if
iSCSI couldn't reference TUF AT ALL, it would probably be pretty easy
to produce an IRFC (or another XRFC?) that defined the use of TUF with
iSCSI.  Certainly writing the draft would be easy, I'm less clear how
it might progress to RFC status.

Steph

---

From: Mark Bakke <[email-masked]>
Date: Thu, 10 Jan 2002 13:19:35 -0600

Steph-

I think that your approach of writing a separate RFC would be the
best way to document any framing method for iSCSI (including the
use of markers).  It's clean, separable, and doesn't get in the
way of getting the protocol itself done, which seems to be the most
important thing right now.  Best of all, if one method doesn't work
or is not adopted, it doesn't clutter the iSCSI specification for
all time.

--
Mark

-- 
Mark A. Bakke
Cisco Systems
[email-masked]
763.398.1054