RE: iSCSI: Markers

["Somesh Gupta" <somesh_gupta@silverbacksystems.com>]

Jim,

What are the issues with "one PDU per TCP segment"? I
think this would really enable simple, high performance
Upper Layer protocol processing over TCP. Of course,
you always have the issue that no matter what method
is used, data can only be placed and not processed
out of sequence (which implies that there is additional
complexity if barrier lists and so on and having to do
control processing at a faster rate when you do perform
out of order processing).

Somesh

> -----Original Message-----
> From: owner-ips@ece.cmu.edu [mailto:owner-ips@ece.cmu.edu]On Behalf Of
> Stephen Bailey
> Sent: Thursday, January 10, 2002 8:24 AM
> To: ips@ece.cmu.edu
> Subject: Re: iSCSI: Markers 
> 
> 
> > If we decided it was the right technique for iSCSI, couldn't we just
> > lift the content and put it in the iSCSI draft?
> 
> >From a standardization standpoint, it's like JohnH said.  iSCSI is not
> chartered to do anything that modifies the transport.  Even if it were
> (which it isn't) the `experimental stigma' of TUF would certainly
> spread to iSCSI if iSCSI ingested TUF in toto.
> 
> The allure of COWS is that iSCSI CAN specify the in-stream format
> without saying anything about TCP segmentation---COWS in-stream format
> solves the same problem as markers.  If iSCSI does that, it's a tiny
> step, for implementations that can take it, to add TUF-compliant TCP
> segmentation & PDU containment processing.
> 
> What would be bad is if the `performance community' (RDMA, iSCSI &
> whomever else) decided that COWS is the best general solution to this
> problem, and iSCSI chose a variant of COWS that didn't work for other
> applications (current & future).
> 
> Basically, the choices, as I see them are:
> 
>   o nothing, FIM, COWS for unmodified senders
>   o key/length or COWS for TUF-compliant senders
> 
> The key questions to make the choices come down to:
> 
>   1) Is PDU containment `worth it'?
>   2) Is resynching in the absence of PDU containment `worth it'?
>   3) Is 0-touch send for software clients `worth it'? 
> 
> Most seem to strongly believe that PDU containment is worth it but
> there are some experienced, noteworthy objectors (e.g. Jim Williams).
> If you don't believe PDU containment is sufficiently beneficial, then
> you simply don't bother with TUF-compliant senders.
> 
> I have no idea what `most' think for 2) & 3), but I can speak for
> myself.
> 
> I don't think resynching in the absence of PDU containment is worth
> it.  That implies that I'd take nothing over FIM.  It also implies
> that I'd take nothing over COWS w/o a TUF sender, except that if the
> TUF sender approach uses COWS, having COWS in-stream is `free'.
> 
> I'm undecided on whether 0-touch send for software clients is `worth
> it'.  If yes, I'd take key/length for a TUF sender.  If no,
> I'd take COWS.
> 
> So the only free variable in my position is whether 0-touch software
> senders are worth it.  I don't have the data (I'm sure you're
> wondering why that's stopping me on this point, and not the others :^)
> If yes, it's `nothing + key/length'.  If no, it's `COWS + COWS'.
> 
> Steph
>