RE: iSCSI: Markers

["John Hufferd" <hufferd@us.ibm.com>]

Folks we can not add TUFs to our iSCSI protocol since it requires TCP/IP
changes.  Our draft says that we WILL NOT work on Modifications to internet
transport protocols,  Hence,  bringing TUFs into our draft is not doable.

I think I made the point about Desktops and laptops on my kick off note,
they use NFS today and think things are fine.  They will accept this in the
future. (Right or Wrong).



.
.
.
John L. Hufferd
Senior Technical Staff Member (STSM)
IBM/SSG San Jose Ca
Main Office (408) 256-0403, Tie: 276-0403,  eFax: (408) 904-4688
Home Office (408) 997-6136, Cell: (408) 499-9702
Internet address: hufferd@us.ibm.com


"Somesh Gupta" <somesh_gupta@silverbacksystems.com>@ece.cmu.edu on
01/09/2002 10:40:17 PM

Please respond to <somesh_gupta@silverbacksystems.com>

Sent by:    owner-ips@ece.cmu.edu


To:    <ips@ece.cmu.edu>
cc:
Subject:    RE: iSCSI: Markers



COWS used in conjunction with "framing" allows for
the "packetization" of TCP, and a lot of good things follow
from that.

COWS and framing allow complete processing of the segment
as a single entity - one PDU, processed in a pipelined
without recursion, and done. Markers enable no such
capability. They actually make things worse by having to
be inserted or removed as extra bytes in the stream.

Markers and CRC interact very poorly since the markers
are part of the data stream, but not part of the CRC.

Markers can only be processed in the context of the
connection state. COWS could actually help locate the
state.

There seem to be two main motivations to push markers

1. laptops and desktops using unchanged TCP/IP stacks
   and running iSCSI.
   a. when do we think customers will really deploy iSCSI
 at desktops/laptops without security and make their
 entire storage vulnerable? If of course, security is
 deployed, then COWS should be minor additional burden
   b. If we have lots of spare cycles, does it matter anyway
   c. even if the first generation does not have the capability,
 the second generation of iSCSI implementation may implement
 the TCP changes required for security - especially if it
 mandatory

2. decide something now and sooner rather than better. Given
   the substantial lack of evidence whether markers are useful
   at all, and the significant promise of COWS/ULP framing,
   I think it would be ill-advised to try to push this one.

I think we should take this as part of our next phase. If
we do want something now, I vote for COWS/ULP. Even if it
is on the experimental track, we can always specify it as
part of iSCSI.

COWS/ULP really allows the cheaper and more widely applicable
adapters that we would all like to see.

Somesh


> -----Original Message-----
> From: owner-ips@ece.cmu.edu [mailto:owner-ips@ece.cmu.edu]On Behalf Of
> Stephen Bailey
> Sent: Wednesday, January 09, 2002 5:25 AM
> To: ips@ece.cmu.edu
> Subject: Re: iSCSI: Markers
>
>
> > assuming iWARP is not an available option
>
> What John is referring to as iWarp is actually `TUF' (TCP ULP
> Framing).  iWarp is a putative RDMA on IP transports protocol, which
> is not what we're talking about.
>
> All the TCP framing proposals we're discussing have:
>
>   1) an in-stream format
>
> To this, TUF adds:
>
>   2) a TCP sender segmentation behavior
>
> The in-stream formats so far are:
>   o fixed-interval markers (FIM)
>   o random key/length headers (TUF's FPDU)
>   o COWS header + marker knockout chain
>
> In addition to Julian's COWS proposal, Costa & I also did one:
>
>   http://www.cs.uchicago.edu/~steph/draft-bailey-tsvwg-cows-00.txt
>
> It's substantially similar to Julian's, with a couple differences:
>
>   o pointers are only forward
>   o payload length is 16-bit length (trivial to make it up to 2^30-1 tho)
>   o payload size is byte-granular
>   o marker is defined a priori (I like Julian's idea of being able
>     to exchange markers if desired---we'd add that)
>
> Our COWS was defined as an alternative to (replacement of) TUF's
> current in-stream format.  Compelling benefits of the COWS in-stream
> format from our standpoint are:
>
>   o the SAME in-stream format is works with or without TCP sender
>     segmentation support
>   o no chance of a false positive from key/length validation
>
> The first point is particularly important.  COWS can be used to
> validate the PDU contaiment property if the TCP sender is
> TUF-compliant, and it can be used for marker-like (better, actually)
> resynchronization if the TCP sender is stock.  Before the COWS
> proposal, we always had two different in-stream representations
> (markers, & key/lengths) for different purposes.
>
> The primary disadvantage of the COWS in-stream format is:
>
>   o prohibits 0-touch software senders
>
> I had suggested that if everybody liked COWS, we would update TUF to
> use it, and even if TUF remains experimental, iSCSI could define the
> same in-stream format for its framing (replacing markers).  That way,
> there would really be only ONE in-stream format in the universe,
> though it might be redundantly defined in two places.
>
> For iSCSI, a single in-stream format that supports both modified and
> stock sender approachs seems nice.  Implementations can easily migrate
> from stock to modified TCP senders (ask one of the authors of the TUF
> draft if you don't understand why modified TCP sender segmentation is
> good).
>
> For the rest of the world it would be nice (essential in my opinion)
> if the same framing technique could be used for iSCSI and other
> protocols (e.g. iWarp).  System vendors that support iSCSI just might
> want to support NAS too, which could mean DAFS (on iWarp).  Chip
> vendors CERTAINLY want to maximize return from their TOE investment
> which means being able support various accelerated protocols with the
> same hardware.  Wouldn't it be stupid if we had a proliferation of
> framing alternatives just because the world originally seemed flat?
>
> The tradeoff of 0-touch versus a single format clearly has powerful
> arguments pulling either way.  I'm personally ambivalent.  Mostly, I
> want to make sure everybody in the iSCSI community is sufficiently
> informed about what's at stake.
>
> Steph
>